Default session vs privileged session vs privileged endpoint

Two terms that often confuse UAG and IAG customers are Privileged Session and Privileged Endpoint. What those actually mean, and how do they differ? And what’s the difference between a default session and a privileged one? Well, here I am, with answers.

To put it simply, a privileged session is a session that was initiated by an endpoint that has met the Privileged Endpoint policy, and therefore receives special treatment. This is useful in a situation where an organization considers users to be at a certain level of risk (or to BE a certain level of threat), but under certain circumstances to be at a lower level of risk/threat. For example, an organization’s users may be using public computers, such as internet kiosks, but some of them are using laptops provided by the workplace. A public computer can be very risky for an organization, if it is used for remote access. It has a high chance of containing viruses or spyware (compared to a private computer), and can be accessed by virtually anyone – the next user, the kiosk owner etc. An organization can reduce its security exposure by detecting that their users are using a public computer, and treating it with higher prejudice than a private computer (or, from a different perspective, treat a private computer as a lesser security exposure, and giving it a break).

The way this works is by the administrator assigning a certain policy for the trunk (on the Endpoint Access Settings tab), and then configuring different settings for endpoints that meet it (on the Session tab):

The tricky parts are deciding which endpoints would be considered “privileged”, and how to detect them reliably. You might decide, for example, that only company computers should be treated as privileged, and everything else as regular endpoints. Another popular differentiator is the security software in use – computers that have a certain Anti Virus product would be considered OK, and all the rest as higher-risk. As you know, the endpoint policy mechanism in IAG and UAG is extremely clever and flexible, and you can check many things for this determination. You can even write a custom detection script to look for a registry key on the client computer, or a certain file.

One thing that concerns some administrator is how reliable are these checks. Would an attacker that is familiar with your organizations policy be able to fake it? Unfortunately, most of the things detected by the UAG/IAG client components are possible to fake, and so this indeed needs to be carefully considered. One thing that is virtually impossible to forge is a computer certificate, and so I strongly recommend employing that (“Use certified endpoints”), but I won’t get into that now. One important thing to keep in mind is that the default privileged endpoint policy that comes with UAG and IAG is just set to “false”, and does not check anything. This means that it cannot be used as-is, because no computer will ever be able to “meet” it and be considered a privileged endpoint.

Once you have defined what you consider to be the differentiators, configured your endpoint policy and selected it in the Endpoint Access Settings tab, it’s time to configure the specific settings for the privileged sessions in the Session tab. Most of these are pretty straight-forward. The inactive session timeout and the trigger logoff scheme are obvious things that make life easier. Setting the server not to delete cookies at log off can benefit users of applications that rely on cookies a lot. For example, an app that stores your last visited page in a cookie will save you some time by being able to go to that page automatically. The “not to cache” setting, if set to be unchecked, allows the user’s browser to cache the application’s files, making the application perform faster. The endpoint session cleanup component (known as the Attachment Wiper in IAG) cleans up files downloaded during the session, so having it disabled for privileged endpoints can make them perform faster when re-visiting the application later-on.

Comments

• Anonymous
  August 22, 2011
  How about an example of how you could look at a registry setting to determine that the endpoint is Privileged. I've been following multiple articles online but I've not yet been able to easily make it work.

• Anonymous
  December 21, 2011
  The comment has been removed

• Anonymous
  December 21, 2011
  Russell, this blog is not the appropriate platform for technical discussiona or troubleshooting. Please post your question in the UAG public forum on social.technet.microsoft.com/.../forefrontedgeiag. If it is not sufficient for your needs, you can ask the support engineer who worked with you on this to escalate the case to a higher resource (such as myself). Ben