Adding SAML authentication profile from second AzureAD to existing gateway

[RobertTryba]

Hi all,

We are required to move authentication of our GlobalProtect users from our own domain to new domain, owned by parent company - O365 licences cost needs to be scaled down on our tenant.

We have already migrated O365 userbase, so we have credentials from new domain, but now need to migrate GP authentication from our O365 tenant and to start using usernames from new tenant.

We already have one authentication profile utilizing MFA in current authentication sequence.

Scenario 1:

Can I just add secondary authentication profile that is linked to new O365 tenant as second line in "GP/Gateways/name/Authentication/Client Authentication"?

Will that allow users to attempt authentication usin legacy tenant, then failing that will move to attempt to authenticate using username from other..?

Scenario 2:

Failing Scenario 1, I have second gateway already created, with only AD as autentication profile. It is still live, just not used.

Can I create new authentication profile using new tenant's SSO application etc, reconfigure second gateway from AD to that new tenant-based profile and just point users to use that portal instead of old one..?

Scenario 3:

Failing that, is there anthing else I can try short of completely new gateway?

Also important - we are not admins on new tenant, so what would I need to from new tenant admins to make it happen - root AD domain cert imported to Panorama/firewalls..?  anything else?

I am good on firewall rules, but not created any of those gateways and need some advices.

[aleksandar.astardzhiev]

Hi @RobertTryba ,

Unfortunately option 1 will not work. The main purpose of having multiple entries on "GP/Gateways/name/Authentication/Client Authentication" is to apply differnt authentication based on OS. However if client match any of those profiles and fail to authenticate it will not try the rest.

Unfortunately you cannot use Authentication Sequence as well, because you are using SAML

In that case option 2 seems as reasonable solution to me.

[RobertTryba]

Hi,

Yeah, your answer is basically in line of what i read prior to posting.

Have more support sessions with Palo engineer, we'll go through my actual config and devise nest steps afterward, before implementation stage, will update with what went with in few weeks.

regards

Robert

[RobertTryba]

Hi,

It is not as easy as I thought it'll be.

Option2 - add new company's O365 tenant as authentication profile:

- created app in new tenant and imported it as new certificate and SAML Identity Provider; had to use metadata 'Import' method, as it was throwing errors that I already have MS Azure Fedrated SSO cert (I do from my current domain's SSO app, but using new app's metadata was able to import new app's cert and create certification profile at same time). 

- in GP Gateway, created new Client Authentication using new certification profile from point above. Set it as first line (did not removed existing profile, but it should not be used due to 'OS=any' in both rules). 

- in GP/Portals created Client Authentication using same new tenant Authntication profile with identical setup.

At this stage Global Protect logs shows that I have logged in 'succesfully' using 'username@newdomain.com' username, but:

I get redirected to browser to chose which account I want to use to authenticate, but I do not get MFA request from new tenant to authenticate my login (which I want), also get 'Matching client config not found' error on GP client when trying to authenticate. 

Troubleshooting steps I took already are:

-removed need for BOTH username AND computer cert to be present. No change

-created "Domain Local" security group in my local AD that includes username from new tenant's local AD for my test account

-have used same PreLogon certificate as in working MFA gateway.

None of it resolved issue with actaully getting to log in. 'Matching client config not found' error suggests that test account is not allowed to use that portal, but it is included in GP config.

Also - for some reason Gateway changes are not replicating from Panorama to physical firewalls, Portal changes are going as I wouldd expected, but none of changes to Gateway part of Panorama config has not been sent to FW's.

So far had to replicate gateway changes manually in physical firewalls and this seems to work, as after amending config on FW I get change in client behaviour...

Any thoughts?

UPDATE:

did some more digging and found that when I look in CLI of physical FW for members of that DOMAIN LOCAL security group that should hold username from new tenant, it does NOT show up any members from that domain. placed test local AD username and it did showed up as single entry.

Another addition worth mentioning: new tenant and AD organisation have differences in both public vs local domain name AND there's difference in AD username vs O365 account name. So neither public domain name I need to use in GP matches local AD name for usernames, but also UPN name for account fiffers between O365 and local AD username.

Unless I get option to match username to email address inside of autrhentication profile somewhere, i do not think I can use email for GP and local AD username for profile match creation here...

[aleksandar.astardzhiev]

Hi @RobertTryba ,

There are couple points so lets tackle them one by one:

- "Gateway changes are not replicating from Panorama to physical firewalls" - this is most probably because GP Gateway config from Panorama is override locally on the firewall. When FW detect local config and config pushed with Panorama template it will always prefer the local config, until admin accept the Panorama config.

You should be able to confirm this by checking on the FW GUI if there is green gear, if there is yello gear over the green gear this means there is local config overriding Panorama template.

Two options:

- Select (not edit, but just select) the gp gateway object, you should see button "revert" at the bottom of the screen. Something similar to this picture (I am don't have access to FW at the moment, so cannot provide actual picture)

After that you need to commit locally on the FW.

- Second option - review eithire (or at least the major config) from Panorama template and make sure all setting in the template are correct. Then push template config from Panorama to FW, but enable the settings "Force template values"

What do the different colors on gear icon indicate when a templ... - Knowledge Base - Palo Alto Netw...

- "Matching client config not found" - it is little difficult for me to follow this one, without looking at your config or group membership output, but it sound like you have a problem with user attribute mapping. Also with the group mapping.

When you are configuring group mapping, you define what user attribute firewall will gather over LDAP. If you are authenticating with UPN to GP, but your group mapping using primary user attribute SAM (sAMAccountName), FW will not be able to match the username with group mapping.

Now as you can see from group mapping, FW should be able to match different username formats (if I may call them this way), by mapping all attributes to a user. Please check this discussion where I have share couple of commands and links how to troubleshoot user attribute mapping - https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000CpgcCAC&lang=en_US%E2%80%A...

- "which account I want to use to authenticate, but I do not get MFA request from new tenant to authenticate my login" - Just to clarify, you are refering to Azure MFA, right? Not Palo Alto supported 3rd party MFA - https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-admin/authentication/configure-multi-factor-auth... ?

If you are configuring GP with SAML authentication only, which will open Microsoft login page, which then should challange you for MFA, this is completely contronlled by your AzureAD. There is an setting that you can tell Azure to not ask you for MFA is you try to login from the same device for the next N hours/days. If you want AzureAD to ask for MFA every time user attempt to authenticate you need to look at AzureAD settings.

[RobertTryba]

Hi all,

Update on final solution:

Have ended up with creating LDAP profile and authentication sequence to new domain. Not an admin on new AD, so had to involve admins from them to do it...

So I get MFA authentication from new tenant, 'client profiles' are being matched using LDAP from AD and authentication is finalised by requirement to have both AD account AND device certificate.

AD account is authenticated from new AD domain via security group, computer is authenticated using machine certificate generated for Palo Alto from legacy AD.

For group mapping issue - it was actually not an issue, defaults worked just fine with new LDAP profile. 

As per firewall templates etc - not worth pursuing, they will get replaced in few months, so will deal with what we have until their demise.. 😉

In the end - it works, end result we wanted to achieve which was to remove need for any O365 licences on old tenant is accomplished.

Thank you all for pointing in right directions..