Microsoft LAPS... yes LAPS not LABS

Microsoft recently published a new tool called LAPS (Local Administrator Password Solution).

https://technet.microsoft.com/en-us/library/security/3062591.aspx

When I talk to customers about local administrator account most of the time I get the same answer.

• We user the same passwort on every client machine that we roll out.
• Our standard local admin password is integrated into our VM deployment. Therefore every new server has got the same local admin password.
• Our standard local admin password on the clients is well know. Every user knows it in case of "emergency".

I bet there are alot of other insecure practices to handle local admin passwords.

In the "good old days" we used Group Policy Preferences to manage local accounts and local admin passwords. We were able to set the password of the local admin via GPP.

Last year Microsoft removed this functionality from GPP because the password was stored insecurely and allowed for priviledge elevation.

https://support.microsoft.com/en-us/kb/2962486

We need to find a more secure and manageable solution for local administrator passwords and that is where Microsoft LAPS comes into the game.

Microsoft LAPS is a solution to automatically change the password of the local administrator account (well known SID -500) on all machines joined to our Active Directory domain to a unique and random value which is regularly changed automatically.

Using LAPS you can make sure that all computers in the AD environment have different and complex local admin passwords. LAPS requires a AD schema extension and adds a new attribute (ms-Mcs-AdmPWD) to the computer class which stores the current admin password. Permissions to read this attribute must be explicitly granted to your users, your helpdesk or your admins. The entire process only relies on Active Directory functionality.

The following steps will show you how to install LAPS. For the demo I used a build of Windows Server vNext (2016) and Windows 10.

The lab (yes, this time with a "b") consists of thow machines.

• DCvNext (Windows Server vNext Domain Controller and LAPS Management Server)
• W10 (Windows 10 Client joined to the AD Domain corp.insidecloud.de working as the LAPS client)

The LAPS client machine can be any Windows OS (from 2003/Vista...no we don't want to use 2003 anymore!). The client MSI package is available in a 32 and 64 bit version. Both packages can be downloaded from Technet (see link at the top of this article).

Now let's start with the installation.

Software Installation

We're logged in to our Domain Controller and double click the "LAPS.x64.msi" file.

Click the "I accept the terms in the license Agreement" (I once met a guy who told me that he knows a guy who knows a guy who has heard of a guy who claims to have ever read the Software License Terms. :-))

 Select every available componenten on the custom setup page.

Click "Next" and click "Install" to install the components.

Finaly close the installed with the "Finish" button.

That's it. Fairly simple. Now let's move on to the client installation.

In order for a client machine (could be Windows Client oder Windows Server OS) to have its password changed automatically it is required to install the client component of LAPS on the machine.
The installation can either be done using the MSI package from above or by extracting a DLL from it and register the DLL manuall. I prefer to register the DLL on my Windows 10 client. Just keep in mind that if you do not install the MSI package and just register the DLL you'll not see the component in the control panel "Programs and Featuers" on the client. On the other hand integrating the DLL silently into your OS deployment.
You can extract the MSI package using the command.

"msiexec /a /qb TARGETDIR="

After extracting the file you'll find severall folders containing the GPO templates and the powershell module as well as a folder CSE which contains the required DLL.

We now copy the DLL to "C:\Windows\System32" and register it using "regsvr32.exe AdmPwd.dll". (Please excuse the German in the screenshot I used a German Windows 10 image)

Active Directory preparation

Now that we have installed the management and client componentn wie need to prepare Active Directory to store the password against a computer object. There will be two attributes added to the Active Directory computer class.

• ms-MCS-AdmPwd - the attribute that holds the password
• mc-MCS-AdmPwdExpirationTime - this attribute stores the time after which the computers password should be changed

We again log on to the Domain Controller where we previously installed the management software. Make sure to be logged on as a member of the "Schema Admins" group and open an elevated Windows PowerShell prompt.

Using the command "Get-Command -Module AdmPwd.ps" we can check the available Cmdlets from the Powershell module. (If you use a Windows Server 2008 R2 you might need to import the module first)

