Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win

x
?
Solved

Windows 2008 R2 Active Directory - Delegate Permissions for Help Desk group

Posted on 2016-11-22
13
Medium Priority
?
142 Views
Last Modified: 2016-12-21
We have a Windows 2008 R2 domain and I'm setting up our help desk folks to have certain permissions to perform their tasks.  For example password resets for users.  I've done this before, and wasn''t having any luck with the permissions working.  I found the link below and followed the same steps I performed already (thinking I missed something):
http://www.howtogeek.com/50166/using-the-delegation-of-control-wizard-to-assign-permissions-in-server-2008/
For some reason the permissions aren't working and the help desk folks aren't able to do this task.
I'm not sure if some other underlying permission set somewhere else is over-riding this or denying them.  I'm using a group called HelpDesk to delegate the permissions.
Thank you,
0
Comment
Question by:trinity2007
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 7
  • 6
13 Comments
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41897646
What exactly are you trying to delegate?  Are you trying to scope your delegation to a specific OU?
0
 

Author Comment

by:trinity2007
ID: 41897662
Yes, I apologize I didn't put that in my notes.  Yes, Help Desk to be able to reset passwords for users under our Desktop OU.
0
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41897673
First thing to check is  when you delegate control to the Helpdesk  group on the Desktops OU, they have "Allow" on the "Reset Password" extended right for all descendant user objects
0
Veeam Task Manager for Hyper-V

Task Manager for Hyper-V provides critical information that allows you to monitor Hyper-V performance by displaying real-time views of CPU and memory at the individual VM-level, so you can quickly identify which VMs are using host resources.

 

Author Comment

by:trinity2007
ID: 41897683
Yes, that is there.
0
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41897697
Have the target users who you want to reset passwords been in the group for a while?  If not, have them logoff/logon to update their tokens (otherwise their current session doesn't have the right membership)

If you look at the OU permissions, using "Advanced" view, what do you see in there?  Are there any explicit denies?
0
 
LVL 6

Accepted Solution

by:
sAMAccountName earned 2000 total points
ID: 41897758
If you are still having issues, try creating a brand new group and a new test user so you arent bumping into an incorrect delegation attempt - it may be easier to start fresh).

In the below example, I'm using the group:   "Helpdesk"
and the OU:   "OU=Accounts,DC=corp,DC=pbzeppelin,DC=com"

Running this bit of powershell created the proper delegation to allow members of "Helpdesk" to reset passwords for any user under  "OU=Accounts,DC=corp,DC=pbzeppelin,DC=com"

# Change to the PSDrive "Active Directory" provider
Set-Location ad:

# make a reference to the RootDSE
$RootDse = Get-ADRootDse


# Create a reference to the group we want to delegate permissions to:
$DelegationGroup = "Helpdesk"
$DelegationGroupSID = New-Object System.Security.Principal.SecurityIdentifier (Get-ADGroup -Identity $DelegationGroup).SID


# Create two hash tables to store the GUID values for each schema class and extended right so we can reference them by names instead of GUID
# You can use these to look up what is available to you as well
$SchemaClassObjGUIDMap = @{}
Get-ADObject -SearchBase ($RootDse.SchemaNamingContext) -LDAPFilter "(schemaidguid=*)" -Properties lDAPDisplayName,schemaIDGUID | ForEach {$SchemaClassObjGUIDMap[$_.lDAPDisplayName]=[System.GUID]$_.schemaIDGUID}

$ExtendedRightsMap = @{}
Get-ADObject -SearchBase ($RootDse.ConfigurationNamingContext) -LDAPFilter "(&(objectclass=controlAccessRight)(rightsguid=*))" -Properties displayName,rightsGuid | ForEach {$ExtendedRightsMap[$_.displayName]=[System.GUID]$_.rightsGuid}


# Create a reference to the BaseDN
$BaseDN = $(Get-ADDomain).DistinguishedName

# Create a reference to the OU we want to delegate ON
$OU = "OU=Accounts,$BaseDN"

# Get the requisite details for the objects we are working with
$OUDetails = Get-ADOrganizationalUnit -Identity $OU
$OUGUID = ($OUDetails).ObjectGUID
$OUAcl = Get-ACL -Path $OUDetails

# Create the construct which will represent the new ACL Rule
$OUAcl.AddAccessRule((New-Object System.DirectoryServices.ActiveDirectoryAccessRule $DelegationGroupSID,"ExtendedRight","Allow",$ExtendedRightsMap["Reset Password"],"Descendents",$SchemaClassObjGUIDMap["user"]))


# Write the updated ACL to our target OU
Set-ACL -ACLObject $OUAcl -Path ("AD:\" + $OU)

Open in new window

0
 

Author Comment

by:trinity2007
ID: 41897836
I'll try this in our test environment, and see how it goes.  I probably won't have time today to work through this, I'll let you know tomorrow as soon as I set it up.
Thank you!  I'll keep you posted.
0
 

Author Comment

by:trinity2007
ID: 41899448
I was able to get it working correctly in the test environment - thank you.  So I thought to add one more attribute.  

Next, In addition to the Desktop Support staff able to change password, I wanted them to have the ability to check the box next to 'User must change password at next logon'.  At first it was 'greyed' out, but I found the attribute for that and set it.

For further testing: (I hope I'm not too lengthy on this next step):   I created a security group called 'HelpDesk' and put 2 test users in this group.  Beneath our domain.com:  I created an OU called:   'Departments', and created a test user directly under that.  I applied the delegated permissions for the 'Helpdesk' group to 'Departments' (password reset, unlock user account, and the 'user must change password....' option).  With a user under the 'helpdesk' security group, I can reset passwords, unlock accounts and option to select 'user must change password at next logon' is available to check or uncheck for that user directly under the 'Departments' OU.

Next, under 'Departments' I created a couple additional OU's:   'Accounting', 'Audit' and 'ClientServices', creating users beneath these.  
With a user from the 'Helpdesk' group, I'm able to do the password reset, unlock user account with no problem,  but the 'user must change password at next logon' is still greyed out.  Does it take a little bit for the permissions to propagate?  I did log off with this 'helpdesk' user account and log back on.

Even domain admin account doesn't have the option to check or uncheck the 'user must change password at next logon for any users in these sub-OU's.  Again, perhaps it takes a little bit for the permissions to propagate?  It works for the user directly under the 'Departments' folder, just not for users under the sub-OU's.
I wouldn't think I would have to set these permissions at each OU level, right?

Thanks,
0
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41899742
you should be able to specify child containers as well so the sub out inherits..   on a phone or I'd post the powershell, but its toward the end of the rule construct
0
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41904546
@trinity2007:

Did you get what you needed to make the child container inherit the rule?
0
 

Author Comment

by:trinity2007
ID: 41904581
Yes, I did.  The issue I was having with the 'user must change password at next logon', was because on a couple of the accounts, I had password never expires checked.  Other than that the inheritance is working as expected.  Thank you for your assistance!!!
0
 

Author Closing Comment

by:trinity2007
ID: 41904585
Thank you for your assistance, I certainly appreciate it.
0
 
LVL 6

Expert Comment

by:sAMAccountName
ID: 41904596
Glad to help!
0

Featured Post

Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Here's a look at newsworthy articles and community happenings during the last month.
Let's recap what we learned from yesterday's Skyport Systems webinar.
This video shows how to use Hyena, from SystemTools Software, to bulk import 100 user accounts from an external text file. View in 1080p for best video quality.
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

636 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question