Microsoft LAPS – Deployment and Configuration

KB ID 0001059 

Problem

Microsoft have released the Local Administrator Password Solution (LAPS). What is does is automatically change the load administrator password on workstations, (and servers if required) periodically. It then keeps those passwords securely in AD. Microsoft tried to mitigate attacks from the local admin account back in the days of Windows Vista by shipping with this account disabled, which is fine, but most large deployments I’ve worked on, I’ve been specifically asked to enable the local administrator account and set its password on deployment.

Some organisations create a different account and leave the local administrator account disabled, but they still suffer from the same problem, (all the machines have the same local admin password), and it gets known, if you have a disgruntled ex-employee they may know this password. Yes you can change them all periodically but it’s a bit of a faff. Note: LAPS can manage local accounts that are admin accounts but not necessarily the ‘administrator’ account.

The LAPS solution works by creating some new attributes on the computer object, ms-MCS-AdmPwd which actually stores the password, and ms-MCS-AdmPwdExpirationTime which is the time stamp for the password expiration. What LAPS sets out to do, is provide a random complex password for the local administrator account, and protect that password in AD by use of an AD ACL. In doing so it will protect your machines from a ‘Pass the Hash’ attack which can use common local administrators passwords to compromise a network.

Solution

 

Microsoft LAPS – Step 1 Setup a Management Machine

1. On a management machine download and install the LAPS software, Things will be easier if this machine is also running RSAT tools for Active Directory, and the Group Policy Management Console as well.

2. Be aware you get the documentation form the download page as well. Make sure you get the appropriate x86 or x64 bit version (LAPS supports Server 2003 SP1 and above).

3. Install the software and install ALL the options. (if you apply the defaults it will only install the GPO Extensions), which is what you would want on the ‘controlled machines’ but you want everything on the ‘controlling machine’.

Microsoft LAPS – Step 2 Deploy the software to the machines to be controlled.

1. To be honest this could not be simpler, I just sent the software out as a standard software package via GPO, (watch the video above if you don’t know how to do that). You can script the install and it will also manually install with a /quiet switch to avoid any user interaction. But if you have any amount of machines, GPO is the way to go.

To manually install quietly;

[box]

msiexec /i \\Server\Share\laps.x64.msi /quiet

or simply

msiexec /i c:\laps.x64.msi /quiet

[/box]

2. To check if the client has received the LAPS software, look in Add/Remove programs and you should see it listed (Run > appwiz.cpl {Enter}).

Microsoft LAPS – Step 3 Extend Active Directory Schema

1. It goes without saying that to do this you need to be a member of ‘Schema Admins’. On the management machine run the following two PowerShell commands, to add the two new attributes mentioned above;

[box]

Import-Module AdmPwd.PS
Update-AdmPwdADSchema 

[/box]

Microsoft LAPS – Step 4 Check/Set Permissions to Read Local Admin Passwords

1. On my test network below you can see I’ve got a couple of test Windows 8 machines in an OU called ‘Domain Computers’, this is the OU that I will be working with.

2. The first thing I need to do is grant the rights to the computers themselves to be able to update the password in Active Directory. (If you have nested OU’s, simply apply on the top level OU). Change the value in red to suit your own OU/OU’s.

[box]Set-AdmPwdComputerSelfPermission -OrgUnit ‘Domain Computers‘[/box]

3. To see who has rights to view the passwords in AD (for a given OU), use the following command. Below you can see the default of SYSTEM and Domain Admins is displayed.

[box]Find-AdmPwdExtendedRights -Identity ‘Domain Computers‘[/box]

4. To grant read password permissions to a particular group, use the following syntax, below I have an AD group called HelpDesk setup and I’m adding them into the AD ACL to be able to read local administrator passwords for the Domain Computers OU.

[box]Set-AdmPwdReadPasswordPermission -Orgunit ‘Domain Computers‘ -AllowedPrincipals PeteNetLiveHelpDesk[/box]

Note: If you have multiple groups you can separate/delimit them with a comma.

Microsoft LAPS – Step 5 – Deploy the GPO Extensions to ‘Controlled’ Machines.

1. On the management machine, create a new GPO object, and link it to the OU containing the computers/servers you want to apply the password settings to.

