Tuesday, November 20, 2007

Another cool Tivoli dude!

I always try to make a point to mention some people I meet every now and then because the network of Tivoli security folks does not appear to be very large. And in this case it just goes to show it really is a small world out there. I recently created a few PMR's to troubleshoot some issues I was having with TAM eSSO. By luck my level 2 support guy assigned to the call was a former Buffalonian!

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.

DPRA url's

I downloaded the latest version of the Desktop Password Reset Adapter from IBM just the other day. It's version 6.00 Rollup D. First of all since when are they starting to use this "rollup" terminology? When you install this code, the web pages for the DPRA Management console say 6.0.04 or something to that effect. Even the base code which today is 6.0.05 suddenly is now referred to as Rollup E. WTF?

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:

http://host/vgoselfservicereset/resetclient/checkenrollment.aspx
http://host/vgoselfservicereset/resetclient/checkforceenrollment.aspx
http://host/vgoselfservicereset/enrollmentclient/enrolluser.aspx
http://host/vgoselfservicereset/resetclient/default.aspx
http://host/vgoselfservicereset/resetclient/checkstatus.aspx

Synchronizing Global Agent Settings can break synchronization???

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


Corrupt TAM eSSO User...

"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

LDAP Adapter Gotcha...

The Problem: CTGIMD014I 1 reconciliation entries were not processed for the following accounts: eruid=users.

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 **********
$dn: DN:eruid=users
erLdapContainerName: dc=mydomain,dc=com
objectclass: OBJ:erLDAPUserAccount
cn: users
eruid: users
erAccountStatus: 1
*********** 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.]]

So ITIM was trying to orphan a bunch of accounts and it came across an account called "users". Well the reason for this apparently is because of the fact that I had created a container in my target LDAP called cn=users. I had provisioned my LDAP users into this container. The LDAP Adapter apparently has a problem with the search base being cn=users,dc=mydomain,dc=com.

The Fix:

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!