Cisco ASA VPN LDAP Password Management

If you wish to enable password management for LDAP on a Cisco ASA VPN profile, there are certain requirements to be met.

  1. LDAP over SSL must be enabled for the aaa-server group.  Issue the command: ldap-over-ssl enable on the aaa-server host properties.
  2. The domain controller(s) that you are authenticating to must support LDAPS. You can accomplish this by installing Certificate Services on the domain controller and rebooting it. Once that is done, it will accept LDAPS queries.
  3. You must enable the command password-management on the tunnel-group for the VPN.
  4. Optionally, you can use option  password-expire-in-days <# of days> under password-management to notify users that their password will be expiring. If you do not specify that, users will not be notified but will still be able to change their password once it expires.
See the below commands for an example of a full configuration.
aaa-server MyLDAP protocol ldap
aaa-server MyLDAP (inside) host
 ldap-base-dn DC=My, DC=com
 ldap-scope subtree
 ldap-naming-attribute sAMAccountName
 ldap-login-password *****
 ldap-login-dn CN=ASA VPN, CN=Users, DC=My, DC=com
 ldap-over-ssl enable
 server-type microsoft

tunnel-group Myvpn-LDAP general-attributes
 address-pool ippool2
 authentication-server-group MyLDAP
 default-group-policy Myvpn-AD
 password-management password-expire-in-days 3

Windows 2003 RDP Desktop session or parts of Desktop session is black

I had an issue today where I was connecting to a Windows Server 2003 machine and after logging in my RDP desktop was black.  I could see icons, but text, menus, etc., did not show up.  This is due to corrupted/incorrect color settings in the registry.

Here is what I did to fix it.  Replace the bold parts with your SID.

  1. Opened the registry and browsed to HKLM\SOFTWARE\MICROSOFT\WINDOWS NT\CURRENTVERSION\PROFILELIST and found the SID associated with my login account. In this case, it was S-1-5-21-269 (part of the SID omitted)
  2. Still in registry editor, browsed to HKEY_USERS\S-1-5-21-269\CONTROL PANEL\COLORS
  3. I noticed most of the values, if not all, were set to ‘0 0 0’.  I backed up the registry key.
  4. Create a new registry editor file (.reg) and paste these values into it:
    [HKEY_USERS\S-1-5-21-269\Control Panel\Colors]
    “ActiveBorder”=”212 208 200”
    “ActiveTitle”=”0 84 227”
    “AppWorkSpace”=”128 128 128”
    “Background”=”0 78 152”
    “ButtonAlternateFace”=”181 181 181”
    “ButtonDkShadow”=”113 111 100”
    “ButtonFace”=”236 233 216”
    “ButtonHilight”=”255 255 255”
    “ButtonLight”=”241 239 226”
    “ButtonShadow”=”172 168 153”
    “ButtonText”=”0 0 0”
    “GradientActiveTitle”=”61 149 255”
    “GradientInactiveTitle”=”157 185 235”
    “GrayText”=”172 168 153”
    “Hilight”=”49 106 197”
    “HilightText”=”255 255 255”
    “HotTrackingColor”=”0 0 128”
    “InactiveBorder”=”212 208 200”
    “InactiveTitle”=”122 150 223”
    “InactiveTitleText”=”216 228 248”
    “InfoText”=”0 0 0”
    “InfoWindow”=”255 255 225”
    “Menu”=”255 255 255”
    “MenuText”=”0 0 0”
    “Scrollbar”=”212 208 200”
    “TitleText”=”255 255 255”
    “Window”=”255 255 255”
    “WindowFrame”=”0 0 0”
    “WindowText”=”0 0 0”
    “MenuHilight”=”49 106 197”
    “MenuBar”=”236 233 216”
  5. Place the .reg file on the machine in question and import the settings into the registry.  Log on with the user and all color settings should be restored.


ASA 8.4 – no valid adjacency

I recently went through the process of upgrading a customer’s ASA from 7.2 to 8.4 code.  After the upgrade was finished, I noticed that internet access for my VPN users coming in over a full-tunnel connection was failing.  The debugging I did led me to seeing TCP connections being torn down due to “no valid adjacency.”  This was caused by a NAT rule sourcing from any destined for my VPN subnet. Based on looking at the configuration, I believe the NAT rule was used to NAT exempt internal network traffic to the VPN users.

In the examples below, these are the object groups:

object-group network Inside_LAN

object-group network VPN_Clients

The NAT rule causing the problem was:

nat (inside,any) source static any any destination static VPN_Clients VPN_Clients

I fixed the issue by setting up a more restricted NAT rule:

nat (inside,any) source static Inside_LAN Inside_LAN destination static VPN_Clients VPN_Clients

Merge private key with certificate using OpenSSL

I had an issue where I needed to replace the current SSL certificate on Exchange 2010 with the same certificate that had additional SAN names added.  Unfortunately, the certificate I was provided was not signed by the provider’s (GoDaddy in this case) private key so the certificate could not be directly imported.  I used OpenSSL to sign the certificate with the provided private key and was able to import the certificate into Exchange successfully after creating a temporary certificate to assign the services while I removed the existing certificate to import the newly created one.

Using OpenSSL, run the following command to sign the certificate with the provided private key:

openssl pkcs12 -export -in -inkey server.mydomain.key -out mycertificate.pfx


Offline Files fail to synchronize when moving to new server

You may experience a time when you move file servers due to restructuring or perhaps your old file server dies. You change the folder redirection paths to the new server, but offline files still tries to replicate from the old, non-existent server. To resolve this, you need to format the offline files database on your PC. This will remove the cached files database and old server references and fix your issue.

To format the offline file database open a command prompt and run the following command to add the necessary registry key to your PC and reboot.

REG ADD “HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\NetCache” /v FormatDatabase /t REG_DWORD /d 1 /f

ASA 8.3+ Asymmetric NAT rules matched for forward and reverse flows

For site-to-site (L2L) VPN connections, you may see the following error message on 8.3(2) and later configurations:

%ASA-5-305013: Asymmetric NAT rules matched for forward and reverse flows; Connection for tcp src Outside:x.x.x.x/3214 dst inside:y.y.y.y/80 denied due to NAT reverse path failure

This is due to the unidirectional keyword setup on your NAT configuration that was migrated incorrectly. If you upgraded from 8.2 code directly to 8.3(2) and did not go to 8.3(1) first, the NAT migrations will tag a unidirectional keyword on all the NAT rules which will essentially only allow one-way traffic initiated only from the source side.

Your configuration will look something like this:

nat (inside,any) source static obj-x.x.x.x obj-x.x.x.x destination static obj-y.y.y.y obj-y.y.y.y unidirectional

Simply remove the unidirectional keyword to make your configuration look like the following and you will be good to go.

nat (inside,any) source static obj-x.x.x.x obj-x.x.x.x destination static obj-y.y.y.y obj-y.y.y.y