PCNSE Prep - Authentication Policy with Multi-Factor Authentication

[Music] greetings I'm Mitch Tinsley with the Palo Alto Networks education delivery department here to talk to you about how to configure an authentication policy utilizing multi-factor authentication in this video we're going to talk about why we would use MFA or multi-factor authentication the authentication policy and its purpose or use cases for it the different multi-factor authentication vendors natively supported by a Palo Alto Networks firewall and then how to integrate non natively supported MFA vendors into the Palo Alto Networks firewall then we'll talk about the challenge factors supported how to build a server profile authentication profile how to configure the captive portal settings zone and interface relevant settings the authentication policy and its actions and then the differences between the security policy and the authentication policy first let's talk about why we need multi-factor authentication as Internet users were constantly required to create accounts on various websites and you'll notice that most users struggle to create strong and unique passwords for every website they would ever go to and as a result we often find users reusing some form of a username and password combination or at least a base password where then they vary different prefixes or suffixes upon that base password the problem with this behavior is if a cyber criminal is able to compromise any single service let's say a less protected gaming website such that they now have harvested the username and password of that user they could easily look at the password and decipher the pattern that this user is using and then make slight tweaks to that password for example changing the password from for secret for to to secret to and then that cyber criminal can attempt to use that credential to log into different web sites that they know that that user uses for example the healthcare website password didn't match but what about the utility website it does the benefit of MFA is that the utility website vendor could then send a multi-factor authentication challenge push to the actual user who has the mobile device or the token associated with that user account this is something that's expected the cyber criminal would not have such that then that user could deny that access preventing the cyber criminal from entering that account on that website this is a very effective method at mitigating stolen credentials and even discouraging account and password sharing between multiple admins to a common system another use of the authentication policy with an Apollo Alto Networks firewall is it's a very reliable user to IP mapping source so for a quick recap on user ID sources generally you want to tell the firewall how to talk to an Active Directory server so that it can grab user name to group associations but then from there you need to map out all of the different IP to user ID sources for example you could use global protect along with this is captive portal these the two most reliable user to IP mapping sources another very effective method is utilizing the XML API where then you can create a script and pass mappings directly into the firewall using the XML API one unique thing about the XML API method is it's the only way to create individual user to IP mappings that do not have a timeout also we have the syslog listener which will parse syslog output looking for user to IP mappings where you have multiple users sharing a common system like a terminal server then we have a terminal services agent that can then map port ranges for each individual user account and then tell the port range association to the firewall such that when traffic arrives at the firewall from a given source IP and they given source port from a range it'll know which user is associated with that traffic along the same lines as the Terminal Services agent when you have multiple users not sharing a common system but sharing a common IP for example their traffic has gone through a proxy server we can still tell which packet comes from which user if that proxy server can inject that user data in as an x-forwarded-for header you can also parse the security logs of Active Directory exchange or other directory sources looking for user - IP mappings this method is very popular in that it grabs many user - IP mappings in a single act however it does have some timings and some delays that can create inaccurate user typing mappings that's why it's so far down in the list and finally the least recommended method is client probing this utilizes a WMI probe from the firewall back to only Windows clients the drawback to client probing if you enable user ID on an outside zone and you have enabled client probing it is possible that internal domain information could leak to outside networks using one of these WMI or NetBIOS probes so it's not the most recommended method once you have user type II mappings they may benefit you within the firewall in several ways two of which are user names appear within the logs you can also run predefined reports based on users or create custom reports based on users and groups the second benefit then is for policy enforcement where you can reference known user unknown user individual user names or groups of users within various policies as match criteria of all these methods global protect and captive portal are the most accurate the difference between global protect and captive portal I like into proactive versus reactive because if you have global protect installed on a PC as soon as the global protect agent connects to its gateway it provides user name to IP mapping data before the user might even launch a session out to some external resource when it comes to captive portal I call it the safety net because if every other user - IP mapping source fails for some reason captive portal is a reactive approach that can then throw up a login page where the user must satisfy that login challenge thus telling the firewall the username associated with the source IP another use case for the authentication policy is a feature we call authentication step up let's say that there's a resource within the dmz that a user over here on the Left wants to browse to however that resource does not have a secure login prompt thus we're just using HTTP in order to access that site if the login were to transit any less secure networks on its way it would be easy for an attacker or a malicious insider to steal those credentials because they are plain text and so what the firewall can do when the user attempts to browse to that resource it can say hold on a second I'm gonna redirect your browser to this HTTPS site now one important thing you'll notice that IP address in a moment is going to be assigned to a firewall interface such that when that browser is redirected to that address the user is presented with a login prompt coming from the firewall itself now this is going to be the first factor in the authentication for this user so when the user satisfies the username and password then the firewall will communicate with a multi-factor authentication vendor and then that vendor service will push a second factor prompt out to that user that could be a mobile device push or it could require a one time pin to be entered sent via SMS or it might even call the user and we'll look at some of these different factors in a moment but once the user satisfies that challenge then they're taken or redirected back to the original site they'd requested and if there is a login then they would see that login but if there's not they're given access directly to that site but they at least first authenticated using a secure mechanism and the firewall learned the username and IP address from this user let's talk about the different multi-factor authentication vendors natively supported within the Palo Alto Networks firewall there's duo and specifically version 2 ping ID octa as well as RSA SecurID access now some multi-factor services are not natively supported by the next-generation firewall but they could still be utilized using radius communication as an intermediary to a proxy or gateway server which then would interact with the cloud service on behalf of the firewall thus sending pushes for the user to satisfy and then once that challenge has been satisfied the proxy server or gateway server would notify the firewall that this user has authenticated one example of this would be something like semantics VIP Lin OTP or there are many others so looking at the different factors supported by a Palo Alto Networks firewall you've got a voice call SMS ad mobile device push or a rotating token code or pin code that the user would have either on a device or a fob or something like that in order to set up multi-factor authentication in an authentication policy you must first add a multi-factor authentication server profile I've done one already which we use in this example but just to show you the settings you come in give it a profile name then you need to reference a certificate profile the certificate profile is really just a container for the SSL certificates on the MFA vendors website to add the certificates you acquire them from the MFA vendor they might be provided as part of a service profile or you can download them from their website and then simply import them into the firewall by doing the import option give it a name specify the file click OK and then there are going to be bundled up into this common certificate profile which I'll reference here in the case of duo certificates then you choose from the drop-down which MFA vendor you wish to configure natively on the firewall there's duo v2 octa adaptive ping ID and RSA SecurID access depending on which one you choose you'll notice that the settings although very similar are slightly different depending on which MFA vendor you're trying to configure for after you've created your MFA server profile then you're going to reference it in an authentication profile so up here under authentication profiles I've added several but just to show you the process come in give it a name reference the type of server profile that has the first factor user accounts now when I say first factor a username and password is generally considered single factor or first factor when you're implementing multiple factors so in this case our first factor is going to be username and password defined in our local database then we come over and define which users from that authentication source are allowed to authenticate you could choose all you could pick a specific user group and then you come over to factors and you enable additional factors and this is where you reference that MFA server profile you'd created like so since I've already done this I'll use the local users DB for the rest of this example next you need to configure the captive portal settings for the user to authenticate to this is done under user identification captive portal click the gear check the box to enable captive portal then you're going to reference an SSL TLS service profile this will contain the SSL certificate that will secure the connection when the user's browser is redirected to the firewall interface to authenticate then you reference the first factor okay this is the local users database or you could use Active Directory or you could use tac-x plus or sam'l okay there's a variety of first factor sources you can reference I'm just referencing the local users database then under mode this is very important transparent you would choose if your traffic is transiting through a V wire or layer 2 interface however for multi-factor authentication you must choose redirect it does not work with transparent now redirect must reference an address assigned to a firewall interface so this happens to be my insight interface to layer 3 Ethernet interface but it could also be a loopback interface or any other layer 3 interface on the firewall so if you're all V wire implementation or an all layer-two implementation you cannot use multi-factor authentication with the authentication policy you must have at least one layer 3 interface for the MFA redirect after you've configured your captive portal settings we're going to enable user ID on our ingress zone I would apply this on my inside zone if I want to use the authentication policy to harvest user - IP address mappings for traffic coming from this zone going to any other zone I could use it on my outside zone if I want to enable some kind of authentication step up for users outside of my environment trying to access a resource inside of my environment let's say within my DMZ one caution with enabling user ID at an outside facing zone if you have enabled client probing it could reveal domain information about your organization - untrusted Network so only turn this on if you are not using client probing then we must go to the interface that we are redirecting our users to so again I said this is my one and two 168 one one happens to be on my Ethernet 1 / 2 interface and a requirement for this to work is you must have added a management profile with response pages enabled you can create a management profiles by hitting the down arrow and clicking new management profile and checking the box for response pages this is the minimum setting required in order to support MFA I've already done that and you can see I'm referencing it here next we're going to go to the objects tab and we're going to create an authentication enforcement object to do so simply hit add give it a name then reference the authentication enforcement method this could be no captive portal now again this will be referenced by the authentication policy and all traffic is compared to policies in a top-down fashion so typically you would want to use browser challenge or web form browser challenge is an ntlm challenge which if the browser does not support the single sign-on ntlm challenge it will fail back to web form so if I create an authentic and policy that requires all inside users to authenticate but then I want to have a singular exception that I could create another rule above that generic one and it's action could be no captive portal this is how you create exceptions within the authentication policy but for this example we're going to turn on webform and then we're gonna reference our authentication profile okay this is going to be our local users DB for our first factor click OK and then over here on policies authentication you hit add I've already done one and this is where you define your match criteria where the traffic is coming from which users might be associated now if I'm going to use this to grab user name to IP mappings then I probably want to reference the user of unknown this means there is no mapping for a given source IP of traffic if I set it to any then even if there is a mapping then the authentication challenge will be presented to the user and this might be most appropriate for the authentication step up use case then we come over to destination where the traffic's going to then we reference our service now service again is Palo Alto Networks terminology for port TCP or UDP port since the MFA challenge is a web page then this is going to be most applicable to service HTTP which is port 80 or service HTTP which is port 443 if I set this to any then this would prevent users who match this source and destination criteria from gaining any kind of network access through the firewall until they have satisfied this authentication enforcement the challenge if you want to allow your user pcs to access things like SSH and Remote Desktop but only give them a challenge when they're going to a given destination in this case my netbox server then I would only reference the TCP port in question for which a challenge should be presented to the user after you've defined all of this match criteria we come over to our authentication enforcement object this could be duo MFA auth which I created earlier or just duo which I created moments ago and again the authentication profile marries up first factor with the second mfa factors and then this is where we specify which of those enforcement services should apply to users matching this rule obviously I can create multiple MFA vendors have multiple authentication profiles and then multiple authentication policy rules each referencing different authentication profiles and different MFA vendors depending on the situation the authentication policy does two things a it creates user to IP mappings for user ID within the firewall and B it could be used for authentication step up where the firewall can proxy multiple factors of authentication for a single factor system downstream a couple drawbacks to the authentication policy is it doesn't have the full scope of match criteria like the security policy has here you can see source and destination zone and address user data Hiep data and then really just service before the authentication enforcement action kicks in conversely the security policy is the primary place for traffic enforcement it has the full scope of match criteria and it also has security profiles which do Content ID inspection for traffic that you've decided you want to allow in the security policy I hope you found this video helpful in preparing you for the PC NSC exam thank you for watching

Channel: Palo Alto Networks LIVEcommunity

Views: 10,181

Keywords: PCNSE, MFA, Mulit factor authentication

Id: GjyMotd5YuE

Length: 19min 20sec (1160 seconds)

Published: Tue Jul 31 2018