Multiple Authentication Policies

[Steven Williams]

Ok I have been struggling here so I need help. I am not sure if its a limitation of ISE or DUO security Proxy servers.

I have an anyconnect VPN termination point on a pair of ASA's. This is integrated with DUO security.

So a user is prompted for username and password and once that is successful then they get a DUO push on their mobile device to accept and they are on the VPN and can work as normal.  Simple right? 

Now for the twist.

I have 2 AD forests with a cross forest 2 way trust. So my ISE server can search both AD Domains, This is working due to both domains having admins that authenticate via TACACS for devices. 

Now I'm working with RADIUS. So the challenge is radius requests from a DUO proxy have to be on different ports for each domain. Ok easy, one domain will use 1812 and the other will use 1645. So I add the ISE server twice in "RADIUS Token" one instance using port 1812 and one using 1645. Same IP address but different ports. 

So Now I need to add policy sets:

I started with two and created one that ties to one radius server on port 1812 and is told to look for external identity source for DomainA. The other Policy set says use the other Radius token on port 1645 and look for external identity source for DomainB. 

The issue is when the user enters their username in anyconnect VPN they just use username, not domain\username or username@domain. So ISE takes in that info and compares it the first policy and if that username is not in DomainA it just fails and never goes down to the next policy set. 

SO I want to add two radius server tokens to the "auth policy" in the policy but cant seem to do that without a condition. 

I just want the authentication policy to use both Duo Proxy servers and both ports so if one fails it will try the other one. Is that even possible. 

[Arne Bier]

Have you tried putting the external identity sources into an Identity SOurce Sequence, and then referencing that in your Authentication Policy?  The search order will be strictly top to bottom, but at least you have the option of looking in the second one if the first once doesn't respond, or doesn't yield a positive result.

[Steven Williams]

I will so no because I don't know what that means. Any resources or blogs to assist?

[Steven Williams]

Identity source sequence for the forest/domains or the Radius token servers?

[paul]

I have a feeling the identity source sequence won't work because the Duo servers will always respond with a pass/fail.  So if you send username to Duo on 1812 going to the first domain, but the username is not in the first domain Duo is going to respond with a fail and ISE will not move to the second one in the sequence.

[paul]

Also this is not really an ISE issue it really is a Duo/multiple domain issue.  Let's say you weren't an ISE customer and were adding Duo 2FA to your ASA VPN authentication path.  The ASA is only going to send to one RADIUS IP/port for authentication.  How would Duo want you to design it in this case?  Most likely they are going to say the user needs to fully qualify their username.

[Steven Williams]

So DUO has told me within my Proxy config I can configure two ldap search queries essentially authenticating against the same RADIUS server (ISE) but on different ports. So I did this. Then setup two radius tokens with the same IP address, but different ports. 1812 and 18120. The when I tell the authentication policy to continue if the first attempt fails then it goes to the next policy. So I can get both usernames in each forest to authenticate but only one will get DUO push. 

[paul]

One final thought.  I would honestly just look to setup two Group URLs, one for each domain, then ISE can pick that apart and send it to the correct Duo RADIUS IP/port.  So:

vpn.mycompany.com/domain-a

vpn.mycompany.com/domain-b

Each of these would be different connection profiles on the ASA. The connection profile name is passed to ISE as the VPN 3000:Tunnel Group Name (attribute 146).  So you could have two policy sets based on the tunnel group name.  Then you send the authentication to the correct Duo IP/port.

[Steven Williams]

That was my original design but the powers to be don't want users to have to select their domain for connection profile. :(

[paul]

Yeah I figured that would be the case, but you can push out client profiles (XML) that have friendly names like "Company VPN Domain A" and "Company VPN Domain B".  The user just has to select it the first time and AnyConnect will remember their selection.

It is either they make a one time selection or they have to specify their fully qualified username when they connect.  If you find something else I would like to know how you got it to work.

[Steven Williams]

Why does this tell me the ASA is sending requests to ISE on 1645?

[paul]

That is just the default RADIUS ports the ASAs use.  I always change them to the newer port, 1812/1813.  ISE listens on both sets of ports so it really doesn't matter.

[Steven Williams]

so the user types in their username and the asa\anyconnect calls out to ISE on port 1812 (even though mine says 1645?) then the request hits ISE, and the policy says use DUO proxy (on what port does this happen) then DUO goes out and checks LDAP and makes sure user is in LDAP and they have an account with DUO, then sends pass\fail back to ISE?

[Steven Williams]

Will having two DUO Proxy servers solve the issue? Each one doing search in one domain both pointing to ISE on 1812, or am I in a bind from an ISE standpoint? Give ISE another IP address? I wouldn't think I have to roll out another ISE server?

[paul]

There is no difference between a single Duo IP with two ports or two Duo IPs with same port. You either need to get the users to fully qualify or use a different group URL. It is more of a Duo issue than ISE.



If you were doing the AD authentication with ISE and not sending to Duo, ISE would automatically check both domains and everything would work just fine.