2. Edit the GPO.

3. Navigate to;

[box]Computer Configuration > Policies > Administrative Templates > LAPS[/box]

4. The policy that turns LAPS on is the last one ‘Enable local admin password management’ > Enable it.

5. The actual complexity and age of the password is set in the ‘Password Settings’ policy, > Enable it and accept the defaults.

Note: the other two policies are;

Name of the administrator account to manage: Use if you you have manually created another common admin account on all your machines NOT if you have renamed the local administrator account.

Do not allow password expiration time longer than required by policy: Set to Enabled.

Microsoft LAPS – Step 6 – View the Local Admin Passwords for Controlled Machines.

1. You can do this from PowerShell with the following command;

[box]Get-AdmPwdPassword -ComputerName hostname[/box]

2. Or if you have installed the Fat client, you can launch that from; [box]C:\Program Files\LAPS\AdmPwdUI.exe[/box]

3. Or as it’s an AD object attribute, you can view it on the Computers AD object.

Related Articles, References, Credits, or External Links

NA

Cisco ASA 5500 – Using a Third Party Digital Certificate

(For Identification, AnyConnect, and SSL VPN)

KB ID 0000694

Problem

A client asked me how to do this, so off I went to the test bench to work it out.

Note: I’m this example In going to submit the request to, and issue the certificate from, my own windows domain certificate authority, you would send your request to a third party certificate authority, here’s a direct link to the certificate type you require. To use your own CA every client connecting to the ASA would need to trust this CA.

Solution

Certificates are date specific, so we need to make sure your firewall knows the correct date and time.

1. Connect to the ASA via ASDM > Configuration > Device Setup > System Time > Set the time and time zone correctly.

Note: As shown, from command line simply enter “show clock”.

2. Configuration > Device Management > Certificate Management > Identity Certificates > Add > New > Supply a key pair name > Generate Now.

Note: If using Digicert change the Key Size to 2048 or you will see this error, when you attempt to get your certificate.

Something is wrong
The CSR uses an unsupported key size, please generate a new CSR with a key size of at least 2048 bits
.

3. Select > Set each attribute, and add it one by one (as shown) > OK.

4. Advanced > Set the FQDN to the SAME name you entered for the CN in step 3 > OK > Add Certificate.

5. Choose a location to save the certificate request.

6. Locate and open the certificate request and it should look something like this.

Note: This is the information your certificate vendor will require.

7. Once your request had been processed the certification authority should send you a certificate. (Note: some vendors may send you a text file that you need to rename from filename.txt to filename.cer before it will look like this).

8. With the certificate open (as above) > Certificate path > Select the the Issuing Certificate Authority > Copy to File.

Note: You need to import the root certificates, and depending on the vendor, any intermediate certificates, I’ve shown an example from two major vendors to illustrate.

9. Select “Base-64 encoded…” > Next.

10. Save the cert somewhere you can find it.

11. Open it with notepad, and it should look like this > Select ALL the text.

12. Back at the ASDM > Configuration > Device Management > Certificate Management > CA Certificates > Add > Paste certificate in PEM format > Paste in the text > Install Certificate.

13. Repeat the process for any other RootCA or Intermediate Certificates. Then you will need to go back to step 8 and export the web certificate itself, (i.e. in this case select vpn.petenetlive.net and export that to file, and copy that from notepad to the clipboard).

14. Back in the ASDM this time you will need to install the Identity Certificate, (this is the one you paid for!) > Select the pending request from earlier > Install > Paste in the text > Install Certificate > Apply.

15. To enable the certificate on the outside interface > Configuration > Device Management > Advanced > SSL Settings > outside > Edit > Select the new one from the list > OK > Apply.

16. Note: If you were configuring your AnyConnect VPN’s later this is the point in the setup, where you would select the new certificate.

17. Make sure you can resolve the name that’s on the CN of your certificate and you can reach it from a client machine.

18. Now you should be able to connect without certificate warnings.

19. Don’t forget to save the settings on your ASA (File > Save Running Configuration to Flash).

Related Articles, References, Credits, or External Links

Securing Cisco SSL VPN’s with Certificates

Cisco ASA – Cannot Enable Third Party Certificate (9.4 and later)