Hello, This is indeed an excellent workaround, tested here also in 8.1. Thanks for this information, it's really useful. Usually, we rely on our Active Directory, which is old enough to be primarily based on the SAM Account Name, which is what the NGFW is looking for by default, in the following format : Domain\SAMAccountName (ie. acme\doej) We began using Okta to authenticate our GlobalProtect users for non-Windows or non-Domain devices, but it was impossible to use the "groups" attribute from the SAML assertion in the GlobalProtect configuration. We opened a case with TAC, and the answer was the following : this attribute can only be used in the "Allow List" of the Authentication Profile, but nowhere else : In order to make this work, the username sent by Okta in the assertion must be the same as the username that the NGFW understand by default, that is, the "Domain\SAMAccountName". This is not an easily available option in Okta. In the GlobalProtect app in Okta : Edit the "Sign On" settings Find "Credentials Details" section Select "Custom" in the "Application username format" Fill the field with this syntax : "yourdomain\" + toLowerCase(active_directory_xxxx.samAccountName) Please note that the "active_directory_xxxx" must match your directory ID, that you can find in the This only works, however, if you have an LDAP server somewhere... With Okta, I know there is a way to use it as an LDAP server, which might do the trick, like described in this link : https://help.okta.com/en/prod/Content/Topics/Directory/LDAP-interface-main.htm With all this combined with a bit of Group-Mapping, you could tinker this to work as expected ! :) It's unfortunate that PAN does not seem to want to integrate a wider use of the group attribute of the SAML Assertion. It complexifies the use of SAML, with little to no documentation... :(
... View more
As I keep on looking for a solution, I tried using a more common EDL.
As of now, the firewall is getting the right number of indicators, with no difference with the values gathered by Minemeld.
I'm therefore wondering if there is a bug with the DAG Pusher prototype... Has anyone got this kind of issue in the past ?
... View more
I tried to reference all the Windows RODC (Read-Only Domain Controllers) using a custom script. The script is working fine : it queries our Active Directory, and returns a JSON list of RODC. Each indicator listed by the script looks like this :
"comment": "This is a comment",
I then used an import script found here : https://gist.github.com/jtschichold/95f3906566b18b50cf2e3e1a44f1e785 which works fine too : it imports all the indicators (around 130) into the configured miner in Minemeld :
I then send these indicators directly to some output nodes :
I used a classic Output feed (as a test output). For populating the firewall, I used the DAG Pusher prototype, one that used our Panorama (CrfRodcDAG) and another one for testing purposes that sends the indicators directly to a firewall (CrfRodcDAG_Test). If we focus on the latter, here is it's configuration :
The firewall has a Dynamic Address Group configured, that matches the MineMeld tag "MM_RODC" :
At first, it looked like everything worked fine :
If a new RODC was found, it was added after a short timer in the firewall.
If a RODC was deleted, it was suppressed from the DAG
However, after a few more tests in Minemeld, I restarted the MineMeld engine several times. And I began having some discrepancies between Minemeld and the firewall : MM still had 130 indicators, but the firewall only got 22, then 90, sometimes 126, then after a few seconds, dropped down to zero... The only way I found to stabilise the situation was to clear all registered IPs from the firewall, and then restart MineMeld engine. But again, if the MineMeld machine restarts or receives modifications, it "breaks" the whole system...
For instance, right now, MineMeld lists 129 indicators, while only 36 are listed by the Firewall...
I check with PAN support if the issue could be with the firewall, but they saw nothing suggesting that.
Do you have any idea on the possible cause of this issue ?
... View more