A few people have sent me e-mails looking to know how to change the Home Page that users see when logging into the ITIM Management screen.
This is pretty easy although not that obvious how to do it. A colleague of mine Scott Hammons and I were talking about it this morning and we decided to throw up a few screen shots with instructions on Scotts blog. If your interested, here is the link to the instructions:
http://scottswebblog.blogspot.com/2007/06/how-to-change-default-page-in-itim-46.html
Thursday, June 28, 2007
Tuesday, June 26, 2007
Anybody searching for Passlogix?
OK, I have not worked with the TAM ESSO product for very long, but what seems to be quite common when deploying it is having to install, uninstall, and re-install the product a few times as you blow up your test systems trying out templates and MSI files. What is the deal with software that does not uninstall completely?
Every time you uninstall TAM ESSO, you have to go into the Registry and search all over for "passlogix" and delete all these keys manually. You would think by now that someone would get something right with this Windows OS.
Every time you uninstall TAM ESSO, you have to go into the Registry and search all over for "passlogix" and delete all these keys manually. You would think by now that someone would get something right with this Windows OS.
Stand-Alone configuration for TAM ESSO
I recently have been doing some work with TAM ESSO. Pretty cool product from Passlogix. The idea is that if you have many applications that users have to remember names and passwords for both client/server, web apps and even terminal applications you can use TAM ESSO to manage the user credentials for each of those apps. When you login to Windows, you must also login to TAM ESSO. TAM will detect when you attempt to access an application that requires a name and password and will login for your so that you are not prompted. Administrators can build templates for all the corporate apps and deploy these templates on an Active Directory Server. AD group membership can then be used to control who has access to which templates.
One of the problems I encountered early this week was in trying to deploy the TAM ESSO client stand alone while including the templates for applications in the stand alone client. The documentation is not very clear on a lot of things including this one so I figured I would go ahead and mention what I had to do.
First I had created templates for 3 applications (Web, Client/Server, and Terminal). Next, you need to click on Global Agent Settings and if you haven't already done so, Import from Live HKLM. Next, open the End-User Experience -> Environment key and select the check box for Location of entlist.ini file. Specify the path to the file including the file name. The default is:
C:\Program Files\Passlogix\v-GO SSO\Plugin\LogonMgr\entlist.ini

There are numerous settings that can be controlled here so make any other settings you desire to be packaged in the distributions MSI.
Next, to create the MSI click Tools -> Generate Customized MSI. Complete the fields similar to the following screen shot:

The BASE MSI file should be stored in the location where you extracted the TAM ESSO binaries. You can store your target MSI where you prefer. Obviously if you want applications templates to be included in the MSI then you will want to add the ones necessary for your purposes. The one part that I was not aware of until working with some other TAM folks was the Global Agent Settings. This must be done in order for the application template show up in the client agent. Once you click OK, your distribution MSI is complete.
This is definitely not one of the more complex areas of working with TAM ESSO, but it was a bit annoying when the documentation did not seem to spend much time on a stand-alone implementation. For folks who just simply want to try it out to get an idea how it works, there will not necessarily be an AD server or even ADAM for that matter.h
One of the problems I encountered early this week was in trying to deploy the TAM ESSO client stand alone while including the templates for applications in the stand alone client. The documentation is not very clear on a lot of things including this one so I figured I would go ahead and mention what I had to do.
First I had created templates for 3 applications (Web, Client/Server, and Terminal). Next, you need to click on Global Agent Settings and if you haven't already done so, Import from Live HKLM. Next, open the End-User Experience -> Environment key and select the check box for Location of entlist.ini file. Specify the path to the file including the file name. The default is:
C:\Program Files\Passlogix\v-GO SSO\Plugin\LogonMgr\entlist.ini

There are numerous settings that can be controlled here so make any other settings you desire to be packaged in the distributions MSI.
Next, to create the MSI click Tools -> Generate Customized MSI. Complete the fields similar to the following screen shot:

