Pass the Hash and LAPS are in a way like Yin and Yang, just without giving rise to each other as they interrelate to one another.
Quick how-to on how they work or don’t work together was recently published by Paula J. in here new blog post: Pass The Hash Attack Tutorial.
While on the subject of LAPS – not long ago Jiri Formacek published blog post regarding the impact LAPS implementation has on AD (replication, NTDS.dit size, network bandwidth and GPO size). For all of you interested in knowing more about inner workings of LAPS, check LAPS and AD sizing considerations.
Recently I started following new blog available at CQURE Academy. Since it’s part of CQURE, I guess most of blog posts will be security related. So far most of the content was contributed by Paula Januszkiewicz. For those of you who haven’t heard her name before, you can check her bio at Paula Januszkiewicz.
Her latest blog is “Decrypting SID-protected PFX Files Without Having a Password“.
If you work with Active Directory and Certificate Services or just simply use PFX files and you want to know more about the implementation of SID-protected PFX files in recent versions of Windows, than this is definitely a must read for you.
One simple tip she points out is how to retrieve password of SID-protected PFX file if you are on the “allow list” (there is always a random password being used and it can be seen during the PFX import phase). You can save this password in your secure password database and use it “in case of…”.
More importantly, she is demonstrating how to inspect SID-protected PFX files and how to decrypt them without being on the “allow list”.
To demonstrate this, she is using two tools, created by CQURE:
– CQMasterKeyAD (retrieve master key from AD)
– CQDPAPINGPFXDecrypter (get decrypted password from PFX with known master key)
She plans to show more details about this at Microsoft Ignite. If you’ll be there, be sure to attend her sessions. For those of us, not so lucky, we’ll have to wait for session recordings at Channel 9.
PowerShell just went open source and is already available on few Linux distros as well as Mac OS X.
Not a Linux or Mac fan but I do like the idea.
Check out all the first-hand details in Jeffrey Snover’s recent blog:
PowerShell is open sourced and is available on Linux (video).
I guess now it’s high time to start learning and using GIT.
On the 28th of July 2016 Microsoft released new version of Security Compliance Manager. You can find some basic info about new version here: Security Compliance Manager 4.0 now available for download!
For those of you who haven’t heard about this solution before, it’s a free tool that enables you to quickly configure computers in your environment using Group Policy and/or Microsoft System Center Configuration Manager. New installer currently includes the same set of baselines as its previous version (3.0.60 released on 22nd of January 2013). All baselines include supporting documentation and referenced set of best-practice GPO settings for:
– Exchange 2007 SP3 & Exchange 2010 SP2
– Internet Explorer 8, 9 & 10
– Office 2007 SP2 & Office 2010 SP1
– Windows XP SP3, Windows Vista SP2, Windows 7 SP1, Windows 8
– Windows Server 2003 SP2, Windows Server 2008 SP2, Windows Server 2008 R2 SP1, Windows Server 2012
Main improvements are:
– Windows 10 and Windows Server 2016 support
– Support for existing Windows 10 version 1507, and Windows 10 version 1511 security baselines
– Support for upcoming Windows 10 version 1607, and Windows Server 2016
– Bug fixes for ‘Compare’ and ‘Simple View’ features in SCM
I guess they were a bit in a hurry since they missed few things in SCM version 4.0.00.1:
– File version of the new installer file is the same as it is on the previous version
– LocalGPO.wsf is gone
– no new baselines included
If you liked and used now deprecated LocalGPO.wsf, you can find new version of LocalGPO here: LGPO.exe – Local Group Policy Object Utility, v1.0.
If you have internet access on the computer where you installed SCM, SCM can and does automatically download new versions of baselines for:
– Internet Explorer 11 (Attachments)
– Windows 8.1 (Attachments)
– Windows 10 version 1511 (Attachments)
– Windows Server 2012 R2 (Attachments)
– Office 2013 (Attachments)
– SQL 2012 (Attachments)
If you wander where do all the links come from, you can check this link (SCM does this when checking for updates). It points to the latest version of RssFeed_BaselineUpdateV4dot0.xml. With some imagination and few lines of PowerShell syntax you can automate this process and auto-download new baselines without SCM or for offline use.
How it all began…
Not many Windows admins heard about AdmPwd in the early 2012. I guess one of the reasons was, that we were all still trusting in the secure storage of passwords that were used as part of Group Policy Preferences (GPP) configuration. As probably many of you, I used GPP for setting and resetting passwords for local users on domain-joined Windows systems. Although not that often, I also used GPP for GPO-based management of Scheduled Tasks (which also supported usage of account names and passwords).
Until 2012 I believed that passwords used in GPP-based GPOs were safe since they were encrypted with AES-265. And then it happened – one day somebody decided to publish 32-byte AES key which was used for password encryption in GPP. Some time after that internet became full of tips and tricks on how to find and decrypt passwords stored in SYSVOL (like this one). More than two years later Microsoft released security update that blocked usage of passwords in the affected GPPs (Drive Maps, Local Users and Groups, Scheduled Tasks, Services, Data Sources).
Soon after Microsoft released security update, Microsoft PFE Tom Ausburne wrote blog post How To Automate Changing The Local Administrator Password. He explained part of the story and, more importantly, presented a solution for something a lot of admins were struggling with – how to manage local admin password in this new world without GPPs. The answer was AdmPwd.
Until I read his blog post I didn’t really know much about AdmPwd – although the product and it’s code was already freely available on the internet for more than two years.
As it happens, around the same time as Tom published his blog post, I started working on a project that had high security requirements and one of them was automated management of local admin passwords. With few different options on the table, AdmPwd was chosen as the final solution for this particular requirement.
Some other tools and resources that were also used for securing this particular environment:
– Microsoft Enhanced Mitigation Experience Toolkit (EMET)
– Microsoft Security Compliance Manager (SCM) and it’s LocalGPO Tool (LGT)
– SANS SEC505 course scripts
As luck would have it, Jiri Formacek, developer of AdmPwd, also joined the same project. After few late evening beers and chats with him I got even more interested in AdmPwd. Although I wasn’t responsible for the implementation of AdmPwd, it got me intrigued and I started investing my “free” time into testing and learning about this new tool. I also added his website Local admin password management solution into my “good to know” collection.
LAPS and LAPS.E
With regular updates/improvements and published blog, AdmPwd started gaining wider audience and more acceptance in the enterprise environment. Approximately one year later, AdmPwd became Local Administrator Password Solution (LAPS) and MS made it part of it’s product portfolio (published in Microsoft Download Center and as MS Security Advisory 3062591).
Few months later in 2015, advanced version of LAPS was released – LAPS.E (also known as LAPS-E or LAPS/E). For the last few months, LAPS.E is at version 220.127.116.11 and is not yet included in MS product portfolio. Regardless of this, based on my experience, new LAPS.E is stable and working solution that is by now probably deployed in quite a few enterprise environments.
Important changes between versions
I won’t go deep into details about all the changes between different versions of this solution. If you want to know more about changes between versions and what they bring to the table, I would recommend you to start with reading Description at Local admin password management solution.
If you want to know all the details about the solution, please read technical specification document, available as part of documentation package of the version you are interested in.
What I’ll focus on are three different versions that you can currently download and start testing.
– packaged as MSI installers
– default installation installs only client DLL (Client Side Group Policy Extension)
– dedicated installers for x86 and amd64
– GPO management with custom ADMX/ADML
– PowerShell module for management is AdmPwd.PS
– GUI for management
– require Windows 2003 SP1 and newer DCs
– require AD Schema extension
– require delegation of permissions on computer accounts
– supports only domain joined Windows clients
– support local and AD auditing
– client settings located in registry at HKLM\Software\Policies\Microsoft Services\AdmPwd
– Documentation and Installers
– supports RODC (CSE and admin tools) – solution requires connection to a writable DC
– supports Windows Vista and above, and Windows Server 2003 and above
– updated GUI, PowerShell module and ADMX/ADML files
– same AD Schema as in previous versions
– installation folder for CSE and client tools is %ProgramFiles%\LAPS
– Documentation and Installers
– samples for development of custom LAPS.E support tools and client applications
– Sway-hosted solution overview
– updated AD Schema, GUI, PowerShell module and ADMX/AMDL files
– supports multi-forest deployment
– supports password encryption
– supports password history
– encryption key managed with GPO
– supports Windows XP/2003 and above
– new password decryption service – PDS (on DC or member server; multiple instances for HA)
– management with client tools is done through PDS and not directly on AD objects
– installation folder for CSE and client tools is %ProgramFiles%\AdmPwd
– LAPS and Nano Server
– Testing LAPS for Nano Server with ws2016lab
– tested on TP5 of Nano server
– only works on Nano server
– instead of CSE it works as a Windows Service
– requires PowerShell DSC to configure settings in registry
I started working with AdmPwd when it was at version 18.104.22.168. Since then it got quite far already but it’s still going to go further – and I’m going to follow🙂.
To ease your first or next step with this solution, I wanted to share few tips I learned along the way. To be honest, this is actually the reason why I wanted to write this post for quite some time. Well, this and some encouraging feedback after I posted my last two posts two weeks ago (after 4 years before that).
- Please, do read technical documentation before you start. You can find some nice examples and a lot of explanation on the “how it works” side of things.
- Learn about the solution and test it in non-production environment first.
- Define permission model that supports your organization.
- Define password policy for local admin account.
- Run AD health check.
- Install and use PowerShell module to extend AD Schema (as member of Schema Admins; whoami /groups).
- If deploying PDS server, define location and HA requirements.
- Install and configure PDS server (port, firewall exception, custom service account).
- Delegate needed AD OU permissions.
- Copy ADMX & ADML to Policies, preferably in Central Store.
- Implement new GPO with needed configuration (easier for future upgrade).
- Install CSE on clients.
- Install GUI and/or PowerShell module on management computer.
- Schema update needed when upgrading to version 7 (versions 4, 5 and 6 share the same AD Schema extensions).
- New versions of management tools are backward compatible.
- Upgrade management tools and ADMX/ADML files.
- If you want to support multiple versions with different settings, use dedicated GPOs.
- Prepare new GPOs or set new policies in existing GPOs.
- Only one CSE version can be installed on any client at one time.
- Deploy new CSE to clients.
– Different versions of PowerShell modules and GUI can be deployed on the same management computer in “portable mode” (without installation) as long as they are in different folders.
– Management tools can be stored and run from central location.
– To create “portable” versions of management tools, use admin install for MSI packages:
MSIEXEC /a “LAPS.x64.msi” /qn TARGETDIR=”AdmPwd.Setup.x64″
– To hide software in Programs and Features Control panel view, use msiexec parameter ARPSYSTEMCOMPONENT=1:
MSIEXEC /i “LAPS.x64.msi” /qn ARPSYSTEMCOMPONENT=1
– To create custom local admin account use msiexec with CUSTOMADMINNAME parameter:
MSIEXEC /i “LAPS.x64.msi” /qn CUSTOMADMINNAME=LocalAdmin
– To change default behavior of component installation (CSE only), you can either customize MSI with MST or use msiexec with ADDLOCAL parameter:
msiexec /i LAPS.x64.msi ADDLOCAL=CSE (this is default configuration)
msiexec /i LAPS.x64.msi /qn ADDLOCAL=CSE (silent install, no GUI, default configuration)
msiexec /i LAPS.x64.msi /qn ADDLOCAL=CSE,Management,Management.UI,Management.PS,Management.ADMX (silent install of CSE and all management tools)
msiexec /i LAPS.x64.msi /qn ADDLOCAL=Management,Management.UI,Management.PS,Management.ADMX REMOVE=CSE
msiexec /i LAPS.x64.msi /qn ADDLOCAL=Management.UI,Management.PS,Management.ADMX REMOVE=CSE (silent install of all management tools, remove CSE)
msiexec /i LAPS.x64.msi /qn ADDLOCAL=CSE,Service (silent install of PDS and CSE)
msiexec /i LAPS.x64.msi /qn ADDLOCAL=Management (silent install, prestage only – no component gets installed) GUI-based selection would be like this:
If you want to check which components are available for ADDLOCAL parameter, use Orca, SuperOrca or any other MSI database table editor and view table Feature. Be aware, that this parameter is case sensitive. If you miss-type something, you’ll get error code 2711 during installation:
Components, supported with LAPS 7 installer:
If you want to learn more about MSIEXEC and supported parameters check:
– Command-Line Options
– How to Use Property Reference Command-Line Parameters with Msiexec.exe
Despite the unusually long post, I hope you managed to get something useful out of if. If nothing else, it’s a nice reference for future reading – another reason why I wanted to write about it.
Stay tuned for the next one…
Although I’m not DB admin (not yet that is), I do have to work with SQL server from time to time. Since I do like automation, I tend to work with PowerShell as much as possible.
And this is where some good news comes in – Microsoft has recently released July 2016 update for SSMS (SQL Server Management Studio) which includes several new CMDLETs.
Part of this update is also new SQL PowerShell Module – SQLPS was the old one and the new one is SqlServer (be sure to check and update existing scripts if you use Import-Module and/or similar Cmdlets). Current version of SSMS installer packs and installs both versions of PowerShell modules but only SqlServer has the updates and new Cmdlets.
New Cmdlets are available for the following areas:
– Always Encrypted
– SQL Agent
– SQL Error Logs
Updated version of SSMS works with all supported versions of SQL Server (SQL Server 2008 – SQL Server 2016), and provides the greatest level of support for working with the latest cloud features in Azure SQL Database.
- Client/Server configuration:
- Clients: Windows 8.1 and up on isolated VLAN
- SCCM Servers: 2012 R2 SP1
- SCCM distribution point: dedicated server for network unlock and client deployment
- change to certificate template used for network unlock: Certification Authority and Certificate recipient fields are Windows Server 2012 R2 and Windows 8.1 respectively
After some initial testing I’ve successfuly deployed this configuration at one of our customer’s sites.
Not sure if it is fully supported from MS side but I didn’t do any “funny” customization to get it working – based on this I would guess it should be supported.
Second link is really useful for understanding how the whole thing works – it even has few screenshots of network trace (good reference for troubleshooting).
Good to know:
– Network unlock by itself doesn’t do PXE boot – unlock happens before that with special DHCP packet (provided, that LAN boot is not first BOOT option – which it shouldn’t be). Check second link for more info.
– This change to BitLocker OS drive unlock process will add few seconds to boot process. Why? Before Windows can successfully start and unlock drive with certificate, boot manager has to get valid IP DHCP address (or not if timeout happens). Only after this happens BootRequest packet is send to WDS server which replies with BootReply. How big can this delay be probably depends on usual network-related configuration.