Set-ADAccountPassword Permissions

Due to the high volume of password resets that we have, I am creating a function where our technicians can quickly authenticate to our Domain Controller through PowerShell and then reset a password for an account.

Each technician is given a domain admin account to the server in the format of their name, ‘firstname.lastname’ which is in the same group as the domain admin account, namely Domain Admins and Administrators. When I run the following commands from the PS console, it fails with the ‘firstname.lastname’ admin account, but is successful with the domain administrator account (See below). Again, the ‘firstname.lastname’ is a member of “Domain Admins” just like the domain administrator account.

Both of the examples below are from the PS console on the domain controller. First one is with a domain admin account ‘first.lastname’. The second is under the domain administrator account.

Third window shows the AD groups ‘firstname .Lastname’ belongs to.

Is this a security feature of Powershell that will only allow the domain administrator to reset passwords?

 

PS C:\Users\brian.clanton> $newPassword = (Read-Host -Prompt "Provide New Password" -AsSecureString)
Provide New Password: *********
PS C:\Users\brian.clanton> Set-ADAccountPassword tptest -NewPassword $newPassword -Reset
Set-ADAccountPassword : Access is denied
At line:1 char:1
+ Set-ADAccountPassword tptest -NewPassword $newPassword -Reset
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : PermissionDenied: (tptest:ADAccount) [Set-ADAccountPassword], UnauthorizedAccessExceptio
   n
    + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.UnauthorizedAccessException,Microsoft.ActiveDirectory.Manag
   ement.Commands.SetADAccountPassword
PS C:\Users\administrator.XXXX> $newPassword = (Read-Host Prompt "Provide new Password" -AsSecureString)
Prompt Provide new Password: *********
PS C:\Users\administrator.XXXX> Set-ADAccountPassword tptest -NewPassword $newPassword -Reset
PS C:\Users\administrator.XXXX>

PS C:\Users\brian.clanton> Get-ADPrincipalGroupMembership brian.clanton | Select-Object Name

Name
----
Domain Users
Group-TechPro-DomainAdmin
Group-TechPro-ExchangeAdmin


PS C:\Users\brian.clanton> Get-ADPrincipalGroupMembership Group-techpro-domainadmin | select Name

Name
----
Domain Admins


PS C:\Users\brian.clanton> Get-ADPrincipalGroupMembership "Domain Admins" | Select-Object Name

Name
----
Administrators
Denied RODC Password Replication Group


PS C:\Users\brian.clanton>

It’s called PowerShell Just Enough Administration (JEA).

Look into JEA and you’ll find ways to allow only certain commands and even the ability to only allow certain parameters. With this, you could give them the ability to only run the one cmdlet Set-ADAccountPassword. Plus they wouldn’t even need an actual account to run it. It would probably need a Managed Service Account to complete this. I’m not sure if the virtual account method would do this for you.

I agree with Russell, creating a JEA endpoint and securing it with a role capability file would be the best method. Then, on the group you give access to the JEA endpoint, they would be able to create a new PSSession to the DC and run that command. With JEA, you are able to not only limit the scope of functions, Cmdlets, and modules, but also limit parameters and values users can enter.

As an example, you can limit the Set-ADAccountPassword to only use the -Identity -Reset and -NewPassword parameters and give the a validation set on what value the -NewPassword parameter can have.

When you create the endpoint, you can run:

$Session = New-PSSession -ComputerName DC1 -ConfigurationName ResetPassword
Import-PSSession -Session $Session -AllowClobber

pwshliquori

Also, you should probably work with your security team to design proper RBAC models for your directory permission.

If I’m reading your post correctly, you are giving domain admin to folks for the purpose of resetting passwords?

that should be considered very… dangerous

Jea most definitely would give you a vastly more secure approach to allow for pw resets and not require DA rights.

You can also delegate the right to reset passwords in ADUC, so it’s not really necessary to use JEA for that specific functionality.
Just google it and you’ll find multiple examples.

You should not hand out domain admin permissions for reseting passwords.

No, the admin accounts are not exclusively for the purpose of changing passwords. These were assigned for other actions by our security team, such as managing our file cluster, terminal servers, exchange servers…etc.

We are on a different domain than the one in our hosting environment, so I am using the pre-existing ‘admin’ account for authentication into that hosting environment.

 