Now we can run "Update-AdmPwdADSchema" Cmdlet to update the schema.

 We need to grant the computers the ability to update their password attribute using the Cmdlet "Set-AdmPwdComputerSelfPermission".

Next we ne to grant rights to users to allow them to retrieve a computers password.

We could also use the "Identity" parameter to grant the permissions to a single computer object.

Group Policy configuration

Client and mangement component is installed and permissions are set. All that's left is to turn on the password synchronization. 

We open GPMC on our Domain Controller and create a new policy "LAPS Clients" that we can link to our "Clients OU" in AD.

These settings are really straightforward, you can configure them how you like. I used the following settings:

• Enable local admin password management: Enabled
• Password Settings: Enabled
• Complexity: Large letters, small letters, numbers, specials
• Length: 14 characters
• Age: 30 days
• Name of administrator account to manage: Not Configured (this will use the default SID -500 account)
• Do not allow password expiration time longer than required by policy: Enabled

How to use LAPS

Now that we have everything installed and configured we can start using LAPS for our daily work and read the passwords from the attribute.

There are different ways to get the password.

You can use "Active Directory Users and Computers" snap-in and the integrated attribute editor to view the password.

Instead of using this simple way you can use the LAPS UI that we installed on the management machine to read the password.

The automated way would be to use Powershell and the Get-ADComputer Cmdlet.

That's it. Next step: Integrate LAPS into your clients and client operations procedures. LAPS could be integrated into your ticket system and allow users to request the admin password and have it automatically resetted to a different value afterwards. Make sure that users didn't create an additional admin account. You could do so using GPP to keep the local admins group clean.

Ideas, ideas, ideas...

Have fun and have a nice week.

Chris

Microsoft Windows based PKI DOs and DON'Ts

DON’T install a Public Key Infrastructure without having a detailed plan. Plan the required PKI roles. Consider availability requirements.

DO use a CAPolicy.inf file for initial configuration during installation. You can use it to define attributes such as basic constraints extension, renewal key length and period, CRLs period, etc.

DO use a standardized naming convention which additionally includes naming of GPOs, templates and accounts related to PKI. Naming conventions should include the CAs Common Name.

DON’T change CA server name after ADCS role installation. Already enrolled certificates will stop working.

DON’T use Root CA to issue certificates directly to end entities.

DON’T install any PKI component on a domain controller. It is technically possible, but not recommended due to security and delegation considerations.

DO install the CA on failover clustering. Microsoft ADCS role can act as active-passive using failover feature of Microsoft Windows operating system.

DO create CPS (Certificate Practice Statement) and CP (Certificate Policy) documents to improve the trust to your PKI. Documents should be based on RFC 3647 recommendations.

DO create at least a 2-tiers architecture. For huge organizations, depending on Active Directory structure and amount of forests and domains, you can extend the architecture to a 3^rd-tier.

DON’T join the Root CA to your Active Directory Domain. Building an “offline” Root CA really means offline with no network connection.

DO protect your offline Root CAs hard drives or virtual disk files and place them in a secure vault until a CA certificate needs to be issued or a new CRL needs to be issued and published.

DO use a HSM to protect the keys of your CAs. I can recommend Gemalto formerly Safenet.

DO consider all operational and security related procedures when implementing a HSM.

DO use at least 4096b keylength for Root CA.

DO change default system accounts. The Local administrator account name should be changed. Domain Admins group should be deleted from the local administrators group on all systems belonging to the PKI.

DO use long and complex password and DO make sure it is kept in safe place.

DON’T leave default AIA (Authority Information Access) URLs with the CA hostname in issued certificates.

DON’T leave default CDP (CRL Distribution Point) URLs with the CA hostname in issued certificates.

If implementing in large organizations, DO use templates OID to differentiate company’s policy objects from default Microsoft policy objects tree. You can request PEN (Private Enterprise Number) from IANA organization (Internet Assigned Numbers Authority).

DO ony use customized templates, DON’T use default ones. Use organization name prefix for templates names.

DO use following commands to publish Roo CA CRLs and .crts to the Active Directory:

