Nice blog Bushra.  You're a great CAP manager and a pleasure to work with.   -chadd ... View more

I am not sure what your goal is, so there may be a much better way to accomplish what your are trying to accomplish..  That being said, here is a link to the admin guide for 5.0: https://live.paloaltonetworks.com/servlet/JiveServlet/previewBody/4118-102-7-19329/PA-5.0_Administrators_Guide.pdf On pages 235 and 236 the "regex" rules are described.  This is not full blown regex as you are likely used to.  It is a very cut down version. Here are some "regex(s)" that I have come up with as an example.  The rules state that your data pattern "regex" must be at least 7bytes long.  This is constrained to the string you are searching for and not anything between brackets (so no tricking the system with logic (and, or, etc.).  In these examples I am keying on HTML form post data - so, uploading a file via a web form.  As you can see, the "string" here is "form-data": Any IP: .*(form\-data).*((([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))).* RFC 1918 (10/8) IP: .*(form\-data).*(([10])\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))).* RFC 1918 (172.16/12) IP: .*(form\-data).*(([172])\.((1[6-9])|(2[0-9])|(3[0-1]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))).* RFC 1918 (192.168/16) IP: .*(form\-data).*(([192])\.([168])\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))).* NOTE: For looking in email, you might use the string "subject" as a key word.  The "regex" would then look like this: Any IP: .*(subject).*((([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))\.(([0-9])|([0-9][0-9])|([1][0-9][0-9])|([2][0-5][0-5]))).* !!!WARNING!!!: This will slow down your commit times, and if you use all of these at the same time, your commit may fail.  This is because there is a limited memory space for compiling custom signatures.  The more complex the signature, the more memory the compile takes.  I tested these on a PA-200 and the commits failed for the most part.  I was able to get the smaller ones to commit and work, but again, this is not recommended. I hope this helps. -chadd. ... View more

Hello Daniel. You can use client certificates in both situations.  You do not need to push your root CA to the clients though.  What you can do is upload the CA public key to the firewall, and use that in a "Certificate Profile".  Then, you will just issue (sign) cerficates for your clients from the Microsoft server, and push them to your clients via a GPO. You can also have one client (machine) certifcation for all your clients and configure that as the "client certificate" on your portal and then give that same certificate to all your clients (GPO maybe).  Then that certificate will be checked against the one configured on the firewall to make sure they are the same cert. There is a third way as well, which would allow you to upload the public key (CA) to your firewall, and have that pushed out to all your clients, so that it is in their trusted root store.  That way, they don't get the nag message about a bad cert.  This is not needed though. Hope this helps. -chadd. ... View more

This configuration is actually a Palo Alto Networks recommended deployment.  If you are using 802.3ad for link aggregation, you should have no issues.  I would suggest you open a case with support so that the issue can be tracked and hopefully resolved. -chadd. ... View more

Here are a few things you can check at the command line. First check to make sure the group in question is recognized by the firewall: admin@PA-200> show user group list cn=vpn-users,ou=groups,dc=panlab,dc=local Total: 1 admin@PA-200> Next, make sure the user you are trying to authenticate with is in that group: admin@PA-200> show user group name "cn=vpn-users,ou=groups,dc=panlab,dc=local" source type: service source:      panlab-389LDAP [1     ] panlab.local\chadd admin@PA-200> As you can see in the output of the last command, domain\user is what the firewall is looking for.  The important parts of the configuration for groups to work correctly are as follows: Device->LDAP->your-ldap-profile: If your LDAP server requires the domain\user login method, you can configure the domain in your profile.  If not, then leave that field blank (try it both ways). Device->User Identification->Group Mapping Settings->Server Profile->your-group-mapping-profile: In 4.1 and later the firewall does the group mapping, so this is where you configure that.  Make sure that these settings match your LDAP install. Device->User Identification->Group Mapping Settings->Group Include List: This is an LDAP filter.  This is used to restrict the LDAP search to these groups.  It is different than the allow list in your authentication profile - this is a filter, not an ACL.  That being said, if you filter out the group you are trying to authenticating to, it obviously won't work. Some things you need to be aware of: There is a delay between the time you add/remove a user to/from a group and when the authentication works.  You can speed up the process by using the following commands: admin@PA-200> debug user-id reset group-mapping   all                        all        panlab-389LDAP   panlab-389LDAP   <value>          group mapping to reset This command is helpful if you want to get the groups to clear from the firewall and have them rediscovered. admin@PA-200> debug user-id refresh group-mapping all admin@PA-200> This command can be run to cause the firewall to pull the new mappings since last time the process ran (delta). If none of the above helps you resolve the issue, it would be great to do a packet capture between your PA and your LDAP server.  Open the pcap in a program like WireShark and filter for ldap (type ldap in the filter and hit enter).  Look for the ldap requests and ldap responses.  Make sure that when you attempt to authenticate, the firewall sends an ldap request to the LDAP server.  If it does not, make sure that your Device->Setup->Services->Service Route Configuration is set up correctly.  If it does send a request, make sure it is correct, and that you get a valid response.  In version 5.x or greater of PAN-OS, you can use tcpdump at the command line to capture this traffic - although, it is best if you scp export the pcap off the box and inspect it with a program like WireShark. All that being said, please open a case with support if you continue to have trouble. Good luck. -chadd. ... View more

Like the last respondent, I would need to know what the intent is here to provide a truely educated response.  I would say this though - if you just need a captive portal, why not use the on buit into the Palo Alto?  If you are trying to use something like Cisco ISE for the captive portal, then the real solution involves WCCP on an intermediate switch, which will intercept the http request, forward it to the proxy server, then after authentication, the switch will redirect the user to the firewall for outbound internet.  Please let us know what technolgies you are trying to leverage, and what the end goal is, and we can make better recommendations.  Good luck. -chadd. ... View more