Hello Simon, That explanation does make sense, thank you. I guess, maybe, the issue is in that, in the end, the ADUC GUI view of the permissions on the object were misleading. (I know, real administrators don't use GUI tools.) The list of the security applied to the user object indicated that both objects (the one getting the adminSDHolder perms and the one inheriting them from the OU above it) had the READ/WRITE permission set on that attirbute for the User Objects, whereas in one case it would have only been inherited by user objects under the particular object. DSACLS was necessary to point out the actual differences.
Rick Bowersox Principle Software Systems Engineer Identity/Directory Services EBusiness Security Rockwell Collins 400 Collins Road, NE MS 120-120 Cedar Rapids, IA 52498-0001 319.295.5095 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Thursday, April 20, 2006 2:59 PM To: [email protected] Subject: RE: [ActiveDir] Anomoly in application of Permissions by adminSDHolder Hi Rick, You need to be aware that the adminSDHolder-Object is equally to a user object. You have corrected this. However I do not see the bug here. If you apply the same rights on the adminSdHolder Objects which you apply to an OU, it would apply to user objects underneath the protected user, which can not exist in AD. Gruesse - Sincerely, Ulf B. Simon-Weidner MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz Weblog: http://msmvps.org/UlfBSimonWeidner Website: http://www.windowsserverfaq.org Profile: http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1214C811 D |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Rick Bowersox |Sent: Thursday, April 20, 2006 9:37 PM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | |Joe | |That ACL change has done the trick! - THANKS! I would still |suggest that there is a bug in the way that the thread that |monitors adminDSHolder applies acls to the objects it |protects. When I applied my ACL to the adminSDHolder |container, (using ADUC), I selected to have it applied to the |'user' object types. This is the same specification that I use |on the OU that these user objects are in and that is inherited |by all other, non protected, user objects in the OU. If I |look at 2 user objects in the OU, where 1 is protected and the |other is not, ADUC shows the same (user |objects) permissions on both objects. However, if I use |DSACLS, the non-protected user object, the READ/WRITE |lockoutTime permissions show under the "Effective Permissions |on this object are:" top level heading, and on the protected |object they show up under the subheading "Inherited to user". | |So while, in theory (and according to ADUC) the 2 user objects |have the same permissions applied, the 1 object inheriting |them from the parent OU, the other from the adminSDHolder |settings, the ones that are "Inherited to user" |do not really apply. | | |Rick Bowersox | |Principle Software Systems Engineer |Identity/Directory Services |EBusiness Security |Rockwell Collins |400 Collins Road, NE MS 120-120 |Cedar Rapids, IA 52498-0001 |319.295.5095 | | | |"If life was fair, Elvis would be alive and all the |impersonators would be dead." | |_________________________________________ | | |Johnny Carson | | | | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of joe |Sent: Thursday, April 20, 2006 9:30 AM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | |The delegation isn't right, check out ONLY the permissions |applied TO the actual object. No lockoutTime delegated. You |have a couple of ACEs that are inherited down to GROUP |subobjects though that is for lockoutTime. | |I would probably apply the lockoutTime ACE directly to the |adminsdholder object with something like | |dsacls cn=adminsdholder,CN=System,DC=domain,DC=com /G |domain\groupofpeoplewhocanunlockadmintypeids:RPWP;lockoutTime | | | | |-- |O'Reilly Active Directory Third Edition - |http://www.joeware.net/win/ad3e.htm | | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Rick Bowersox |Sent: Thursday, April 20, 2006 9:16 AM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | | Hello, Joe. Good to hear from you. Sorry I missed DEC this year. | |1) !!RLBAdminTest 04/19/2006-12:22:27 LOCKED |VIEW_ONLY |-------------------------------------------------------- |2) C:\Temp>dsacls |CN=!!rlbadmintest,OU=AdministrativeAccounts,OU=Collins,DC=ccane |t,DC=rockwell |collins,DC=com |Access list: |{This object is protected from inheriting permissions from the |parent} Effective Permissions on this object are: |Allow BUILTIN\Administrators SPECIAL ACCESS | DELETE | READ PERMISSONS | WRITE PERMISSIONS | CHANGE OWNERSHIP | CREATE CHILD | DELETE CHILD | LIST CONTENTS | WRITE SELF | WRITE PROPERTY | READ PROPERTY | LIST OBJECT | CONTROL ACCESS |Allow NT AUTHORITY\Authenticated Users SPECIAL ACCESS | READ PERMISSONS | LIST CONTENTS | READ PROPERTY | LIST OBJECT |Allow CCANET\Domain Admins SPECIAL ACCESS | READ PERMISSONS | WRITE PERMISSIONS | CHANGE OWNERSHIP | CREATE CHILD | DELETE CHILD | LIST CONTENTS | WRITE SELF | WRITE PROPERTY | READ PROPERTY | LIST OBJECT | CONTROL ACCESS |Allow INTRANET\Enterprise Admins SPECIAL ACCESS | READ PERMISSONS | WRITE PERMISSIONS | CHANGE OWNERSHIP | CREATE CHILD | DELETE CHILD | LIST CONTENTS | WRITE SELF | WRITE PROPERTY | READ PROPERTY | LIST OBJECT | CONTROL ACCESS |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS | LIST CONTENTS |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS | READ PERMISSONS | CREATE CHILD | DELETE CHILD | LIST CONTENTS | WRITE SELF | WRITE PROPERTY | READ |PROPERTY Allow BUILTIN\Pre-Windows 2000 Compatible Access |SPECIAL ACCESS | READ PERMISSONS | LIST CONTENTS | READ PROPERTY | LIST OBJECT |Allow NT AUTHORITY\SYSTEM FULL CONTROL |Allow INTRANET\TempCcanetDomainAdminsPool SPECIAL ACCESS | READ PERMISSONS | CREATE CHILD | DELETE CHILD | LIST CONTENTS | WRITE SELF | WRITE PROPERTY | READ PROPERTY |Allow CCANET\Cert Publishers SPECIAL ACCESS for |userCertificate | WRITE PROPERTY | READ PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |displayName | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |groupType | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |Personal Information | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL |ACCESS for Public |Information | WRITE |PROPERTY Allow BUILTIN\Windows Authorization Access Group |SPECIAL ACCESS for tokenGroupsGlobalAndUniversal | READ PROPERTY |Allow Everyone Change Password |Allow NT AUTHORITY\SELF Change Password | |Permissions inherited to subobjects are: |Inherited to all subobjects |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS | LIST CONTENTS |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |displayName | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |groupType | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS for |Personal Information | WRITE PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL |ACCESS for Public |Information | WRITE PROPERTY | |Inherited to group |Allow BUILTIN\Terminal Server License Servers SPECIAL ACCESS for |Add/Remove self as member | WRITE PROPERTY | READ PROPERTY |Allow INTRANET\TempCcanetDomainAdminsPool SPECIAL ACCESS for |Add/Remove self as member | WRITE SELF |Allow INTRANET\TempCcanetDomainAdminsPool SPECIAL ACCESS | READ PERMISSONS | LIST CONTENTS | READ |PROPERTY Inherited to user |Allow CCANET\HelpDeskStaff-global SPECIAL ACCESS for |lockoutTime | WRITE PROPERTY | READ PROPERTY |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS | READ PERMISSONS | LIST CONTENTS | READ PROPERTY | LIST OBJECT |Inherited to group |Allow CCANET\Exchange Enterprise Servers SPECIAL ACCESS | READ PERMISSONS | LIST CONTENTS | READ PROPERTY | LIST OBJECT |Inherited to user |Allow BUILTIN\Account Operators SPECIAL ACCESS for |lockoutTime | WRITE PROPERTY | READ |PROPERTY The command completed successfully |-------- |net user !rlbtestadmin | |User name !RLBTestAdmin |Global Group memberships *SMS20HPD |*PrintServerAdmins | *HelpDeskStaff-global *Domain |Users |The command completed successfully. |-------- |c:\>whoami |CCANET\!RLBTestAdmin | |C:\unlock . !!rlbadmintest | |Unlock V02.01.00cpp Joe Richards ([EMAIL PROTECTED]) August 2004 | |Processed at crntdc04.ccanet.rockwellcollins.com |Default Naming Context: DC=ccanet,DC=rockwellcollins,DC=com | |1: !!RLBAdminTest 04/19/2006-12:22:27 LOCKED |UNLOCK_FAILED |(Insufficient Rights) |-------------------------------------------------------- | |I think that may leave 3) | | | |Rick Bowersox | |Principle Software Systems Engineer |Identity/Directory Services |EBusiness Security |Rockwell Collins |400 Collins Road, NE MS 120-120 |Cedar Rapids, IA 52498-0001 |319.295.5095 | | |"If life was fair, Elvis would be alive and all the |impersonators would be dead." |________________________________________ | |Johnny Carson | | | | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of joe |Sent: Thursday, April 20, 2006 7:47 AM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | |The issue is one of three | |1. The account isn't locked |2. The delegation really isn't applied properly 3. ADUC bug | |Grab unlock.exe from my website (www.joeware.net) and it can |help work out if you the account is really locked and whether |or not you delegation is correct. Use the -view switch to |verify an account is locked. Several versions of ADUC showed |this incorrectly (possibly it still does, it isn't something I |doublecheck as I don't really use ADUC to manage anything). | |If an account is definitely locked is the checkbox still |greyed out? If so, then can you unlock with unlock.exe? If |not, dump the ACL with dsacls and post the results. | | |-- |O'Reilly Active Directory Third Edition - |http://www.joeware.net/win/ad3e.htm | | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Rick Bowersox |Sent: Thursday, April 20, 2006 7:54 AM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | |Ulf: | |My original post must not have been clear enough. I HAVE |delegated this on the adminSDHolder container and it does get |applied to the protected accounts. Unfortunately, even though |the security setting on the account then shows that the |HELPDESK group has READ/WRITE ability on the lockoutTime |attribute, that option is grayed out in ADUC for them. | | |Rick Bowersox | |Principle Software Systems Engineer |Identity/Directory Services |EBusiness Security |Rockwell Collins |400 Collins Road, NE MS 120-120 |Cedar Rapids, IA 52498-0001 |319.295.5095 | | | |"If life was fair, Elvis would be alive and all the |impersonators would be dead." | |_________________________________________ | | |Johnny Carson | | | | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Wednesday, April 19, 2006 4:33 PM |To: [email protected] |Subject: RE: [ActiveDir] Anomoly in application of Permissions |by adminSDHolder | |Hi Richard, | |You can change the settings by delegating write access to |lockoutTime on the adminSDHolder-Object in the system |container. After doing that your helpdesk will be able to |unlock any administrative account anywhere in the domain. | |For more information query my blog for adminSdHolder or use |google, which will bring it up as well. | |Gruesse - Sincerely, | |Ulf B. Simon-Weidner | | MVP-Book "Windows XP - Die Expertentipps": http://tinyurl.com/44zcz | Weblog: http://msmvps.org/UlfBSimonWeidner | Website: http://www.windowsserverfaq.org | Profile: |http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B48 |9-F2F1214C811 |D | | | ||-----Original Message----- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Richard ||Bowersox ||Sent: Wednesday, April 19, 2006 10:09 PM ||To: [email protected] ||Subject: [ActiveDir] Anomoly in application of Permissions by ||adminSDHolder || ||I have noticed what appears to be an anomoly in the way that ||adminSDHolder is applying object permissions and was wondering if ||anybody else has seen something similar or has a workaround. || ||We want our internal helpdesk staff to be able to unlock any users ||account, even privliged accounts that are protected by adminSDHolder ||'inheritance'. ||The HELPDESK group has been give Read/Write permissions on the ||lockoutTime attribute for User Objects protected by adminSDHolder. ||However, when members of HELPDESK go to unlock a locked |account of this ||type, the choice is grayed out. (The same permissions given to the ||same group for accounts not protected by adminSDHolder allow the ||HELPDESK to unlock those accounts without any problem.) || ||When I look at the permissions applied to the specific user object it ||shows that the HELPDESK group has Read/Write on the lockoutTime ||attribute as expected. The only way that members of the |HELPDESK group ||can gain access to the account lockout box is to set the |security on a ||specific account for the lockoutTime READ/WRITE permission to |apply to ||'This Object' ||rather than the "User Objects' choice. || ||Unfortunately, when setting the security on the adminSDHolder ||container, I cannot use the "This object and all child |objects" choice ||because when that is selected, the lockoutTime attribute is not an ||available option. || || || ||Rick Bowersox ||Rockwell Collins || ||"If you cannot convince them, confuse them." ||------------------------------------------ ||Harry S Truman || || ||List info : http://www.activedir.org/List.aspx ||List FAQ : http://www.activedir.org/ListFAQ.aspx ||List archive: ||http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ | |List info : http://www.activedir.org/List.aspx |List FAQ : http://www.activedir.org/ListFAQ.aspx |List archive: |http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
