ASA LDAP Authentication

[sbader48220]

I'm testing LDAP authentication on our ASA and it is working well. A problem I am experiencing though is that we have some users who log in as 'DOMAIN\user' and 'user@domain.org'. LDAP authentication doesn't appear to support this. I'm able to log in as 'user' just fine, but 'DOMAIN\user' and 'user@domain.org' do not work. I've enabled the options to strip the realm and group before sending to the AAA server, but it doesn't make a difference. Using 'user@domain.org' and 'DOMAIN\user' works fine when authenticating using RADIUS via IAS.

Does anyone know if there is a way to support 'DOMAIN\user' and 'user@domain.org' authentication while using LDAP authentication? Is there a way to just strip this information before sending it to LDAP?

Thanks,

-Steve

[Eric Hansen]

When you say "I'm able to log in as 'user' just fine" - what LDAP attribute does that apply to?

In MS AD, the DNS login (user@domain) maps to the 'userPrincipalName' attribute

In MS AD, the netbios login (domain\user) maps to the 'sAMAccountName' attribute

Ive never personally mapped ASA directly to AD (we go through ACS) but it should be pretty straight forward. Choose which attribute you want to have for user itendity and specify it in the server group on the ASA under 'naming attribute'.

I am assuming your Base DN(never query the whole of AD), Login DN/password, attribute maps and are all good.

hth

e-

[sbader48220]

'user' maps to sAMAccountName. I'm not able to get 'DOMAIN\user' to work when using sAMAccountName as the 'naming attribute'. I am able to use userPrincipalName and use the 'user@domain' login, and it does work, but then that breaks just 'user'. I'm trying to find a way to make it so all three combinations (user,DOMAIN\user,user@domain) will all work.

Thanks,

-Steve

[Eric Hansen]

I'm wondering if its something in the code, or maybe something just beyond me.

I tried to replicate what your doing on some dev ASA's and when I use userPrincipalName I can get user@domain to work. When I use sAMAccountName I can get juse user to work. But when I put a comma seperated multivalue of 'sAMAccountName,userPrincipalName' I cant get anything to work. I have also tried "sAMAccountName, userPrincipalName" with the quotes no luck.

Any idea what the delimiter might be?

I thumbed through the docs, and I cant find any indication that the naming attribute cant be multivalue. I assume it can since is says in ASDM "naming attribute(s)".

[sbader48220]

Looks like you're trying the same things I am. I was looking at how it says "naming attribute(s)" as well and thinking it must allow multiple options. I've tried comma and semi-colon with no luck.

I appreciate your help. This is definitely and interesting one. I want to get very restrictive with user access, and mapping access to groups within AD makes the most sense in our situation, otherwise I'd just use RADIUS.

Thanks for all your help!

-Steve

[Eric Hansen]

no problem, barring you calling tac I'll keep playing with this. I'll have a ccie sec here on thursday, maybe he'll know. =)

They should really specify in the docs. =(

[Eric Hansen]

Hey I was looking at the command line and I am starting to think its is not a multivalue attribute. I took this from the CLI..

aaa-server-host mode commands/options:

WORD < 129 char Specify the Relative Distinguished Name attribute that

uniquely identifies an entry on the LDAP server

ASAVPNUsers(config-aaa-server-host)# ldap-naming-attribute samaccountname ?

aaa-server-host mode commands/options:

"samaccountname ?" and all we get back is a ? that tells me that there is not a seperator value. Could be looking at a clerical error in the ASDM.

and if you pass in "ldap-naming-attribute userprincipalname" in the hopes you can have the command twice, it overwrites other other vale and replaces with the new.

e-

[sbader48220]

I'm going to contact TAC to get a firm answer on this. I was also looking at the CLI and came to the same conclusion as you. Maybe there is way to use a regex to change the username. I'm going to open the case in a minute here.

Thanks!

[sbader48220]

I just spoke with TAC. It appears as though the strip realm/group feature should work, but there is a bug in 8.2(1) which prevents this from working. They are sending me another release to try. I'll try it tomorrow and let you know.

Thanks,

-Steve

[Jatin Katyal]

HI Steve,

What kind of VPN connection do you have?

remote access or L2TP or what?

Check the Cisco documentation:

http://www.cisco.com/en/US/docs/security/asa/asa80/command/reference/s8.html#wp1408323

Did you try this:

hostname(config-tunnel-general)# default-group-policy remotegrp

hostname(config-tunnel-general)# strip-realm

There is a bug also and it has identified the problem of not stripping the realm in

L2TP/IPSEC connection as a functionality bug and have registered a defect CSCta39633.

Looks like this bug has been fixed in 8.002(001.010)

TIP: stripping is also possible on the ACS server since you are using LDAP directly with ASA...this is not for you :)

HTH

Regards,

JK

[sbader48220]

Hi,

I'm using LDAP authentication for IPSec and Clientless SSL & AnyConnect authentication.

TAC sent me version 8.2(1)1, but it still doesn't appear to be stripping the realm. I'm enabled 'strip-realm' for the group policy we're using, but it isn't making any difference. As a test I setup RADIUS authentication, and it still doesn't strip the realm when using RADIUS.

I'd have no problem using RADIUS, but I need to be able to allow users within certain groups within Active Directory access to specific resources. For instance, users in the 'intranet' group get Clientless access and get the intranet bookmark. Only users who are in the 'anyconnect' group can connect via anyconnect, etc. I haven't found an easy way to do this through RADIUS.

Thanks,

-Steve

[sbader48220]

So here is what I've found out after working with TAC. There is a bug in 8.2.1 which prevents the strip realm and strip group commands from working. I downgraded to 8.0, and it works, but that only supports user@domain, and not DOMAIN\user.

So, my workaround is to use RADIUS authentication for IPSec access and LDAP for SVC and WebVPN. It isn't pretty, but it works.

Thanks for all the help!

=Steve