Presentation on UAG authentication and authorization,with a scenario discussion.
Hi folks, Uploading a presentations for UAG admins and my peers. This is to provide more information around this topic, i m pretty sure there must be documents around it already but i have tried to give my perspective to it.
I will add audio /video to it in later revisions. I am also discussing here the scenario I discussed in the presentation.
Issue: if we point BaseDN of UAG authentication repository to domain level then portal access goes very slow,you cant get logged in, its kind of unresponsive.
UAG Admin has configured user group based access on the applications published on the UAG server.
Troubleshooting
Lot of work has already happened, when this case same to me. I suggested the UAG admin, to collect network captures for 3-5 minutes, on the internal NIC of the UAG, after pointing BaseDn to root of the domain and when he starts facing the issue.
Data Analysis
- In the network captures, in the traffic between UAG and domain controllers , I saw window size advertised by the UAG server was gradually dropping, to zero for almost all the Global catalog traffic sessions,Please refer to the snapshot below.
- Another observation was , we had huge amount of this LDAP/Global catalog traffic. It appeared that lot of data transfer was happening from domain controller to UAG and that can happen, if UAG forcing domain controller to do so with its certain
way of querying. - So next thing that I wanted to see was the Repository configuration, specifically the BaseDN and include subfolders option as they can force UAG to do such queries.
- I found that the include subfolder was set to 5.
Action plan/workaround/solution
- After seeing this, I made the include subfolder to 2 and asked admin to observe.But I still saw same behavior in the network captures. So reduced the included subfolder to 0 and then unchecked that option (for testing)and then observed. That reduced the impact and problem did not come for a week .once again I looked at the traces when problem again came back. We still had similar pattern.
- Then we had detailed analysis of the way admin has set up his active directory.
- We redesigned active directory infrastructure little bit, after detailed discussions with admin, where we created a specific OU for UAG users and then added the OU, that had most of user groups in it, we also found out that these user groups were not nested user groups, users in these groups were members of other groups, but the group themselves were not nested in one another. So we also removed the check box of nested level so that searches for groups within groups is not done as that also create huge amount of queries. After that issue did not happen.
- Learning from this case was that if we reduce the search scope, we reduce amount of queries made to domain controller and also the resultant amount of data that was causing UAG to choke as we saw in the network traces.
Few ideas
- We can have more then one repositories in UAG
- We can use more then one repository on a trunk.
- We can use different repositories and the user groups in them to authorize users on applications on a trunk.
- Using these ideas , if we run into a performance issue where admin has a huge AD infrastructure and they have performance issues (due to huge queries and query responses by domain controller)if they use root of the domain for search in BaseDN, we
can suggest a way that would reduce the scope of search of queries by pointing to a OU that’s related to the UAG access.