I am having troubles with getting the Palo's in my network to only use the UPN of a user in our environment. I would like to start creating security policies to control staff members access to resources based on their AD user rather than IP address and then further to that leverage groups. Long term of course the idea is to leverage AD groups to control access to resources, however I need to prove that this will work on individual users first.
It is not working currently because what I am seeing in the monitor logs is either domain\user.name or firstname.lastname@example.org and because of this whenever I make a security policy sometimes it works for the end user and then the next moment it doesn't work. It will work 100% of the time if I update the policy to domain\user.name and email@example.com . This of course is not practical and scalable.
Currently we are using 2 Palo Alto Windows Server Agents to get the access data from our AD servers. Palo Alto monitor logs are reporting back connected and the User-ID log shows the source as being either of these servers.
Here is some screenshots of our current configuration for the user & group mapping.
Are there additional settings, or things I need to be doing to resolve this and either only match on domain\user.name or firstname.lastname@example.org
if you want everything to be UPN, you'll need to set userPrincipalName in the User Object Search Filter, and in the primary Username, or set sAMAccountName in both
@reaper - Thanks for your assistance here. I have updated the settings to match this but I am still seeing the duplicate username in the monitor traffic log and user-id log. Is this still expected? If this is expected and normal, I will do some policy testing just using the UPN.
@kgopichand- Thanks for sharing this post but I have already followed this guide and it sadly did not fix the issue.
@kgopichand- Thanks for helping here Kavi appreciate it.
I would prefer to use UPN. Is this possible or for the sake of testing and working out the issue would you prefer I stick with SAM?
I adjusted my configuration to the following.
When I run the command you have suggested, I get a blank response. So maybe I am missing a configuration step somewhere?
are your user-id servers the only source of user-id... check the user-id server monitor tab to see what it is forwarding to the palo.
Edit--- check the user-id log to see where the source is for the different user ID's.
if you have more than 1 user-id source (perhaps CP or GP) then increase your user-id agent timeout to 8-12 hours because it may be that the user ID agent timeout is too soon and other auth sources are remaining.
you can also exclude the domain part of usernames in the local user id agent setup but cannot see if this can be done with the server agents.
Correct the user-id servers are the only source currently. I can confirm this when I review the User-ID monitor tab as you suggested. Further to this I can see both versions of the username coming through on both servers in the same moment.
As in email@example.com & domain\user.name exist in a log entry at the same time. The second User-ID server also records both of these duplicate usernames and does so with a Palo User-ID Monitor tab entry 1 second apart from the first server, or sometimes the other way around.
It seems the User-ID servers are determined to give the Pan-OS bother UPN and SAM.
We have not rolled out GP yet, and it is something that I am thinking from an Internal Gateway perspective to overcome the User-ID issues. However that's a bigger project as we would need to deprecate our current client to site vpn solution.
I cannot see in the User-ID agent server a way to filter either, potentially it may be worthwhile for testing not using the User-ID agent servers?
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!