Captive Portal pop-ups for AD users

[ZEBIT]

We have a huge problem with the captive portal.

There is a connection between our PA500 and two Active Directory servers through the user-id agent.

In a day our employees (who use AD credentials on there computers) get 3 - 5 pop-ups to fill in there credentials in the captive portal in there browser. We don't have a clue why and our partner can't find any solutions.

The moment they get this captive-portal I checked through CLI that our firewall knows who is behind the IP and there we see unknown.

We have a policy that an unknown user can't access the internet without authenticating with there Active Directory account.

I hope the community van help me out.

[reaper]

Hi There

how is the AD UserID set up? are you using agents or agentless

did you enable User Identification Timeout (on the cache tab)? this will remove a mapping after x minutes, if you have this set up, you will want to increase the idle time (in an average office environment with not a lot of 'roaming' clients, a timeout of 9 hours is recommended)

is probing enabled ?

[ZEBIT]

My two AD servers have the User-Id agents installed

Where I can find that caching? Does it need to be enabled?

Where can I find probing?

Screenshot of the User-ID settings on my AD servers

[JDominguez]

Open up you agent, that on the AD server changes these settings in the "Setup"

[JDominguez]

Also do you have just one agent instance and that one agent "talks" to the secondary AD?

or do you have two seperate Agents running individually on the respective AD's and those 2 Agents talk back to the PANW fw?

[ZEBIT]

Each AD has its own agent and talks with the PAN fw.

[reaper · Accepted solution]

---

@ZEBIT wrote:

My two AD servers have the User-Id agents installed

Where I can find that caching? Does it need to be enabled?

Where can I find probing?

Screenshot of the User-ID settings on my AD servers

---

as displayed in your screenshot, your timeout is set to 45 minutes which means that the mapping is removed unless a new logon event is detected within the 45 minute timeframe

in a normal environment a user will log on in the morning and may not require another logon event for a long time, so those 45 minutes may be a little too short. Unless you have many roaming users and several access levels i'd recommend setting the timeout to 540 minutes, which is an average working day. that way your users log on in the morning and have access throughout the day. additionally you can enable probing which will verify every x minutes if a user is still logged on, and remove the mapping if the user is logged off or the IP is no longer used by the workstation

[ZEBIT]

I configured my settings like you example on the user-id agents.

It is not any problem that every ad server runs his own user-id agent and connect with the firewall?

[reaper]

for the probing to work you need to make sure your clients accept the probes, make sure the client firewalls are set to allow netbios/wmi

it is not a problem that you set up 2 agents, I would even recommend having 2 just in case one fails. You may want to consider having both agents read from both AD's so they have overlapping information, also in case one agent were to fail (so there is full redundancy), the firewall will automatically use one agent as primary and keep the second as backup

[MRosloniec]

There's some great comments here on this thread.  One additional comment I can make that I personally get value out of is the session monitoring feature.  I would suggest enabling that as well.  

Also, I am no kerberos / windows / AD authentication expert, but processing this through my mind, I would think you would want to make sure that there is a regular cadence of a client/server exchange that takes place on a shorter time interval than your User-ID timeout.  I believe this would register an authentication event on the AD server thus transparently renewing the User/IP mapping in the client.

Another thing you could try is doing NTLM authentication through Captive Portal.  I tested this a bit in my infrastructure and got mixed results in regards to transparency, but it was on older versions of PanOS so that may have been the problem.  Of my positive results in testing NTLM, the captive portal page displayed momentarily but then NTLM passed the user's credentials through and automatically mapped the users.

Lastly, if you have PKI in your environment, you could use those certs to identify users through captive portal as well.  I really like this method of doing captive portal, however the one major drawback is that there is no fail-safe or manual login option should a client fail to have the proper cert for one reason or another.  We actually floated the idea of not using the UserID agents at all, and strictly forcing Captive Portal for all users, using cert base authentication.  Unfortunately it was that lack of having a manual authentication option that forced us to pull the plug on that initiative.  It may be more sensible in a smaller organization though.  We have 25,000+ clients that connect to our network so that introduced it's own host of problems.