- Managing Clients
- Viewing password settings in Active Directory Users and Computers
- Viewing passwords with the Fat Client
- Fat Client Active Directory Users & Computers Integration
- Retrieving passwords with PowerShell
- Password Maintenance
Updated: 22 Jul 2017
Viewing password settings in Active Directory Users and Computers
Once everything is configured, and Group Policy has refreshed on the clients, you can look at the properties of the computer object and see the new settings. The password can be stored encrypted or unencrypted. Encrypted passwords contain a keyID prefix.
Ex: Unencrypted Password
Ex: Encrypted Password
What happens if a user who hasn’t been granted rights to see the local Administrators password tries to access it? If they were to gain access to the GUI interface the password won’t be displayed. They are also given an Access Denied message.
If they have installed the RSAT tools and run Active Directory Users and Computers (ADUC) to view the password it will show as <not set>.
This information is not seen because only the Decryption Service can read the password. Membership in the Password Readers group tells the service that it is allowed to reveal the password to the user.
The Expiration time is stored as the number of 100-nanosecond intervals that have elapsed since the 0 hour on January 1, 1601 until the date/time that is being stored. The time is always stored in Greenwich Mean Time (GMT) in the Active Directory.
If you want to manually convert it use this command:
w32tm /ntte <number you want to convert>
Viewing passwords with the Fat Client
There is a graphical interface available (Fat Client) that can be installed standalone, in a network share or as an add-in to Active Directory Users and Computers.
The Fat Client can be installed using the AdmPwd.E.Tools.Setup.<platform>.msi. When you install the program on a computer where you want the ability to easily retrieve the password just select the Fat client UI option.
The program you want to run is C:\Program Files\AdmPwd\ AdmPwd.UI.exe. It will be in the menu and may be accessed differently on various operating system versions:
Launch the interface, enter the client name and click Search.
The Fat Client supports running from network shares. To do so, copy all the files contained in the install folder (without subfolders) to a network share.
Users can then run UI from network share without the need to install UI on their machines.
Note: UI running from network share caches itself completely in %TEMP% folder and updates the cached copy of files every time it finds that network copy is updated
Fat Client Active Directory Users & Computers Integration
To be able to launch the Fat Client from Active Directory Users and Computers, you need to install the Fat Client on one machine and copy the following files to a network share with high availability.
%ProgramFiles%\AdmPwd\UI files: AdmPwd.UI.exe, AdmPwd.Utils.dll, AdmPwd.ServiceUtils.dll
In this example the files were copied to folder in the NETLOGON share in SYSVOL.
Open ADSIEdit.msc as a Schema Admin and choose Connect To…
Choose Select well know Naming Context and pick Configuration.
Navigate to: CN=409,CN=DisplaySpecifiers,CN=Configuration,DC=<domain>,DC=<domainsuffix>
Note: When you run different display language that English US, locate container that contains display specifiers your language
Right click on CN=computer-Display and select Properties.
Choose the adminContextMenu attribute and double click to edit it.
Type the following string modifying the position number and network location:
2, Local Admin Password UI…,\\greycorbel.com\NETLOGON\ADMPWDE\AdmPwd.UI.exe
Note: Depending on your environment your position number may vary.
Verify that the position is added and click OK.
After completing the above steps you should verify that the Active Directory console has an additional context menu for a computer object.
Selecting the new menu option should now open the Fat Client from the network share.
Note: You may receive a warning the first time you launch the Fat Client from a Network Share.
To resolve this issue, add file://*.<domain>.<domainextension> to the Local Intranet zone in Internet Explorer.
In this example we used:
Retrieving passwords with PowerShell
You can also get the password using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Get-AdmPwdPassword -ComputerName <computername>
Get-AdmPwdPassword -ComputerName <computername> -IncludeHistory | select -expand PasswordHistory
Passwords can also be retrieved from deleted computer accounts:
Get-AdmPwdPassword -ComputerName <computername> -IsDeleted
Note: This can only currently be done through PowerShell.
Administrators can use the cmdlet Set-AdmPwdPdsDeletedObjectsPermission to delegate the permission of Deleted Objects container to the PDS service account.
Set-AdmPwdPdsDeletedObjectsPermission -AllowedPrincipals <name of the PDS service account> -DomainDnsName <fqdn of the domain>
Note: The account that you’re logged in with needs to have permission to the Write ACL on the Deleted Objects container. If an Access Denied is received running the above command, use the following command to take ownership of the Deleted Objects container.
dsacls "CN=Deleted Objects,DC=<domain>,DC=<domainsuffix>" /takeownership
Resetting the Password
To manually reset the password click the Set button. Password reset request can be either immediate (click Set with the current date and time) or planned (put desired expiration time into New expiration time field). Password will be reset during next GPO update after expiration time expires on respective computer.
You can also reset the password using PowerShell.
Reset-AdmPwdPassword -ComputerName <computername> [-WhenEffective <date time>]
Note: If [-WhenEffective <date time>] parameter is missing, then password reset is effective from now.
Managing Password History
Managing the number of passwords that will be stored in Active Directory is done using PowerShell. Passwords can be limited by date or total number of stored passwords.
It is responsibility of the AD administrator to maintain password history and decide to delete passwords that are no longer needed. The solution itself never deletes any passwords.
Note: The person performing this operation needs to have read/write permission on password history AD attribute. This operation interacts directly with AD – it isn’t routed via PDS.
To keep the last (x) number of passwords:
Update-AdmPwdPasswordHistory -ComputerName:<ComputerName> -KeepLast:5
Note: A wildcard character can be used in place of <ComputerName>.
To keep all the passwords newer than a specific date:
Update-AdmPwdPasswordHistory -ComputerName:<ComputerName> -KeepNewerThan:<Date>
Note: A wildcard character can be used in place of <ComputerName>.