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=ccanet,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-B489-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/
