User-ID with Azure AD

[djohnson229]

Hey all, I've set up User-ID with on-prem AD servers a few times - quite straightforward.

My question is, how do I set up User-ID when my customer uses Azure AD (with no on-prem servers)? I need to someone get the user-to-IP mappings on the firewall but pulled from Azure AD but not sure how its done. I did see/hear about the "Cloud Identity Engine" but wasn't clear on whether this would do the job or if there is a better way....

Any pointers would be appreciated.

Thanks

DJ

[TomYoung]

Hi @djohnson229 ,

That is a great question.  I have wondered the same thing myself.  This docs walk through a process where CIE combined with the Authentication Portal can get User-to-IP mappings -> https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-new-features/identity-features/cloud-identity-e....

The Authentication Portal would be best if it can be setup to authenticate in the background rather than have the user type their credentials in, but that would require the same creds on the PC and Azure AD.  You could also use certificates.

There are other ways to get User-to-IP mappings depending on what you have in place.

1. Use GlobalProtect with internal host detection to require login but not tunnel to a gateway.  (I have not tested this method.)
2. Retrieve mappings from 802.1x configure on wireless and/or wired.

Thanks,

Tom

[djohnson229]

Hi there, thanks so much for the reply. I find this solution pretty lame from Palo.... Previously with on-prem AD the user experience didn't change, they simply logged in as they normally did and the firewall would learn the user-to-IP mapping from AD. Very simple/easy....

Now with Azure AD, I have to deploy Cloud Identity Engine (new product) and the user experience is different - the user is required to authenticate in a portal or use Global Protect (new software agent on PCs) to authenticate users in order to learn user-to-IP mappings. Its pretty clunky in my opinion.....

Note: I do know about other User-ID methods - including syslog, etc but I want my firewalls to integrate directly with AD.

[TomYoung]

Hi @djohnson229 ,

I totally understand your side of the story.  It is not as seamless.

I can take a guess at the PANW side:

1. Azure AD has no MAC address to link the user to the IP address which exists with a local AD DC.
2. Why didn't they build CIE into the NGFW?  I would assume they looked at this 1st but decided to move it to the cloud for some reason.

At least they have a solution for Azure AD User-ID.  Maybe it will get better.

Thanks,

Tom

[djohnson229]

Yeah we are on the same page Tom 🙂

Regarding point 1, I don't believe the MAC address is anything to do with it. Regarding point 2, I agree it would be much better if the CIE could be built into the NGFW somehow - no-one wants "more stuff" to manage.......

Thanks man

Darren

[TomYoung]

Hi @djohnson229 ,

I believe the MAC address is the common parameter on the local AD DC that is used to link the username in the authentication logs with the IP address in the DHCP logs.  How does the User-ID agent know which username goes with which IP address?  I can't think of anything else.

Thanks,

Tom

[djohnson229]

I thought that the event logs in AD (that the firewall looks at) contained the username in the authentication and the IP address that the authentication came from (the users PC). From this the firewall has the user to IP mapping...

I didn't think there was anything related to the MAC address in the AD event logs - the MAC address would only be relevant if the AD DC was on the same layer 2 network (VLAN) as every user which is not really practical. I could be wrong here though.....

[TomYoung]

Hi @djohnson229 ,

That makes sense.  Do you think Azure AD knows the IP address of the user when they authenticate?

Slightly different topic:  I think the Windows agent works if the user has a domain computer.

Thanks,

Tom

[djohnson229]

I don't think Azure does no - thats the problem (and why the other solutions have been provided).

[mb_equate]

I'm finding more customers in the same boat - on-prem AD will become a rarity except for maybe government and OT networks.

Our current approach is GP with AAD SSO (SAML), extracting the username from the claim. Alternative is certificates which IMO does not fit the zero-trust model. Both are clunky and require _another_ agent on the endpoint.

I am willing to lab the CIE approach as I do think it is a step in the right direction, although I don't know if we can make it as transparent as the GP approach unless the SSO experience is the same...

[mb_equate]

Looking into this further, it appears to be the captive portal that does the mapping rather than CIE - an authentication rule steers the client to the captive portal which authenticates the user (presumably via a CIE auth profile), once the user is authenticated the portal provides the mapping data as it would in any other case. In theory you could do this without CIE if you used AzureAD as your authentication source in the rule, but you'd need CIE to do the group mapping if you don't have on-prem LDAP.

I've found the documentation rather sketchy when it comes to this, e.g. this KB article states CIE does not have the functionality to learn user to IP mapping which is correct - CIE itself does not provide the mapping however the documentation suggests you run show user ip-user-mapping all after configuring CIE which wouldn't work until you have a mapping source which CIE does not provide.

The best I could find is this video https://youtu.be/_ppC2H8Ta_M?t=452 which loosely shows the auth flow to CIE via a captive portal which is a standard method for mapping users to IPs when you don't have a Windows event log source (e.g. non-domain joined / BYOD): Map IP Addresses to Usernames Using Authentication Portal (paloaltonetworks.com)

I'm yet to be convinced this is reliable method that would be transparent to users without understanding the SSO methods (which will need to be either certificate based or dependent on existing authentication tokens).

It would be great if PAN could demonstrate a working end-to-end solution for this 🙂