About jbworley

Another post regarding an additional method for gaining userID info for non-domain joined assets.   There are lots of examples of using other idPs, but not much I could find regarding ADFS, so hope this is helpful for others looking for a similar option.     To begin, create an Auth policy and list the matching criteria.  In my config, I used, - src zone “Inside” - dst zone “Outside” - any src/dst IP - unknown users - service-http and https (TCP - 80, 8080, 443) - URL Cateogory “slack” containing “slack.com/” and “*.slack.com/” - Authentication Enforcement to “default-web-form” - Timeout (min) to “1” since the captive portal settings override this setting anyway   So, in short, my policy only gets triggered when connections without userID attempt to connect to “slack.com” or “*.slack.com”           Next, you need to download the metadata file from ADFS… https://#SERVER-FQDN#/federationmetadata/2007-06/federationmetadata.xml .  You can find this link listed in ADFS Management under “Endpoints / Metadata”.           On the Palo, click “SAML Identity Provider under “Devices” and give the server profile a name, then Browse to and select the ADFS metadata file you downloaded.   NOTE: I renamed my file from “federationmetadata (1).xml” to “newFederationMetadata.xml” so the Palo would take it: doesn't like "()" in the name.   Select checkbox to validate the idP certificate, and set the clock skew if needed…my systems are off, so I selected the max to be safe (max: 900s, default: 60s), then click “OK”.         Open up the newly created server profile and update the http binding from “Redirect” to “Post”, then click “OK”.  In my case, I did not choose to sign SAML requests from the Palo, so I unchecked “Sign SAML Message to IDP”.   NOTE: If you use a self-signed cert from AFDS, you cannot perform the trust verification (Validate Identity Provider Certificate) using a certificate profile.         Generate a certificate profile to verify the idP cert against a trusted root cert.  Choose any other options if you wish to provide further verification.         Create an Authentication Profile, type “SAML”, select the idP (SAML) server profile you created previously, choose a certificate that the Palo can use to sign requests (in this case, I’m not using a cert to sign requests to the idP, but it must be provided), select the cert profile to verify the idP cert trust, and leave the “Username Attribute” set to the default value “username” (it will not be used).         Select the “Advanced” tab and update the allow list.  Once finished, click “OK”.         Configure the captive portal to use the new Authentication Profile and make sure an SSL/TLS Service Profile is configured with a valid web cert for the redirect (in this case https://cp.praktikl.com).  I set the “Idle Timer” to 5 mins and the “Timer” value to 480 (8 hours), but you can decide which timer values work for your situation.  Make sure redirect is being used, and uncheck the session cookie “Enable” and “Roaming” (in testing, this absolutely did allow a computer to roam (change IPs and still get through), however, userID did not log for the new IP, so that is something to consider).  Lastly, set the redirect host FQDN pointing the configured firewall interface to handle the SAML auth traffic (please see my post on Kerberos SSO: you can use the interface configuration and DNS section from that post to see how to configure a firewall interface for captive portal redirection).   NOTE:  In testing, having the idle timer set to 300s is plenty enough to ensure the user mapping/authentication persists during general device usage.  Any traffic that passes through the firewall matching the same source/destination zones and sourced from an IP with an established user/authentication cache will reset the idle timer (does not not have to match the Authentication Policy criteria).  So, in environments where there is a quick release/assignment IP allocation method, such as VPNs with local IP pools, you can end up with users being pre-authenticated and logged as a different user (prior true user).  To circumvent this, most VPN local pool assignments have a method for delaying reissue of an IP that has been released.  In my case, if I delay reassignment for beyond 5 mins, the user and policy cache will timeout before any other users grab that IP.  For the general enterprise using DHCP, this is not an issue (extended period leases).  If a device moves from wired to wireless, w/in 5 mins, the policy and user cache will timeout.         Next, select the “Metadata” link (see below at top of example: blue hyperlinked "Metadata" under "SAML") on the Authentication Profile in the authentication profile window, then select “Service: captive-portal” for the top dropdown box.  The “Authentication Profile” field will be prepopulated.  Next, click the dropdown for “IP or Hostname”, which should have an available value based on the captive portal settings (in my case, "cp.praktikl.com:6082").  Click “OK” to download the .xml file.  Transfer this file to the ADFS server to create the relying party trust.         In ADFS Management, select “Relying Party Trusts” and select “Add Relying Party Trust” to begin configuring.  On the welcome page, select “Claims Aware”, and then click “Start”.         Select “Import data about the relying party from a file” and browse to/select the metadata file from the Palo, then click “Next”.         Enter a “Display name” and click “Next”.         Choose an access control policy and click “Next”.         Click “Next” again, then check the box for “Configure claims issuance policy for this application" and click “Close”.         At this point, the claims issuance policy dialog box will open.  Click “Add Rule”, then select “Send LDAP Attributes as Claims” and click “Next”.         Give the rule a name, select “SAM-Account-Name” under “LDAP Attribute…” and select “Name” for the outgoing claim type, then click “Finish”.   NOTE: SAM-Account-Name contains multiple values (#USERNAME#, and #DOMAIN#\#USERNAME#).  Claim type “Name” stores both values so you can use a transform rule to grab the #DOMAIN#\#USERNAME# format to send as an attribute to the Palo for proper user group mapping.         Click “Add Rule” again, then select “Send Claims Using a Custom Rule” and click “Next”.         Give the rule a name and enter the rule data.  In short, this rule takes the “Name” claim values acquired from the SAM-Account-Name, performs a regex operation (Value=~) to match on the attribute value beginning with (^) “PRAKTIKL” (the domain), and assigns this value to attribute “NameID”, which is automatically picked up by the Palo as it is contained within the <Subject> field in the SAML response.  Click “OK”, then click “Apply” and “OK” again.         Next, ADFS is set to encrypt claims for relying parties by default.  This must be disabled.  Open PS (run as admin) and type in the following command to disable claim encryption for the relying party trust (-Targetname is the same as the “Display name” value used when configuring the relying party: in my case, “PALO”). "Set-AdfsRelyingPartyTrust -Targetname "PALO" -EncryptClaims $false"       Also, make sure that “keep me signed in” “KmsiEnabled” is set to True.  This will allow users to authenticate with ADFS for a predetermined period without having to enter credentials again by using SSO cookies.  The default lifetime is 1440 mins, but it can be scaled back or extended if desired.       At this point, you should be able to perform a test.  Since I’m using Slack as the URL matching criteria for my authentication policy, I browse to https://www.slack.com.  In the screenshot below, you can see my ADFS splash page and that I’m selecting a certificate for authentication.   NOTE: I’m using the SAML Devtools Extension for Chrome.  This is extremely helpful in verifying the attributes sent.         I connect successfully.  In the SAML data, you can see attribute name “NameID” is set to “PRAKTIKL\user2”.     Checking the Authentication logs in the Palo, you see that the Palo received the SAML assertion, that it verified the idP cert from ADFS, and that the authentication was successful and userID “praktikl\user2” was acquired.         Via the CLI, you can see the IP-user-mapping from “SSO”.       Tested using a mobile device with a user certificate loaded (Android).         With KmsiEnabled set to True, other connections matching the authentication policy, where the policy and user cache are gone in the Palo, causes the same redirection to ADFS, and because the client has a valid SSO cookie, it uses it to authenticate with ADFS and trigger the SAML response back to the Palo (SP) without user interaction (below, the ADFS redirect happens fast, but you can see the captive portal "User Authenticated" acknowledgement page showing that this device has reauthenticated with the captive portal).       The end.   ... View more

