I am trying to lock down security including removing the leaked password hashes that the UNIX addon creates. I removed Authenticated Users from the Pre-Windows 2000 Compatible Access group. However after doing this, a small portion of users could not log into various non-Windows things like Redmine, Subversion, our VPN etc. These services authenticate with a ldapbind user account and then use SSL LDAP to authenticate against AD and check group membership. We also use Linux machines running SSSD that authenticate via Kerberos and check group membership with LDAP.

The problem I found is that group membership could not be enumerated for a small amount of users. They can be authenticated but not authorized. For example if I log onto a Linux box and do "id user" nothing would be found for these users. However "id user" would return the information for most of the users. I can't think of any difference between the user accounts that work and those that don't. What could be going on?

  • 1
    Just an off-the-top-of-my-head question: you said you don't know of anything in common with the specific users. Are the "broken" users all in groups protected by AdminSDHolder (thekortrights.com/wp/?p=116) ? – MikeBaz - MSFT Feb 13 '13 at 1:54
  • Why do you think that removing Authenticated Users from the Pre-Windows 2000 Compatible Access Group will make your system more secure? – Greg Askew Feb 13 '13 at 3:19
  • It looks like the broken users are all not in the protected groups. That might be significant, I'll have to read this. – Doug Feb 14 '13 at 1:22
  • I want to remove Authenticated Users because when I ldapsearch any users since installing the UNIX add on there is a field called unixUserPassword which appears to have a hash of the password. In other words any user can read every other users password so far. According to this link, if I disable the pre-windows 2000 group it will fix this. en.gentoo-wiki.com/wiki/… – Doug Feb 14 '13 at 1:25

You removed Authenticated Users from Pre-Windows 2000 Compatible Access in order to prevent users from reading each others UNIX password hashes. Pre-Windows 2000 Compatible Access has rights to read almost all properties of most objects and is how most non-admin security principals read object properties. Group membership is determined for a user by reading the memberOf attribute and, like unixUserPassword, the ability to read it by most of your users is now removed. The reason users who ARE in protected groups are NOT broken but users who are NOT in protected groups ARE broken is because, oddly-enough, the AdminSDHolder grants more permissive rights to read properties of protected objects than unprotected objects.

There's no "correct" answer to fix your issue since it's generally not a good idea to store confidential data in AD in the first place (this is exactly the reason why). You might look into setting the confidentiality bit. I've never done it but this KB article goes into detail: How to mark an attribute as confidential in Windows Server 2003 Service Pack 1

| improve this answer | |
  • btw after much research, I found that unixUserPassword was not in fact visible to all users -- same issue -- it just appeared so to me because I was in the admin groups. – Doug Apr 11 '13 at 17:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.