Panorama 4.0.5 not syncing Administrators down to devices

[jbaker80]

I'm managing two PA-5060 firewalls running PanOS 4.0.5 with Panorama also running 4.0.5.  I am authenticating adminstrators via LDAP - I have an LDAP server created as a shared resource, I have an authentication profile created, also as a shared resource pointing to the previously created LDAP server.  I have created 4 administrators on Panorama each pointing to the LDAP authentication profile, and defined as dynamic, superuser.

All four administrators can log in to Panorama with no problems, and the shared server definition, and authentication profile show up on the firewall device when I change the context, but the administrators are not.

The problem this is causing is when 1 of these administrators trys to connecte directly to one of the firewalls via ssh (to clear a hung download) they cannot log in.

Is this expected behavior or should the administrator accounts be pushed down to the firewall devices?

[Bart_Jocque]

You have to push the shared authentication profile to the firewalls.

Then you can select this authentication profile under device/setup.

Unless you are using VSYS's, because panorama pushes all objects to the vsys contexts, you will not see the pushed authentication profile under the device context.

Took me 1/2 day to figure this out, it would be nice to see this documented.

(see my other threat on kp about this issue )

Bart.

[jbaker80]

I've pushed the shared profile down and when I change the panorama context to the device - I see the it under authentication profiles.  I went into the device setup to select the Authentication Profile there, but it does not show up in the drop down.  The note under the box says - "Authentication profile to use for non-local admins. Only RADIUS method is supported."  We're using LDAP - so I'm assuming that is why I can't select it.

Also, none of the superusers that exist on the Administrators tab in Panorama to that point to that authentication profile are being pushed down to the device.  The only user on the device administrators tab is the default admin.

Maybe I'm setting this up correctly but it seems odd to me that the ldap server definition and the authentication profile syncs, but the users do not.

[mgentile]

I see similar behaviors with the Syslog and Authentication profiles, too.  I can push them out to the remotes, and I can see the profiles on the remotes, but when it comes time to select one of those profiles for configuration on the remotes, it doesn't show up in the drop down list!

What's even stranger is that this worked for some of my remote firewalls in the past, but no longer seems to work for the newer ones.  Running 4.0.5.

[apcecpadmin · Accepted solution]

Hi There,

Just a note I experienced this issue on a previous 4.x release and opened a ticket.  As described by support at the time the push of the authentication profiles was not intended and the pushed profile would be non-functional.

The estimated fix I beleieve i got was 5.x and though I attempted to escalate the issue to be fixed sooner, there is an "easy" workaround this is not a priority item.  the fix as expained to me was to remove this functionality.  This mindset may have changed, but this is what I was told at the time (I beleve the 4.0.3 release)

What is worse is if you had a local LDAP configuration of the same name as the panorama one pre-4.x upgrade you could not push policy after the upgrade.

Here is the possible solutions (like it or not):

- do not share the profile from panorama or do not use it on the local device

- create a local profile with a name different from panorama and use the local profile

- use a different authentication mechanism on local units vs panorama

-if you have same object/policy names in the 3.x world locally and those objects are centralized in panorama 4.x world make those names unique locally before upgrading

I really did not want to monkey further with our naming conventions and had both radius and ldap as available mechanisms to I just did radius local and ldap on panorama.  It was painful to "clean" these configurations in a HA active-standby configuration post upgrade.

Probably not the answer you wish to hear, but the solutions above worked in our environment across different PAN models.

We are currently running on 4.0.4 and besides painfully slow log functions and policy pushes the release is operational in a pure 4.0.4 environment.  I just checked knowledgepoint as I do before considering every upgrade and I see one too many "scary" posts to consider going to 4.0.5 unless I experience a production issue in our environment.  Maybe 4.0.6 will be the golden release.

[jbaker80]

Thanks for your comments - I also called support about this yesterday and after our conversation, we chose the second option that you noted:

- create a local profile with a name different from panorama and use the local profile.

Although it's definately not an optimal solution - the thinking is that the support group that would actually need to directly access the device outside of Panorama is small and rather static so hopefully access won't have to be modified that often.

[wittejj]

One of the things that PA tells you about Panorama (but it doesn't register until you deal with it) is what items get passed down to the devices if they are configured as "shared" in Panorama.   That includes address, object groups, authentication profiles, and LDAP servers just to name a few.  I think even web-server certificate for Panorama was passed down in some of the 4.0.x code, but I believe it has been fixed.  The one thing that they don't make very clear is if you have the same object created on the device and the shared Panorama configuration is that can cause problems.

I ran into the exact same problems that you did and I had to rename the authentication profiles and LDAP servers in Panorama so they wouldn't conflict.  I also had to create the same administrator accounts on all of the devices so they could directly accesses the devices via HTTPS or SSH.

The way I view Panorama is that it's not so much a centralized management sytem as much as it is a centralized configuration system.  It's not quite as intertwined with the devices as you would like it to be.  Once you come to terms with its features and limitations you realize that it's pretty useful.  Just my two cents.