- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-25-2020 09:32 PM
Hi,
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 user.name@domain.local 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 user.name@domain.local . 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 user.name@domain.local
Thanks.
02-25-2020 11:17 PM
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
02-26-2020 03:46 PM
@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.
Thanks.
02-29-2020 07:05 PM
Just wondering if this document would help.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClpsCAC
Kavi
03-01-2020 07:58 PM
@kgopichand- Thanks for sharing this post but I have already followed this guide and it sadly did not fix the issue.
Thanks,
03-02-2020 09:32 AM
Regards
Kavi
03-02-2020 05:24 PM
@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?
Thanks,
03-03-2020 03:03 AM - edited 03-03-2020 04:35 AM
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.
03-03-2020 05:30 AM
ust to be sure, your 'user domain' is set to the NetBIOS name, right? (domain, not domain.com)
03-08-2020 07:47 PM
@Mick_Ball
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 user.name@domain.local & 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?
03-08-2020 07:49 PM
@panwreaper - Correct, it is set to NetBIOS. I have set the domain to 'domain' not 'domain.local'
Thanks,
03-08-2020 11:11 PM
The userid agent is supposed to simply pick up logs
Is it possible that it is either reading 2 different sources, or the eventlog is getting populated by 2 processes that write the username differently?
One workaround would be to set up thebignire_user_list.txt and exclude either domain\* or *@domain, but it would be better if you figure out why the userid agent is seeing both and suppress one source
03-08-2020 11:17 PM
I think there is something to what you are saying, however I will look into it tomorrow with a colleague. I have deployed User-ID in other environments before and not had this issue, there is something peculiar with this AD setup I am thinking.
The ignore text file which you meantion here, I have not seen a guide mention it, apologies if I have missed this though. Is this a file that should exist on the User-ID agent servers?
Thanks,
03-08-2020 11:22 PM
The file doesn't exist, you need to create it
This is a bit of tribal knowledge 😉 but it's described here https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClklCAC
03-09-2020 12:20 AM
Hey mate, looks like this has really started to filter out the @domain SAM log entries. I will let this run over night and for some of the day tomorrow then begin testing some rules to see how it goes now with this filter and then let you know if this has solved it.
Really appreciate the help!
Thanks,
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!