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.
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.
I've been trying to use a download policy that checks the clients SourceIP Address to allow users from specific IP Addresses to download files from our sharepoint site.
I created a custom Detect.inc file that sucsessfully takes the requestors IP Address and puts it in a "policy session variable". In Web Monitor I can see that the value of this variable is set to the clients IP addresss whether they have the UAG client components installed or not.
The detect .inc contains
ip = GetSessionParam (g_cookie, "SourceIP")
But when I create a download policy using this variable (XsourceIP="220.127.116.11") the policy doesnt work -- it always evaluates to false- even though when I look at the Session in Web Monitor it clearly shows that XSourceIP IIS equal l to 18.104.22.168.
I worked with MS Support on this and they said that because the client components were not installed, the download policy could not see this variable , and my policy expression would evaluate to false.
My Question[s]: Would a Privileged Endpoint Policy be able to evaluate the XSourceIP variable described above even if the client does not have the UAG Client tools installed, or would it behave the same as my download policy?
How can I allow users from a specific IP/Domain to download even if they don't have the endpoint components, while keeping the endpoint component requirement for everyone else?
I've seen some references to TrustedIP.inc, I dont know what it is , but could that help my situation?
I have an important (and trusted) counterparty whose IT department won't allow them to install the endpoint components.
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).