Lastly, this mindset for password implementation for change every 30 -60 -90 days or whatever, has been the bane of our IT admin existence for decades. It’s something I’ve avidly thought was in effective approach. It’s just a self-imposed DOS (denial of service) attack and costly operational implementation due to the undue stress and time on support folks. As well as forcing user to gen up lame passwords just to deal with it.

Now, even NIST and Microsoft finally agrees.

NIST Special Publication 800-63B
https://pages.nist.gov/800-63-3/sp800-63b.html

Summary of Recommendations

Advice to IT Administrators

Azure Active Directory and Active Directory allow you to support the recommendations in this paper:

1. Maintain an 8-character minimum length requirement (and longer is not necessarily better).
2. Eliminate character-composition requirements
.
3. Eliminate mandatory periodic password resets for user accounts.
4. Ban common passwords, to keep the most vulnerable passwords out of your system.
5. Educate your users not to re-use their password for non-work-related purposes.
6. Enforce registration for multi-factor authentication.
7. Enable risk based multi-factor authentication challenges.
https://www.microsoft.com/en-us/research/publication/password-guidance
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/06/Microsoft_Password_Guidance-1.pdf

Stop expiring passwords

Both Microsoft and NIST address password expiration, and they both recommend that passwords should not be arbitrarily expired after some interval unless there’s evidence of compromise. In contrast to on-premises identity systems such as Active Directory, most websites have always followed this rule. I’m not giving them credit for being forward-looking in their password policies, however; they just didn’t want the hassles that password expiration would cause their help desks and their customers.

NIST is rejecting knowledge-based authentication (hints) that can be discovered, or brute forced, by an attacker. Let’s face it, most of the bad guys know your mother’s maiden name by now. They also recommend not using compositional rules because it’s too hard for the user and they don’t provide as much security as originally thought.
https://www.semperis.com/blog/nist-joins-microsoft-in-changing-how-we-should-think-about-passwords

•Remove periodic password change requirements This is one that legions of corporate employees, forced to create a new password every month, will surely be happy about. There have been multiple studies that have shown the requirement of frequent password changes to be counterproductive to good password security; but the industry has doggedly held on to the practice. This will remain controversial for some time, I am sure.

•Drop the algorithmic complexity song and dance
No more arbitrary password complexity requirements, needing mixtures of upper case letters, symbols and numbers. Like frequent password changes, some claim these password policies can result in worse passwords.

•Here is a completely new one… require screening of new passwords against lists of commonly used or compromised passwords
One of the best ways to ratchet up the strength of your users’ passwords is to screen them against lists of dictionary passwords and known compromised passwords. There is even a new product from a company called PasswordPing that will do that for you. They claim to be coming out with an enhancement in the future that will also check for credentials to see if they are listed as having been compromised in other breaches. We have not yet tested the product so this is in no way an endorsement, but it is worth looking into if secure passwords are important to you.

https://www.alvaka.net/new-password-guidelines-us-federal-government-via-nist

For Service accounts, if you have to change them, just use MSA or gMSA automatic password changes.
For default localhost admin accounts, use DSC to change them periodically.
Use a defined, enforce, maintained RABC methodology.

I am a bit confused about what is going on under the hood here. As you can see from my list of group permissions, the account I am using to change the password is in fact a ‘domain admin’ in the system. Should that account not have rights to enter a session and change an AD password?

I totally get it. JEA is one of those things where most people don’t get what’s going on under the hood. At least not at first. No worries.

Overview

Role capability files define what cmdlets/functions you are giving the users. Session configuration files define who gets those permissions and how the session is performed (either using a virtual account or group managed service account). Virtual accounts don’t actually exist anywhere, but are created on the fly using the session configuration and role capability. Group managed service accounts are special service accounts in Active Directory. You only use group managed service accounts when you need the account to access things off of the server they just logged into.

Process

  1. Set up role capability files on the server where the work needs done.
  2. Then register a session configuration that gives an Active Directory group permissions to certain cmdlets via the role capability file.
  3. Use the session name when you import the PSSession.
I use this with regular user accounts, rather than administrative accounts. This allows us to limit who gets an administrative account, reduces the number of passwords users have to remember, and keeps the sessions on virtual accounts that don't persist on the servers.

So, if I were to recommend something to you, it would be to remove those Domain Admin accounts and give those users’ regular accounts specific cmdlets (probably even specific parameters for those cmdlets) to use for their duties. Domain Admin accounts are best kept under lock and key with frequently rotating passwords. Maybe use a cool tool like CyberArk for those all-too-powerful Domain Admin accounts.