Cisco ASDM/MS AD VPN authentication question

lsud00d

So I'm not a network guy but I can poke around the ASDM interface to get an idea of what's going on. I'm trying to do cleanup in AD and as of now we have several AD groups that membership grants access to the VPN, however in the ASDM I can only locate one location where groups are specifically mentioned (Remote Access VPN-->Network (Client) Access-->Dynamic Access Policies.)

I don't see any attribute mappings in use so it appears to be controlled through DAP's but there are only 2 AD groups configured and somehow there are other groups in our AD that allow users to access the VPN. I can't figure out where else they would be coming from...I don't think it's RADIUS either.

Any pointers?

ASDM version is 7.1. I've been looking through Cisco docs and on Google but no avail.

TIA

RouteMyPacket

lsud00d wrote: »

So I'm not a network guy but I can poke around the ASDM interface to get an idea of what's going on. I'm trying to do cleanup in AD and as of now we have several AD groups that membership grants access to the VPN, however in the ASDM I can only locate one location where groups are specifically mentioned (Remote Access VPN-->Network (Client) Access-->Dynamic Access Policies.)

I don't see any attribute mappings in use so it appears to be controlled through DAP's but there are only 2 AD groups configured and somehow there are other groups in our AD that allow users to access the VPN. I can't figure out where else they would be coming from...I don't think it's RADIUS either.

Any pointers?

ASDM version is 7.1. I've been looking through Cisco docs and on Google but no avail.

TIA

From your perspective, DAP is most likely irrelevant. You need to know how they are authenticating and verify which AD groups are in production yes?. RADIUS most likely, so go to Configuration->Device Management->Users/AAA->AAA Server Groups

Here you should see the server group for your NPS/RADIUS server. RDP to your server and go to Administrative Tools->NPS and you will see the RADIUS client being the ASA is in there coupled with network policies and from there you will see the AD groups applied.

Also, post a running-config snippit

lsud00d

Thanks RMP. Here's the running config of what I believe is the relevant information. I sanitized some of the data, D1 = domain one and D2 = domain two, there is a two-way transitive trust between forests (each domain is in a different forest).

You need to know how they are authenticating and verify which AD groups are in production yes?

Yes, this is essentially what I am trying to do.

The DAP's are the only place I see specific AD groups mentioned. Let me know if you need a different/specific part of the config:

dynamic-access-policy-record DfltAccessPolicy
dynamic-access-policy-record D1-MGMT-ANYCONNECT-USERS
description "Management Group AnyConnect Users"
dynamic-access-policy-record D1_STAFF
description "D1 AnyConnect Users"
aaa-server RADIUS protocol radius
merge-dacl before-avpair
aaa-server RADIUS (SERVER-CORE) host 10.10.10.60
key *****
aaa-server D2 protocol ldap
aaa-server D2 (SERVER-CORE) host 172.17.22.10
ldap-base-dn OU=Vendors,DC=D2,DC=ORG
ldap-scope subtree
ldap-login-password *****
ldap-login-dn D2\service.asa
server-type microsoft
group-search-timeout 300
aaa-server ORION01 protocol radius
ad-agent-mode
aaa-server ORION01 (SERVER-CORE) host 10.40.0.20
key *****
aaa-server D1-AD protocol ldap
aaa-server D1-AD (SERVER-CORE) host 10.40.9.10
ldap-base-dn DC=D1,DC=ORG
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn CN=service asa,OU=NoPolicy,OU=Servers,DC=D1,DC=ORG
server-type microsoft
aaa-server RADIUS01 protocol radius
aaa-server RADIUS01 (SERVER-CORE) host 10.40.0.40
key *****
no mschapv2-capable
user-identity domain D2 aaa-server D2-DC7
user-identity default-domain D2
user-identity action domain-controller-down D2 disable-user-identity-rule
user-identity ad-agent aaa-server ORION01
url-server (SERVER-CORE) vendor websense host 10.40.54.10 timeout 30 protocol TCP version 1 connections 25
aaa authentication enable console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL
aaa authentication serial console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL

lsud00d

Regarding RADIUS--

I looked at it earlier and the RADIUS server mentioned in the config only has network policies configured for internal wifi and AD authentication to manage the network devices themselves. The NPS is very straightforward and from what I can see is not handling VPN authentication.

RouteMyPacket

Look at this server 10.10.10.60, it most likely authenticating your VPN users from the looks of this config

description "Management Group AnyConnect Users"
dynamic-access-policy-record D1_STAFF
description "D1 AnyConnect Users"
aaa-server RADIUS protocol radius
merge-dacl before-avpair
aaa-server RADIUS (SERVER-CORE) host 10.10.10.60
key *****

lsud00d

