You can see the article from Okta and use it for Azure AD, you just need to find the Azure AD documentation how to set the atributes:
I arrived here to seek for answer to a problem that I could not find an answer to anywhere.
In fact, I still didn't find it but having access to lab, and some thought got me the desired result.
So what is it.
If you have setup a Security Web Policy based on LDAP Groups, and you authenticate using Kerberos/LDAP AD , PAN will identify you as domain\user.name
You have some influence over how domain\ will look, but overall PAN will identify the user and will know groups you are a memeber of.
Now, you want to introduce AzureAD SAML authentication.
You found the article and followed it to the letter: https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g0000008U48CAE
You were able to authenticate, and get connected so what's the problem?
The problem is that your user name is no longer domain\user.name but now it is email@example.com , it is the account you have used to authenticate against Azure AD.
The user no longer matches any groups and the desired access for this user or group of users no longer works.
I found that the Attributes in the article do not contain group attribute.
Under AzureAD Portal for Single-Sign on I've added the attribute then for Security Groups
Its under "Add a Group Claim"
Source Attribute: GroupID
Customize the name of the group claim: Group
All these is case sensitive(apparently)
Once you have the extra attribute, export the XML and Import to Palo.
Import it as Authentication Profile and add Group attribute you created:
When I log in using SAML now, I have different view:
The User: shows the email address I used to authenticate.
The Primary User name is domain\user.name
Firewall can "match" the SAML account I used to the local AD.
Now, interesting part to some is the fact that I do not use Active Sync. My Local domain is entirely different to Azure AD. They are seperate.
I do have email attribute populated in my AD as the account I use with Azure though.
Hope this helps someone.
You do not need to add a group attribute, and it will not work for login control using groups. If you change the username attribute to match the settings below and have LDAP configured for userID Groups will work even for Prelogin. users will still login as before only the username submitted will be using local domain username format 🙂
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!