PowerShell/ADSI Permission Issue with AD related tasks

Question

I'm working on a PS script that will give users a GUI & a few buttons to click to do some basic tasks such as unlocking an account, enabling/disabling, changing passwords and killing processes / logging user off. The parts that do NOT work are : enable/disable users and change passwords.

First of all, everything works as a domain admin but I can not make the user a domain admin, so please do not suggest that :)

Here's the change password part:

    $name = "osman"
    $Searcher = [ADSISearcher]"(sAMAccountName=$Name)"
    $Results = $Searcher.FindOne()
    $password = "pezevenk@321"

    [string]$adspath = $Results.Properties.adspath
    $enable = [ADSI]$adspath
    $enable.psbase.invoke("SetPassword", $password)
    $enable.psbase.CommitChanges()

The Error is pretty generic:

Exception calling "Invoke" with "2" argument(s): "Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))"
At line:14 char:13
+             $enable.psbase.invoke("SetPassword", $password)

Now, obviously, I've tried to give proper permissions to the user before even I attempted this: The user I'm running this with has the "reset password" and "change password" rights delegated on the "Users" folder in AD which includes all the users.

Is there any way to see exactly what permission I'm missing? Can you guys think of anything else that is required?

Edit: These are the permissions for the OU:

"CN=Users,DC=domainname,DC=root,DC=com","All","User","ReadProperty, GenericExecute","Descendents","00000000-0000-0000-0000-000000000000","bf967aba-0de6-11d0-a285-00aa003049e2","InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","Pwd-Last-Set","User","ReadProperty, WriteProperty","Descendents","bf967a0a-0de6-11d0-a285-00aa003049e2","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","Lockout-Time","User","WriteProperty","Descendents","28630ebf-41d5-11d1-a9c1-0000f80367c1","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","User-Account-Control","User","WriteProperty","Descendents","bf967a68-0de6-11d0-a285-00aa003049e2","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","User-Force-Change-Password","User","ExtendedRight","Descendents","00299570-246d-11d0-a768-00aa006e0529","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","User-Change-Password","User","ExtendedRight","Descendents","ab721a53-1e2f-11d0-9819-00aa0040529b","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","False","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","User-Change-Password","User","ExtendedRight","Descendents","ab721a53-1e2f-11d0-9819-00aa0040529b","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","True","ContainerInherit","InheritOnly"
"CN=Users,DC=domainname,DC=root,DC=com","User-Force-Change-Password","User","ExtendedRight","Descendents","00299570-246d-11d0-a768-00aa006e0529","bf967aba-0de6-11d0-a285-00aa003049e2","ObjectAceTypePresent, InheritedObjectAceTypePresent","Allow","domainname\osman","True","ContainerInherit","InheritOnly"

First thing that pops into my head is that those actions might require an elevated access token (elevation of your script). — HopelessN00b, Mar 24 '15 at 21:05
1. Can you post the given permissions? 2. You know you can do a GUI just like that with the existing AD.msc along with custom right click commands? — EliadTech, Mar 24 '15 at 21:37
Does the user in question have the `adminCount` attribute set to 1? — Mathias R. Jessen, Mar 24 '15 at 22:12
@HopelessN00b Yes it works with elevated PS. Script works with a domain admin user. — user2629636, Mar 24 '15 at 23:32
@EliadTech I will post the permissions. Which GUI are you talking about? Can you give me a link to read it? — user2629636, Mar 24 '15 at 23:33
@MathiasR.Jessen It is not set to anything. What does that attribute control? — user2629636, Mar 24 '15 at 23:36
@user2629636 it doesn't control anything, but [it indicates SDProp interference](http://serverfault.com/a/665331/105072) - that doesn't seem to be the case here though. — Mathias R. Jessen, Mar 25 '15 at 00:51
Have you checked the effective permissions on the "osman"-user for the user you are trying to change his password from? Even if you delegate permissions in ADDS there might be objects that does not have inheritance turned on. — Zerqent, Mar 25 '15 at 08:24

score 1 · Answer 1 · answered Mar 25 '15 at 08:16

1

You can edit the original AD.msc and add functionality as you like.
Here are some links:
Custom AD console
Right Click password reset
Right Click Unlock
Add additional columns

answered Mar 25 '15 at 08:16

EliadTech

1,230
9
14

score 0 · Answer 2 · answered Mar 24 '15 at 22:35

The only way I know of for a user to set their own password is this command. Set-ADAccountPassword -Identity $Name -Reset -NewPassword (ConvertTo-SecureString $Password -AsPlainText -force) -PassThru It will prompt them for their current password or if you leave out NewPassword it will prompt for both. If you are trying to give a helpdesk type person these rights make sure you are not testing on an administrative account since they will never be able to change the password on an administrative user they are protected with the attribute adminCount = 1. I have successfully allowed help desk personnel to change passwords in ADUC with change password permission on the user OU. We ended up buying a product to allow users to reset their own passwords. I know it doesn't exactly answer your question but I hope some of this information helps.

I don't want AD module for this script to load. And I do know that my script works with domain admin credentials. So I don't plan on changing that. But thanks for the suggestion — user2629636, Mar 24 '15 at 23:31

score 0 · Answer 3 · answered Mar 25 '15 at 16:04

0

I've noticed the problem: The destination user "osman" I was testing this on was a domain admin and apparently, domain admins do not inherit delegation (no idea why, not documented as far as I can see). All other non-admins work just fine! Thanks for all you suggestions.

answered Mar 25 '15 at 16:04

user2629636

752
5
19
38

See Matthis comment above: http://serverfault.com/questions/677981/powershell-adsi-permission-issue-with-ad-related-tasks/678082#comment832008_677981 – EliadTech Mar 25 '15 at 18:40
@EliadTech I don't understand the relevance. – user2629636 Mar 26 '15 at 02:01
You wrote you don't understand why this domain admin wasn't receiving the ACLs you applied (correct me if I misunderstood you). He explained in is his linked post about the process that runs in the AD and changes the ACLs of protected objects. – EliadTech Mar 26 '15 at 06:00

PowerShell/ADSI Permission Issue with AD related tasks

3 Answers3