certutil -dspublish -f "name_of_root_ca_cert.CRT"  RootCA

certutil -dspublish -f "name_of_ca_crl.CRL"

DO make CDP (CRL Distribution Point) redundant. Include in CDP and publish CRLs to HTTP. Highly consider using split-brain DNS scenario to publish the CRLs.

Microsoft ADCS default repository is C:\Windows\System32\certsrv\CertEnroll. CRLs and CAs certificates are published to this folder. DON’T publish CertEnroll folder directly to the Internet. Instead create a mechanism which copies *.crt and *.crl to another machine and folder. Publish this other machine to the Internet with a reverse proxy.

DO use role separation. In simple scenario these should be: PKIBackupOperators, PKITemplateAdmins, PKIAuditors, PKICertAdmins, PKICAAdmins.

DO enable key archival for private keys if you are using certificates for email or file encryption. Otherwise you’ll not be able to recover old keys used to secure data in the past.

DON’T write down your user’s certificate password/PIN and stick it to monitor or hide under the keyboard.

DO use tokens or smartcards for users and special purpose accounts (Enrollment Agents, etc) if possible.

DO make sure that system time on CAs machines is set correctly.

DO renew the CA certificate with a supply of time so that certificates issued by the CA have shorter life time than the remaining life time of the CA certificate.

DO enable all auditing events for the CA.

certutil -setreg CA\AuditFilter 127

DO perform health checks on your PKI infrastructure using PKIView and check the eventlog on a regular basis.

DO create a CA backup, including private key, CA certificate, certificate database and certificate database log, CAPolicy.inf file, CA configuration from the registry and exported CA templates.

DO make sure that system backup is done regularly. Backups should be protected with password and kept in safe place.

DON’T consider internally issued certificates as a qualified certificate. Consider certificate usage to make sure the certificate is issued by the corresponding internal or external CA.

Microsoft Identity Manager Public Preview is now available

Hi folks,

Microsoft recently announced the first public preview of the FIM 2010 R2 successor MIM (Microsoft Identity Manager).
For those of you who doesn't know FIM 2010 R2 let me quickly explain what MIM will be in the future. :-)

• MIM can synchronize identities between different types of systems. Identities in this case doesen't limit MIM to users or groups. I've been working in projects where we synchronized different other things like computer objects, GPOs, organization objects and so on. Synchronization of identities includes provisioning and deprovisioning of identities in connected systems.
• MIM can connect to on premises services as well as cloud 
• MIM provides easy to configure workflows for all those synchronization steps. Again, these workflows can be IAM (identity and access management) related or not. Workflows can be extended by public available workflow modules e.g. Powershell.
• MIM can provide a management solution for role based access control (RBAC) based on a web portal and business rules.
• MIM includes a self-service-portal for password reset, account unlock, group management, JIT (just in time) privileges.
• last but not least MIM can provide a management solution for certificate management.

You can find more information here: http://blogs.technet.com/b/ad/archive/2014/11/18/microsoft-identity-manager-preview-release-1-is-now-available.aspx

and download the preview of MIM here: https://connect.microsoft.com/site433/Downloads

Have fun and happy synchronization :-)

Chris

Videos and books about FIM 2010

Hi folks,

it has been quite a while since my last post but I'm currently busy with some nice identity management project and of course FIM 2010 R2 or hopefully MIM in the future.

