Aspiring Oracle Nerd

So a couple of weeks ago I was complaining about SSO and the difficulty in troubleshooting problems.  It turns out that much of that complaining was not justified.  It was more an issue of my lack of understanding of AD -> OID integration.

We’ve had long standing issues where users who normally authenticate transparently through wna are prompted for credentials and after entering those credentials are presented with an authentication error.

The AD -> OID integration was initially set up by consultants during my first week at ADM so I never really had a very good understanding of how it all worked.  There was enough going on in my first 6 months of employment that I was just trying to keep my head above water.  After banging my head against Portal access issues (99% of the time they users were trying to access our Portal homepage and not partner applications we have registered with SSO) I developed a strategy that worked for me.  For each user experiencing problems accessing our Portal page I would take the following steps:

1) Make sure there weren’t duplicate entries in OID.  The AD -> OID sync was not initially set up to handle deletes so when employees would be transferred to a different group and their AD accounts would be updated, OID would have 2 entries.  This was a problem.  I eventually installed a patch to handle this but for the first few months it happened infrequently enough that manually doing this was not an issue.

2) Make sure the SAMaccount attribute was populated and the format was correct.  Apparently this is necessary for OID to look up the password in AD.  (Passwords cannot be synchronized with AD!)

3) If the above two things were correct, wait a day and call the user back to see if they were still experiencing the problem

Invariably, once I got to step 3, the problem always seemed to fix itself if I waited long enough and I was never able to figure out why.  Until last week!

So wna will break for some user for short periods of time for any number of reasons.  When wna is not working, the fall back method is for the user to enter the credentials and have OID look-up the password in AD for authentication.  It turns out that you have to tell OID what parts of the OID tree should use AD as the holder of password information and what parts of the OID tree should maintain its own password information.  This is done through  Plug-in Subscriber DN Lists.  It turns out that this was only configured to handle a portion of the user base.  As soon as wna failed (which, again, is pretty fragile), a certain percentage of users were shit out of luck because OID didn’t know their password information was stored in AD.   As soon as I added the cn’s necessary to encapsulate all users stored in AD to the Plug-in Subscriber DN List, things worked as the should.

Hopefully this will help someone out there.