Been working through options for gathering userID data on non-domain-joined machines lately, so here's another complete option using Kerberos (krb) SSO.   Create a user in AD (my example, username: krb.palo), check the boxes for: User cannot change password Password never expires This account supports Kerberos AES 256 bit encryption NOTE: this account is only a member of “Domain Users”, no special privileges   NOTE: this screen capture was taken after running the console commands, so the "User logon name" already shows the SPN     Issue the “setspn” and “ktpass” commands/parameters in the AD server to generate a krb keytab file.   Examples:                                     (your CP URL)     (AD user) setspn -s HTTP/cp.praktikl.com krb.palo                                                (your CP URL)      (AD domain)                                 (AD user)                                     (AD user pwd) ktpass /princ HTTP/cp.praktikl.com@PRAKTIKL.COM /mapuser PRAKTIKL\krb.palo /pass !QAZ2wsx /out (*TRUNCATED*)   (Location to save keytab file) c:\users\domain.admin\desktop\portal.keytab /ptype KRB5_NT_PRINCIPAL /crypto AES256-SHA1   You can see the file created on the desktop above the console window.     On the Palo, add a krb server profile listing all the DCs you want to include.     On the Palo, create a new authentication profile of kerberos type with the realm and domain (use the netbios name for "User Domain" to ensure proper recording by the FW, if you include “.com, .gov, etc”, format will be “domain.com\user”).  Username Modifier didn't seem to make a difference, but still used the "down-level" logon format.  In the Single Sign On section, import the keytab file generated on the AD server.     On the Advanced tab, add the user group that has allow access (for this example, used “domain users”).     Next, under “Device/User Identification”, configure the Captive Portal.  Check the enable box, tweak the timer values if needed, add the kerberos auth profile, and set up a redirect to a URL (in this case, cp.praktikl.com).  You’ll need a DNS record for this and an L3 interface on the firewall for it to connect (will configure that in a next).  Also, add in an SSL/TLS Service Profile with a cert containing SAN entries for the URL (using cert w/ *.praktikl.com).     Configure an interface management profile if needed and allow “ping” and “response pages”.     Set up an L3 interface to terminate the redirect (keep it in the same zone as the internal zone for boundary traffic and add the Interface management profile previously created).  Create a separate virtual router with a static quad-zero route and add the new interface to it.       Create a DNS A record.     Lastly, create the Authentication Policy.  Set the zones according to the traffic, set the user to “any”, set the ports to whatever you need (http/https), add the URL category for the traffic you want to authenticate, and then choose the “default-browser-challenge” option to prompt the user for creds. NOTE: Destination URL needs to be decrypted       For testing, verify there is no user cache for the test user/IP you plan to use.  In this case, I’m coming from 192.168.3.7.  Since I do not have an IP-user-mapping, it is “unknown”.     When I try to browse to https://www.slack.com, I get redirected to “cp.praktikl.com:6080” and the login prompt comes up.     Once I log in, my mapping is created and I’m good to go.  You see the mapping is from “SSO”.       The default userID timeout is 60 mins, and the default auth policy cache timeout is 60 mins as well.   An interesting byproduct of this method: you're authenticating against your kerberos realm, so in the case of active directory, you are literally authenticating via the domain, and if using agents pointed to active directory, the agent will populate a IP-user-mapping too.   Also, if you're using username/password for login, use the down-level logon format "DOMAIN\USER" versus user principal name "user@domain.com".  This will ensure your IP-user-mapping entries stay consistent and are able to line up with groups acquired via ldap. ... View more

