Sun Identity Sync for Windows troubles...

Sun's Identity Sync for Windows has been a pain in my butt lately. Turns out ISW doesn't make it easy to point at new global catalogs.

Products in play:

• MS WIndows AD (unsure of AD version right now, servers are 2k3).



• SunONE identity Server 5.2 patch 2



• Sun Identity Sync for WIndows 2004Q3

So what brought this about? At ${CLIENT} they have an application that for various reasons can not authenticate directly against AD for credentials and group memberships. It needs some attributes set for the user and setting those in AD was problematic, if I remember correctly. This was set up a long time ago and a lot as changed, so if we were doing this from scratch today, it's likely that this version could be made to work with AD. The latest version of this Documentum product does support native AD anyway so it's kind of a moot point. Anyway, on the 'issue' at hand.

The theory of operation is that an account is created in AD, added to the appropriate AD ou's, groups, and given the correct attributes. ISW then takes that information and creates the corresponding LDAP entries. After creation, ISW then montiors AD for changes and makes the corrisponding LDAP changes. It does this by talking/listenting to the Domain Controller (DC) with the PDC FSMO role. Now when a user changes their password, the ISW sees this. But it's not a domain controller so it can't actually capture the password. So ISW does the next best thing, it tells LDAP that the stored password it has is invalid and that it needs to verify AD for it next time the user logs in. So if I change my password, the LDAP password entry gets set to PW-NEEDS-SYNC (i'll try to find an actual entry to get the 'real' value). Anyway, when I try to log in via LDAP, the LDAP server takes the uname and password credentials I have provided and does a bind to an AD server with my credentials. It's the actual password I provided, not an encrypted hash or what not, which is why all of this is done over SSL This uname/password pair is then used to attempt a bind to the AD servers via LDAP. If the bind is succesfull, LDAP does two things: One, it lets me into the app. Two, it stores that password it just used as the new LDAP password, and presto, it has my 'changed' password. Pretty clever.

Now on to my story. So this has been working, not perfectly, but it worked, It talked to three AD servers I'll call them DC2, DC4 and VDC1. So, DC2 is my PDC role, and DC4 and VDC1 are the DC's we were using to talk to the two domains in play. Well, $CLIENT is moving their data center from Falls Church, VA to a CSC facility in Chicago. The datacenter move as been a great project. I should write up some of my experiences with that. It went about as well as could be expected. Part of this is to migrate to new domain controllers. So my DC2, DC4 and VDC1 are going away. Three big problems: One, DC2 is the SSL-CA for the enterprise (they failed to notice this and migrate it's services). Two, the AD team didn't realize they had an ISW/LDAP dependancy. Three, ISW doesn't let you simply repoint the Global Catalogs or Domain Controllers. Anyway, water under the bridge, we stood up a new enterprise CA, installed certs on the DC's and allowed LDAPS on them.

The big troubles have been with repointing ISW. Turns out you have to uninstall the ISW connectors and reinstall them to repoint them. Once you do that you can specify a new global catalog from which the ISW can learn the PDC FSMO role from. One issue we did come across is that when the ISW does a search for DC's in the GC, it does something equivelent to:

ldapsearch -v -H ldaps://<DC-hostname> -x -b "ou=domain controllers,DC=<DOMAIN TREE STUFF>t" -D "<USER TO LOG IN AS>" -W "(objectclass=computer)"

But it doesn't traverse sub-folders. So if your domain controllers are 'organized' into sub-folders, you're sunk. This happened in my case. The quick fix was to move a few 'core' DCs to the top level. This allowed ISW to find the DC's to talk to. I'm still having issues getting it work with the GC correctly for some reason. My ticket has been open with SUN for over a month now.

More to come I'm sure...