User identification (AD)

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

User identification (AD)

L3 Networker

Dears,

We have PA2020 implemented (w/ HA) and sometimes the user identification doesn't work well.

In the picture below we can see the following scenario

ScreenShot340.jpg

1st line - PA2020 doesn’t relates my IP w/ my user and I got blocked accessing youtube.com (rule “Block R Sociais, Videos, Audio”)

2nd line - PA2020 doesn’t relates my IP w/ my user so I could only access because of last “Allow All” (rule Permite Tudo)

3rd line - PA2020 doesn’t relates my IP w/ my user so I could only access because of last “Allow All” (rule Permite Tudo)

4th line - PA2020 recognizes my IP and relates with my user “Fabio.garcia” then I could access thru rule “Permit - Grupo TI”

Those events happend in a very short time slot... around 40 seconds....

Why PA sometimes regnizes my user, sometimes it doesnt ?

I am using 60 seconds for the update interval to identify users with my agent (AD)

ScreenShot342.jpg

Thanks in advance!!

15 REPLIES 15

L0 Member

Your timeout of 60 seconds seems really short.  This may not be enough time to read all of the users in your AD structure.  Try setting this to at least an hour and see if the problem resolves itself.

Hello, I did the change but I am still facing the problem...

Right now I am being blocked because PA cannot recognize my AD user (which is part of an allowed group)

The image below shows PA identifying my user and soon after that... I was not recognized...

I got blocked, then allowed... then blocked...

I was wondering, if the problem is related to PA reads the AD user list, PA should be able or not ... but that behavior doesnt follow a pattern... I mean... in a very short time window, I was recognized, then not recognized...

That looks like for some packets PA can recognize my AD user, but another packets PA cant do that... is that make any sense ?

Logs

ScreenShot349.jpg

Please check the 2 lines at the bottom... it was 2 seconds time window.... and 2 different behaviors....

Thanks in advance!!

L3 Networker

Guys, look the screen shot below...

Right now, this IP address below should be blocked, but as my PA cannot resolve that IP to the user... he can access internet easily ...

I would like to thank you guys for all help I am receiving... but to be honest that has been very frustrating specially to our directors that spent a lot of money with this tool and that is not working... even PA support cant help me with this problem...

Anyway, thanks again all help you guys are giving me these last weeks!!

ScreenShot352.jpg

Hi Fabio,

There were several User-ID and group mapping issues fixed in 4.1.9 and 4.1.10, are you on those versions or something older? In some cases, group mappings were being eliminated when making changes on the firewall or on the AD server, in others there is a timer being used to poll group changes.

Some commands you can issue in the CLI that can help pin down the issue when you are experiencing it:

> show user group-mapping state all

> show user group list

> show user user-IDs

> show user ip-user-mapping detail yes

Those commands can give you a list of your user IDs and the group mappings associated with them. You also may want to check to see the timeout and logs on your User-ID Agent. Make sure that User-ID is able to read the security logs on your DC. If it cannot, and it uses WMI or NetBIOS probing, sometimes those can be unreliable.

You also indicated that 193.242.41.103 can access the web. The "ALLOW WEB TRAFFIC" rule is letting it through. Check that rule, you will probably find that it is allowing outbound traffic without checking for user names.

Lastly, you mentioned that support could not help with the problem. If you have an active support contract I would encourage you to open a ticket. It sounds like this would be worth investigating if you are on a recent release.

Best,

Greg Wesson

Hi Greg,

Thanks for the feedback, actually after changing some parameters the agent looks fine now.

Changes performed:

- Upgrade PAN OS to 4.1.10

- In devices > user identification > group mapping settings I changed the update interval to 300

- In the agent config, added 2 more DC in the same network segment (total of 4, 2 of them win2003 and other 2 win2008)

- In the agent config, changed user identification timeout to 5 minutes

Looks like the problem is solved right now.

We are planning to put PA definitely later today.

Again, thank you very very much for your help and patience!!

Fabio

L3 Networker

Dears,

Thats happening again... Smiley Sad

In a one minute window interval, PA could resolve and could not !!!

Screens below from monitor > traffic > "click at detailed log"