The BASE MSI file should be stored in the location where you extracted the TAM ESSO binaries. You can store your target MSI where you prefer. Obviously if you want applications templates to be included in the MSI then you will want to add the ones necessary for your purposes. The one part that I was not aware of until working with some other TAM folks was the Global Agent Settings. This must be done in order for the application template show up in the client agent. Once you click OK, your distribution MSI is complete.
This is definitely not one of the more complex areas of working with TAM ESSO, but it was a bit annoying when the documentation did not seem to spend much time on a stand-alone implementation. For folks who just simply want to try it out to get an idea how it works, there will not necessarily be an AD server or even ADAM for that matter.h
Monday, June 11, 2007
Time Flys when you're busy
The last time I posted here was April 20. So what the heck have I been doing since then? I guess piling up a long list of things to blog about. So here's what I've been up to:
1.) Implementing the Notes Adapter for ITIM
2.) Implement new ITIM Self Care App and configure SSO with TAMeB
3.) Implementing the AD Adapter for ITIM
4.) SSO Between TAM WebSEAL, WebSphere Portal, and Domino (TAI++ vs LTPA)
5.) Attended a handful of sales engagements between NY and Boston
6.) Install and Test TAM eSSO
7.) Implement TIM in a High Availability configuration using WAS Network Deployment and HACMP clustering with AIX.
8.) Work on TAMeB WebSEAL Clustering and HACMP clustering for TAMeB
9.) Implement TIM Self Registration app from ITIM Examples.
10.) Pass the ITIM 4.6 Certification Exam
What I aim to do is post some more detail about these experiences in the coming weeks. It's tough when you spend most evenings actually working. The blog always takes a back seat. Also, now that the weather is nice here in Buffalo, I have to take advantage of that and cross off all the items on the "honey do" list. I just had a large patio poured behind my house. It's nice, but I've had to spend the last two weekends landscaping it. I figure maybe two more weekends before I'm done. I can't seem to convince my wife that I should be keeping my blog up to date instead of landscaping.
Anyhow, more on these topics later!
1.) Implementing the Notes Adapter for ITIM
2.) Implement new ITIM Self Care App and configure SSO with TAMeB
3.) Implementing the AD Adapter for ITIM
4.) SSO Between TAM WebSEAL, WebSphere Portal, and Domino (TAI++ vs LTPA)
5.) Attended a handful of sales engagements between NY and Boston
6.) Install and Test TAM eSSO
7.) Implement TIM in a High Availability configuration using WAS Network Deployment and HACMP clustering with AIX.
8.) Work on TAMeB WebSEAL Clustering and HACMP clustering for TAMeB
9.) Implement TIM Self Registration app from ITIM Examples.
10.) Pass the ITIM 4.6 Certification Exam
What I aim to do is post some more detail about these experiences in the coming weeks. It's tough when you spend most evenings actually working. The blog always takes a back seat. Also, now that the weather is nice here in Buffalo, I have to take advantage of that and cross off all the items on the "honey do" list. I just had a large patio poured behind my house. It's nice, but I've had to spend the last two weekends landscaping it. I figure maybe two more weekends before I'm done. I can't seem to convince my wife that I should be keeping my blog up to date instead of landscaping.
Anyhow, more on these topics later!
Friday, April 20, 2007
TIM AD Password Sync Plug-in
If your considering using the PwdSync plug-in to sync passwords from AD into TIM there are a few things you need to consider. For one thing this is an all of nothing option. All accounts that ITIM manages will be included when you use the AD Password Sync plug-in. So it is important that there are no systems being managed by ITIM which more restrictive password policies than your AD password policy. Otherwise users in AD will set their password to something that passes the AD checks and fails when ITIM tries to sync that password to other systems. The problem is that the user will not know about the failure which will cause more help desk calls.
Also, an important point is that SSL is required for this to work. You will need to export a cert from your TIM server and import it into the PwdSync plug-in. My downloads page contains a detailed document that I typed up with screen shots explaining a but more about these issues that I found not very clear in the install guide. Feel free to check it out. Hopefully it will help to save someone some time.
Downloads {Link}
Also, an important point is that SSL is required for this to work. You will need to export a cert from your TIM server and import it into the PwdSync plug-in. My downloads page contains a detailed document that I typed up with screen shots explaining a but more about these issues that I found not very clear in the install guide. Feel free to check it out. Hopefully it will help to save someone some time.
Downloads {Link}
Tuesday, April 17, 2007
TIM and AD Integration - Group Membership in provisioning
Just as a follow up to my earlier post about the AD Adapter, I figured out how to provision users into the proper groups in AD. What I eventually figured out is that you can't simply type the names of the groups into the advanced provisioning parameters. The adapter is expecting to pass the GUID of those groups through to AD. This GUID needs to be looked up in TIM. So let me take a step back here.
When you get the AD adapter installed and configured the first time you recon the AD all the groups from your AD will be imported into the TIM LDAP in the container defined for the AD Service you created. If you export one of these group objects from the TIM LDAP it would look something like my AD Domain Users group here:
dn: eradgroupguid=5fcbe38c66d1f343b7572848a642a8e9, erglobalid=77847836466036
35175, ou=services, erglobalid=00000000000000000000, ou=CA, dc=ca,dc=com
eradgroupguid: 5fcbe38c66d1f343b7572848a642a8e9
objectclass: erADGroup
objectclass: erManagedItem
objectclass: top
description: All domain users
eradprimarygrptkn: 513
eradgroupcn: Domain Users
eradgroupdn: CN=Domain Users,CN=Users,DC=CA,DC=local
So on the entitlement -> Advanced Provisioning Parameters you will need to add some JavaScript which will look up the GUID for the group or groups you want your user to belong to when provisioned to AD. Also, the Primary Group uses a Token represented in TIM by the eradprimarygrprkn attribute. One way to cheat here is to use the standard view of the provisioning parameters and use the search button to find the groups you want. Then switch to the advanced provisioning parameters view and you will see the GUIDs for the groups you chose:

