Grrrrr…..bloody Microsoft

We run Sun LDAP server (Directory server 5.2) and we use idsync (or SUNWisw, or “Sun identity syncronisation for windows” or whatever they are calling it this week) to enable passwords in our Microsoft AD domain to be kept in sync with the passwords in LDAP. This has worked brilliantly for a couple of years.

A couple of months ago we upgraded our Window 2000 domain to Windows 2003. We tested idsync in a dev environment and thought it was all working fine. However, since then, we’ve been getting reports of users changing their passwords on windows but LDAP only accepting their old passwords. The idsync logs showed that it all appeared to be working perfectly, the windows logs showed, well, showed bugger all really (don’t they always?). Finally today while a few of us were chatting over a coffee the penny dropped…

As AD doesn’t make passwords available (or hashes of) the LDAP server has no way of obtaining the passwords directly. What it has to do is to monitor the AD changelog (point at PDC emulator role – odd things happen otherwise with replication delays in AD) to detect when a users password changes. When it does, it flags the user as having a password that needs syncing by setting the attribute dspswvalidate to true. Then, when the user next binds to the ldap server (via mod_auth_ldap in apache, UWC, msging express, whatever) the idsync plugin to DS takes the password that it has been given and attempts a bind against the AD domain controller. If it works it knows the password is correct and squirrels it away in LDAP (at least, a hash of it) and allows the bind to succeed. Clever, and reliable until Windows 2003 SP1 when for some reason I can’t fathom Microsoft changed the behavior. Now, for 1 hour after changing a password in AD a user can still use their old password for 1 hour. Sounds a trivial change but if you have users who have their (old) password stored in email clients etc then it’s a race to see which password is synced first. If the user happens to use their *new* AD password then idsync sends that to the DC and gets it validated, stuffs it into LDAP and huzzah, the world is sweet. If however the user (or more likely, a client they have running with a saved password) uses their old password first then idsync again sends this to the AD DC which since SP1 now returns a success for the old password! Of course, idsync the stuffs that into ldap and never bothers syncing it again – why should it, it has the new password doesn’t it?

Arggggghhhh

Of course, it’s not all Microsoft being shit. We have had a call logged with sun for this for several weeks now (case ID 37917017 if anyone reading can look it up). They haven’t managed to come up with a reason why this is happening despite in v6 of DS it’s actually a documented issue on suns site (see http://docs.sun.com/app/docs/doc/820-2487/isw-bugs-known ). For version 2005Q4 Sp1 which is the version that supports 2003 it isn’t mentioned at all :-/ I’ll suggest a doc update tomorrow when I get into work. In the meantime, hopefully I’ve scattered enough of the relevant keywords through this post that others suffering the same odd behavior will find it.

BTW, the fix it alledgedly described in http://support.microsoft.com/?kbid=906305 although we’ve yet to confirm this – fiddling with the registry on live domain controllers during signup week isn’t something we can just do without thinking carefully… Also, that doc seems to suggest that it’s NTLM auth that is effected – it’s certainly LDAP and we’ve also confirmed it’s an issue with radius auth (windows desktops work properly and reject the old password immediately – convenient).

Finally, is it just me who finds the end of that document rather laughable?

Note This behavior does not cause a security weakness. As long as only one user knows both passwords, the user is still securely authenticated by using either password.

If a user’s password is known to be compromised, the administrator should reset the password for that user. The administrator should ask the user to change the password at the next logon to invalidate the old password as soon as possible.

Ask the user to change their password as soon as possible when you know it’s been compromised???? ARGGGHHHHHHH

This entry was posted in General, Sun JES. Bookmark the permalink.

3 Responses to Grrrrr…..bloody Microsoft

  1. Barry says:

    Just bloody typical. I am sick of these “updates” and “Service packs” from Redmond not just “fixing” stuff but making fundamental changes without warning!

    And as for that last comment! They really are comedians! Substitute “The User” for “10,000 new and angry students complaining that they are not getting what they paid for and baying for blood”, and you have a scalability problem! Just tell them to change their password, and be calm and sympathetic when they ask “Which bloody one?”

  2. Justin says:

    Just wanted to let you know that this still exists, almost a year later. Even with running DS 6.3, ISW 6, and Win 2003 sp2.

    Did making the changes in the MS knowledge base fix your problems? We’re looking into doing them here.

  3. dmc says:

    Hi,

    Yep, that “fix” sorted it out – we’ve been running like it for ages now and we haven’t had any reappearance of the problem \o/

    Let me know if you have success as well

    bloody MS…. grrrrr.

Leave a Reply

Your email address will not be published. Required fields are marked *