Okta Admin Authentication on HA deployment

[Jonathan_C]

Hi,

I have configured multiple Active/Passive firewalls for Okta SSO (admin authentication) this is working as expected on the active devices, however I was planning to use a separate authentication profile for the passive devices. Everytime I push the profile for the secondary firewall it syncs it back to the primary.

It was my understanding that authentication profiles don't sync in HA (https://www.paloaltonetworks.com/documentation/80/pan-os/pan-os/high-availability/reference-ha-synch...). The devices are running 8.0.9. so I am not sure if this is expected behaviour and/or how to get around it

[gwesson]

The admin auth settings (Device > Setup > Management > Authentication) do not sync, but the auth profiles (Device > Authentication Profiles) are not specific to administration and so they do sync between peers.

If your auth profile on both active and passive is called "OktaSSO" and you try to change the settings of that profile on only the passive, those won't stick.

You'll need to set two different auth profiles ("OktaSSOPri", "OktaSSOSec" for example), and set the active to use one and passive to use the other.

[Jonathan_C]

"You'll need to set two different auth profiles ("OktaSSOPri", "OktaSSOSec" for example), and set the active to use one and passive to use the other."

I have tried this, however because the auth profile syncs between both firewalls I end up with the same profile on both everytime. I have set "OktaSSOSec" on the passive device and I end up with the same profile on the primary, which doesn't makes sense to me. So no matter the order both FWs end up with the same profile and Okta then works for one and not the other. 

Have you managed to get around this and get Okta admin access working on both devices of the HA pair?

I have raised this with support and been told they are aware of the issue but not in the pipeline to fix it.

[gwesson]

Again, the profile itself will sync which is why you need two. Both of the two profiles will exist on both peers. If you have both profiles defined, and you tell the primary to use OktaSSOPri and you tell the secondary to use OktaSSOSec, those settings should stay unique after a commit and config sync.

Are you saying that the settings are also syncing (Device > Setup > Management > Authentication)? Those should not be syncing between the peers as you found in the document you linked. If you're seeing that the settings themselves are syncing contrary to the documentation, that would be a bug (or the very least a problem with documentation).

I haven't actually set it up how you are. I don't understand the use case of having different login info between an HA pair - they are essentially interchangable, so I've never seen anyone configure it that way. That's not all that important though, it *should* be functional as you want it to work. 

[Jonathan_C]

" you tell the primary to use OktaSSOPri and you tell the secondary to use OktaSSOSec, those settings should stay unique after a commit and config sync"

You would expect so, I agree with you. This is not the case though. If I tell the Primary to use "OktaSSOPri" and the secondary to use "OktaSSOSec" I end up with both firewalls using one or the other but not separate due to the sync process

"I don't understand the use case of having different login info between an HA pair"

When you use Okta for admin access, you provide the landing page, which is essentially the login page for the firewalls, since the devices have different hostnames and different management IP addresses Okta treats these as two separate profiles and generates different metadata for those profiles, this is the reason you end up needing different auth profile in the HA pair

[gwesson]

Thanks for the use case, I hadn't realized it was specific to the hostname/IP. Makes it impossible to use Okta syncing like that.

It sounds like you're hitting a bug. The profiles should sync but the actual settings for the admin login shouldn't. I'd recommend getting your support case reopened if it's closed, if it's a known limitation then it should be well documented at the very least.