Click on the screen shot to see a larger view.
The installation and configuration guide mentions that you can set certain Windows registry keys that will change the behavior of the adapter. One of these options is the useGroupCN setting. If you set this to true then you can reference the common name of the group in your provisioning parameters. This option may make it a bit easier for scripting.
I'm still having some issues with the Home Directory behavior, but I think the key to that is also in part how I set these registry configurations in the AD adapter. So far though, I have the AD adapter working pretty well in my sandbox system.
When you get the AD adapter installed and configured the first time you recon the AD all the groups from your AD will be imported into the TIM LDAP in the container defined for the AD Service you created. If you export one of these group objects from the TIM LDAP it would look something like my AD Domain Users group here:
dn: eradgroupguid=5fcbe38c66d1f343b7572848a642a8e9, erglobalid=77847836466036
35175, ou=services, erglobalid=00000000000000000000, ou=CA, dc=ca,dc=com
eradgroupguid: 5fcbe38c66d1f343b7572848a642a8e9
objectclass: erADGroup
objectclass: erManagedItem
objectclass: top
description: All domain users
eradprimarygrptkn: 513
eradgroupcn: Domain Users
eradgroupdn: CN=Domain Users,CN=Users,DC=CA,DC=local
So on the entitlement -> Advanced Provisioning Parameters you will need to add some JavaScript which will look up the GUID for the group or groups you want your user to belong to when provisioned to AD. Also, the Primary Group uses a Token represented in TIM by the eradprimarygrprkn attribute. One way to cheat here is to use the standard view of the provisioning parameters and use the search button to find the groups you want. Then switch to the advanced provisioning parameters view and you will see the GUIDs for the groups you chose:

Click on the screen shot to see a larger view.
The installation and configuration guide mentions that you can set certain Windows registry keys that will change the behavior of the adapter. One of these options is the useGroupCN setting. If you set this to true then you can reference the common name of the group in your provisioning parameters. This option may make it a bit easier for scripting.
I'm still having some issues with the Home Directory behavior, but I think the key to that is also in part how I set these registry configurations in the AD adapter. So far though, I have the AD adapter working pretty well in my sandbox system.
Monday, April 16, 2007
Anyone out there ever Integrated Novell with TAM?
Novell has for a long time been a system used for file and print operations in organizations. Many organizations still use Novell for providing users with their Home directories. Somewhere along the way Novell developed an application which serves up these Home directories and files via a web browser. Novell calls this application NetStorage. A fairly basic application like this allows the user to login with a name and password and veiw their home directory and drag and drop files to and from it. Novell also has a product called iFolder. This application allows you to sync your files from the desktop and is also apparently a web based application. I would like to attempt to protect these applications behind TAM WebSEAL. I'll start with a Windows server and I have already downloaded the eDirectory 8.7.3 code. Before you install Novell you have to acquire a license so I have completed the form for the license and am waiting for a response from Novell so that I can try this out.
If anyone out there has ever attempted this, please let me know your results.
If anyone out there has ever attempted this, please let me know your results.
Subscribe to:
Posts (Atom)