An issue that has been experienced by many UAG customers is a situation where the UAG portal becomes unresponsive while users try to access it externally. This can also manifest itself as a slow login.
When the user clicks on the ‘Log-on’ button on the Portal Page, to check whether the user is an Authenticated user or not UAG checks all its ‘Authentication Repository’ settings to get the Domain Controllers information and the other settings associated with them. One of those settings is the ‘Level Of Nested Group’. This setting, if not set correctly, can cause a lot of slow Log-On Issues and the UAG Portal becoming unresponsive as well.
Let me share a scenario with you, in which a customer reported a similar issue and how we fixed it.
We had an issue where the UAG Portal Page was becoming unresponsive while trying to access it externally. Restarting the UAG services would temporarily resolve it, but it would recur on subsequent logins.
The issue manifested itself as the UserMgrCom.exe process causing a CPU Spike of around 100% CPU utilization. When we checked the Authentication Repository settings in the UAG console we noticed the following setting:
As you can see in the above screenshot the value of Level of nested groups was defined as 1000. However, Ideally, this value should not be configured above 2 or 3. Group nesting relates to group authorization configured on applications on the portal. If the applications are configured to allow all users to be authorized there is no need for any nesting. On the other hand if groups are used for granular application authorization then group nesting would only be required if the group(s) selected for authorization are groups that are nested (members of) another group in Active Directory. If the groups are direct user containers and not group members, nesting is also not required. Setting the level of nesting to anything other than its default tells UAG to preform recursive queries on every group a user is a member of until the level of nesting is reached. This set of recursive query is incredibly resource and time intensive both to UAG and to the Domain controllers that are being accessed.
In this case, because it was set to such a high value of 1000, it was causing UAG to perform unnecessary checks for Group Memberships for users and this was causing the UserMgrCom.exe to Spike, and the Portal to become unresponsive.
Nitin Singh Security Support Escalation Engineer Microsoft CSS Forefront Security Edge Team
Dan Herzog Security Sr. Support Escalation Engineer Microsoft CSS Forefront Security Edge Team
Ben Ben Ari Security Sr. Support Engineer Microsoft CSS Forefront Security Edge Team
We expieranced this exact issue, although we were only set to 10. By changing to 1 we not only decreased logon time by almost 30 seconds, we also resolved the timeout issue.
Same issue here, thanks for explaining. I had the setting on 0, effectively unlimited and it was slowing login times on quite a few users!