Doing all that stuff with FIM I was always looking for a good book about the product it self. I like to read books in my spare time (which I always don't have enough :-)) therefore I would like to write a short blog post about available books and videos about FIM 2010 R2.

Let's start with a video that is available from Kent Nordström (konab.com). The video is based on Kents book "Microsoft Forefront Identity Manager 2010 R2 Handbook"
https://www.packtpub.com/application-development/enterprise-identity-management-microsoft-forefront-identity-management-video

The video as well as the book has got the following chapters and to me is the best book available for the topic.

• Installing FIM 2010 R2 on Windows Server 2012 
• Basic Configuration of FIM Synchronization and FIM Service
• User Management
• Group Management
• Configuring FIM for Self-service
• Customizing FIM
• Reporting
• Issuing Smart Cards Using FIM CM

I realy recommend this to everybody if you're interessted in FIM. There is also a ebook version availabl for your tablet or Kindle. To order the book your can use Kents link http://aka.ms/FIMR2Book.

The second FIM book available.

It's called "FIM R2 Best Practices Volume 1: Introduction, Architecture and Installation of Forefront Identity Manager 2010 R2" from David Lundell and Brad Turner

http://www.amazon.com/FIM-Best-Practices-Volume-Introduction/dp/B009LP8CW8

I haven't finisched it yet but it is slightly different from Kents book. I contains more backgroud information on the product, its architecture and the topic identity management itself.

It's realy worth reading it.

At the moment these are the only two books I know about.

Please leave a comment if you know about any other books or videos and I'll include them into my post.

Have fun reading the books.

Chris

Forefront Identity Manager vNext is now known as Microsoft Identity Manager (MIM)

Yesterday, Wednesday April 23rd 2014, Microsoft announced the roadmap for Forefront Identity Manager 2010, known as FIM 2010.  The new product will be called Microsoft Identity Manager (MIM) and will be availabl in H1CY15.  The official announcement was posted to the Server & Cloud Blog: http://blogs.technet.com/b/server-cloud/archive/2014/04/23/forefront-identity-manager-vnext-roadmap-now-microsoft-identity-manager.aspx

The product is used to be renamed and was formerly known as MMS, MIIS, ILM, (ILM V2), FIM.
With the new name Microsoft shifts the product to a new central strategy and deliveres some nice features.

Even though I'm not to keen on the new name I'm confident that I have backed on the right horse.

Cheers!

Chris

View certificate properties via Powershell (and some RDP stuff)

Hi all,

we've implemented Windows Remote Desktop Services at a customer and were facing those ugly security popus asking if we trust the publisher even though the certificate was issued by the customers PKI and was valid and trusted by the client (certificate chain was installed on the client, CLR was reachable and so on).

It's not a bug...its a feature according to Microsoft. :-)
You can get rid of these popups configuring a GPO that specifies valid publishers.
http://technet.microsoft.com/de-de/library/cc771261(v=ws.10).aspx
The GPO requires the SHA1 thumbprint of the certificate. We fiddled around copying the thumbprint from the certificate UI, the GPO was applied but we were still seeing the popup.

This was caused by a none-printable character which we copied from the certificate UI into the GPO. Very ugly. :-)
Therefore I created this simple Powershell script to get the thumbprint in the right format (no spaces, upper case and most important no none-printable characters).

$cert1 = New-Object System.Security.Cryptography.X509Certificates.X509Certificate „my certificate.cer“

$cert1.GetCertHashString()

The last line returns the thumbprint of the certificate e.g. BCE26899803C4806911B01F969FF7721562E07D6

You can find more methods here:
http://msdn.microsoft.com/en-us/library/system.security.cryptography.x509certificates.x509certificate.aspx

more information can be founde here:
https://blogs.technet.microsoft.com/askpfeplat/2017/12/18/remote-desktop-connection-rdp-certificate-warnings/

Happy coding
Chris

Enable FIM and PCNS logging

FIM 2010 and the PCNS service can make use of the Application log to record events. In order to get more details on password synchronisation we can set the logging level to high and check the Application log during the initial configuration an deployment of PCNS.

For FIM 2010, there are four different logging levels that are controlled by adding the FeaturePwdSyncLogLevel (REG_DWORD) entry to the following registry subkey:

      HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\FIMSynchronizationServices\Logging

0 = Minimal Logging
1 = Normal logging (default)
2 = High logging
3 = Verbose logging

For PCNS, there are also four logging levels that are again controlled by adding the EventLogLevel (REG_DWORD) entry to the following registry subkey:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\PCNSSVC\Parameters

0 = Minimal Logging
1 = Normal logging (default)
2 = High logging
3 = Verbose logging

A reboot is required in order for the changes to be applied.

Have fun and check the logs
Chris