Posts Tagged Active Directory

Cisco ASA and Windows Server 2008: Welcome Back LDAP

You may or may not have problems doing Windows style authentication to your Server 2008 for your AAA access on your ASA firewall.

I have seen it work and not work, I suspect that the forest/domains were probably at different levels, I have heard that Server 2008 doesn’t support NTLM version 1.

If your doesn’t or you want to use LDAP, read on.  One reason you may want to use LDAP is you can stack attributes using Dynamic Policies,

The first problem I will encounter at a customer site is getting the ASA to talk to the domain controller as part of the LDAP AAA group setup. Usually it’s an OU issue, to find the exact string run the dsquery command on the Domain Controller (DC):

dsquery user -samid ciscoldap
"CN=ciscoldap,OU=Service Accounts,OU=HQ,DC=somedomain,DC=com"

In the case above there was an additional OU of HQ.  Now when clicking on the Test button on AAA group setup it successfully communicates.


Be aware that a failure of credentials for LDAP will give the same error as if there is a connectivity issue or the Windows firewall is blocking the port.


Now the cool thing IMHO is you can browse the various Windows attributes from with in the ASA.  I use this to “stack” attributes, instead of just controlling whether someone can log in if the RemoteDialIn I can also authorize them based on membership in a second group or select a group policy depending on which AD attributes match.


To View the various AD groups that can be used as a selection criteria go to:

Remote Access VPN>Clientless SSL>Dynamic Access Polocies

On the left select Add,  then LDAP for AAA Attribute type.  Now click on “Get AD Groups” and you can change filters, policies, etc all based on AD group membership.

Ideal for keeping vendors limited to work hours and a single network asset.

Share

, , , ,

No Comments

x64 Sagas: Trashed DNS and Active Directory

Just recovered an Active Directory domain that was hurting (busy weekend) . DNS was not pushing correctly between servers, AD replications stopped and Exchange went offline except for OWA access.

Problem was traced to a probably corrupted DNS cache file on the Exchange server, demoting and re-promoting the server did not help. Users were getting immediate rejections from the Exchange server as offline and attempts to create new email accounts would fail as being not reachable. When substituting a domain controller’s name for the exchange server entry in Create Account, the process would get further: the server would be replaced with the underlined (real) name of the Exchange server and the username would verify as underlined, and then fail for lack of connectivity, pretty clear proof that it was a DNS issue.

On top of that DNSMGR was acting funny and stopping netlogon and running netdiag /fix was not backfilling the zone correctly.

Bottom line was we changed the DNS instance to Slave and changed the other DC to allow transfers and forced a transfer of zones (deleted all cache files we could find first). We then reintegrated DNS with AD and tested. Email started flowing and the Exchange server once again knew his own name.

Why is this an x64 Saga? The Exchange server was 2007 which only runs on x64 and the <skepticism> only </skepticism> event that we can find is that the x32 AD utilities may have been run against the x64 install which is supposed to be bad. I am not going to put the customer through proving it by testing that theory in detail, one remaining issue is the dnsmgr app remains broken, we have to use the DNS snapin for MMC to see the zones.

Share

, , , , , , , , ,

No Comments