Tag Archives: ldp

Get Ready for LDAPS Channel Binding

Posted on by
7

KB ID 0001645

Problem

I have written about Enabling LDAPS a long time ago, but it’s a subject that’s about to become important again, so I’ll revisit the subject. Microsoft are about to ‘enforce’ LDAPS authentication against their domain controllers, in the March 2020 round of updates. Now delayed until second half of 2020.

What does that mean? Well lookups against LDAP will now need to be secure, (i.e. SSL protected and over TCP port 636,) where as before they were in plain text and over TCP port 389.

So you need to start worrying about this now!

Solution

Enable LDAPS for your Domain Controllers

As I’ve mentioned above I’ve covered this before but as a quick recap, you need to have Microsoft Certificate services deployed, please don’t just add the role to a server, and click ‘Next’ furiously. Take this opportunity to deploy Certificate Services properly!

Microsoft PKI Planning and Deploying Certificate Services

Then make sure you have a Kerberos Authentication certificate template published;

If you do not: Simply follow the steps shown below.

Then on your domain controller(s): Windows Key +R > mmc.exe > OK > File > Add/Remove Snap-in > Certificates > Add > Computer > Local Computer.

Expand Certificates > Personal > Certificates > Request a Kerberos Authentication certificate.

Ta-Da!

Windows Server Testing LDAPS

The simplest way, I’ve found to do this is to use Ldp.exe, simply run Ldp from command line. Note: Ldp will normally only be found on domain controllers, and servers/clients that have the ‘AD and DS and AD LDS Management tools‘ installed.

Connection > Connect > Enter the FQDN of the domain controller to test > Tick SSL > Ensure Port is set to 636 > OK

Connections > Bind > Bind as currently logged on user, (unless you want to test a particular account), any member of domain users should work > OK.

View > Tree > Select the root DN of your domain > OK

If all is well you should be able to browse your Active Directory.

Tech Tip: I do this every time I need to enter a DN, because you can browse to any object and copy its DN from here, (and I’m too lazy to type them out by hand!)

Test LDAPS Port With PowerShell

If you want to check the port is open, i.e. not blocked in the Windows firewall or a physical firewall in between you and the server use;

[box]

Test-NetConnection {FQDN-Of-Server} -Port 636

[/box]

Additional LDAP Test Tools

Over on Github theres also a tool called LDAP Explorer Tool, if you want to do some more granular testing;

Find Out What’s Using LDAP and Prepare for LDAPS

If you don’t enforce LDAPS already then your Directory Service Event logs will be full of Event ID 2886, and Event ID 2887

Event ID 2886

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: xx/xx/xxxx xx:xx:xx
Event ID: 2886
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: (Server-Name}
Description:
The security of this directory server can be significantly enhanced by configuring the server to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing (integrity verification) and LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. Even if no clients are using such binds, configuring the server to reject them will improve the security of this server.

Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a non-SSL/TLS connection, and will stop working if this configuration change is made. To assist in identifying these clients, if such binds occur this directory server will log a summary event once every 24 hours indicating how many such binds occurred. You are encouraged to configure those clients to not use such binds. Once no such events are observed for an extended period, it is recommended that you configure the server to reject such binds.

For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.

You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the “LDAP Interface Events” event logging category to level 2 or higher.

Event ID 2887

Log Name: Directory Service
Source: Microsoft-Windows-ActiveDirectory_DomainService
Date: xx/xx/xxxx xx:xx:xx
Event ID: 2887
Task Category: LDAP Interface
Level: Warning
Keywords: Classic
User: ANONYMOUS LOGON
Computer: (Server-Name}
Description:

During the previous 24 hour period, some clients attempted to perform LDAP binds that were either:
(1) A SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP bind that did not request signing (integrity validation), or
(2) A LDAP simple bind that was performed on a clear text (non-SSL/TLS-encrypted) connection

This directory server is not currently configured to reject such binds. The security of this directory server can be significantly enhanced by configuring the server to reject such binds. For more details and information on how to make this configuration change to the server, please see http://go.microsoft.com/fwlink/?LinkID=87923.

Summary information on the number of these binds received within the past 24 hours is below.

You can enable additional logging to log an event each time a client makes such a bind, including information on which client made the bind. To do so, please raise the setting for the “LDAP Interface Events” event logging category to level 2 or higher.

Number of simple binds performed without SSL/TLS: 0
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing: 1

Enable LDAPS Logging / Reporting

So you need to enable logging then when insecure (non LDAPS) connections are made, another Event ID will be logged which will point you towards what needs to be fixed. 

Open Regedit and navigate to;

[box]

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics

[/box]

Change the ’16 LDAP Interface Events’ DWAORD value to ‘2’ > OK.

Or Execute the following command;

[box]

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v “16 LDAP Interface Events” /t REG_DWORD /d 2

[/box]

