Who, What, Where, When, LDAP

Who’s talking to my Active Directory?

What is LDAP?

Active Directory, ADAM and AD-LDS.  Microsoft’s implementation of directories that follow the X.500 standard.  Referred to as Lightweight Directory Access Protocol, or LDAP to the layman:

If you want to talk to Active Directory you need to speak the lingo, LDAP lingo that is.  If you’ve ever managed AD through ADSI Edit, written a PowerShell script or looked at attributes through ADUC, you will more than likely have worked with LDAP.  Just as English is the global language of business, LDAP is the global language of X.500 directories.  Of which Active Directory is the primary Microsoft variant.

Why do you need to be concerned with the language, the protocol and not just the parts you can see?

In response I ask:

• What in your environment uses Active Directory?
• Do you have AD aware applications?
• Do you use Windows Authentication anywhere?
• Do you know every application in your environment?
• Do you understand the complete effects of turning off every server?
• Do you understand the impact of AD changes to your applications?

I’m sure that the answer to these questions would be very different depending on who you speak to as well as who is asking the question.

Often, organizations don’t concern themselves until one of a few scenarios arise:

• Security Incident / Compliance requirement
• Decommissioning a server
• Performance
• AD Migration

Why is auditing LDAP so critical?

Generally, you should audit anything that can access and manage your critical services, both known and unknown entities.  As with many things, the basic requirements are identical.  It’s the use case that differs:

1. Identify what servers, services, and service accounts are accessing AD
2. Identify what objects and attributes are being accessed in AD
3. Understand the query being run
4. Determine the use case

Let’s address the four scenarios directly:

1. Security Incident / Compliance requirement

It stands to reason that if there is a way to manage your business critical services, of which AD is one, then you want to know who, what, where and when.  Anyone with sufficient privileges, access to PowerShell, and an understanding of LDAP can do things in AD.  Restricting access to ADUC and other management UI’s does not stop someone from using a direct connection.

Monitoring LDAP activity can help you detect this.

2. Decommissioning a Server

How many servers in your estate are unknown entities?  By that I mean, do you 100% know what’s on there and how it works?  So many servers are often used for development, both official and unofficial.  Many servers also have in-house written or third party software.

What would happen if you turned one of these off?  I personally have turned off numerous servers in my time.  I crossed my fingers and prayed that the helpdesk wouldn’t suddenly receive a glut of calls from irate users.  I’ve spoken to many Sys Admins who have and still do the same.

One way to make this scenario less risky to business (and your nerves), is to understand whether anything on those servers relies on AD.  It may be that Windows Authentication is used, maybe an application relies on a hardcoded FQDN or IP Address.  Lots of Ifs and what ifs.

3. Performance

I think it’s safe to say that 90% of AD Domain Controllers are over specified in terms of CPU, RAM, and disk resources.  It’s not often that a DC is stressed, load wise, in any way.

So why is it that sometimes there is a huge peak in resource utilization.  What if replication, backup, and AV client have all been accounted for.  It’s not even during peak logon times.

Have you considered LDAP queries?

All it takes is a poorly written or malicious script that uses LDAP to query AD.  Next thing you know a DC is brought to its proverbial knees.  This is far more common than many Sys Admins are aware of.

As a sys admin, have you ever wanted to point the finger at the department that has carte blanche when it comes to ‘bespoke’ critical applications?  Monitoring LDAP is a great way to do that!

4. AD Migration

One of the riskiest things you can do with Active Directory is migrate.  Moving the various objects from one domain to another has many inherent risks, such as maintaining access to resources and data before, during, and after the migration process.

One aspect that is often overlooked, at least until one has a problem, is the effect of moving an application server between domains.  In a similar vein to decommissioning servers, the first challenge is to identify all sources of LDAP communication to Active Directory.  Once identified it is imperative to understand how the LDAP query is being used, as in all of the previous use cases.  However, the added consideration is how does the application identify the Domain Controller to use.  Does it use a hostname, IP address, or possibly FQDN?

If an FQDN has been hard coded into an application, a domain migration will quite simply stop the application to AD communication as the Domain Controller (and application server) FQDN will always change.

Maybe a service account has been configured in the application, this will change.

Maybe a DN has been used to identify an object in Active Directory.  Again, this will change.

Many years working in the migration industry has taught me many things, but one stands head and shoulders above the others in importance:

Assess, assess and assess.  You need to know everything about your environment, applications especially.

StealthINTERCEPT has an LDAP feature that helps to address all of these use cases and any others in respect to AD LDAP.  It’s not an extra chargeable module, it comes as part of the Active Directory solution.

Another reason to choose StealthINTERCEPT as the go to for AD, Authentication and LDAP auditing and compliance solution.

Don’t miss a post! Subscribe to The Insider Threat Security Blog here:

Name

Email*