Joe it sounds like you are being bitten by adminSDHolder. Poke around for it (archives for here and the newsgroups and MSKB) you will find considerable info on it now.
Basically there is a process that goes through and protects certain accounts (usually admin type accounts like Ent Admins, Dom Admins, Admins, Acc Ops, Serv Ops, etc) by removing the inherit flag and setting the ACL to the ACL of the adminSDHolder object in the system container. Once you "clean up" an ID you should see it reset in about 5-10 minutes. Check to see if you have the admincount attribute populated on these ID's, that is the flag for the process. Any groups that the users are in that have that flag set will force the user to get that flag set as well. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, January 06, 2004 12:08 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] Wierd issue with security descriptor reverting on replication Hi all, I believe this is my first post here after reading for a while. I have an problem that I need some help on. Essentially, we have a few user objects (not sure how many) in two of our domains (separate forests) that have their security descriptors set to not inherit permissions from their parents (an OU). The control field is set SE_DACL_PRESENT | SE_DACL_AUTO_INHERITED | SE_SACL_AUTO_INHERITED | SE_DACL_PROTECTED | SE_SELF_RELATIVE. The problem comes in when we set the inherit flag in AD Users and Computers or ADSI Edit. The change is accepted and the object starts inheriting ACEs from parent as expected, but then a little while later (presumably after replication), the security descriptor reverts back to its previous state with the protected flag set in the control field. We aren't sure what to do to make the change stick. I can post replication metadata if that would be helpful. I do see a replication event that looks like it might coincide but I'm not sure how to tell. Does anyone have any idea what's going on? It seems like it might be some kind of a permissions issue, but the DC where the change is made allows the SD to be updated just fine. I'm not even sure where to look on this. I'd like to fix this if I can as having random objects that don't have the expected permissions causes all sorts of things to break unexpected. I'd also love to hear if anyone has any ideas on how to find affected objects efficiently. The issue is that we have about 80K user objects to check and retrieving security descriptors with ADSI is a notoriously expensive call. I'd rather grab the binary data directly if I can to avoid the DACL expansion done by IADsSecurityDescriptor, but I'd also rather not write LDAP API code or call IDirectorySearch or IDirectoryObject if I can avoid it. I know I have at least a dozen of these, but I have no idea how pervasive the problem is. Thanks in advance for your help. Joe Kaplan MVP - ADSI This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