Or Execute the following Powershell command;

[box]

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics’ -Name “16 LDAP Interface Events” -Value 2 -PropertyType DWORD -Force

[/box]

Checking for Insecure LDAP (TCP 389) Connections

Now you can locate the insecure connections by looking for Event ID 2889

Event ID 2889

Above you can see the IP address of the device trying to bind insecurely, you can also see that Anonymous Login was attempted’.

Above you can see the IP address of the device trying to bind insecurely, you can also see the domain username that is being used ‘PNL\asa’.

Disable LDAPS (Temporarily)

LDAPS is enabled and disabled with the following registry key;

[box]

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LdapEnforceChannelBinding

[/box]

Note: You will need to CREATE this DWORD yourself;

Values: 0 Disabled, and 1 Enabled

WARNING: Take note I said temporarily, just because you have a crappy old insecure appliance or service that can’t use LDAPS, does not mean you should simply turn off security. Get it fixed! However, I appreciate you work in the real world, and if systems are down and you are getting shouted at, then fair enough. But you should have read this when I wrote in January 2020 my friend – bet you wished you followed me on Twitter or Facebook now eh?

Cisco ASA Change from LDAP to LDAPS

Well I’m the Cisco ASA guy so what happens if you are securing AAA access using LDAP on you firewall (for AnyConnect, Remote VPN, or device access). How do you swap to LDAPS? Like so

You will also need to upload the Root-CA certificate from your CA Services Server to the ASA, (so it trusts the servers Kerberos Certificate).

 

Related Articles, References, Credits, or External Links

Moving Certificate Services To Another Server

Microsoft PKI Planning and Deploying Certificate Services

Upgrade Your Microsoft PKI Environment to SHA2 (SHA256)

Duo: Migrate from LDAP to LDAPS

Using LDP to Find an Objects ‘Distinguished Name’ in Active Directory

Posted on by
Reply

KB ID 0001337 

Problem

There are a few occasions when you need to know an objects ‘Distinguished Name’ (DN). For me it’s usually when I’ve got a device that needs to do LDAP/LDAPS lookups, (RSA Appliance, Netscaler, Cisco FirePOWER, etc). Today someone needed to ‘bind’ a Checkpoint firewall to Active Directory, and asked me to create user, and give them the DN and password.

I’ve mentioned ldp.exe many times, but never dedicated a post to it, it’s a tiny executable, that was first seen in the server 2003 support tools.  With 2008 you needed to add the Active Directory Lightweight Directory Service Role to get it. With server 2012 and 2016 you will get it on any Domain Controller.

For a member server, (or non domain joined server) you can add LDP.exe by simply adding the following feature from server manager.

LDP Usage

Windows Key+R > ldp {Enter} > Connection > Connect > select localhost, (if you are on the DC, or the FQDN of a DC if you are not). Normally port 389 is fine, but if you have enabled LDAPS, you might want to use port 636, and tick SSL also > OK.

Now you need to bind to LDAP, I’m using my logged on account, but if you want to test a user account can bind to Active Directory, then you can specify a username/password and domain > OK.

Note: To bind to, and read all objects in Active Directory, only  domain user is required.

Now to view anything > View > Tree > Select the root DN to view all of AD, (in my case DC=pnl,DC=com) > OK.

You can now browse your AD, and get the DN for any object.

Related Articles, References, Credits, or External Links

Windows Server 2012 – Enable LDAPS

Cisco FirePOWER Management Center Appliance – Allowing Domain Authentication

Cisco FirePOWER Management Center Appliance – Allowing Domain Authentication

Posted on by
Reply

KB ID 0001117 

Problem

Once deployed, authentication is handled by the appliances own internal user database, in larger organisations this is a little impractical. So the ability to create an Active Directory Group, and delegate access to Firesight to members of that group is a little more versatile.

Solution

I’m making the assumption that the appliance does not already have external authentication setup at all, so I’ll cover everything from start to finish.

Newer Versions

Logon to the Appliance > System >Users > External Authentication > Add External Authentication Object

Older Versions

Logon to the Appliance > System > Local User Management > External Authentication > Create External Authentication Object.

  • Authentication Method: LDAP
  • Name: Chose a sensible name for the connection.
  • Server Type: MS Active Directory
  • Host Name/IP Address: the IP of your domain controller
  • Port:389 (this is standard LDAP)

If you have a second Domain Controller enter the details here.

Note: In Active Directory, I’ve created a USER to make the connection to Active Directory with, and I’ve also created a SECURITY GROUP that my administrators will be in.

You can use the ldp.exe tool to locate and find the correct LDAP path for the user you created, (and the group because you will need that in a minute as well).

  • Base DN: Usually the root of the domain, in standard LDAP format.
  • Username: The LDAP path to the user you created.
  • Password: For the user above.
  • UI Access Attribute: sAMAccountName
  • Shell Access Attribute: sAMAccountName

