Meeting the InCommon Assurance profile criteria using Active Directory

[Brian Arkills <>]

I’m actively working in this space too, Brett, so when I saw your email, it struck a nerve. J

 

Having learned a few things from my NTLMv1 mitigation efforts, I planned from the start to put together a toolkit that others could re-use for simple bind mitigation. And if anyone wants early versions of some of the components, I can probably entertain that. I’ve got a PS script (along with the documented perms to automated it) that’ll grab the right events and ship them to a SQL table. I’ve got a simple asp.net web app that can show all the simple binds from the last 30 days for any user that has had a simple bind in the last 30 days. I’ve got a PS script to run on a monthly basis to email users who have had a simple bind in the last 30 days. I also have a PS script that ships daily simple bind metrics to a Graphite server, if you use Graphite.

 

I’m currently working on a change to my planned toolkit that’ll make it easier to identify the sources of simple binds and target them. That’s one of those ‘gee, I didn’t quite think that through’ things, where we realized that the cause of most of these are poorly configured applications that the end users have no awareness of. Today, I just contacted the top 10 of those, and have 7 of them cleaned up already, and are in the process of notifying the owners of the exposed passwords to reset them. J

 

Anyhow, my plan has always been to have some running mitigation process around this, where we feed the data we’ve got into some broader process. We’re not to the point of having a broader process, or even close to applying for an assurance level.

 

I think you are on the right track, though, that those who do send their password in the clear need to lose their assurance level until they reset it.

 

-B

 

From: [mailto:] On Behalf Of Brett Bieber
Sent: Monday, March 23, 2015 2:11 PM
To:
Subject: [AD-Assurance] Unencrypted LDAP to Active Directory

 

Have any of you been able to eradicate unencrypted LDAP for credentials?

 

We've tackled NTLMv1, and the next obstacle was unencrypted LDAP. My expectations were slightly different than the result we've seen.

 

We've spent a significant amount of time tracking down all the devices triggering Event Code 2889 on our Domain Controllers, and eliminating as many as we could before flipping the switch.

 

This morning, we deployed the change to require "LDAP Signing" as Microsoft calls it, described on this page:

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

 

Active Directory continues to permit traffic on port 389 to the domain controller. I had some expectation that this would continue for LDAP ping, StartTLS clients etc. What I didn't expect, is that the Domain Controller would still permit an unencrypted BIND and send a different message depending on if the credentials were valid or not.

 

Over an unencrypted connection, attempting to BIND to AD with invalid credentials yields the following message:

"AcceptSecurityContext error, data 52e, v1db1"

 

A valid credential yields:

"The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v1db1"

 

...and, we continue to see Event Code 2889 logged by the Domain Controllers for those unencrypted BINDs with valid credentials.

 

Some clients apparently try an unencrypted LDAP BIND, and upon failure, try something more secure.

 

I had originally thought by requiring "LDAP Signing" on AD, I would have eliminated any need to monitor for these types of events and could check off many concerns related to the following IAP items:

4.2.5.2 Resist Eavesdropper Attack

4.2.5.3 Secure Communication

4.2.5.6 Mitigate Risk of Credential Compromise

4.2.8.2 Network Security (Silver)

 

Now that we know these events can continue to occur, what is my responsibility as a good InCommon Assurance citizen?

 

Must everyone running Active Directory monitor for these types of events, and revoke Bronze/Silver Assurance for those credentials when such an event is logged?

 

Any wisdom would be appreciated.

 

-Brett