Here I am being recognized and getting a permission... rule "permit - grupo ti" consider only 4 users ( I am in that group with special permissions)

ScreenShot353.jpg

Then 50 seconds after, I am denied to access a file sharing website.... because PA cannot recognize my username anymore... so it treats me as default users...
ScreenShot352.jpg

Any suggestion ?

Not applicable

Hi,

we are having the same issue with version 4.1.9 and user agent 4.1.6-5.

Trying to use Captive Portal like a workaround and waiting for a solution.

Regards

We are upgrading to 4.1.10 tonight due to some pretty big bugs in 4.1.9 relating to user-id.

L3 Networker

Dears,

That problem seems to be related to different WIN servers here.

Right now my agent is connected to 4 DCs... 2 of them are 2003 and other 2 are 2008... Looks like user in authenticated in 2003 DCs are OK but users autheticated with 2008 face problems...

And I got some problems since the beggining to give the proper group membership to that user... rught now my pangent user is domain admin which is not a bets practices... We are planning to deploy version 5.0.1 upgrade next week which is not using any agent anymore.

Anyway thanks for all help.

Will keep everybody posted after the upgrade.

Hi,

I'm having exactly the same problem with a customer.  PA-2020 standalone, PanOS 5.0.1.  Most traffic is 'tagged' correctly, sometimes it isn't.  We did not experience this issue on the previous software version, which was 4.1.6.

I implemented PAN Agent only, User-ID Agent 5.0.1-2 only, and combination of both, but the issue always remains.  I also have a quite aggressive group mapping interval, I'll try lowering it to 5 minutes, but doesn't look from your experience that that solves the issue.

I have a case open with support for this, but so far not much luck ...

Frederic

Hello,

After upgrading to version 5, are you still using agent installed in a DC ?

I hired a local consultancy and they said my problem would be related to different DCs in my environment.

I have DCs 2003 and DCs 2008. So my agent have different profiles concerning the rights to access to logs... Event log reader doesnt show up in some DCs.... etc etc..

As a temporary solution we configured agent user as domain admin which is not a best practicies. Next week my local consultancy will start to work and if I got a real solution for that I will post here... dont worry.

anyway, thanks in advance for your message.

lets keep in touch!

We have 2 domain controllers in 1 domain, same subnet, both Windows 2008, nothing fancy.  I tried the 3 options: only the User-ID Agent, only the PAN Agent, both combined.  Always the same issue.

L1 Bithead

All.

I would like to comment on this discussion. Since we are all using the User Identification Agent on a remote box, one thing to check would be the LOGONSERVER for your username by running the SET command in a command prompt window. That LOGONSERVER is managing the security events for your username and if the User Identification Agent on the remote machine does not have the same LOGONSERVER IP Address in the configuration, then it won't be looking at the right server for your security events.

I was just about to update our UIA software before being told to look at this from PAN Support. Our UIA software is still on version 3.1.4. After double-checking the IP Address of the LOGONSERVER and making sure that it was inserted into the Domain Controller section, my user-ip-mapping was successful.

Hope all is fixed for you.

essilorbr wrote:

Hello,

After upgrading to version 5, are you still using agent installed in a DC ?

I hired a local consultancy and they said my problem would be related to different DCs in my environment.

I have DCs 2003 and DCs 2008. So my agent have different profiles concerning the rights to access to logs... Event log reader doesnt show up in some DCs.... etc etc..

As a temporary solution we configured agent user as domain admin which is not a best practicies. Next week my local consultancy will start to work and if I got a real solution for that I will post here... dont worry.

anyway, thanks in advance for your message.

lets keep in touch!

From memory, there is some difference in the security rights required to read/audit the security logs between a Windows 2003 domain controller and a Windows 2008 domain controller.

You'll need to modify those permissions LOCALLY on the Windows 2008 domain controller, especially if your domain functional mode is lower than 2008 native - a domain policy won't work.

I'm working from a really faint memory, so I can't recall the exact differences - but I know I ran into them at some point.

Check the security policy on the Windows 2008 domain controller, and make sure your user agent account has rights to "Manage Auditing and Security Log"

  • 7966 Views
  • 15 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!