Duo SAML SSO confusing GlobalProtect

[jwckauman]

When a user attempts to connect GlobalProtect VPN, Duo succesfully authenticates the user but is NOT sending back the username to our Palo Alto firewall. It is sending back the email address which is not the same as the username. Why is Duo even looking at the email address of the user? It should receive the username/password and that’s it, right?

For example, let’s say my account name is jsmith and I’m a member of the domain contoso.com, but my email address is johnsmith@outlook.com. When jsmith connects the VPN, Duo authenticates him succesfully, but sends back johnsmith@outlook.com to the firewall, which confuses the firewall as it doesn’t know who that user is.

[DuoKristina]

Note the bridge attribute mappings in step 4 here. Did you leave the default mappings in place (so Username is sAMAccountName)?

In the Authentication Profile for Duo SSO, is the username attribute there also set to the username?

[jwckauman]

I believe everything is default when we setup the Azure AD SAML IdP. The SAML IdP’s Attributes section show username = and Email = . Is that what you mean?

In the AUth Profile for Duo SSO, the username attribute says ‘username’. In the link you sent it says ‘user.username’. I will try changing that and seeing if that works.

[jwckauman]

No go. I tried user.username but still returning email address. Why on earth is Duo querying the email address field in our user properties? Username should be username, not email address. How do I make Duo send back the actual username???

[jamieis]

Hi @jwckauman,

The problem might be that I don’t believe there is a sAMAccountName like attribute in Azure AD if that is your IdP by default. This means that only formats like username@domain.tld exist in Azure AD so that’s all Duo SSO is able to send to Palo Alto.

If you’re able to find an attribute in Azure AD that is just username formatted you can send that to Duo SSO as the Username attribute which will then make its way to Palo Alto.