I’m simply having one administrative group, if you have a granular RBAC requirement, there are a number of pre-configured roles you can assign your AD groups to, (or you can create custom ones). So I’m adding the LDAP path of my administrators group to the ‘Administrator’ role.

Also set the default role to ‘Security Analyst (Read Only).

  • Group Member Attribute: member.
  • Username: A user in the AD Administrative group you created.
  • Password: Password for the above account.

Press ‘Test’

All being well you should see a success, Press Save.

Newer Versions

Switch the ‘slider’ to enabled > Save > Save and Apply. (Now skip to All Systems below).

Older Versions

You now need to add this to the policy being applied to this appliance. System > Local System Policy > Select the policy in use  >Edit.

External Authentication

  • Status: Enabled
  • Default User Role: System Analyst (Read Only)

Finally change the slider button and ensure it is ticked. Save policy and exit.

Now apply the policy (green tick).

Tick the appliance > Apply.

Success.

All Systems

Now you can login with your administrative AD accounts.

You can also create a local user to match an AD account.

And get the appliance to use AD for authentication of this user.

Related Articles, References, Credits, or External Links

Original Article Written 18/12/15

Windows Server – Enable LDAPS

Posted on by

KB ID 0000962 

Problem

Active Directory is built on LDAP, I’ve known this for a long time, but other than it’s a directory protocol that’s about all I did know. Like any directory, if you want information when you query the directory it returns a result. The problem is that information is sent in ‘cleartext’, which is not ideal. To address that you can secure and encrypt that traffic with SSL.

The reason I’m concerned with LDAPS this week, well I was deploying, an RSA Authentication Manager Appliance and when I tried to add Active Directory as an Identity source, this happened;

RSA Operations Console

Add New Identity Source

There was a problem processing your request.
Test connection failed. One
or more directory connections is incorrect.

Solution

To query a domain controller over LDAPS you need a certificate to secure that communication, techies tend to back away when PKI is mentioned, I’m not sure why, but most people fear what they don’t understand, and encryption is pretty complicated,but just think;

  • PKI issues certificates to things.
  • The certificates make stuff work.
  • They expire and need to be renewed.

With that in mind, there are two ways for us to solve this problem. Option 1: Install an enterprise root CA on one of your domain controllers, (that fixes all these problems in one hit). If you only have one server that’s probably our best option, but in any production network thats not a very elegant solution. So Option 2: Is setup a domain PKI solution and use that.

If you already have a PKI/CA infrastructure great, if not, then simply pick a server and launch Server Manager > Manage > Add Roles and Features > Add in the Active Directory Certificate Services role > Follow the on screen prompts.

Actually setting up PKI is outside the scope of this article, I’m running with the assumption that you have a Root/Enterprise CA setup and ready to go.

 

1. On your CA Server launch the Certification Authority Management Console > Certificate Templates > Right Click > Manage.

2. Locate the Kerberos Authentication certificate > Make a Duplicate.

3. General Tab > Call it ‘LDAPoverSSL’ > Set its validity period > Decide if you want to publish the cert in AD.

4. Request Handling Tab > Select ‘Allow private key to be exported’ > Apply > OK.

5. Right click Certificate Templates again > Certificate Template to issue.

6. Locate and select the ‘LDAPoverSSL’ certificate > OK.

7. Now logon to a DOMAIN CONTROLLER > Windows Key+R > mmc {Enter} > File > Add/Remove Snap-in > Add in the Certificates Snap-In > Computer account > Finish > OK > Expand Certificates > Personal > Certificates > Right Click > All Tasks > Request New Certificate > Next > Next.

8. Select the LDAPoverSSL Certificate > Enroll > Close the Certificate Snap-in.

9. In my case I need my device to ‘Trust’ the CA, So on the CERTIFICATE SERVER > open a command window and run the following command;

[box]
certutil -ca.cert ca_name.cer
[/box]

10. It will display the certificate PEM on the screen and should complete successfully.

11. You will notice my command was run while I was on the root of the C: Drive, yours will probably be C:Users{your-username} go there and retrieve a copy of the ‘Root Certificate’.

Testing LDAP and LDAPS

12. On another server > Open a command windows and run ldp > Connection > Connect > Type in the FQDN of the DC > Set the port to 636 > Select SSL > OK > It should return some results

Note: If you get an error you may need to reboot the domain controller.

That’s your DC configured (You can repeat the process for further DC’s), but remember Imtrying to connect my RSA Appliance.

Adding Active Directory to RSA Authentication Manager

13. Log onto the Operations Console (https://{fqdn}/oc) Deployment Configuration > Identity Source Certificates > Add New > Add in the Root-Cert you exported above.

14. This time when I add my Active Directory as an Identity Source, it completes without error.

 

Related Articles, References, Credits, or External Links

NA