> it would apply to user objects underneath the protected user, which can not exist in AD.
Careful... It can not exist in the default schema of AD. You can certainly make it so AD will allow you to have a user object as an inferior object to another user. C:\Program Files>admod -b CN=User,CN=Schema,CN=Configuration,DC=joe,DC=com posssuperiors:+:user AdMod V01.06.00cpp Joe Richards ([EMAIL PROTECTED]) June 2005 DN Count: 1 Using server: 2k3dc01.joe.com Modifying specified objects... DN: CN=User,CN=Schema,CN=Configuration,DC=joe,DC=com... The command completed successfully C:\Program Files>admod -b "" schemaupdatenow::1 AdMod V01.06.00cpp Joe Richards ([EMAIL PROTECTED]) June 2005 DN Count: 1 Using server: 2k3dc01.joe.com Modifying specified objects... DN: ROOTDSE... The command completed successfully C:\Program Files>admod -b cn=subadmin,cn=administrator,CN=Users,DC=joe,DC=com -add objectclass:+:user AdMod V01.06.00cpp Joe Richards ([EMAIL PROTECTED]) June 2005 DN Count: 1 Using server: 2k3dc01.joe.com Adding specified objects... DN: cn=subadmin,cn=administrator,CN=Users,DC=joe,DC=com... The command completed successfully I can't say why someone might want to do things this way but possibly there is something - maybe you want all people responsible to another listed under that user's object. I can't vouche for how well other programs may handle this situation, including say GPOs. It isn't something that I have tested other than to say, look here, you can create a user under another user.... joe -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Thursday, April 20, 2006 3: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/
