Windows, Kerberos, LDAP, RADIUS

[DavidHostetter]

Hi! My company is rolling out a small pile of Palo Alto firewall models and I'm trying to learn the nuances and best practices of these devices. Initial implementation and basic functionality has been pretty straightforward. Now we are trying more advanced things.

My current issue is user authentication.

I have a scenario that I feel must be very common but I can't find any KB, blog or discussions that address this directly. I am surprised that I cannot find any description nor help for this scenario.

We have a Windows environment, and on test lab devices have successfully implemented, separately:

• Kerberos auth to AD to allow us to define AD users as firewall Admins.
• LDAP auth to AD for user access through Global Protect.
• RADIUS connectivity to our 2FA provider (used with Global Protect).

Now I am wondering if these can be used in combination? Here is our scenario:

• Windows AD
• Don't need SSO
• No NAC or other identity management outside of AD
• Assume Palo Alto cannot join active directory domain

We wish to use AD security groups to control:

• Firewall admin access
• Use AD Security Groups with firewall security policies incl. Global Protect

Given that, which authentication and user ID method is preferred?

My general understanding of Kerberos/LDAP/Radius is:

Kerberos - Preferred for secure authentication protocol. Does not handle directory lookups sich as AD groups or user attributes

LDAP - User authentication and directory lookup protocol. Allows lookup of AD group and user attribute.

RADIUS - user authentication and directory lookup protocol. Allows lookup of AD group and user attribute. More complex configuration than LDAP. Often required for MFA.

Any corrections to the above information?

Would someone offer their thoughts on pros/cons of using each w/ Palo Alto in my environment of Windows AD?  Are there basic best practices here?

My  main question though is can Kerberos be used for user auth and LDAP used for security group association of the auth'ed user? If so, how?  If not, what is the downside of using only LDAP, not Kerberos in an AD only environment?

Thanks for any advice offered!

[S.Cantwell]

Hello there.

I have often used LDAP for much of my configurations, based on simplicity and need.

As you mentioned, LDAP can do authentication, can be used for LDAP Group Mappings, etc.

As you also mentioned, you have individually confirmed that authentication profiles for each type, have been configured.

Now, you would need to create an Authentication Sequence, which allows each auth profile to be queried/tested.

The other configuration you would want to implement is creating an service account with the following permissions:

Event Log Reader (to determine/establish user to ip mappings)

Server Operator (to maintain known ip mappings of those ppl using file/print share sessions)

WMI Probing (if needed) to query unknown IPs that may be microsoft devices, but not picked up by the previous 2 techniques.

You can configure the FW (User ID --> Group Mappings) to limit those LDAP group you want policies to be for (such as FW admins)

You can enabled UserID on the trusted zone, so that the FW knows who the users are.

You can create policies, based on UserID name (or group mapping) to be used at matching conditions for your policies.

I would recommend the old "RTM" method of reading the admin guide on UserID.

All techniques that you want and described, can be accomplished. You just need to engineer the solution to do them.

What other questions can we answer for you?

[DavidHostetter]

Thank you Steve,

I'm looking at this document on authentication sequence:

https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/authentication/configure-an-authentication...

If I don't need SSO, should I only use LDAP and not Kerberos?  I believe that Kerberos is a better AD authentication mechanism than LDAP.

If authentication sequence has both profiles for Kerberos and also LDAP and these profiles are pointing at the same directory (AD), once Kerberos was passed (valid login) would LDAP again validate the login or is the process "smart" enough to only LDAP only to retrieve details for the Kerberos-authenticated user account?  Or am I not understanding this right?

I'm trying to follow the above document to use Kerberos for user auth and LDAP to permit that user to have an admin role via security group membership.

Thanks again!

[asilliker]

You can't directly control your admin access using AD groups via  kerberos/ldap. You can control admin access via RADIUS/TACACS/SAML.

You can auth admin users via kerberos/ldap, but you'll need to locally define/authz the admins and externally authenticate them.

https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/getting-started/best-practices-for-securin...

https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/firewall-administration/manage-firewall-ad...

