Anyconnect VPN, granular access based on multiple AD group membership

VPN
1

Hi all!

The company I work for has the following setup:

  • ASA VPN
  • ISE
  • several subnets (/26-/30)
  • Azure AD
  • Integration between ASA and Azure AD via NPS server (MFA, AAA)

Each subnet is mapped to an Azure AD group via ISE (see SGT explanation below).

The business would like the anyconnect users to reach these subnets only when the user is member of the corresponding group, in a mix and match fashion. Example:

User 1 belongs to group A and B = can access both subnet A and B
User 2 belongs to group B = can only access B

(explained very similarly here)

SGT setup: In ISE, we map each subnet to its own SGT tag, and each AAD group to its own SGT tag. The ASA ruleset is therefore based on SGTs (src/dst) instead of IP/Subnet objects.

The big limitation in this approach is how the ASA sees the anyconnect user: when the user connects, it belongs to only one AAD group (SGT) at a time. This breaks the mix-and-match-multiple-groups requirement.

I have been searching for a solution to this need, and all I could find is the following:

I am afraid both of the above would not scale, as we are talking of hundreds of subnets/ad groups and consequently SGT tags.

Any idea? I am willing to radically review the approach. My knowledge of ASA and ISE is not so extensive, I am sure I am missing some bits.

Thanks!

Update: thanks all for the suggestions. I’m pushing for a simplification of the requirements. An alternative is to use ad-group based rules. Still, too many, but it’s something.

2

Problem is no solution will scale to hundreds of AD groups

ISE is realistically the best option but in any setup you are going to have hundreds of policies, it’s going to take months to create and be an absolute joke to maintain

I know it’s difficult to say no when the business is telling you to implement, but this will take months to implement and massively increase your workload with requests like “Why can’t I access this application?”, then you need to go down the laggy list of 1000 policies to find the issue.

I would just go for a different VPN policy for each department and say that’s as granular as you can go realistically

Good luck!

3

Connect the ASA to windows NPS via RADIUS. You can make flexible rulesets in NPS, including ones that reference names ACLs, via one of the RADIUS attributes.

Basically when a user authenticates and hits a policy rule in NPS, it will send to the ASA the ACL that should be applied to the user. When you check the ASA you can even review what rules are active which will be named for the user— “john-smith-acl-1234”.

I believe the attribute is “Cisco-AVpair” and follows the format “ip:inacl#150=allow tcp any 1.1.1.1 eq http”.

Note that I do not know how nps works with azure groups. My experience is entirely with native windows security groups.

See:

4

Wonder if using the posture module, used to be called Cisco Secure Desktop, on the ASA would do what you are looking for.

I control ours at work and I can lock down subnets with an ACL applied to each session depending on the LDAP or RADIUS group your account is part of.

5

My limited understanding of this is that when you utilize ad groups’ it replaces the group policy of the profile in the asa.

So if you would apply it by a group, it will either find the first one and stop looking or apply all of them and only the last one matters.

I am no way an expert, but I had to do a group based access for my company and this is what I found.

6

How are your scripting capabilities? Check out ISE ERS. Could feel a little hackish.

7

Is it possible to create a script which will generate a separate ACL for each individual user and then write those hundreds of ACLs to the ASA? You’d have to have the script regenerate the rules every day at midnight or whatever…
I mean it’s not pretty but it should work and meet the requirement.

8

This is easy with ISE but takes separate group policies on the ASA.

Create the group policy on the ASA that is limiting the subnets they can reach.

Write an authorization profile in ISE that pushes that Group policy.

Write your VPN policy in ISE that applies that authorization profile based on users AD group.

As others have stated I would work on narrowing down how many policies need to be managed. You either trust users to access the applications or you don’t, we only enforce this for Vendors in our environment with granting them specific resources (least privilege , zero trust model) while our internal company employees can reach most things. Explain to management that some applications need to have security enforced at the application layer, not the network access layer. See if you can narrow it down to 2 or 3 access levels (everyone, middle zone, high sec zone)

9

Have you looked at the conditional access policies in anyconnect?

10

Just dos DACLs in ISE to control access to devices from the VPN. Put all your Anyconnect users into an SGT for VPN users. Trust that ASA will limit access at the firewall vs the switch network. This can scale to many groups using your Authz policies.

Or you need to create more SGTs for each unique set or users or group more users under less SGTs. Your design almost sounds too segmented. Like when someone first discovers vlans. networks had 50 vlans for 100 devices.

11

I’ve had a similar setup in my previous role. Can’t you just nest group A + B into another AD group?

If I remember correctly, you can create an authZ policy on the ISE as follows for the VPN user:

If the user is part of group A ‘AND’ group ‘B’ assign SGT of 10. Then you can create a rule on the ASA with this SGT. What I see from my experience is this can get complicated very easily.

12

Thank you, i feared so. The business was sold the concept of sgt matrix. Awesome concept, but at that scale it won’t fly. The var was very honest mentioning this, at least.
I guess I’ll go with the roles, it’s much easier.

13

Thanks, we do use nps. I’ll look into the docs you provided!

14

I wish I had the luxury. Asa/ftd shop. They both support user based access, thankfully.

15

Not sure why you got down voted but have an up vote

16

My limited understanding of this is that when you utilize ad groups’ it replaces the group policy of the profile in the asa.

Different cause, same outcome. We use only one group-policy/tunnel-group, and the access rules are based on SGT tags.What you describe below is exactly what happens, but applies to the sgt tag:

So if you would apply it by a group, it will either find the first one and stop looking or apply all of them and only the last one matters.

To clarify, here’s what you see when the user connects:

Username     : cisco                  Index        : 1
Assigned IP  : 10.10.10.10            Public IP    : 192.168.10.68
Protocol     : AnyConnect-Parent SSL-Tunnel DTLS-Tunnel
License      : AnyConnect Essentials
Encryption   : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)RC4  DTLS-Tunnel: (1)AES128
Hashing      : AnyConnect-Parent: (1)none  SSL-Tunnel: (1)SHA1  DTLS-Tunnel: (1)SHA1
Bytes Tx     : 35934                  Bytes Rx     : 79714
Group Policy : GP-SSL                 Tunnel Group : RA
Login Time   : 17:49:15 CET Sun Mar 16 2014
Duration     : 0h:22m:57s
Inactivity   : 0h:00m:00s
VLAN Mapping : N/A                    VLAN         : none
Audt Sess ID : c0a8700a000010005325d60b
Security Grp : 2:Finance		<<< ONLY ONE SGT/AD GROUP

source (ASA Version 9.2 VPN SGT Classification and Enforcement Configuration Example - Cisco)

17

Thanks, we are considering that. It can most likely be done without scripting, probably via ISE+dacl.

18

Thanks. I guess it’s the right balance.
We need way more than a few, and application level security is out of the question: it’s access to the factory floor, so simple devices.

19

This is usually what a zero trust proxy would be for.

20

Not familiar with the concept, I am going to do some research. Thanks.