Tuesday, November 20, 2007
Sey Gan lived right in North Amherst for about 12 years and landed a job with IBM Tivoli some time ago. And lucky for me he is a darn good TAM eSSO guy working level 2 tech support. Sey gave me some great tips and helped me work through a few problems. It's always nice to have good tech support from IBM, but it's even nicer when you discover they are from your own neck of the woods too. Of course I'm sure Sey is very much enjoying the nicer weather out in Costa Mesa, CA. But hey, we in Buffalo don't have forest fires and we certainly don't have any shortage of fresh water! Even better you can still get a pint of beer here for under $3.00.
Well, lets get to the real point of this post... The documentation. I noticed that still the DPRA Client Install Guide has one of the URLs wrong on page 9. The first time I installed this a while back this drove me crazy. I finally noticed on the actual web service in IIS that there was no such file enrollments.aspx. The file name is enrolluser.aspx. Come on guys, can you at least fix the inaccuracies in this documentation already??? And why would they list the URLs in a different order than that in which the client software asks for them? Luckily after I had figured this out the first time I made notes for later.
Anyhow here is what is on page 9:
Here is what the URLs need to be in the order the client asks for them:
Just because you can do something doesn’t always mean you should. One of the Tivoli Level 2 support guys from IBM warned me that synchronizing your Global Agent Settings to the repository can lead to issues such as synchronization problems. So synchronizing can cause synchronization problems. Go figure. I guess I won’t do that then.
· Just right-click the object (vgoadminoverride in my case) and click delete
"There was an error trying to load your chosen primary logon method. You may want to reinstall it in order to correct this."
I have a workstation in which 4 or 5 different users will logon to. All the users except one worked fine. The problem user would login to the Windows Domain and the above error would be displayed as soon as the TAM agent would start to load. To fix this problem I followed these steps.
1.) Logon to the Admin workstation and clean up the server side by deleting the users credential objects
· TAM eSSO Admin Console -> AD Repository -> Twist Open Users Container -> Twist Open User
· Right-click TAM eSSO object -> Delete
1.) Next, logon to the users workstation and cleanup the agent side
· Start -> Run -> %appdata%
· Delete the Passlogix folder
· Start -> Run -> Regedit
· Delete the Passlogix folder from HKEY_CURRENT_USER\Software\
· In this case it was also necessary for me to delete the folder in the %appdata%\Microsoft\Crypto\RSA folder. There is normally a single file in this folder, but since this problem had something to do with the logon method it was necessary to delete this folder as well.
3.) Finally, log off Windows and log back on. TAM eSSO should start correctly.
Tuesday, November 13, 2007
I had this problem on one of my TIM servers. It was relatively early on in the build process for this environment and I had created a service for an LDAP which I was to be provisioning user accounts. Really straight forward stuff here. But, I kept having these recon warnings. The Reconciliation would complete with the warning noted in the title of this post. The trace.log showed several errors like this one:
*********** ENTRY **********
*********** ENTRY END ******
![CDATA[Unable to create orphaned account]]
![CDATA[Thread 2 Encountered an exception processing eruid=users: CTGIMS001E At least one required attribute is missing.]]
To fix this I simply re-created the users container as an OU. So I deleted the users from the cn=users container, then deleted the container and re-created it as an OU. I changed the search base on the service and now everything works fine.
I know that typically containers such as cn=something are usually seen more often in AD, but ITDS had no problem letting me create these. Technically for my solution it really makes no difference so it was easy enough to just blow away the containers and re-create them as OU's. Just a little gotcha with the LDAP Adapter I guess. BTW, IBM Tech support caught this very quickly where I just didn't see it. Thanks Melvin!