How to configure ASA for AnyConnect RA VPN using SAML authentication with DUO and LDAP authorization

I sometimes get the request to help a customer integrate duo with sam'l authentication for any connect with an advanced configuration on the aasa' for any connect such as dap or dynamic access policies or using things like LDAP mappings for specific group policies etc DEP in particular comes up quite often as these DAP or dynamic access policies as they're called are a way for the a SA to us to apply a special set of controls to an inbound VPN connection based upon things like endpoint attributes or or perhaps what ad groups or radius groups a user might be in so this configuration is not super straightforward from the dual documentation we don't include that so I thought it'd make a short video to explain how that's configured what I won't cover in this video is the basic configuration of configuring the a SA with single sign-on using dual for sam'l you can follow the guide on duo comm I'll make thee or all nice and big here but it's dual comm slash Doc's slash Cisco KSA - SSO and if you go to this URL we detail in excellent verbosity here all of the configuration steps to configure both your a sa for for the standard duo sam'l configuration as well as how to deploy something called the dual access gateway this handles the authentication the sam'l authentication and acts as the identity provider IDP for the authentication and that configuration is is very well spelled out in here so if you follow all the steps including downloading certificate installing then you're a sa et cetera you'll have a functional configuration basic configuration where you're any connect users can connect to the a sa via sam'l authentication what I want to focus on here is how to enhance that configuration to provide for secondary authorization and what that authorization will perform is a lookup into Active Directory for group membership and then apply some special settings to the connection so here at my a si I have my my connection profile or sometimes called a tunnel group and I've named it AC for any connect split profile underscore sam'l and if I go under my group URL you can see I have a special URL configured which is my ASA's hostname slash sam'l I do this so it's easy for me to connect directly to this to this URL which will connect me to this connection profile or tunnel group for testing now the go back to our basic screen here you'll see our authentication method is set for sam'l by the way Triple A servers always set for local it's not really local in this case but there's a sam'l it's using the sam'l configuration which is the identity provider here that's covered in the dual documentation but the trick to getting this to work is to create a authorization so the aasa' supports a secondary authorization not to be confused with a secondary authentication which would be validating the password in the case of authorization the aasa' after it authenticates the user via sam'l will perform an authorization lookup against whatever Triple A server group we configure in this case I've configured a triple a server group with the name of my Active Directory domain and that is an elder group of type LDAP with two entries in it which is my two domain controllers and I can show you what those look like so pretty standard stuff in here in terms of my login DN etc the one thing that's different though is my naming attribute if you've ever configured LDAP authentication on an a si the naming attribute we generally use to make LDAP Cori's to Active Directory to lookup or authenticated password is the Sam account name and the same account name in active directories typically the Active Directory user name however for our sam'l authentication we want our users to log in with their email address and that email address is not the same as the same account name but it that email address does exist in the Active Directory record known as user principal name or UPN so we have to tell the aasa' that when it makes the the LDAP authorization look up to Active Directory to pass that email address that's going to get from the sam'l authentication to Active Directory in retrieve that Active Directory LDAP record for the user and in doing so it's not going to validate the password because this is authorized ation so it's just going to send that email address after the salmon authentication is complete to Active Directory Active Directory will the domain controller will respond with the LDAP record and that AL Debra curd includes things like which windows groups the user is in and then we can check for membership in those groups to do things to the connection as you'll see shortly so this is what our Triple A configuration looks like so I have my group that I named after to my domain and I'm choosing math for my authorization and that's that so that standard sam'l authentication connection profile will now perform an authorization against Active Directory now let's take a look at our dynamic access policy rules and I have two created here why don't you just show a little more complicated configuration both these rules are almost identical the first rule which I've called employee sam'l check is going to do two things it's going to verify that the connection profile or talam group that we're connecting to is our sam'l tunnel group because I don't want this dapple to to apply for connections that aren't saml-based and it's going to check if the user is in an LDAP group called employees - BYOD in this LDAP that member of this is what Microsoft named the LDAP group that holds the Windows groups that the users are in and as you can see I've configured this to user has all of the following which means both of these things need to be true so in order for this rule to to be true in the bottom half of the rule to be applied the user has to be in this LDAP group and they have to be connecting to my sam'l connection profile now assuming those things are true what we have on the bottom of the rule will apply now in order to test this I've added a user message I normally wouldn't do this because I don't like user messages when I connect with a VPN client but I created a little user message it says welcome employee and you'll you your access to the employee Network hasn't been provided for your connection and I did this so I know that the rules working when I connect now the second thing I did of course is to actually apply a ACL access control list that adds the subnet that I want the user to be able to have remote access to what after their VPN is up so not to be configured with the split tunnel group that that's the kind of subnet that will be routed to any connect but once that connection is up this ACL will act as kind of a stateful firewall rule for what the user can do inside the confines of that split tunnel group so if this rule is true this ACL will be applied to the connection and I created a second one that checks if the users in the domain admins group does something similar adds access to a second management subnet now these DAP roles are applied in order and they have a priority order and the reason for the priority order is because you can have a deny and one of these rules but if you don't they'll stack on top of each other so in the case of a connection that matches both of these rules the both ACLs will be added to that users connection and they'll have end up having access to both of these things so that's it we have our our sam'l connection profile that is not only performing sam'l authentication but LDAP author to Active Directory and then we have our dynamic access policies or DAP rules that are checking for ad membership and the reason why they're able to do that is because the aasa' will retrieve that user's LDAP record after authentication let's have a look at the climb experience running Windows 10 with any Kinect installed I'm going to connect to my VPN URL and I've created a special one that is using the sam'l authentication when I connect to this URL any connect is going to invoke a browser window for me to authenticate now I have my dual health policy configured for this VPN connection to perform a check on the operating system and let me know if there's any out-of-date browser or operating system configuration here and I could enforce that check but in this case I'm merely going to advise the user that their software is out of date and I'm not going to require it be upgraded so I'll disregard that notice send my push notification to my mobile phone that I'll acknowledge now and it's gonna warn me again on its edges some update here my browser but I'll go ahead and skip that you'll see I'm successfully authenticated and now any connect automatically bringing it back up is connected and you'll see I have a pop-up message that I configured normally this wouldn't show up unless you want it to and what this is indicating is that some additional policies have been set for this connection namely two policies one that has identified me as an employee and it's provided me access to the employee network and a similar second policy that's identified me as an admin as an administrator providing me access to the administrator administrative management network and I did this to highlight the capabilities on the aasa' where even with sam'l authentication we can perform a Active Directory group look up and assign various privileges or permissions to the connection based upon those group memberships there we had it I thought might be interesting to show off what the logging looks like the real-time logging on a SDM and this is the syslog coming from the a s a when a one of these remote access users with any connect and sam'l authentication connects to the a sa so what we have the the the first record we see is a a actually the the triple a sam'l authentication because remember when the user connects with any connect they're going to get redirected to that dual access gateway for the sam'l authentication user name/password and push notification generally with duo and then redirected back to the a SA and that a sa is going to validate that sam'l assertion and know that we have a fun ticketed session and here we can see authentication successful for that user now we get information about the user of course such as what their their username is in this case the user principal name an email address they typed in for authentication and then we process our dynamic access policy rules so these DAP rules that I have def debugging turned on to see this we see all the information that DAP evaluated for the rules and DAP was configured in this case to do an LDAP lookup so it's going to pull for example all the groups I belong to such as my domain admins group and if I look down on the bottom I can I can see the the details about this log entry and then scrolling up I can see the other LDAP attributes that were brought to bear which connection profile or tunnel group I connected to and what operating system and then finally I can see which DAP rules were matched and we can see that there were two rules matched here both the employee sam'l check rule and the domain domain admins sam'l check rule so for troubleshooting and making sure that your policies is applied correctly this this logging is super helpful so of course we see all of the the connection finally established and in other settings that have been brought to bear and I'll go ahead and disconnect that user now from the client and you can see we get our session termination messages here as well

Channel: Cisco Network Security

Views: 4,160

Keywords: Cisco, Umbrella, AnyConnect, Umbrella Roaming, VPN, ASA, Security, DUO, SAML, DAP

Id: Ku0mvU9XS94

Length: 13min 44sec (824 seconds)

Published: Wed Apr 01 2020