Lately I’ve been wondering about the impact of the following setting: Domain controller: LDAP server signing requirements. The documentation (TechNet #1 and TechNet #2 ) spells it out pretty well: This policy setting determines whether the Lightweight Directory Access Protocol (LDAP) server requires LDAP clients to negotiate data signing. You can set it to either None or Required. None is the default and allows signing if the client asks for it.

Sometimes when I read information I read too fast and draw my conclusion. Shame on me. Wrong conclusion from my side: configuring this setting to required requires all connection to use LDAPS (TCP 636). Nope. It says data signing! Signing can be perfectly done with traffic targetted at both LDAP (TCP 389) or LDAPS (TCP 636).

From AskDS: Understanding LDAP Security Processing I learned various things about simple binds. Simple binds send your username and password in clear text. Needless to say that in combination with LDAP you’re at risk. On the other hand, if the communication is using LDAPS, sending passords in clear text could be acceptable. 

Now the documentation I referenced earlier is a bit conflicting on this topic:

• This setting does not have any impact on LDAP simple bind or LDAP simple bind through SSL.
• If signing is required, then LDAP simple bind and LDAP simple bind through SSL requests are rejected.
• Require signature. The LDAP data-signing option must be negotiated unless Transport Layer Security/Secure Sockets Layer (TLS/SSL) is in use.

Now it might be just me but I would phrase that in another way. Both articles suffer from the same wording. So like with any other uncertainty we just test it. Once you see and experience it you’ll never forget!

This is part of the Default Domain Controller Policy on Windows Server 2012 R2:

I changed it to:

Now using LDP.exe we can do some tests:

Connecting over LDAPS:

Performing a simple bind:

And the result:

Now if we try to connect over LDAP:

Bind like before. But now we get:

In words: Error <8>: ldap_simple_bind_s() failed: Strong Authentication Required
Server error: 00002028: LdapErr: DSID-0C090202, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580
Error 0x2028 A more secure authentication method is required for this server.
Conclusion:

All of this is definitely not new. But writing about it helps me never forget it. Setting the LDAP Server Signing Settings to required will probably require some planning and testing. But it doesn’t mean you can’t use simple binds. As long as you can configure your application to use LDAPS. Your domain controller should be logging a warning event every once in a while when simple binds or unsigned LDAP traffic is seen. Here’s some more info on this event: Event ID 2887 — LDAP signing.

If you want to read more on LDAP signing, please check KB935834: How to enable LDAP signing in Windows Server 2008

I’ve been educating myself on the capabilities of OpenID Connect/OAuth in Server 2016. The version I’m currently playing with is based on TP5. I created a small application which consists of a web application and an API. Just for educational purposes. The actual application can be found here: https://github.com/tvuylsteke/TodoListWeb

When I started testing my application I ran into an issue. I would visit my application, hit the sign in button and be redirected to AD FS. I would either enter my credentials or be authenticated transparently and then be redirected to my application. That’s where things went wrong. I always seemed to get this error:

In Words:We're having trouble signing you in.

IDX10311: RequireNonce is 'true' (default) but validationContext.Nonce is null. A nonce cannot be validated. If you don't need to check the nonce, set OpenIdConnectProtocolValidator.RequireNonce to 'false'.;

Some online searching led me to some threads but no real good suggestions. I also found a session off Build 2015: Cloud Authentication Troubleshooting and Recipes for Developers They mention that IDX10311 typically happens when you don’t receive an expected cookie from the browser. Likely cause: Your reply URL is sending the browser to somewhere different than where you started. I double checked everything, but that didn’t seem to be the cause.

Now I found out that using chrome everything was working as expected. Still I had no real clue. I posted my issue to an internal DL and one of my colleagues quickly spotted my issue using the Fiddler traces I provided. He told me that the OpenIdConnect.nonce.OpenIdConnect cookie was not being set correctly for the todolistweb.contoso.com application in IE. And when I took my traces I could indeed see this:

A trace from Internet Explorer:

You can see the response from AD FS and then the browser going back to the application without any cookies:

Now if we compare that to a session from within Chrome:

You can clearly see the OpenIDConnect.nonce cookie

As a solution to this issue I added my application to the Local Intranet Zone in IE and that resulted in the cookie being sent to the application. Mystery solved!

Earlier this week I’ve been talking to a customer about the “Protected Users” group. You might have seen it appearing when introducing the first 2012 R2 domain controller. Here’s a good explanation on its purpose:

Protected Users is a new global security group to which you can add new or existing users. Windows 8.1 devices and Windows Server 2012 R2 hosts have special behavior with members of this group to provide better protection against credential theft. For a member of the group, a Windows 8.1 device or a Windows Server 2012 R2 host does not cache credentials that are not supported for Protected Users. Members of this group have no additional protection if they are logged on to a device that runs a version of Windows earlier than Windows 8.1. Source: TechNet: How to Configure Protected Accounts

The above is actually a bit misleading. The functionality was actually backported to Windows 2008 R2/Windows 2012 in the hotfix KB2871997 See blogs.technet.com: An Overview of KB2871997 for an explanation on this.

This group might be part of your organization’s strategy to reduce the attack surface for pass the hash. A great white paper on this can be found here: Mitigating Pass-the-Hash (PtH) Attacks and Other Credential Theft, Version 1 and 2

One of the things the Protected Users group ensures is that no NTLM hashes are available to be used or stolen. Now I wanted to see this for myself. There are various tools out there that are capable of listing the various secrets. I tried Windows Credential Editor (WCE) but that one didn’t work on (my) Windows 2012 R2. So I used Mimikatz. My setup: A 2012 R2 domain controller and a 2012 R2 member server. I’ve got 3 domain admins: one that has the remote desktop session open to the member server and then two that have a powershell runnning through runas. Of the latter one is a member of the Protected Users group:

Run as different user: SETSPN\john

Run as different user: SETSPN\thomas

As you can see John is an oldschool Domain Admin whereas Thomas has read the Mitigating PtH whitepaper and is a proud member of the Protected Users group. This is the PowerShell oneliner I used to dump the groups I care about: WHOAMI /GROUPS /FO CSV | ConvertFrom-Csv | where {$_."group name" -like "Setspn\*"}

Here you can see the Protected Users admin has no NTLM available:

Where the regular admin has NTLM available:

Here’s the difference from an attacker point of view:

Start Mimikatz –> Privilege::debug –> sekurlsa::logonpasswords And here are the goodies:

John:

Authentication Id : 0 ; 3529276 (00000000:0035da3c)
Session           : Interactive from 0
User Name         : john
Domain            : SETSPN
Logon Server      : SRVDC01
Logon Time        : 2/24/2016 6:59:54 PM
SID               : S-1-5-21-4274776166-1111691548-620639307-5603
        msv :
         [00000003] Primary
         * Username : john
         * Domain   : SETSPN
         * NTLM     : 59884edfb057d0fec8cb7e0d571dc200
         * SHA1     : 7e655db2b3a7e88fb0c50ca56416ae655469f09e
         [00010000] CredentialKeys
         * NTLM     : 59884edfb057d0fec8cb7e0d571dc200
         * SHA1     : 7e655db2b3a7e88fb0c50ca56416ae655469f09e
        tspkg :
        wdigest :
         * Username : john
         * Domain   : SETSPN
         * Password : (null)
        kerberos :
         * Username : john
         * Domain   : SETSPN.LOCAL
         * Password : (null)
        ssp :
        credman :

Thomas:

Authentication Id : 0 ; 3493146 (00000000:00354d1a)
Session           : Interactive from 0
User Name         : thomas
Domain            : SETSPN
Logon Server      : SRVDC01
Logon Time        : 2/24/2016 6:59:36 PM
SID               : S-1-5-21-4274776166-1111691548-620639307-5602
        msv :
         [00010000] CredentialKeys
         * RootKey  : db1c2347608db0c4e2d89bbd6c328bf6f42671b7d88653cd4cc9af2713
e958f0
         * DPAPI    : 63adfe49948fca81c885933b3aa23eba
        tspkg :
        wdigest :
         * Username : thomas
         * Domain   : SETSPN
         * Password : (null)
        kerberos :
         * Username : thomas
         * Domain   : SETSPN.LOCAL
         * Password : (null)
        ssp :
        credman :

As you can see the admin that’s a member of the Protected Users group does NOT have the NTLM hashes dumped. Wooptiedoo! Now think and test before you start adding the Domain Admins group to the Protected Users group! By no means you should do that! Here’s some good information on how to start with the Protected Users group and some additional caveats: How to Configure Protected Accounts

Here’s one from my side: after adding my admin user to the Protected Users group he was no longer to RDP to a 2012 R2 member server:

In words: A user account restriction (for example, a time-of-day restriction) is preventing you from logging on. For assistance, contact your system administrator or technical support.

Remote desktop to a Windows 2008 R2 worked fine with that account. It seems for my Protected User admin to be able to log on to a Windows 2012 R2 server it had to actualy use mstsc.exe /restrictedadmin and I had to enable Restricted Admin mode on the member server:

You can find that value below HKLM\SYSTEM\CurrentControlSet\Control\Lsa

If you want to know more about the Protected Users group and the Restricted Admin feature read up on both of them here: TechNet: Credentials Protection and Management or digital-forensics.sans.org:Protecting Privileged Domain Accounts: Restricted Admin and Protected Users

Some additional reading on Restricted Admin mode: Restricted Admin mode for RDP in Windows 8.1 / 2012 R2