Deployment Guide

Quick Start Steps

Updated: 22 Jul 2017

The following are a list of the major steps that need to be completed to install ADMPWD.E in  default configuration. Commands are single lines and have been wrapped for readability. Detailed information for each step is located in the referenced section.

  1. Install Management Tools

Msiexec /i AdmPwd.E.Tools.Setup.<platform>.msi ADDLOCAL=Management.PS,Management.ADMX,Management.UI /q

  1. Modify the Active Directory Schema

Update-AdmPwdADSchema

  1. Create Groups for PDS servers and add PDS servers as members
  2. Add Service Account Permissions to normal and deleted computers

Set-AdmPwdPdsPermission -AllowedPrincipals <name of Password Decryption Service Servers Group> –Identity <name of the OU to delegate permissions>

Set-AdmPwdPdsDeletedObjectsPermission -DomainDnsName <name of domain> -AllowedPrincipals <name of Password Decryption Service Servers Group> 

  1. Add Machine Rights

Set-AdmPwdComputerSelfPermission -Identity <name of the OU to delegate permissions>

  1. Add Password Reader Rights

Set-AdmPwdReadPasswordPermission -AllowedPrincipals <name of Password Readers Group> -Identity <name of the OU to delegate permissions>

  1. Add Password Resetter Rights

Set-AdmPwdResetPasswordPermission -AllowedPrincipals <name of Password Resetters Group> -Identity <name of the OU to delegate permissions>

  1. Install Password Decryption Service
  2. Generate keypairs

New-AdmPwdKeyPair -KeySize <Keysize of 1024, 2048, 3072 or 4096>

  1. Edit Group Policy
  2. Distribute Software to clients

 Requirements

 Management Tools

  • .NET Framework 4.0
  • PowerShell 3.0 or newer for command line management

 Client

  • Only x86 and x64 supported (no Itanium, no ARM)
  • Any supported Windows client and server Operating System (including Nano Server)

 Password Decryption Server

  • .NET Framework 4.6
  • Dedicated server (preferred but not mandatory); co-hosting with Domain Controller supported
  • Virtualization supported
  • Server sizing: Any CPU and RAM that supports Windows

Installation

There are three parts to the installation:

  • The management computer(s)
  • The clients you want to manage
  • Password Decryption Service

The installation of binaries and related files are handled by the MSI packages. There are two different installation packages:

The AdmPwd.E.Tools.Setup.<platform>.msi is used to install:

  • Management tools:
    • Fat client UI
    • PowerShell module AdmPwd.PS
    • Group Policy Editor admin templates
  • Password decryption service

The AdmPwd.E.CSE.Setup.<platform>.msi is used to install the CSE only.

File Reference

CSE

Installs to: %ProgramFiles%\AdmPwd\CSE

Files:

AdmPwd.dll Main executable
Client.man Event source manifest

Fat Client UI

Installs to: %ProgramFiles%\AdmPwd\UI

Files:

AdmPwd.UI.exe Main executable
AdmPwdUtils.dll Helper library
AdmPwd.PDSWrapper.dll PDS SDK runtime library


PowerShell Module

Installs to: %WINDIR%\System32\WindowsPowerShell\v1.0\Modules\AdmPwd.PS

Files:

AdmPwd.PS.dll Main executable
AdmPwd.PS.psd1 PS Module manifest
AdmPwd.PDSWrapper.dll PDS SDK runtime library
AdmPwd.Utils.dll Helper library
AdmPwd.PS.format.ps1xml Powershell formatting file
en-US\AdmPwd.PS.dll-Help.xml Help file

Group Policy template

Installs to: %WINDIR%\PolicyDefinitions

Files:

AdmPwd.E.admx Policy definition file
en-US\AdmPwd.E.adml Policy localization file


Password Decryption Service

Installs to: %ProgramFiles%\AdmPwd\PDS

Files:

AdmPwd.Service.exe Main executable
AdmPwd.Service.exe.config Service configuration file
AdmPwd.PDS.KeyStore.dll Keystore interface library
AdmPwd.Utils.dll Helper library
EventManifest.xml Event source manifest
PDS.Messages.dll  Event viewer resource library


Management Computers

The Management computer is a machine that will be used to initially set up and configure AdmPwd.E.  The computer you plan to use as your Password Decryption Server works well as the Management computer.  Copy the two Tools setup files, AdmPwd.E.Tools.Setup.x64.msi and AdmPwd.E.Tools.Setup.x86.msi to a working directory on the Management computer. Double click on the file appropriate for the computer you are using to get started.

2016-11-14_12-57-28

Click Next.

2016-11-14_12-57-51

