User-ID Agent identifies local PC users so captive portal never kicks in?

[networkadmin]

I upgraded our PAN from 4.1.x to 5.0.10 and also upgraded the User-ID agent from 3.x to the latest 5.x.

We have some rules configured with groups specified and we have captive portal in place and what used to happen was if you came along on a domain joined laptop but were logged on as a local account (so LAPTOPNAME\LocalAccount) you'd get the portal and would have to authenticate using a domain account (standard Kerberos auth against the DCs).

What's happening now is that the request is blocked because it's hitting the last whitelist rule which blocks all URL Categories other than the allow whitelist.

The block page is showing the user as LAPTOPNAME\LocalAccount so the firewall must be picking up the local logon name from the User-ID agent - looking at the mapping list on the User-ID agent on the DCs confirms this.

So I'm assuming we don't get the captive portal because the user is always known so the portal never needs to kick in?

How can I make it so that the firewall won't see any usernames other than DOMAIN\Username from the User-ID agent please, so that in the situation above the portal would kick in like it used to?

I've looked everywhere I can think of and I'm drawing a blank.

[HULK]

Related discussions:

password

Re: Captive Portal to Internal Servers

Thanks

[networkadmin]

Thanks, but I don't see anything in those that leaps out as being applicable here?

We're not even seeing the portal - the PAN seems to assume the username is "LOCALPC\localaccount" so simply blocks access because it doesn't match any rule.

[sraghunandan]

Following docs will help:-

https://live.paloaltonetworks.com/message/20368#20368

https://live.paloaltonetworks.com/docs/DOC-3629

[networkadmin]

It looks similar to the second issue.  We have a standard AD though at 2003 Functional Level - nothing unusual or custom so this seems bizarre behaviour.