Heh, I totally forgot about that lil guy. He's a D1 legacy RADIUS server who has one more remote access policy than RADIUS01 (other than internal wifi and connecting to devices), and it is aptly titled 'ASA-VPN-Authentication' but it only contains one AD group. So, there still exists other groups in AD that users are members of and somehow connect to the VPN.

RouteMyPacket

lsud00d wrote: »

Heh, I totally forgot about that lil guy. He's a D1 legacy RADIUS server who has one more remote access policy than RADIUS01 (other than internal wifi and connecting to devices), and it is aptly titled 'ASA-VPN-Authentication' but it only contains one AD group. So, there still exists other groups in AD that users are members of and somehow connect to the VPN.

How do you know users connect with the groups? Have you tested this or just going off seeing they exist in AD? If they are not defined within the VPN/RADIUS configuration they are not being utilized for authentication.

lsud00d

I know what you're saying and I'll do further testing/poking around. Essentially, I have tested this with AD group membership and there are groups that are not the three found in RADIUS or the two found in the DAP's that grant VPN access. It's a head scratcher.

RouteMyPacket

Ok, now looking closer you should find your users are authenticating based on the following DAP Group Policy

dynamic-access-policy-record D1-MGMT-ANYCONNECT-USERS

Which in turn uses 10.10.10.60 as the RADIUS server, I would have to look through it myself to say more but I doubt the "DfltAccessPolicy" which is the default group policy is being used and if it is will be providing functionality to end users who do not match the "D1-MGMT-ANYCONNECT-USERS" policy

lsud00d

I checked the current connections and one is using this connection profile:

aaa-server D1-AD protocol ldap
aaa-server D1-AD (SERVER-CORE) host 10.40.9.10
ldap-base-dn DC=D1,DC=ORG
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn CN=service asa,OU=NoPolicy,OU=Servers,DC=D1,DC=ORG
server-type microsoft

It has the base DN so it can do it's LDAP crawl, but this says nothing of group AD specificity.

RouteMyPacket

lsud00d wrote: »

I checked the current connections and one is using this connection profile:

aaa-server D1-AD protocol ldap
aaa-server D1-AD (SERVER-CORE) host 10.40.9.10
ldap-base-dn DC=D1,DC=ORG
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-password *****
ldap-login-dn CN=service asa,OU=NoPolicy,OU=Servers,DC=D1,DC=ORG
server-type microsoft

It has the base DN so it can do it's LDAP crawl, but this says nothing of group AD specificity.

That is your authentication method for your VPN users right there. D1-AD is your group most likely

One way to check is to connect to the VPN then on the ASA run the following command

sh vpn-sessiondb detail webvpn

RouteMyPacket

Also, check this out..will help shed some light on this for you

ASA 8.0: Configure LDAP Authentication for WebVPN Users - Cisco Systems

lsud00d

Thanks for the info, I was referencing this for ASDM 7.1:

Book 3: Cisco ASA Series VPN ASDM Configuration Guide, 7.1 - General VPN Setup  [Cisco Adaptive Security Device Manager] - Cisco Systems

About to head out for the day, will look more into it tomorrow. Thanks for your help RMP!

RouteMyPacket

You can also check in ASDM, go to Configuration->Remote Access VPN->AAA/Local Users->LDAP Attribute Map

Give you a GUI to look through

Cheers

phoeneous

RouteMyPacket wrote: »

sh vpn-sessiondb detail webvpn

Or, sh vpn-sessiondb detail anyconnect

lsud00d

OK the sh vpn-sessiondb detail looks like the CLI equivalent of Monitoring-->VPN-->Statistics, which I was looking at yesterday. I ran the command and it looks like everyone that's connected currently is using the D1-MGMT-ANYCONNECT Group Policy/Tunnel Group. All of these users are in the defined AD group so I'll have to wait for someone else to connect that I know is not in an AD group I've located to see what's going on.

Also as mentioned, there's nothing going on with the LDAP attribute mapping, so it has to be AD group membership, right?

lsud00d

Alright so...as is often the case with things you should not believe everything you are told. Apparently the ASA is authenticating anyone with domain membership (lol). So I guess I'll be seeing how to lock this down! Thanks for the help y'all.

phoeneous

lsud00d wrote: »

Alright so...as is often the case with things you should not believe everything you are told. Apparently the ASA is authenticating anyone with domain membership (lol). So I guess I'll be seeing how to lock this down! Thanks for the help y'all.

Was going to say that earlier but didn't want to be wrong. I think it's getting that from these lines since it is very top level:

ldap-base-dn DC=D1,DC=ORG
ldap-scope subtree

lsud00d

Well, true and false. The base-dn is where it starts its search, and subtree allows it to walk down all OU's (vs. one-level). I'm working on redesigning the AD tree to be more inline with best practices. If the ASA was configured as I was told it should be specific group membership to connect to the VPN. Then there are the ACL's that do network restrictions, but...I'm looking at locking this all down as well.