If you are looking to do MFA for the GP connectivity (and you should be), you'll likely want to do this via either RADIUS or SAML, unless you are using the Cert+LDAP approach.  

[DavidHostetter]

Thank you.  Those documents look very helpful, I will read them.

"locally define/authz the admins and externally authenticate them."  That is it, exactly.  We don't want to do that.  Yes, we are using 2FA for GP and that is working now, but I want now to restrict GP or at least create differing policies for GP users based on their AD groups.

[asilliker]

For admin users, fully external admins can be achieved via SAML/RADIUS/TACACS.

Your GP use case can leverage an AD group defined in the allow list of the authentication profile to restrict VPN login, or apply different GP configuration. 

Different network access is generally enforced post authentication by implementing User-ID. 

[DavidHostetter]

"by implementing User-ID."  Or by Security Group?

[asilliker]

You need to implement user-id. This include both the authentication to the VPN (IP-User mapping) and the configuration of Group Mapping (user-group)

This allows you to implement rules based on your AD security groups. 

https://docs.paloaltonetworks.com/pan-os/9-0/pan-os-admin/user-id/user-id-concepts.html

[DavidHostetter]

Sorry, I mistook you.  I thought you meant create policies matching AD user, not SG.  I understand the user-id process now.

I'm still stuck on RADIUS to AD.  We have RADIUS to our MFA provider working, but I am still working out certificate issues connecting to AD, I think.

I do still have some conceptual areas that are unclear.  Reading about authentication sequence, the documentation states that the first authentication method to succeed causes the sequence to complete with a success.  No further authentication profiles are used.  So if I want to use Kerberos for user ID and then RADIUS to return group membership, that doesn't seem like it works that way.  If Kerberos works, the rest of the authentication sequence is not processed.

RADIUS alone seems like it would work correctly to authenticate the user and match security group.  So the only usefulness of Kerberos with Palo Alto then seems to be for SSO?  But this implies that if you did use SSO (requiring Kerberos) you can't then create further policies matching the AD security group instead of the user account.  That seems like a needless limitation, if true.

Another area that I don't quite understand is that it seems like RADIUS security group matching occurs on the RADIUS server end / AD ?  In other words, it seems like one makes NSP policies that match the security group and allow login or not allow and this is what is returned to Palo Alto, not the security group membership?  That can't be the case but I don't see how RADIUS passes back the SG membership nor how Palo Alto identifies it and uses it.  Maps SG group to Role is what I am assuming.

This would be a whole lot easier and more powerful if PanOS could join the domain as a member workstation and directly integrate with AD.

[S.Cantwell]

@DavidHostetter 

I am a little confused by this comment

This would be a whole lot easier and more powerful if PanOS could join the domain as a member workstation and directly integrate with AD.

This is how AD integration works on the PANW Firewall

You have your MS person create a service account with 3 permissions:

Event Log Readers

Distributed COM Users

Server Operator Privileges.

You use this account to create a LDAP Server profile

You go to UserID  ==> Group Mappings, and refer to the LDAP Server profile, and determine what LDAP Groups you want to create policies for.

You enabled UserID on the zone (trusted)

You create security policies. based on LDAP user or group.

Am I misunderstanding?

What I have understood by PANW (as a trainer and PS engineer) is that the service account you created is exactly used for joining the domain, but is not an end user service account... if that makes sense.

[DavidHostetter]

No, you are correct. I was not thinking clearly before. LDAP isn't quite the same as directly joining the domain with a workstation account and accessing AD directly, but it does work similarly and is more universally compatible.

I guess my last remaining question is, why would I have to use both RADIUS, for implementing admin access through AD security group membership, and LDAP, for using AD group membership with user-id ?  Why can't either method be used for both?

Currently I am assuming that I should drop Kerberos as being redundant (or possibly blocking LDAP/RADIUS when used within an authentication sequence), implement RADIUS for admin access via AD security group and implement LDAP for user-id security group matching.

Eventually when I'm done, I'll document it clearly for posterity including the Windows side of things. Where would one submit such documentation?