Tag Archives: LDAPS

O365 with Duo MFA (Without a P1 License?)

Posted on by
4

KB ID 0001737

Problem

Working for a cloud service provider, (and a Duo partner). I get a lot of queries about Duo MFA for Office 365. Typically (I think) the best solution is to enable Azure Conditional Access and couple that with Trusted sites, so clients get challenged when out on the road, but not in the office. The drawback of this is Azure Conditional Access requires a P1 License, at time of writing that’s about $6 a month on top of you normal 365 licence. So it can work out expensive.

A couple of weeks ago, I was on a call with a client who wanted to use Duo Access Gateway to provide Duo MFA to their 365 tenancy. I’ve done the same thing for other clients with ADFS before, Basically you are just Federating a DAG into your Azure AD, rather than Federating an ADFS Server

This is what it looks like;

Duo MFA: DAG & Office 365 Pre-Requisites

  • Azure AD Sync needs to be setup, and a registered domain setup in your office 365 tenancy. (NOT the onmicrosoft domain!)
  • You need (at least) Duo MFA licensing to deploy. One level above free ($30 for a year).
  • DAG Server 2 x CPU, 4GB RAM, 60Gb HDD (Windows Server 2012 or newer (2019 supported) Note: You can also deploy DAG on Linux.
  • DAG Server should be in a DMZ, (not domain joined).
  • DAG Server needs IIS role installing.
  • DAG Server needs TCP Port 443 open (outbound) to Duo.
  • DAG Server needs TCP Port 443 open (Inbound) to Duo on the public IP address that your public DNS record is pointing to.
  • Download PHP (in Zip file format) Keep the Zip file handy.
  • Install a publicly signed SSL certificate (Common name or SAN must match the public DNS name). 

Note: Duo have great walkthroughs and videos on their site, this article is just to tie the various steps together.

Installing Duo MFA DAG

To setup IIS just use the following Powershell commands

[box]

import-module servermanager
add-windowsfeature Web-Server, Web-Mgmt-Tools, Web-CGI, NET-Framework-Core, Web-Asp-Net45, Web-Scripting-Tools

[/box]

Install and Bind a Publicly Signed Certificate: Let’s do this for free with Let’s Encrypt! See the following article.

Free Certificate for IIS with Let’s Encrypt

Download the newest version of PHP in zip format. and drop it on your desktop, then run the Duo Windows installer. You may be prompted to install the C++Runtime software (which may require a reboot). Post reboot the installer will launch.

Browse to and select the PHP Zip file > Next > Select the correct server hostname (if it’s not listed, then you need to enter it in the ‘hostname’ section of the https binding in IIS manager > Next > If you want to manage the DAG from any other IP addresses enter them > Next > Install.

When done  launch the ‘Configure’ page > Create an access password > Submit.

Configure Duo DAG Active Directory LDAPS Access

In the next step we need a copy of your CA Certificate (the CA that issued your domain controller(s) kerberos certificates). If you have just glazed over have a read of the following article;

Get Ready for LDAPS Channel Binding

From the DAG console > Authentication Source > Configure Sources > Select Active Directory* > Enter the FQDN of a domain controller, (the DMZ server needs to be able to resolve this I suggest putting it in the server hosts file).  > Port will be 636 (LDAPS) > Select LDAPS > Scroll down.

*You cant use Azure as a authentication source for Office365 MFA, (counter intuitively!)

Browse to and select the CA certificate you downloaded above > Set the attributes to “mail,sAMAccountName,userPrincipalName,objectGUID” > Search Base (I’m setting it to the top of my active directory e.g. ‘DC=pnl,DC=com’ > Search Attributes (I’ve set the same as the attributes above) > Search Username, set to a normal domain user account, (I’ve set-up a service account that’s just a member of ‘domain  users’ > Scroll down  > Type in the users password > Save Settings.

What should happen is, it should say LDAP Bind Successful, if it does not;

  • Make sure TCP Port 636 is open from the DMZ server to the Domain Controller(s)
  • Make sure you used the domain controller FQDN NOT its IP address, (the IP address is NOT on the Kerberos certificate).
  • Install the Remote Server Admin tools for ADDS – this will give you access to LDP exe which you can test LDAPS connectivity with (I’ve written about LDP before, use the search box above).

When happy, ensure Active Directory is set as the Active Source.

Federate Duo DAG With Azure Active Directory

Within the Duo DAG management console > Applications > Metadata > Download the Certificate  > Copy all the URLS to a notepad file.

 Copy the notepad file, and the certificate, to a domain joined server/PC that has the the Azure Active Directory Module for Powershell installed.

Execute the following commands, (change the values in RED to match your own);

[box]

Connect-MsolService
Log into your Tenancy, when prompted

get-msoldomain -domain your-domain-name.com

Make sure it says 'Managed' and NOT 'Federated'!
$dom = "your-domain-name.com"
$url = "https://portal.petenetlive.co.uk/dag/saml2/idp/SSOService.php"
$uri = "https://portal.petenetlive.co.uk/dag/saml2/idp/metadata.php"
$logoutUrl = "https://portal.petenetlive.co.uk/dag/saml2/idp/SingleLogoutService.php?ReturnTo=https://portal.petenetlive.co.uk/dag/module.php/duosecurity/logout.php"
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\dag.crt")
$certData = [system.convert]::tobase64string($cert.rawdata)
Set-MsolDomainAuthentication –DomainName $dom -Authentication Federated -PassiveLogOnUri $url -ActiveLogOnUri $url -IssuerUri $uri -LogOffUri $logoutUrl -PreferredAuthenticationProtocol SAMLP -SigningCertificate $certData

get-msoldomain -domain your-domain-name.com
NOW it should say 'Federated'!

[/box]

Duo MFA Protect Office 365

Log into your Duo online admin console > Protect an application > Locate Office 365 (2FA with SSO self hosted) > Protect.

Unless ALL your mail clients* support modern authentication then tick “Allow legacy mail clients that only support basic auth to bypass 2FA” 

*Modern Authentication Supported on: Outlook 2013 (or newer), older Android mail clients don’t, though on modern versions of Android that you can install MS Outlook on does. Modern Apple IOS devices support modern authentication.

Click ‘Save Configuration‘.

Click “Download your Configuration File” this will download a JSON configuration file, put it somewhere your Duo DAG server can get to.

Add Office 365 MFS to Duo DAG

Back on the DAG server > Applications > Browse > Select the JSON file you downloaded above.

Open a web page, and try to log into office 365, after  you’ve entered your username, you should be forwarded to your DAG for 2FA

Related Articles, References, Credits, or External Links

NA

FortiGate LDAPS Authentication Failure

Posted on by
2

KB ID 0001733

Problem

Here’s a brief one that tripped me up a couple of weeks ago, I was deploying FortiGate LDAPS authentication for some FortiClient SSL VPN connections into a FortiGate firewall like so;

Despite my best efforts I was getting authentication failures? If I tested the username and password in the GUI web management portal, that worked fine?

Testing FortiGate LDAPS

First step is to test authentication at command line, like so;

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' failed!

[/box]

Note: My-DC is the domain controller, test, user is the username, and Password123 is the password for my AD user. (The fact I need to explain that is depressing, but c’est la vie).

So despite what the GUI is telling me, authentication is actually failing, remember I’m using LDAPS, so the FortiGate needs to have the CA certificate, (that issued the Kerberos certificates on my domain controller(s)), in its trusted CA list! And TCP port 636 needs to be open between the firewall and the domain controllers.

Debugging FortiGate LDAPS

So now we need to debug what’s going on;

[box]

Forti-FW # diagnose debug enable
Forti-FW # diagnose debug application fnbamd 255
Debug messages will be on for 30 minutes.

[/box]

Then simply attempt to authenticate via FortiClient, or recall the ‘diag test’ command from above.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
[1932] handle_req-Rcvd auth req 1296531457 for test.user in My-DC opt=0000001b prot=0
[424] __compose_group_list_from_req-Group 'My-DC', type 1
[617] fnbamd_pop3_start-test.user
[970] __fnbamd_cfg_get_ldap_list_by_server-
[976] __fnbamd_cfg_get_ldap_list_by_server-Loaded LDAP server 'My-DC'
[1131] fnbamd_cfg_get_ldap_list-Total ldap servers to try: 1
[1713] fnbamd_ldap_init-search filter is: sAMAccountName=test.user
[1722] fnbamd_ldap_init-search base is: dc=testbench,dc=co,dc=uk
[1146] __fnbamd_ldap_dns_cb-Resolved My-DC:192.168.1.122 to 192.168.1.122, cur stack size:1
[919] __fnbamd_ldap_get_next_addr-
[1152] __fnbamd_ldap_dns_cb-Connection starts My-DC:192.168.1.122, addr 192.168.1.122 over SSL
[874] __fnbamd_ldap_start_conn-Still connecting 192.168.1.122.
[591] create_auth_session-Total 1 server(s) to try
[1097] __ldap_connect-tcps_connect(192.168.1.122) failed: ssl_connect() failed: 337047686 (error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed).
[930] __ldap_error-My-DC:192.168.1.122, addr 192.168.1.122
[725] __ldap_stop-Conn with 192.168.1.122 destroyed.
[919] __fnbamd_ldap_get_next_addr-
[902] __ldap_try_next_server-No more server to try for 'My-DC'.
[785] __ldap_done-svr 'My-DC'
[755] __ldap_destroy-
[2870] fnbamd_ldap_result-Error (3) for req 1296531457
[217] fnbamd_comm_send_result-Sending result 3 (nid 0) for req 1296531457, len=2044
authenticate 'test.user' against 'My-DC' failed!
Forti-FW # [747] destroy_auth_session-delete session 1296531457
[755] __ldap_destroy-
[1764] fnbamd_ldap_auth_ctx_free-Freeing 'My-DC' ctx
[2099] fnbamd_ldap_free-Freeing 'My-DC'

[/box]

OK so it’s SSL related? For SSL to work you need the following;

  1. To trust the CA that issued the certificate
  2. To be able to resolve (via DNS) the common name (or Subject Alternative Name) on the certificate
  3. If you’ve specified the LDAP server by IP address the IP address of the server needs to be on the certificate as a Subject Alternative Name (SAN).
  4. Your firewall and the AD/LDAP server need to have compatible SSL ciphers.

So I had number 1 covered, and the chance of it being number 4 are rare, (server and firewall are fully updated).

So my problem was initially number 2 I’d specified the LDAPS server via its internal IP. I needed to use its FQDN, then of course the firewall needed to be able to resolve that IP with a DNS lookup (try execute ping server-name.doman-name if you’re unsure!)

[box]

Forti-FW # execute ping win-server.testbench.co.uk
Unable to resolve hostname.  <---OOPS THAT'S NOT GOOD!

Forti-FW # execute ping 192.168.1.122 <---CONNECTIVITY IS OK!
PING 192.168.1.122 (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=5.4 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.0 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=1.9 ms
^C
--- 192.168.1.122 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 1.9/3.1/5.4 ms

[/box]

Once DNS was setup correctly;

[box]

Forti-FW # execute ping win-server.testbench.co.uk
PING win-server.testbench.co.uk (192.168.1.122): 56 data bytes
64 bytes from 192.168.1.122: icmp_seq=0 ttl=128 time=1.9 ms
64 bytes from 192.168.1.122: icmp_seq=1 ttl=128 time=2.3 ms
64 bytes from 192.168.1.122: icmp_seq=2 ttl=128 time=2.1 ms
^C
--- win-server.testbench.co.uk ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss <---BOOM THAT'S BETTER
round-trip min/avg/max = 1.9/2.1/2.3 ms

[/box]

Then retest.

[box]

Forti-FW # diag test auth ldap My-DC test.user Password123
authenticate 'test.user' against 'My-DC' succeeded!
Group membership(s) - CN=GS-VPN-Users,OU=Securty-Groups,DC=testbench,DC=co,DC=uk
                      CN=Domain Users,CN=Users,DC=testbench,DC=co,DC=uk

[/box]

Related Articles, References, Credits, or External Links

NA

AnyConnect: ‘Quick and Dirty’ Duo 2FA

Posted on by
4

KB ID 0001701

Problem

Normally if I were deploying Duo 2FA with AnyConnect I’d deploy a Cisco RADIUS VPN on my LAN, (usually on my Duo Authentication Proxy). See the following article;

AnyConnect: Enable Duo 2Factor Authentication

However, last time I set this up, a colleague said ‘Oh by the way, you don’t need to do that, you can just point the firewall directly at Duo‘. I was initially skeptical but I tried it, and it worked. I thought no more about it until this week when another colleague asked me to help him setup Duo for AnyConnect.

As you can see the firewall queries Duo using LDAPS, but the Duo product I’m using is called ‘Cisco RADIUS VPN’. This makes my networking OCD itch tremendously! (RADIUS and LDAPS are completely different protocols!) But it works, so here we go.

Solution

Note: For this solution you don’t even need to sync your users to Duo, (but it’s OK if you do)! As long as the users exist there.

With Duo, you need to select ‘protect an application‘ and select ‘Cisco RADIUS VPN‘. If you are unfamiliar with Duo you need to take a copy of the Integration Key, the Secret Key and the API Hostname. (Note: Don’t try using these ones, they have been changed!)

On the Firewall > Configuration > Device Management > Users/AAA > AAA Server Groups > AAA Server Groups > Add > Call it ‘DUO-EXTERNAL’ > Select LDAPS > OK.

With your DUO-EXTERNAL group selected > In the bottom window > Add.

  • Interface Name: {Your outside interface name}
  • Servername: {Your Duo API Hostname}
  • Timeout: 60 
  • Enable LDAP over SSL: Enabled
  • BaseDN: dc={Your Integration Key},dc=duosecurity,dc=com
  • Naming Attribute: cn
  • Login DN: dc={Your Integration Key},dc=duosecurity,dc=com
  • Login Password: {Your Secret Key}

OK > Apply.

TO TEST: Press Test > Select Authentication > Use the username displayed in Duo > Type push into the password box, and your phone should then prompt for 2fa authentication. (If it fails: Make sure the time is correct on the ASA, and at least do some debugging before posting below!)

Now either create a new AnyConnect profile, and use this new AAA method, or simply change the AAA method for an existing AnyConnect profile, (like below).

A word of warning, when I did this, (both in production and on my test ASA,) I got a strange error, I’ve documented that and the fix, below.

AnyConnect: Unauthorized Connection Mechanism

Related Articles, References, Credits, or External Links

NA

Duo: Migrate from LDAP to LDAPS

Posted on by
3

KB ID 0001647

Problem

With the impending ‘turning off’ of cleartext LDAP queries to Windows Server, I wanted to make sure my new Duo deployments were already using LDAPS. I got LDAP deployed very quickly and easily, but making the ‘swap’ to LDAPS proved to be massively problematic.

Normally I find Duo a pleasure to deploy, but their technical documentation just confused me for this and I went running up some blind alleys, and eventually ended up logging a call to Duo to try to get it working. So to save you this pain, read on.

Solution

Firstly your domain controller(s) need to be setup to accept LDAPS queries, SORT THAT OUT FIRST. I’ve covered that in the following post;

Get Ready for LDAPS Channel Binding

In the following section I’ll assume you have LDAP already setup on your Duo ADSync, if this is a new deployment, and you are going straight to LDAPS, then you can ignore this next section.

Duo Existing LDAP AD Sync

It goes without saying, (but I’ll say it anyway,) your ADSync should already be connected, if you’re switching room LDAP!

So your domain controller(s) will be using TCP port 389.

Your transport type will be set to ‘Clear’.

Duo Deploy LDAPS for ADSync

The first thing that held me up was reading the Duo documentation, and wondering what I needed to add to my authproxy.cfg file! The truth is;

YOU DON T NEED TO ADD ANYTHING TO AUTHPROXY.CFG!!

Here’s a copy of mine for reference, you ONLY need the sections highlighted, the additional section on mine was for my Cisco ASA RADIUS client;

Rights and Permissions for Duo Service Account

Note: By default the Duo service on your Duo Auth Proxy server will be running under the LOCAL SYSTEM ACCOUNT. I had problems using this account, so I used the service account specified in the authproxy.cfg file. But there are some rights you need to assign to the account first. On the Auth Proxy server, run secpol.msc > Security Settings > Local Policies > User Rights Assignment > Log on as a service > Add User or Group > Add in your Duo service account.

 

All domain users should have the following right, but let’s take a ‘belt and braces’ approach! On a domain controller open ‘Active Directory Users and Computers’ > Right click your domain > Properties > Security > Advanced.

Add in the Duo service account, and grant;

  • List contents
  • Read all properties
  • Read properties

Note: They will probably, already be selected.

Finally: Add the Duo service account to the LOCAL ADMINISTRATORS group on the Duo Auth Proxy server, (Server Manager > Tools > Computer Management).

You can now open the services console and change the account the service runs under, to the Duo Service account, (Windows Key + R > services.msc > OK > Locate ‘Duo Authentication Proxy Service’ > Properties > Log On > Change the account to your service account and enter the password.) Then RESTART THE SERVICE.

Change Duo ADSync to LDAPS

To do this you are going to need a copy of your Root CA certificate (in PEM format). If you have Microsoft Certificate services make sure you get a copy of the Root CA cert in Base 64 format, (if you don’t, when you open the Certificate with Notepad, it will link like gobbledegook!)

Open your Cert with a text editor, and it should look a bit like this, copy that, (with no additional spaces on the end!) To the clipboard, you will need to paste it into the Duo Admin Panel in a minute.

In the Duo Amin Portal > Users > Directory Sync > Active Directory > ADSync > Change the port on your Domain controllers to 636 (That’s LDAPS TCP Port 636, so it needs to be open on any firewalls between the Duo Auth Proxy, and the domain controllers!)

Go to Transport Type > Change to LDAPS > Paste in your CA Certs PEM information into the ‘SSL CA Certs’ Section > Save Directory.

Why didn’t you tick ‘SSL Verify Hostname’? Simply because it fails when I do that, I’m assuming the common name on the LDAPS cert on my domain controllers is the hostname of the DC, and not its FQDN, so I needed to leave this unticked.

All being well it should say connected.

Troubleshooting Duo LDAPS

Duo have a tool that will check your domain controller certificates are OK. It’s called acert.exe or you can enable debugging, or use the connectivity tool.

Related Articles, References, Credits, or External Links

NA

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

Cisco AnyConnect – Allow Domain Password Change via LDAP

Posted on by
4

KB ID 0001273 

Problem

 

If you have remote users who connect via VPN, and a policy that forces them to change their password periodically, this can result in them getting locked out without the ability to change their password (externally).

If your Cisco ASA is using LDAP to authenticate your users, then you can use your remote AnyConnect VPN solution to let them reset their passwords remotely.

Solution

Standard LDAP runs over TCP port 389, to allow the ASA to reset the password for the users, it needs to be connected via LDAPS ((TCP Port 636). Your AD server needs to be able to authenticate via LDAPS, by default it will not. I’ve already covered how to set that up in another post see the following article.

Windows Server 2012 – Enable LDAPS

So, assuming your AD server(s) that the Cisco ASA is authenticating against is already setup, you need to ensure that your AAA Settings for LDAP is set to use port 636.

Enable LDAPS via Command Line

On my test network I only have one LDAP server in my LDAP AAA group, you may need to repeat this procedure for each one in yours.

[box]

Petes-ASA(config)# aaa-server TEST-LDAP-SERVER (inside) host 192.168.110.10
Petes-ASA(config-aaa-server-host)# server-port 636

[/box]

Enable LDAPS From within the ASDM

Log into the ADSM  > Configuration > Device Management > Users/AAA  > Select the LDAP Server Group > Select the Server > Edit > Enable LDAP over SSL > Server Port = 636.

Note: If you attempt to reset a user password without LDAPS, then you will see the following error;

Unwilling to perform password change

Next you need to edit the AnyConnect connection profile to allow password resets. Or the tunnel-group if you work at command line.

Allow Password Reset via Command Line

[box]

Petes-ASA(config)# tunnel-group ANYCONNECT-PROFILE general-attributes
Petes-ASA(config-tunnel-general)# password-management password-expire-in-days 3

[/box]

Allow Password Reset via ASDM

Connect to the ADSM > Configuration > Remote Access VPN > Network Client remote Access > AnyConnect Connection Profile > Select the one for AnyConnect > Edit > Advanced > General > Password Management > Enable Password Management > Select to notify user the amount of days before his/her password expires > OK > Apply > File > Save running configuration to flash.

Now your users have the ability to reset their password remotely as they are about to expire, and when they have expired.

If you want to test with a particular user you can set his password to ‘expired’ using the following procedure;

Reset an AD Users Password Expiry Date

Related Articles, References, Credits, or External Links

NA

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

Cisco ASA – Allowing Domain Trusts, and Authentication

Posted on by

KB ID 0000973 

Problem

I cringed this morning when I was asked about this, last time I had to get a client to authenticate to a domain through a firewall, it was ‘entertaining’. The problem is Windows loves to use RPC, which likes to use random ports, so to make it work you either had to open TCP ports 49152 and 65535 (Yes I’m Serious). Or you had to registry hack all your domain controllers and specify individual ports for RPC as per MS KB 224196, then allow those ports. I have a client that’s got a separate domain in their DMZ and I need to setup a trust with their internal domain, so I started writing the firewall config. Then when I asked the ‘Do you want to open all these ports or simply lock RPC down on all the domain controllers?’ Question, my colleague found ‘dcerpc’ inspection.

Dcerpc has been available since at least ASA version 7.2, I had never heard of it! Cisco Says;

DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.

DCERPC inspection maps inspection for native TCP communication between a server called the Endpoint Mapper (EPM) and client on the well-known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and port number are received from the applicable EPM response messages. Because a client can attempt multiple connections to the server port returned by EPM, creation of multiple pinholes is allowed

Heres how to do it with the following topology;

Note: Setting up a ‘Trust’ or allowing a client to ‘Authenticate’ requires the same configuration, but below I will use the IP of the Domain controller, rather than the IP of the client.

Solution

I’m assuming you ALREADY have access-lists from your internal network, and from your DMZ, you may need to replace the names of the ACL’s I use below with your own, ‘show run access-group’ will tell you.

1. There are a myriad of ports, (both TCP and UDP) that you are required to open, those being;

So connect to the ASA, Go to enable mode, then global configuration mode, and add the ACL’s to open the ports above. BE AWARE the last line enables ICMP/ping (just for testing you can remove it later and you will need to have ICMP inspection on for it to work).

[box]


Type help or '?' for a list of available commands.
PetesASA> enable
Password:**********
PetesASA# configure terminal
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 135
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 464
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 464
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 389
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 389
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 636
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 3268
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 3269
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 53
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 53
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 88
PetesASA(config)#access-list outbound permit udp host 192.168.1.10 host 172.16.1.10 eq 88
PetesASA(config)#access-list outbound permit tcp host 192.168.1.10 host 172.16.1.10 eq 445
PetesASA(config)#access-list outbound permit icmp host 192.168.1.10 host 172.16.1.10

[/box]

2. Then we need to allow the traffic from the other direction, again here my ACL is called ‘DMZ’, check and change yours accordingly.

[box]PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 135
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 464
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 464
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 389
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 389
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 636
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 3268
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 3269
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 53
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 53
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 88
PetesASA(config)#access-list DMZ permit udp host 172.16.1.10 host 192.168.1.10 eq 88
PetesASA(config)#access-list DMZ permit tcp host 172.16.1.10 host 192.168.1.10 eq 445
PetesASA(config)#access-list DMZ permit icmp host 172.16.1.10 host 192.168.1.10[/box]

3. Now create a class-map and set it to inspect TCP port 135.

[box]PetesASA(config)# class-map CM-DCERPC
PetesASA(config-cmap)# match port tcp eq 135[/box]

4. Then create a policy-map to use that class map to perform dcerpc inspection.

[box]PetesASA(config-cmap)# policy-map PM-DCERPC
PetesASA(config-pmap)# class CM-DCERPC
PetesASA(config-pmap-c)# inspect dcerpc
PetesASA(config-pmap-c)# exit [/box]

5. Finally apply the policy-map to the interfaces with a service-policy.

[box]PetesASA(config)# service-policy PM-DCERPC interface inside
PetesASA(config)# service-policy PM-DCERPC interface DMZ[/box]

6. Give it a test, make sure the machines can ping each other, and you may at this point want to remove the ICMP lines from the ACL. Once you are happy, save the changes.

[box]PetesASA# write mem
Building configuration…
Cryptochecksum: 4d7f7ccd 5c55a9e1 6ced12c4 46728bc7
[OK]
PetesASA#[/box]

 

Related Articles, References, Credits, or External Links

NA