Enhanced Security Measures in Place:   To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.

User-ID two usernames being identified by User-ID servers

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

User-ID two usernames being identified by User-ID servers

L2 Linker

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.

 

ldap_group_mapping1.pngldap_group_mapping2.png

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.

 

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com
16 REPLIES 16

Cyber Elite
Cyber Elite

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

@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.

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

@kgopichand- Thanks for sharing this post but I have already followed this guide and it sadly did not fix the issue.

 

Thanks,

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

@DanielBostock 

Ok , lets look into this further. If you want , you could open a ticket and one of us will investigate.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
One thing I noticed is the user attribute that is specified .
 
 
You specified
 "sAMaccount" . It is supposed to be "sAMAccountName".
    
 
 
 
 
 
Can you please change this entry to 
"sAMAccountName" and repeat your tests .
 
 

Second point : If you  repeat the command "show user user-attributes user all" a number of times, what attribute do you see for the "Primary user" . Do the primary user attribute always show "sAMAccountName" or does it fluctuate between "sAMAccountName" and "userPrincipalName".
 
 
 
 

 

Regards

Kavi

 

@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.

 

ldap_group_mapping3.png

 

ldap_group_mapping4.png

 

When I run the command you have suggested, I get a blank response. So maybe I am missing a configuration step somewhere?

 

Thanks,

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

@DanielBostock 

 

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.

ust to be sure, your 'user domain' is set to the NetBIOS name, right? (domain, not domain.com)

@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?

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

@panwreaper  - Correct, it is set to NetBIOS. I have set the domain to 'domain' not 'domain.local'

 

Thanks,

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

Cyber Elite
Cyber Elite

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

@reaper 


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,

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com

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

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

@reaper 

 

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,

Daniel Bostock | Senior IT Operations Engineer, EML Payments | Blog: https://danielbostock.com
  • 11355 Views
  • 16 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!