The Sysadmins

Tips and tricks from the Sysadmins

Category: Security

Deploying Microsoft LAPS – Non-Persistent VDI

Deploying Microsoft LAPS to a non-persistent VDI environment requires a slightly difference approach to traditional machines, especially for those environments that force a reboot after user log off (e.g. Citrix XenDesktop using PVS).


  1. Computer Boots up for the first time after LAPS installation and GPO configuration
  2. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed which will read 0 as a password has never been set for given computer
  3. New password is set on the Computer, written to Active Directory and the ms-Mcs-AdmPwdExpirationTime attribute is updated giving an expiry date for the password (as per the Group Policy “password age (days)” setting)
  4. Computer is restarted and boots the golden image
  5. LAPS CSE views ms-Mcs-AdmPwdExpirationTime when Group Policy is refreshed, the value is now populated with an expiry time for the password set in step 2
  6. Computer does not update password
  7. LAPS is not functional


Originally I looked at clearing the ms-Mcs-AdmPwdExpirationTime attribute on shutdown with VBS.

Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0 
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD 

This can also be accomplished with PowerShell but requires you install the Remote Server Administration Tools which wasn’t desirable. Running the script on shutdown was unsuccessful, due to an issue with how Citrix Delivery Controllers manage the shutdown process of the virtual desktops, essentially preventing the script from running. More information here: Logoff Script is terminated early on XenDesktop.  This may not be an issue for you if you are using another VDI solution.

After trying a few other methods, the following has proven to be reliable. The VBS script sets the ms-Mcs-AdmPwdExpirationTime attribute to 0, waits 3 minutes and then runs GPUpdate to trigger a password update. The 3 minute pause is insurance that the ms-Mcs-AdmPwdExpirationTime change has been replicated to other DCs within the same site. With this method you are essentially setting a new password and expiry date at every startup, maybe Microsoft will add this as a feature in a future release of LAPS.

Add this to a startup script either in Group Policy or locally on the golden image with gpedit.msc and enjoy LAPS within your VDI environment!


Set objSysInfo = CreateObject("ADSystemInfo")
Set objComputer = GetObject("LDAP://" & objSysInfo.ComputerName)
' Change ms-Mcs-AdmPwdExpirationTime attribute to 0 
objComputer.Put "ms-Mcs-AdmPwdExpirationTime", "0"
' Write change to AD
' Sleep 3 minutes
Set WshShell = CreateObject("Wscript.Shell")
' Run GPUpdate force and target only the computer policies
Result = WshShell.Run("cmd /c echo n | gpupdate /target:computer /force",0,true)
' Exit with code

Deploying Microsoft LAPS – Part 2

We recently covered preparing Active Directory and deploying the LAPS CSE/Client to the machines you wish to manage in part 1 of deploying Microsoft LAPS. Part 2 covers “Turning on” LAPS via Group Policy, the LAPS process and how it works once deployed.

Group Policy

On your LAPS management machine, head to C:\Windows\PolicyDefinitions, there you will find AdmPwd.admx and AdmPwd.adml (under en-US). Copy these files into your Group Policy Central Store, if you do not have a Central Store (and do not which to create one) you can launch Group Policy Management Console directly from your management machine, or copy the ADMX/ADML to a Domain Controller where you will be editing the policy.


Create a new GPO and navigate to Computer configuration -> Policies -> Administrative Templates -> LAPS


Password Settings
This is where you’ll choose your password policy. The default is complex passwords, 14 chars and a password age of 30 days (machines will automatically change their password when this is met).

Continue reading

Deploying Microsoft LAPS – Part 1

What is LAPS?

A lot of organisations will use the same local administrator password across all machines, which is a bad idea for a number of reasons. At a basic level, if this password is learnt, it allows anyone to install software as an administrator – at a higher level it facilitates things such as pass the hash, mimikatz and general reconnaissance against your machines (usually with the goal of elevating to Domain Admin).

If you currently deploy your Local Administrator Account via Group Policy Preferences, this makes things even easier for an attacker to obtain the shared local administrator password. The CPASSWORD value is easily searchable against SYSVOL and Microsoft provide the 32-byte AES key which can be used to decrypt the CPASSWORD. Alan has a great post here why you should stop using Group Policy Preferences for deploying Local Administrators.

