Dual NIC - IP Mapping Issue

[Brandon_Wertz]

This appears to happen at random to a random subset of users.

Environment:

> 160 AD DCs

4x UIAs (2 - 80 DCs / 2 - other 80 DCs)

Assume:

All possible DCs that a user would authenticate to are being monitored by the agents.

Scenario:

When users with laptops come into work in the morning, dock and start their computer up.  Their computers (Win7) have both a wired and wireless connection.  Users while docked log into the domain for the first time.  Once they've logged in they open up a web browsers and are presented with the Palo authentication pop-up.

I look through the UIA logs and the agents see the wired IP to user mapping but no wireless IP mapping.  I have the user turn their wireless off, re-open their browser and the auth pop-up doesn't happen.  I have them turn wireless back on, un-dock, log-off, then log back in via only their wireless connection.  They successfully log in, open a web browser and do not get the authentication pop-up box.

Can anyone explain why the PC/DC wouldn't log both IP/users IDs?  Also of note this doesn't happen to everyone just to random people, some more frequently that others.  Is there some setting within the AD environment that needs to be set?

[VinceM]

Hi,

IP to user mapping is based on security logs then if session is opened through the wire, user is linked to the wired IP.

After that, you will need to configure WMI. With WMI, palo will make some request (a lot :-() for trying to see if something change on knwon laptop.

Or you can try to configure captiv portal with NTLM authentification (if your users are windows based.

V.

[Brandon_Wertz]

I had WMI enabled previously, but had a bunch of error logs.  I don't remember specifically but was told from TAC/SE to not WMI, so that's been disabled.  I've gone ahead and enabled it on 2 of the 4.  We'll see what happens there.

We've got NTLM/CP enabled but we're doing CP in transparent mode so we should never actually see a true CP auth.

Hopefully the WMI query fixes the pop-ups.

[Brandon_Wertz]

So with WMI on it doesn't appear to resolve the auth pop-up issue.

[Adam_Karol]

Can anyone explain why the PC/DC wouldn't log both IP/users IDs?  Also of note this doesn't happen to everyone just to random people, some more frequently that others.  Is there some setting within the AD environment that needs to be set?

---

I'm having the same problem. We've got a cisco controller using enterprise authentication via RADIUS aganist our DC's. When I look at the DC security logs for the wireless users I can see that there is no source IP in the log, like there is from a wired user. I'm thinking that's the problem.

So I assume I'm either going to have to figure out to get the controller to pass along the IP with the RADIUS auth (if that's even possible) or configure the controller to send login events via syslog to the agent directly. 

I'll be interested to hear if you get that working! 

[Brandon_Wertz]

Not sure who marked this as a solution, but it's not.  (As evident by my posts indicating so)

[glastra1]

Could be a lot of things:

You need to check if their logins are generating security logs in the AD monitored servers*. Also make sure you're monitoring all your AD servers,  verify network connectivity between the wireless networks and your AD servers. If you're using DHCP in your AP make sure you're sending the correct DNS server and domain name (If the machines can't locate any AD they'll use they local cached password).

Workarounds:

If your wireless AP is authenticating users you can try to configured it as a syslong sender

And you can also deploy global protect to auth internal users using internal gateway (without an extra license starting from PANOS 7.0)

Also it's recommended to enable the 'redirect' mode in the CP, so if you're in vWire you can use a loopback interface.

*The Agent looks for any of the following Microsoft event IDs:
On Windows 2003 DCs:
• 540 (Network Log On)
• 672 (Authentication Ticket Granted, which occurs on the logon moment),
• 673 (Service Ticket Granted)
• 674 (Ticket Granted Renewed which may happen several times during the logon
session)

On Windows 2008 DCs:

4624 (Account Log On)
• 4768 (Authentication Ticket Granted)
• 4769 (Service Ticket Granted)
• 4770 (Ticket Granted Renewed)

Regards,

Gerardo

[Hithead]

we also had some experience with that.

Clients were connected on both networks and the client was sending kerberos tickets with the wrong ip but using the other interface for traffic. To solve that issue we set our laptops to disable WLAN when connected to wire/docking station.

[Brandon_Wertz]

One of our desktop guys suggested this as well.  Though this doesn't actually solve the problem it might be a solution.  One thing I can't quite think through is how would it solve the problem?  Wouldn't the client still get the auth pop-up, since they're merely undocking and not actually generating the required DC event IDs?

[Hithead]

the thing is:

the user id agent is reading kerberos(authentication) tickets logs on the DC/AD generated by every client. If the client has two NICs connected, it could happen (as explained) that the generated kerberos ticket includes the wrong IP of the client. But the client is using the other NIC for commuication --> Fail, because the user is unknown for the PA.

If only one NIC is connected, the client is sending just kerberos(authentication) tickets of this IP. So the User-ID will get for sure the correct IP-User mapping.

Just try it out.

[Lucky]

Hi guys,

FWITW - my two cents: what UserID Agent sees, it will send to the firewall. If you see consistency between UIA and ip-to-user mappings on the firewall, than it is working as expected. To check this, go to the UserID Agent and find username in "monitoring" tab, than check for the same user by looking in firewall for "show user ip-user-mapping all | match username" and "show user ip-user-mapping-mp all | match username"

Any user can be mapped to multiple IP addresses as in any environment, that is not an issue. If you don't have mappings, review your AD logs, find logon events in AD for wireless user and see if they do contain IP address. If there is networking problem with setup etc, test only on wifi and see what happens - follow user by IP address through Monitor and figure out how come it is going through un-authorized. You can also impose rule that allows only known users from wifi zone, so they will have to authenticate.

I usually saw problems not consistent with group of users, when they are up to the mapping from big forest, and 9 out of 10 times it will be due to one or few servers in the whole AD forest that are either not in sync with clock so they provide wrong logs or are mis-syncing info from other ADs for other reasons. But such problems usually do not target single group or zone of users, they are more consistent across the whole domain.

To me, this sounds much more like networking setup and authentication issue rather than UserID problem....not convinced yet that it is UIA problem. If it was random users from different networks I could buy UserID problem, but consistent failure for wifi users smells much more like misconfiguration. You can always open a TAC case, problem should be cought in one-two GTMs for sure.

Regards

Luciano

[Brandon_Wertz]

I don't believe this is a UIA problem at all.  I think the architecture is correct.

I don't think it's a "Network problem" as I get the mapping when singly connected, but only when and only sometimes when using a wired and wireless connection at the same time is there an issue with the mapping to both IPs.

This is what's leading me to think it's a windows issue and nothing what-so-ever with anything Palo or network related.  I've got a ticket opened with M$ enterprise support.  So we'll see what they say.

[Lucky]

I think you got it in the right direction. For test, try to pull put information for the same problematic user from as many AD servers as you can and compare information - if there is discrepancy in one or few, those are your points to start investigation at. I am not sure how to do the batch job of polling logs from plenty of AD machines at the same time but google will probably know 🙂

I would still check info from UIA and firewalls, just to be sure, doesn't take too long and helps to better understand architecture of PAN.

[Brandon_Wertz]

I think I found the issue...I'm still waiting for a group policy change to propgate through my enviornment of >35k users, but I think this was the source of my problem:

The primary form of UIA attribution is from AD logs of some sort (passive)

The second form of authentication is UIA NTLM browser credential request (active – behind the sceens)

The third form is direct Captive Portal NTLM prompt (Active - if Transparent) or web page redirect (Active - if on Redirect mode).

The issue was with the second form it was basically non-existent for these reasons:

http://clintboessen.blogspot.com.au/2013/09/ie-10-prompting-for-credentials-windows.html

https://support.microsoft.com/en-us/kb/943280

As most of my users use laptops with an active wired and wireless Ethernet adapter their PCs have two IPs.  Given the passive attribution only works for a single given adapter the second browser NTLM credential request is really important to us to prevent a user pop-up.  This brings us to our issue.

The Windows environment sees Web requests coming from fully qualified domains as “Internet” sourced domains and as such does not pass credentials to those web pages unless specifically told to do so.  So in our case the Palo Alto internal VIP performing a NTLM credential request to a host browser isn’t working.

A necessary modification to the Windows environment is described in the above two URLs.  Adding the source of the NTLM request enables the windows client to successfully pass credentials to the firewall which allows the second non-intrusive form of authentication to be completed.