5

Attempting to make a site administrator user account for an Active Directory Domain. Using the Active Directory Delegate Authority Wizard. a user account has been grated rights in a OU. However, when attempting use of the authority some of the options are grayed out. Current settings allow the site admin to edit accounts created by the Site Admin, values are not grayed out. When the site admin attempts to edit user accounts created by Domain or Enterprise admin have some areas grayed out.

A user account that has all Authority of an administrator but limited to OU and it's children. Are desired.

Created by admin VS created by Site admin

In the probmatic OU there are ~50 user objects 8 of those object inherit the pwdLastSet value. the Image on the right shows one of the objects that inherite the permissons. the left image shows a User object that has not. they are in the same OU.

In the Security tab for most the objects doe snot have my HelpDesk Group while the right image's Security tab does have the HelpdeskGroup with permissions.

for some reason the permissions are being inherated by some but not all the objects.

update

I tried with a different OU in a different forest with the same results Step 1 make a new user account in forest Step 2 right OU Delegate control step 3 select my new user check all boxes Using my new DelegatedAdmin account I navigate to the UO. There are 4 Users in the OU. Users 1&2 I am unable to edit. User 3&4 I am able to edit as expected. enter image description here

Update

I have made a test OU with test users and a test administrator/helpdesk user. in these test OU's everything works exactly as it should. I fear there is something wrong with my Global catalog or Schema at this point.

Community
  • 1
Honk
  • 143
  • 1
  • 12
  • 1
    Give this a read: http://technet.microsoft.com/en-us/magazine/2009.09.sdadminholder.aspx – techie007 Feb 12 '14 at 19:52
  • That was a good read learned something but I don't know how to solve the problem. non of the users are in a protected group. they are all normal users in a normal OU for the site. Is it even possible for a delegated user to disable accounts or force change password on next login? – Honk Feb 15 '14 at 01:08
  • 2
    Is permission inheritance enabled on the problematic objects? Is the AdminCount attribute on them set to anything other than 0? – MDMarra Mar 03 '14 at 20:10

2 Answers2

2

Check the permissions on both objects. To review the permissions, you view the "Security" tab just like you would with a file or folder.

Since there is no "Security" tab, you'll need to go to the View menu in Active Directory Users and Computers and select Advanced Features. Then you'll be able to see the security tab and verify the permissions on the objects.

Jack
  • 1,336
  • 2
  • 7
  • 4
  • Any object created *after* I delegated authority to the site-admin shows the siteadmin with full control. there are a few 1000 users that have been made before hand. Which permissions do I need to add to allow my site-admin to edit these objects. I know how to find the security tab. – Honk Feb 13 '14 at 18:58
2

Objects created in Active Directory have "Creator Owner" permissions granted to, well, the Creater/Owner. This can have unexpected effects. For example, one of the desktop techs at a previous job discovered that he could delete some PCs out of AD despite not having explicit permission to do so, but only if he was the one who added them. This was because he was the creator of the PC object, and as such had special permissions on it.

Your statement on Jack's answer, "Any object created after I delegated authority to the site-admin shows the siteadmin with full control. there are a few 1000 users that have been made before hand," suggests to me that something similar is going on. I imagine that if you pull up one of the objects created by the siteadmin and choose Security -> Advanced -> Owner, you'll find your siteadmin owns that object.

If you want the siteadmin to have full control over that OU, you probably need to explicitly grant that permission in the security tab under advanced features that Jack mentioned. Unlock/change password is probably modify.

Katherine Villyard
  • 18,550
  • 4
  • 37
  • 59
  • The OU and ALL the user objects (both working and non working objects) are all owned by the domain\administrator account. – Honk Mar 04 '14 at 22:41
  • Okay. Do you see any difference in the actual permissions between working and non-working objects? – Katherine Villyard Mar 04 '14 at 22:42
  • 1
    under security tabworking accounts have an additional user/groups. Adding the missing accounts does seem to affect the issue. -RAS and IAS server (read account,group,logon) -Account Operators (full controll) -ENTERPRISE DOMAIN CONTROLLERS (special) – Honk Mar 04 '14 at 22:53
  • 1
    Do the working and non-working object both have the "Allow inheritable permissions from parent to propagate to this object" checkbox checked? – Katherine Villyard Mar 04 '14 at 23:10
  • 1
    The probmatic objects did not have this setting ticked. The working objects did. That looks like that might be the issue. Is there a way to set/check this setting across the whole forest? I have a few 1000 users in many OU's to go though. – Honk Mar 04 '14 at 23:29
  • 1
    Yeah, that's a lot. It looks like this guy has a script to do it, which will hopefully do the trick. http://richardspowershellblog.wordpress.com/2007/10/21/allow-inheritable-permissions-from-parent-to-propagate-to-this-object/ – Katherine Villyard Mar 04 '14 at 23:31