- Managing shared mailboxes in Office 365 with PowerShell - Thu, May 5 2016
- Managing shared mailboxes in Office 365 with the GUI - Wed, May 4 2016
- Installing and configuring the Enhanced Mitigation Experience Toolkit (EMET) - Wed, Mar 16 2016
Local Administrator accounts on workstations and servers are still a necessity in most enterprise environments today. These accounts are often needed for management purposes as an IT backdoor should the computer have network difficulties or issues contacting Active Directory. The problem with these accounts is that, most times, the passwords are set once at OS deployment time and they never change again. Even worse, the same password gets used over and over across hundreds or even thousands of computers. This opens up corporate networks to massive risk should an attacker get access to the local password database on one of these systems.
Managing administrator passwords with Group Policy Preferences ^
In the past, it was possible to use Group Policy Preferences to update local Administrator passwords for domain-joined computers. In the Group Policy Management Console (GPMC), right-click a Group Policy Object (GPO) and go to Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups. Right-click in the open area on the right and choose New > Local User.
On the New Local User Properties window, you can change the User Name field to Administrator (built-in), but you’ll quickly notice that the Password and Confirm Password fields are grayed out and can’t be used on any management station that is fully patched.
Password field grayed out in New Local User Properties
In May 2014, Microsoft released a security advisory, MS14-025, for passwords stored in Group Policy Preferences. These passwords that use the CPassword attribute use an easily reversible encryption. This means that any user with access to the Sysvol folder (which is everyone in AD) can pull any GPOs that contain CPasswords, reverse the encryption, and learn passwords for local accounts (including Administrator accounts) that are modified using Group Policy Preferences. In addition, because the password change is being pushed out to whole Organization Units (OUs) of systems, the attacker instantly knows the password to all the systems that are receiving the setting from the GPO.
The MS14-025 security advisory includes an update that disables the ability to use Group Policy Preferences for updating local user account passwords as well as other uses of CPassword such as mapping drives, services, scheduled tasks, and ODBC data sources. In other words, don’t use Group Policy Preferences for managing passwords to local Administrator accounts.
Introducing LAPS ^
The solution to this problem is the Microsoft Local Administrator Password Solution (LAPS for short) that was released on May 1, 2015. LAPS allows you to manage the local Administrator password (which is randomized, unique, and changed regularly) on domain-joined computers. These passwords are centrally stored in Active Directory and restricted to authorized users using ACLs. Passwords are protected in transit from the client to the server using Kerberos v5 and AES.
The LAPS UI app
LAPS requires the .NET Framework 4.0 and PowerShell 2.0 or higher. On server systems where LAPS will manage the local Administrator password, you must be running Windows Server 2003 SP1 or higher; on desktop systems, you must be running Windows Vista SP2 or higher. (Sorry, but there’s no support for Windows XP.) For all the desktop and server client systems, an MSI file that includes a Group Policy client side extension (CSE) must be installed for the local Administrator password to be managed.
Your Active Directory environment will need to be running at least Windows Server 2003 SP1 and will require a schema update to support LAPS to add the ms-Mcs-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes. These attributes are used for storing the local Administrator password and the password’s expiration time.
The biggest limitation of LAPS is the need to update the Active Directory schema. For some organizations, this isn’t an issue. But for other organizations, getting a schema change tested and approved through a change control process can be difficult.
LAPS is also only capable of managing the local Administrator account on domain-joined machines or a custom local Administrator account if you create your own local Administrator account. (Note: it can also manage the password of the local Administrator account if you’ve chosen to rename the account.) If the machine isn’t domain-joined, you won’t be able to use LAPS. LAPS also can’t manage other local service accounts for things such as SQL or scheduled tasks.
If you’re just looking for a way to rotate passwords on the local Administrator accounts for your workstations and servers, the Microsoft Local Administrator Password Solution is a free, easy-to-use option for your organization. In the next part of this series, I’ll cover setting up your Active Directory environment for LAPS.