Managing Local User Accounts with Windows PowerShell
In my previous article, I demonstrated how to create a local user account with Windows PowerShell. In today’s article, I want to cover some basic management tasks that can be done with PowerShell.
The first step is to use ADSI and get the local user account object.
PS C:\> [ADSI]$HelpDesk="WinNT://CHI-FP01/HelpDesk,User"
Remember, the WinNT moniker is case sensitive.
One task you are most likely to need is changing the local account password. If you pipe the ADSI object to Get-Member, you won’t see any methods; you just have to know they are there, such as SetPassword(). This is the same method we called when we set up the account.
Say Goodbye to Traditional PC Lifecycle Management
Traditional IT tools, including Microsoft SCCM, Ghost Solution Suite, and KACE, often require considerable custom configurations by T3 technicians (an expensive and often elusive IT resource) to enable management of a hybrid onsite + remote workforce. In many cases, even with the best resources, organizations are finding that these on-premise tools simply cannot support remote endpoints consistently and reliably due to infrastructure limitations.
PS C:\> $HelpDesk.SetPassword("[email protected]")
The change is immediate and there is no need to call SetInfo(). By the way, if you want to see how old a password is, you can look at the PasswordAge property.
PS C:\> $helpDesk.PasswordAge 1775
This is a value in seconds. So if you wanted to get the age in days all you need to do is divide it by 86400.
PS C:\> [ADSI]$Admin="WinNT://CHI-FP01/Administrator,user" PS C:\> $admin.PasswordAge.value/86400 269.749664351852
Changing Group Membership
When I set up the HelpDesk local account, I added it to the Power Users group. Well, the account needs to belong to the local Administrators group so I need to fix group membership. First, I’ll remove the account from the Power Users group.
PS C:\> [ADSI]$power="WinNT://CHI-FP01/Power Users,group" PS C:\> $power.Remove($HelpDesk.Path)
The change is immediate. Now I’ll get a reference to the local administrators group and add the Help Desk account.
PS C:\> [ADSI]$Admins="WinNT://CHI-FP01/Administrators,group" PS C:\> $Admins.Add($HelpDesk.path)
I don’t think it can get any easier.
Disabling the Account
There may come a time when you need to disable the local account. This is part of the accounts’ userflags bitmask value, which requires some little bitwise operations. We’ll need to work with the value that indicates if an account is disabled.
PS C:\> $AccountDisable=0x0002
First, I’ll verify the account is currently enabled by performing a bitwise AND operation:
PS C:\> ($HelpDesk.UserFlags.Value -band $AccountDisable) -as [boolean] False
I cast the result as a Boolean to make it easier to interpret the results. To disable the account, I’ll need to do a bitwise OR and assign the value to the userflags property.
PS C:\> $new=$HelpDesk.UserFlags.Value -bor $AccountDisable PS C:\> $HelpDesk.put("userflags",$new) PS C:\> $HelpDesk.SetInfo()
I can verify by refreshing my cached copy of the object and re-running my –band expression.
PS C:\> $helpdesk.refreshcache() PS C:\> ($HelpDesk.UserFlags.Value -band $AccountDisable) -as [boolean] True
To re-enable it almost uses the same steps, except you need to use a bitwise XOR operation.
PS C:\> $new=$HelpDesk.UserFlags.Value -bxor $AccountDisable PS C:\> $HelpDesk.put("userflags",$new) PS C:\> $HelpDesk.SetInfo() PS C:\> $helpdesk.refreshcache() PS C:\> ($HelpDesk.UserFlags.Value -band $AccountDisable) -as [boolean] False
Deleting the Account
Finally, the day may come when you want to delete the account all together. Remember, the account is a child object of the computer so that’s where we need to do the deletion. First, get an ADSI object for the computer.
PS C:\> [ADSI]$server="WinNT://CHI-FP01"
Then call the Delete() method, specifying the type of object and its name.
PS C:\> $server.delete("user",$helpdesk.name.value)
The change is immediate and there is no need to call SetInfo().
Managing local user accounts obviously can also be done just as easily with the legacy NET commands, which you could easily incorporate into a PowerShell remoting command or session. If you have a larger PowerShell based task that involves local user accounts, using ADSI object is the right approach.