So what can we do?

LAPS – Local Administrator Password Solution! This is Microsoft’s solution to managing Local Administrator account passwords across an organisation. LAPS solution features include:

• Sets a unique randomly generated password PER machine
• Automatically change the Local Administrator Password every x days
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Password is protected during the transport via Kerberos encryption

Deployment Steps

  1. Installs LAPS onto management machine
  2. Extend Schema and prepare Active Directory
  3. Deploying LAPS client to those machines you wish to manage
  4. Configure Group Policy to enable and set the relevant policies

This post will cover steps 1, 2 and 3.

Management Machine

First off, we’re going to install the management portion of LAPS. Download LAPS here and next, next through the installation. On the custom setting page choose all of the management tools. The AdmPwd GPO Extension is required if the machine you’re installing the management portion on will also be managed by LAPS.

Continue reading

Wi-fi Protected Setup (WPS) Vulnerability Exploited

In the last few days I’ve been following this vulnerability with interest, and boy- it’s been fun!

What is WPS?

Wi-Fi protected set-up (WPS) was designed to ease the task of joining clients to a wireless network. The user simply types an 8 digit numeric pin, which transparently gives the user the WPA/WPA2 PSK and allows them to join the wireless network. So far so good.

So what is the exploit and how big a deal is it?

Currently WPA/WPA2 exploits are long winded and typically involve testing the PSK against large dictionaries, which takes a huge amount of computing resources and time. On top of that, more often then not they’re unsuccessful.

Stefan Viehböck discovered a vulnerability in WPS which allows its PIN to be discovered much quicker than brute forcing the PSK, which in turn exposes the WPA/WPA2 PSK. The exploit is explained in detail in a document here but here’s a quick break down of why it’s so fast.

There are 8 digits in the pin, the 8th being a checksum of digits 1-7. So with 7 digits left, it then gets interesting: during a WPS negotiation attempt, the system acknowledges when the first 4 digits of the PIN are correct. So we try up to 10^4 keys first, then 10^3 keys plus the checksum. There are around 11,000 keys/PINs to be attempted, but because of how the exploit works, searching half of the key space first, on average the number of keys that are probably tried before the right one is found is around half that. That small number means the key space can be tested in a relatively small amount of time, typically somewhere between 4 and 10 hours.

WPS is enabled on a lot of Wi-Fi access points by default, especially on Wi-Fi-equipped modem routers issued by ISPs. Some routers will actively block multiple attempts, or slow down requests- a spreadsheet of tried and tested devices can be found here.

The obvious solution is to disable WPS, if you can, but on a larger scale newer firmware will need to be deployed to completely mitigate the flaw. That’s something that will take time, and something that’s hard to communicate with the general public, so I foresee a lot of WPS-enabled APs in circulation for some time.

How to perform the exploit

There are a couple of valuable tools that can use the exploit that are available for pentesting your current AP infrastructure; it’s especially worth doing so if you’re unable to turn WPS off. The tools are very easy to use, and please note I don’t advocate performing this on anything but your own environment.

Linux distro of choice (Backtrack 5R1)
Supported Wireless Card (Realtek RTL8187L)
Reaver ( or (, I’ve focused on Reaver.

tar -xvf reaver-1.3.tar.gz
cd reaver-1.3/src
make install

##Make sure your wireless card is detected
##Put the wireless card into monitor mode
airmon-ng start wlan0
##Show Wireless networks with strength and more importantly the BSSID needed for Reaver
airodump-ng mon0

reaver -i mon0 -b BSSID 

…and off it goes. There are currently some bugs that are being ironed out and as mentioned earlier some APs will throttle or simply lock out multiple requests.

As you can quite clearly see this is extremely easy to perform and potentially exposes a large security flaw in any WPA/WPA2-protected network with WPS enabled. I’ve run Reaver against two of my spare APs and it’s been successful both times with a completion time of around 6 hours. The tools can be used for pentesting using exploit, but in the wrong hands the tools provide a ridiculously easy method for anyone to gain unauthorised access, if your AP infrastructure is vulnerable. If WPS-protected Wi-Fi networks you administer are vulnerable, take steps to protect them.