active directory delegation problem

I have created a non-admin user and enabled "Account is trusted for delegation". Then I create a OU to which I assign delegation rights to that non-admin user. I unchecked policy inheritance, and proceed to create a domain admin account in the aforementioned OU. When the non-admin user attempt to exercise it's delegated rights all is well and the admin is being managed. About 1 day later, apparently after replication to other domain controllers, the right seems to be gone and the non-admin can no longer manage the admin, however if I create a new admin in the OU, I can manage it(for about 24 hours)...... Does anyone have some suggestions on how to get to the bottom of this? Thanks in advance for the help.
LVL 1
pyrokinAsked:
Who is Participating?
 
LauraEHunterMVPConnect With a Mentor Commented:
The delegation you are describing grants write permissions to the userAccountControl attribute, which will allow the ability to modify all of the following account features: http://support.microsoft.com/kb/305144

AdminSDHolder is an all-or-nothing proposition. If a user is a member of a protected group, any delegations that you manually specify will be removed. If a user is not a member of a protected group, AdminSDHolder offers them no protections whatsoever.
0
 
LauraEHunterMVPCommented:
[1] You do not need to enable the "Account is trusted for delegation" option - this refers to Kerberos delegation, which is a different concept than delegation of authority.

[2] The behavior you are describing is by design, and cannot be overcome. See the following for a description of the issue: http://msmvps.com/blogs/ulfbsimonweidner/archive/2005/05/29/49659.aspx
0
 
pyrokinAuthor Commented:
LauraEHunterMVP,

Thanks for the response. In the link providing the description, it points to http://support.microsoft.com/kb/817433. Does this mean there is a workaround?
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
LauraEHunterMVPCommented:
If you read the link involved, you will see that there are multiple potential workarounds.
0
 
pyrokinAuthor Commented:
I'm a little confused. You said "The behavior you are describing is by design, and cannot be overcome".  Do you know if any of these would work in my scenario? Would it be possible for you to elaborate on Method 2, as this is a little over my head.  Thanks again for your time.
0
 
LauraEHunterMVPCommented:
Method 2 involves modifying the default security descriptor for all protected groups managed by adminSDHolder. This is not a best practice and is not recommended by most in the AD profession. Allowing a non-DA to manage the account of a DA is an inherent security risk, and should not be permitted despite the fact that you "can" do so using the workaround listed in the KB article.
0
 
pyrokinAuthor Commented:
Thank you for the clarification. Currently, I have a non-admin user, hosting a windows service(WCF), listening for connections from users to enable and disable the admin account in the OU . I used the delegation wizard to allow that user to enable and disable the admin account. I did this by adding the following delegwiz.ini

[template48]
AppliesToClasses=domainDNS,organizationalUnit,container

Description = "Enable a disabled user account"

ObjectTypes = user

[template48.user]
userAccountControl=WP


  Do you think this delegation will allow some unintended privileges to gain access to the admin account? Does the delegation wizard have flaws that get corrected by the hourly AdminSdHolder-Thread?  
0
 
LauraEHunterMVPCommented:
If the "admin account in the OU" is a member of one of the protected groups that is covered by AdminSDHolder, any delegated permissions on this account will be reset automatically, regardless of any delegations that you have manually established. The only recommended workaround is to configure the admin account itself with delegated permissions such that it is not a member of a protected group.
0
 
pyrokinAuthor Commented:
You lost me..Could you provide an example "The only recommended workaround is to configure the admin account itself with delegated permissions such that it is not a member of a protected group."
0
 
LauraEHunterMVPCommented:
Configure the "admin account for the OU" (since this is your terminology, I cannnot comment on the specifics of how this account is or is noty configured) with only the specific permissions that it requires. Do not make the account in question a mrember of any protected group.
0
 
pyrokinAuthor Commented:
LauraEHunterMVP,

   Thanks again for all your input. My final 2 questions are :

Do you think this delegation will allow some unintended privileges to gain access to the admin account which was added to the OU i created? and if so does the delegation wizard have flaws that get corrected by the hourly AdminSdHolder-Thread?  

[template48]
AppliesToClasses=domainDNS,organizationalUnit,container

Description = "Enable a disabled user account"

ObjectTypes = user

[template48.user]
userAccountControl=WP


 
0
 
pyrokinAuthor Commented:
Thanks again.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.