Read through the End-User License Agreement and check the box to accept the terms and then
Click Next.

2016-11-14_12-58-24

For the first machine you should enable all of the management tools. Do not install the Password decryption service at this time.   Click Next.

2016-11-14_13-01-51

Click Install.

2016-11-14_12-58-43

2016-11-14_13-02-50

Click Finish. 

Managed Clients

Managed client includes any machine on which you want to randomize the local Admin password. This works on servers and workstations. The installation uses a separate installation file that installs the client side extension (CSE) only, AdmPwd.E.CSE.Setup.x64.msi or AdmPwd.E.CSE.Setup.x86.msi depending on the architecture of the client. These can be installed/updated/uninstalled on clients using a variety of methods including the Software Installation feature of Group Policy, SCCM, login script, manual install, etc.

There are many command line options available to automate installation. For a complete list please refer to the Functional specification.

An example that does a silent install and creates a custom local Administrator account is:
msiexec /i AdmPwd.E.CSE.Setup.<platform>.msi [[CUSTOMADMINNAME=<name of new admin account>] [PROTECTBUILTINADMIN=true]] /q
2016-12-15_15-52-24

Parameters CUSTOMADMINNAME and PROTECTBUILTINADMIN are optional; their using will create a new local administrator account and set the existing Administrator’s password to a complex random password.

Installation using Software Installation feature of Group Policy

Create and edit a new GPO, go to Computer Configuration/Policies/Software Settings/Software Installation and create a new Package:

2016-12-15_17-24-24

Note: Two separate packages must be created: x86 and x64.

Select the package, it must be available on the network share accessible by all computers.

2016-12-15_17-26-19

Select Advanced and click OK.

2016-12-15_17-27-17

In the main window select tab Modifications.

2016-12-15_17-29-14

If you need to add modifications stored in MSI Transform file (MST), add them and click OK. See below on description on how to create a MST file.

2016-12-15_17-33-05

For x86 package the entire procedure needs to be repeated in the same way with one exception. After adding the x86 specific MST file, click Advanced Deployment Options

2016-12-15_17-35-08

and deselect:

“Make this 32-bit X86 application available to Win64 machines.”

2016-12-15_17-38-16

Link the policy to the OU(s) with managed computers.

2016-12-15_17-53-16

Note: To enhance security you can disable the local Administrator account using group policy. To do so, open Group Policy Management Editor, navigate to Computer Policy | Windows Settings | Security Settings | Local policies | Security Options and then set the Accounts: Administrator account status setting to Disabled.

Once this is installed you can see it in Programs and Features.

2016-12-15_17-55-02

Creating MSI Transform file

If you want to install client side using Group policy, and want to create new admin account during install, you must create MSI Transform file with required parameters. This is because you cannot pass parameters from command line when installing from GPO. You do this by MSI editing software, such as Orca:

2016-12-15_16-02-07

2016-12-15_16-02-07

2016-12-15_16-16-09

2016-12-15_16-34-12

Note: Transformation file has to be done separately for x64 and x86 versions of MSI files.

Minimall install without MSI

A minimal install can be accomplished by copying AdmPwd.dll and Client.man to the target computer and this commands:

regsvr32.exe "C:\Program Files\AdmPwd\CSE\AdmPwd.dll"

wevetutil im /rf:"C:\Program Files\AdmPwd\CSE\Client.man"

2016-12-15_17-57-56

Note: If you install client by just registering the dll, it will not show up in Program and Features.

Important: This installation option does not perform creation of custom admin account and does not randomize password of built-in admin account. Those actions are available only via MSI installation.

 AD Preparation

All actions below need to be performed from management machine with the PowerShell module installed.

Modifying the Schema

The Active Directory Schema needs to be extended by three new attributes that store the password of the built-in Administrator account for each computer, the timestamp of password expiration and previous passwords for each computer. All three attributes are added to the may-contain attribute set of the user class.

Note: computer class inherits from user class in AD, schema. As a result, new attributes are added to both computer and user objects.

ms-MCS-AdmPwd Stores the current password
ms-MCS-AdmPwdExpirationTime Stores the time to reset the password
ms-MCS-AdmPwdHistory Stores previous passwords

To update the Schema you first need to import the PowerShell module. Open up an Administrative PowerShell window and use this command:
Import-module AdmPwd.PS

2016-11-14_13-46-35

Note: PowerShell module (AdmPwd.PS) is installed to $pshome\Modules\AdmPwd.PS folder. Module is compiled for use with .NET Framework 4.0, however it is also compatible with .NET Framework 2.0.

