PAN Firewall LDAP Authentication user handling

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

PAN Firewall LDAP Authentication user handling

L1 Bithead

Hello Community,

 

so i've got a small "issue"/question regarding PAN Firewalls and LDAP User-Authentication handling.

I configured it like it is documented here

My issue now is that when i add an Administrator, then delete the user from the Active-Directory group, the user is still able to log on even after the firewall refreshes the connection.

Am i doing something wrong here, or do i manually have to delete the user, from the firewall so he cant connect to it anymore?

 

Best regards.

2 accepted solutions

Accepted Solutions

Cyber Elite
Cyber Elite

@christoph_oppelt,

For the user to actually be removed from the firewall, yes you would need to delete the account manually. However as long as the admin session had expired, I wouldn't expect that the user would actually be allowed to login unless your LDAP server was still giving the firewall the 0 response code. If the user account no longer exists you should be getting a 49 response and the firewall wouldn't auth the user. 

 

* I just saw that you said group. Have you tried ensuring that the group membership has actually updated on the firewall through the cli command 'show user group name <group>'. Otherwise the firewall will simply verify that the LDAP credentials are correct. 

View solution in original post

Hi @christoph_oppelt,

 

Current versions doesn't support remote authorization for administrators using LDAP.

 

Administrative Authentication

 

The administrative accounts are defined on an external SAML, TACACS+, or RADIUS server. 
The server performs both authentication and authorization.

For that reason as you have seen from the KB in order to authenticate admin via LDAP you need to localy (on the FW) create the username and set it to authenticate using the LDAP. 

 

Behind the scenes the firewall is try to made a bind request using the username and password provided during your login attempt. FW doesn't really care in what user group this user is configured in the AD. As long as you have provide valid username and password, the bind request will successed and you will be allowed to login.

 

You actually have a "workaround" to tell the FW to try to authenticate only specific users.

 

When you are configuring the authentication profile, you can specify "allow list". This list will tell what users are allowed to authenticate using this profile. That way you can tell the FW you allow only users member of FW_admins user-group in the AD. This will mean that when you try to login there will be additional step:

- you type your username and password

- FW will check if the username you have provide is member of the that allow list

- If it is in this list, FW will again try to make bind request with provided username and password

 

 

So what you can do is on the step 2c from the guide instead of all you can list the user group or specific users

View solution in original post

3 REPLIES 3

Cyber Elite
Cyber Elite

@christoph_oppelt,

For the user to actually be removed from the firewall, yes you would need to delete the account manually. However as long as the admin session had expired, I wouldn't expect that the user would actually be allowed to login unless your LDAP server was still giving the firewall the 0 response code. If the user account no longer exists you should be getting a 49 response and the firewall wouldn't auth the user. 

 

* I just saw that you said group. Have you tried ensuring that the group membership has actually updated on the firewall through the cli command 'show user group name <group>'. Otherwise the firewall will simply verify that the LDAP credentials are correct. 

Hi @christoph_oppelt,

 

Current versions doesn't support remote authorization for administrators using LDAP.

 

Administrative Authentication

 

The administrative accounts are defined on an external SAML, TACACS+, or RADIUS server. 
The server performs both authentication and authorization.

For that reason as you have seen from the KB in order to authenticate admin via LDAP you need to localy (on the FW) create the username and set it to authenticate using the LDAP. 

 

Behind the scenes the firewall is try to made a bind request using the username and password provided during your login attempt. FW doesn't really care in what user group this user is configured in the AD. As long as you have provide valid username and password, the bind request will successed and you will be allowed to login.

 

You actually have a "workaround" to tell the FW to try to authenticate only specific users.

 

When you are configuring the authentication profile, you can specify "allow list". This list will tell what users are allowed to authenticate using this profile. That way you can tell the FW you allow only users member of FW_admins user-group in the AD. This will mean that when you try to login there will be additional step:

- you type your username and password

- FW will check if the username you have provide is member of the that allow list

- If it is in this list, FW will again try to make bind request with provided username and password

 

 

So what you can do is on the step 2c from the guide instead of all you can list the user group or specific users

L1 Bithead

Alright, thanks to both of you.

Guess i'll have to just live with it.

  • 2 accepted solutions
  • 6596 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

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!