Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

migrated from superuser.com Feb 14 at 21:55

This question came from our site for computer enthusiasts and power users.

1  
    
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? –  Xiuhtecuhtli Feb 15 at 1:08
2  
Is permission inheritance enabled on the problematic objects? Is the AdminCount attribute on them set to anything other than 0? –  MDMarra Mar 3 at 20:10

2 Answers 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.

share|improve this 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. Which permissions do I need to add to allow my site-admin to edit these objects. I know how to find the security tab. –  Xiuhtecuhtli Feb 13 at 18:58

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.

share|improve this answer
    
The OU and ALL the user objects (both working and non working objects) are all owned by the domain\administrator account. –  Xiuhtecuhtli Mar 4 at 22:41
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) –  Xiuhtecuhtli Mar 4 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 4 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. –  Xiuhtecuhtli Mar 4 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. richardspowershellblog.wordpress.com/2007/10/21/… –  Katherine Villyard Mar 4 at 23:31

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.