In Win2008R2 PowerShell below 3.0 (1.0 or 2.0) uses .NET 2.0 even when .NET 4.0 is available. In such case it is recommended to install PS 3.0 (http://www.microsoft.com/en-us/download/details.aspx?id=34595) or higher, or create a custom powershell.exe.config that includes the following section:

<?xml version=”1.0“?>
<configuration>
<startup useLegacyV2RuntimeActivationPolicy=”true“>
<supportedRuntime version=”v4.0.30319“/>
<supportedRuntime version=”v2.0.50727“/>
</startup>
</configuration>

Update the Schema with this command:
Update-AdmPwdADSchema

2016-11-14_13-47-08

Multi-Forest Support

The Solution supports the delegation of permissions across forests, and the administrative tools allow specifying the forest DNS names of where to look for the computer account to retrieve and reset passwords. To enable multi-forest support, the Schema must be updated in each forest separately. Install the PowerShell module and repeat the Schema modification in each forest to be managed.

AD Permissions model

This is a summary of AD permissions necessary for the three attributes for successful operation of the solution:

  • SELF:
    • Read/write ExpirationTime
    • Write Password and Password history
  • PDS Service account(s):
    • Read/write Expiration time
    • Read Password and Password history
    • Enumerate objects in Recycle Bin
    • Read general properties of computer accounts
  • AD administrators:
    • Read/Write Password History

Other user accounts do not need to have any explicit permissions on any of those attributes – AD interaction is done via PDS and authorized using newly created extended permissions.

Note: If you have an RODC installed in the environment and you need to replicate the value of the attribute ms-MCS-AdmPwd and ms-MCS-AdmPwdHistory to the RODC, you will need to change the 10th bit of the searchFlags attribute value for ms-MCS-AdmPwd and ms-MCS-AdmPwdHistory schema objects to 0 (substract 512 from the current value of the searchFlags attribute). For more information on Adding Attributes to the RODC Filtered Attribute Set, please refer to http://technet.microsoft.com/en-us/library/cc754794(v=WS.10).aspx.

Extended rights

Two new extended rights are created in the Configuration Partition that are applicable to the computer object. These rights are created when the Schema is updated.

  • Read Administrator password
  • Reset Administrator password

New permissions are used to authorize Read and Reset admin password operation for admin accounts on specific computers: holders of those permissions are allowed to read and reset admin password on specific computer.

By default, no one is granted any of those permissions (even Domain admins). Delegation of permissions needs to be done as part of initial setup. PowerShell commands exist to simplify delegation of permissions.

Permissions and Groups

The Active Directory infrastructure offers advanced tools for implementation of the security model for this solution by allowing for per-attribute Access Lists (ACLs) and implementing confidential attributes for password storage.

The solution manages permissions in following way:

  • The ability to Read and Reset the Password is controlled by Extended permissions applying to computer objects instead of by direct permissions to read/write AD attributes of computer objects.

Generally, for solution implementation, 3 roles need to be implemented:

  • Password Decryption Service role: has permission to directly interact with AD
  • Password Reader role: has permission to read admin passwords via PDS
  • Password Resetter role: has permission to reset admin passwords via PDS

Best practice is to implement those roles by AD groups, so there are three Groups that need to be created and membership populated. Group names are not specific and can be anything that works for your organization. For this example we will use these:

  • ADMPWDE-PDS-Servers   (Machines running the Password Decryption Service)
  • ADMPWDE-Readers  (Users who need to read the Local Administrator Passwords)
  • ADMPWDE-Readers  (Users who need to reset the Local Administrator Password)

Note: In case if more granular delegation of rights is required, additional groups may need to be created.

Note: Schema update needs to be in place before adding permissions.

Adding Permissions for PDS

There is a PowerShell cmdlet for granting permissions to the Password decryption service to read and write information to Active Directory. This service runs under NETWORK SERVICE by default. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdPdsPermission -AllowedPrincipals <name of Password Decryption Group> –Identity <name of the OU to delegate permissions>
2016-11-14_15-48-06Note: <name of the OU to delegate permissions> is expected to work for any OU provided that OU name is unique. Otherwise <Distinguished Name of the OU to delegate permissions> should be used.

Repeat this procedure for any additional OUs that contain computer accounts that are in scope of the solution and are not subcontainers of already processed containers.

PDS on Domain Controller

If you are running the Password Decryption Service on a Domain Controller you need to also delegate the Service Account permission to NETWORK SERVICE as the Domain Controller tends to access the local instance of Active Directory in the security context of the NETWORK SERVICE account, rather than computer account.
Set-AdmPwdPdsPermission -AllowedPrincipals "NETWORK SERVICE" -Identity <name of the OU to delegate permissions>
Note: Be sure to reboot the machine(s) running Password Decryption Service after making them members of the group.

Deleted computer accounts

If you want to retrieve passwords from deleted computer accounts, you have to add appropriate permissions on Deleted Objects container in AD domain. This is done by the following command:

Set-AdmPwdPdsDeletedObjectsPermission -AllowedPrincipals "NETWORK SERVICE" -Domain <name of the AD domain where permissions are delegated>

After this configuration is done, you can use command Get-AdmPwdPassword -IsDeleted

Adding AD permissions for managed machines

Managed machines access Active Directory using special well-known account SELF, so necessary permissions (see 3.1 for details) have to be added to the SELF well-known account. This is required so the machine can update the password and expiration timestamp of its own built-in Administrator password on own computer accounts in AD. This is done using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdComputerSelfPermission -Identity <name of the OU to delegate permissions>

2016-11-14_15-50-34

Repeat this procedure for any additional OUs that contain computer accounts that are in scope of the solution and are not subcontainers of already processed containers.

Adding Password Reader Rights

Add the extended permission Read Local Admin Password to the group that will be allowed to read the local administrator’s password for managed computers. This is done using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdReadPasswordPermission -AllowedPrincipals <name of Password Readers Group> -Identity <name of the OU to delegate permissions>

2016-11-14_15-50-47

Use the same –Identity name(s) as in the previous command.

Adding Password Resetter Rights

Add the extended permission Reset Local Admin Password to the group that will be allowed to reset the password of the local admin account for managed computers. This is done using PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdResetPasswordPermission -AllowedPrincipals <name of Password Resetters Group> -Identity <name of the OU to delegate permissions>

2016-11-14_15-50-58

Use the same –Identity name(s) as in the previous commands.

Multi-Forest Support

Delegating rights between forests for the PDS and password Reader and Resetter Groups is supported using Global and Universal groups only. Specify the AllowedPrincipals using the “domain\group” syntax when granting rights to users and groups in other domains. 

 Password Decryption Service

Responsibilities for Password Decryption Service are:

  • Maintain RSA key pairs used for local admin password encryption and decryption stored in AD
  • Read and Decrypt local admin password for eligible users
  • Perform Resets of local admin passwords on behalf of eligible users

The Password Decryption Service is thus handling some interactions with AD infrastructure. Computers don’t directly read directly from Active Directory, they only directly write. Instead the Password Decryption Service maintains the decryption keys and is responsible for password reads and decrypts, and for password resets.

The Password Decryption Service runs under the NETWORK SERVICE account by default, so it is accessing Active Directory as the computer account it is running on. It uses its own security context and does not perform delegation. The data transfer between PDS and AD and between PDS and its clients is encrypted with Kerberos encryption. By default the PDS service listens for client requests on port 61184/tcp (configurable).

Note: When the Password Decryption Service is hosted on a Domain Controller it accesses the DC as NETWORK SERVICE rather than the computer account.

The Password Decryption Service is installable from the same MSI packages as management tools and client side: AdmPwd.E.Tools.Setup.x64.msi and AdmPwd.E.Tools.Setup.x86.msi.

Keypairs

To store encrypted passwords in Active Directory, a key pair must be created. For security, only the Key Admin role can generate a new key pair. (By default the Key Admin role is defined as an Enterprise Admin. This is configurable in the AdmPwd.Service.exe.config file). Keypairs are generated using PowerShell. Upon request to generate keys, 2 files will be created in the configured location:

  • 1 file contains public key and is should be distributed to managed machines via GPO
  • 1 file contains private key and is used by the Password Decryption machine(s)

The size of the generated keys is configurable; default minimum is 1024 bit. To generate a new key pair use PowerShell. You may need to run Import-module AdmPwd.PS if this is a new window.
New-AdmPwdKeyPair -KeySize <Keysize of 1024, 2048, 3072 or 4096>

2016-11-14_15-30-04

Key pairs are stored on the file system of the first machine running the Password Decryption Service.

Note: These keys will need to be manually copied to any additional machines running the Password Decryption service.

To view the public key, use PowerShell to export it to a text file. You may need to run Import-module AdmPwd.PS if this is a new window.
Get-AdmPwdPublicKey <keyId> |Export-csv <filename>

2016-11-14_15-32-03

The public encryption key is the text located between the ” ” as seen below.

2016-12-20_17-06-00

Copy the encryption key to the appropriate Group Policy (see details on configuring GPOs)

Service Account Discovery

There is no need to configure clients to find the service. Autodiscovery is done via SRV records automatically maintained by the Password Decryption Service.

2016-12-20_17-32-13

Note: When PDS is running under NETWORK SERVICE account (this is default), then first instance of PDS installed takes ownership of SRV record, preventing other PDS instances to maintain their data on SRV record. It is necessary to grant the PDS role group in AD the necessary permissions on SRV record in DNS as seen beow:

2016-12-20_17-29-01

After granting necessary permissions on SRV record to the group containing all PDS server accounts (e.g. LAPS Servers) the additional instances of PDS may be implemented to allow High Availability using DNS round robin local balancing mechanism. Additional SRV records are created automatically.2016-12-20_17-14-12

Multi-Forest Support

The Password Decryption Service (PDS) servers in multi-forest deployments should be placed in the forest and domain that contains that contains the user accounts. If users are located in multiple domains/forests, then place the PDS in the domain/forest that contains the largest number of users.

The PDS creates its SRV record automatically in the domain where it is located. If domain names are specified in the PDS configuration file, the PDS creates SRV records in all specified domains (provided that the PDS service account has permission to create DNS record in each of the domains).

Group Policy

Group Policy is used to enable the local admin password solution and to configure various settings.

For GPO maintenance, an ADMX/ADML template needs to be installed on machines on which Group Policy Management Console (GPMC) is running.

Important: In environments where a Central Group Policy store is used, the ADMX/ADML files need to be present in the Central GPO store instead of on local machine with GPMC.

When properly configured, a new folder “AdmPwd Enterprise” shows itself in the GPO editor under Computer policy:

Changing the client Group Policy Settings

By default this solution generates random password with maximum password complexity, 12 characters long and changes the password every 30 days. You can change the values to suit your needs by editing a Group Policy. These settings are located in under Computer Configuration\Administrative Templates\AdmPwd Enterprise\Managed clients.

Password Settings

You can change the individual password settings to fits your needs.

Note: Password settings in GPO must follow domain Password Policy, else OS will block password changes to too simple passwords which do not meet requirements of that policy. Else password complexity requirement for local accounts can be adjusted accordingly.

Administrator Account Name

If you have created custom local admin account on managed machines, you will want to configure its name in Group Policy.

Note: DO NOT configure when you use the built-in admin account, even if you renamed it. That account is auto-detected by well-known SID. DO configure when you use a custom local admin account.

Protect against manual changes of passwords

Protection against manual changes of passwords for the managed account is enabled by default. If anyone manually changes the password, this change is detected during the next GPO refresh and a password change is immediately enforced.

Enabling this setting prevents setting a password expiration that is longer than specified in the Password Settings.

Do not allow password expiration time longer that required by policy

Enabling this setting prevents setting a password expiration that is longer than specified in the Password Settings policy.

Enable local admin password management

To start managing computers, enable the password management setting and link the policy to the OU you want to manage.

This setting associates client side GPO extension with GPO and allows CSE to perform local admin account management tasks.

Password Encryption

Passwords can be stored encrypted in Active Directory. Enable this policy and specify one or both keys:

Encryption key field is for key generated by CNG API. Legacy key field is for key generated by legacy CryptoAPI. Clients version 7.5.2.0 and newer support CNG key; older klients support CryptoAPI key. Policy supports both keys, so can configure both newer and older clients.

Note: because of switch to CNG, clients version 7.5.2.0 and newer are not supported on Windows XP and Windows 2003 – to manage this outdated operating systems, pre-7.5.2.0 cliens must be used.

Logging Level

This policy controls logging level for operations on managed machines. If you enable this policy, you can specify desired logging level. If you disable or do not configure the policy, logging level is on default value, which is Errors Only.

Note: If you configure registry value ExtensionDebugLevel, it always takes precedence over this policy setting.

Maintain Password History

Password History is not maintained by default. To enable Password History, enable this policy.

 

Group Policy Settings for management tools

PDS to be used

If you are running multiple PDS instances, you may want to give priority to a specific server. This policy allows you to list the PDS instances to be used by administrative tools. The order of the list indicates the priority.  Enter just the host FQDNs if the PDS listens on the default TCP port (61184) or the FQDN:Port if the PDS listens on custom TCP port.

Note: This setting takes precedence over service discovery via DNS SRV records

AD forests shown in management tools

Enabling this policy defines the list of AD forests supported by the administrative tools.

PDS service runs under domain account

If you enable this policy, it means that you configured PDS to run under domain account, so admin tools use service specific SPN (Svc/AdmPwd) when connecting to PDS.

If you disable or not configure this policy, it means that you configured PDS to run under NETWORK SERVICE account, so admin tools use default SPN (HOST/computerFQDN) when connecting to PDS.