I ran through the process of creating a solution to get userID consistently for MacOS machines via the syslog feature in the User Agent.  The goal was to authenticate to a domain webserver using cert-based auth, and to have the web server provide the IP and user information via syslog to the user agent.      I set up a general webserver site “exch” (AD-joined server, requiring SSL, enabled “Active Directory Client Certificate Authentication and disabled other authentication methods)         Tested cert auth from client machine using “PRAKTIKL\user2”         Checking the event security logs, you see the user logon event (4624), but the IP is not recorded.  I found that when the provider is “schannel” (this seems to always be the case with cert-based auth to webservers in an AD domain), the IP is never logged.    Best info I could find on this is: “This is because the service handles authentication on behalf of the client”.  If I use username/password, I get the IP, although via a different service.  Unfortunately, this affects OWA too, where logging in via the app uses logon process “kerberos” and provides the IP, but logging in via OWA with cert-based authentication uses “schannel” and does not provide the IP.  This is also reflected in the user agent where app login logs userID, and OWA login does not.       IP and user information is stored in the IIS logs.  You just need to verify logging is enabled for the site.  I chose the IIS format: csv.       If you browse to the log file location you can verify the logs contain the right information by opening the latest log and searching for a user, in my case “user2”.  Looking at the example, the source IP is logged first, followed by the user in down-level logon format.       To parse these log files and get any sort of useful format, I found that LogParser 2.2 from Microsoft https://www.microsoft.com/en-us/download/details.aspx?id=24659 was the best SIMPLE/FREE option.  Also, if you make sure that “IIS 6 Metabase Compatibility” is installed, this will simplify using LogParser where you can reference the IIS logs for a site using only <SITENAME>.       LogParser opens in command prompt, and you can query the IIS logs to test extracting the IP and username, in my case “user2”.  Selecting on “UserIP” and “UserName” provides only the output needed (IP and username).  NOTE: If you run command (logparser “SELECT * FROM <SITENAME>”), it will show the heading and all fields you can use to select on.       You can test sending this output to the user agent using the output switch for syslog and “INTO” redirection to @IP:port.  “-o syslog” and “INTO @192.168.2.5:514”       Log messages received on user agent machine       Then you can configure the user agent to accept logs from web server and configure regex to match on log information to extract the IP and user.   The string to match on is “EXCH LogParser:192.168.2.5 PRAKTIKL\user2” per the pcap above.   For the user agent syslog regex configuration, you can have a specific match, or you can lead with some data and surround the relevant portions in “()”.  For example, there are three fields:   Event Regex: “EXCH LogParser” – nothing special here   Username Regex: Beginning Delimiter                                                      User Matching Data [0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3} (PRAKTIKL\\[a-zA-Z0-9]*\.?[a-zA-Z0-9]*) needed to match on a delimiter to trigger the start of the username.  In this case, I matched on the preceding IP and space before matching on the username.  “+” is not available for use in the Palo user agent, somewhat limited w/other options too.   Address Regex: Delimiter    IP Matching Data LogParser: ([0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3})           If you log into the webserver again from the client: in my case “user2”, and run the LogParser command again, you’ll have the user ID info logged in the user agent.   LogParser ran again after site logon       Syslog received on user agent       User ID logged in agent       The full LogParser string is: Logparser.exe -i:IIS “SELECT UserIP, UserName INTO @192.168.2.5:514 FROM <exch>” -o syslog -icheckpoint:C:\userid\mycheckpoint.lpc Logparser.exe (moved to system32 folder, no need for path) -i:IIS (just tells LogParser that format of logs is IIS) SELECT UserIP, UserName INTO @192.168.2.5:514 FROM <exch> (SQL query) -o syslog (output to syslog format/syslog server) -icheckpoint:C\userid\mycheckpoing.lpc (used by LogParser to follow logs, only trigger on and send new logs   Adding the -icheckpoint switch allows LogParser to track the parsing location in the log file using a special file ".lpc" (in my case, C\userid\mycheckpoing.lpc), so it will not resend entries that were previously received and sent. For example, if I clear the user agent cache and wireshark, and I run the command again, nothing will be sent.       If I authenticate to the site again and run the LogParser command, there will be a new entry.       Once the command and user agent are ironed out, you can automate using “schtasks.exe” (Task Scheduler) and a batch file.  See below: I just added the same command to a txt file and saved as a .bat       Then, I ran “schtasks.exe /create /tn userIDsyslog /sc minute /tr C:\userid\userid.bat” to get the task going.       I also found that it will be set to “Run only when user is logged on” under “Security options”, and it will fail initially.  I changed it to “Run whether user is logged on or not” and “Do not store password. The task will only have access to local computer resources.”.  Once I did that, it started working.   New logs received by user agent       At this point, you can just set up this logging option on frequently used web servers and/or set up a special-purpose web server, use Desktop shortcuts on Mac clients, and tell users if they’re not able to get to stuff, to open the link, authenticate, and they’ll be good to go in 1-3 mins.   If you want to automate it so that machines are always authenticating without user interaction, that is possible too. If you take a user cert, break it up into cert and key, and call it in a curl action, you can add this to a cron job and have it checking in continuously.   Below, I took the user cert for “PRAKTIKL\domain.admin” and broke it up using openssl       Next, I made a .bash file identifying the location of the CA cert, the private key, and the cert, with a curl to https://exch.praktikl.com       Then, I used Crontab to run this file every minute. (NOTE: IP 192.168.3.16)       Checking back on the user agent, I verified that “PRAKTIKL\domain.admin” was logged to IP 192.168.3.16.     That’s it, hope it helps.   ... View more