Tag Archives: port 636

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