What happens when session timeout of 720 minutes ends in Identity Awareness

[Gareth_Kik]

I have integrated our gateway to corporate AD. I'm reading materials about it and cannot find one thing.

I see there is an option of 'Session Timeout' where default time value is 720 minutes. Our corporate policy is not forcing users to logout / shutdown PC after leaving working place.

I tested what happen after timeout 12 hours and I saw in logs this message: 'This is a reauthentication for session event ID*****'. Identity Awareness successfully made user update and employer was able to continue internet access next day without logout / login / restart.

My question: what is the background process between security gateway and AD when this value (720 minutes) ends and during all this time user has not made any logout. 

Is security gateway communicating directly to LDAP and requesting information if this User ID is still signed-in? Maybe LDAP is sending after 720 minutes an update to security gateway?

[Daniel_Taney]

The PDP (Policy Decision Point - Process that collects and shares Identities) and PEP (Policy Enforcement Point - process that enforces network access restrictions) processes on the Gateway handle processing sign-on / sign-off events. Depending on your configuration, a Gateway could be both a PDP and a PEP. Or, if you have multiple Gateways, you may want to assign one the PDP role and have other Gateways share identity information from it. In this distributed model, the other Gateways collecting identity data would only utilize the PEP process.

If you are using AD query, the PDP is monitoring Active Directory logs for Logon / Logoff events for each user in your environment. When the PDP sees these actions, the Identity Awareness "tables" are updated and identities inside Identity Awareness are either created or revoked. 

The tricky thing about AD query as the sole authentication method is that users could stay logged in on systems for long periods of time without creating Logon/Logoff events. Or, alternately, they could generate lots of events that could keep refreshing that 720 minute keep-alive. For example, locking and unlocking your workstation triggers such an event. Accessing a remote File Share mapped with their AD credentials also creates a logon event. So, depending on user's habits, you may have some users who never time out because they are constantly locking and unlocking their machine in that 12 hour window. AD / LDAP itself won't send an event after 720 minutes to log the user's Identity Awareness session off. 

I had this kind of issue with users who frequently moved between our 3 buildings and Wi-Fi; which all use different IP Subnets. They would disconnect / reconnect to a different LAN without ever creating an AD Logon or Logoff event and the PDP's User Table wouldn't have the right IP for that user and their access would break. I would usually tell them to lock/unlock the machine, or open a File Share to restore their access.... enter the IA Agent!

If you are experiencing unpredictable results using AD Query, you may want to consider deploying the IA Agent. It is very lightweight and transparent to the user, but it is capable of providing more up-to-the-minute Identity information to the PDP about the machines and users connected to your network. The Agent can be configured to phone-home at a tighter interval to keep your user tables more current. You can also make the agent "time-out" at a shorter interval. If you are using the SSO option (highly recommended), this re-auth will happen completely transparently to the user. But, it will verify their machine is still logged on and being used.

Their are also fantastic command line tools to help troubleshoot IA issues. You can run commands against the pdp or pep processes to see the state of things. For example, pep show user query usr <username> is a staple when you need to troubleshoot a single user.

Hope this helps!

[Gareth_Kik]

Daniel Taney‌

At this moment I use AD query only. When my user locked PC and leave the working station for next business day what happens?

PC (User) is inactive (there should not be generated any activity log in AD, correct?) and at the same time default 720 minutes are gone - What now? I mean, next day when user unlocks PC why he still have an access to internet. Strange is that in logs I see during the night hours reauthentication logs for this user was made by IA blade.

Question is, if user locked PC and it was passive during all 720 minutes, why it makes reauthentication? What kind of events are receiving security gateway and how it decides to grant additional 720 minute before session ending? 

[Daniel_Taney]

I don't know for sure if something as simple as leaving a document open that keeps auto-saving back to a file server on the network would cause this? I'd lean towards it might be possible since I found the simple act of opening a file share in Explorer would cause an authentication action.

[Johannes_Schoen]

you can check on your DCs if one of the event ids from sk60501  are generated by the client.

If this is the case, the log entry tells you, e.g. that the user had a network share mounted, which did a kerberos reauth or similar (SSO web applications?).

[Aaron_Pritchar1]

Hey,

I have installed and tested a reasonably complex AD Query install, using layers of nested groups within Access Roles, while also pulling identities from several AD Domains and there are some interesting behaviour points.
The info Daniel Taney‌ just provided is good.

Other things to note -
the #pdp and #pep command strings are invaluable. particulay the 'revoke_ip' as i had issues with 'stale' entries.

(cmd.exe) from a widows machine, run 'echo %logonserver%' to see what DC they are authenticated against.

after trying to tune the default timeout as low as 30min (from 720) this caused large 'disconnect' issues, where tables and user activity wasnt updated in due time. This could have been resolved by using Agents or Collectors, but for AD Query in a large envirnoment 360 was about as low as we felt acceptable.

these tables on the gateway are also great for when you have AD cache entries issues (values here should match. we had issues and required a specific hotfix)

fw tab -t pdp_ip -s

fw tab -t pdp_super_sessions -s

[Daniel_Taney]

Also, just for additional clarity, we opted to go with both options. Once electing to deploy the agents, we still kept AD query running. If you have users that move around a lot, the agent is invaluable. If your users are mostly desktop-based, it may be just as useful to tune your AD Query like Aaron mentioned above. 

Another good command to keep in mind is pdp update all if you have issues were things don't seem to be properly in sync. I've had to use this when a user gets added to an AD group that is used in IA Access Roles and needs access right away.