Presentation on theme: "UAG Authentication and Authorization- part1 By Suraj Singh, Security Support Escalation Engineer. Microsoft Security Team."— Presentation transcript:
UAG Authentication and Authorization- part1 By Suraj Singh, Security Support Escalation Engineer. Microsoft Security Team
Understanding the Authentication Process. Components of Authentication. Authorization configuration in UAG and usage. Impacts of authorization, performance angle. I have chosen to discuss few parts of different components explained here, to be discussed in subsequent parts, to reduce the length of this presentation. Agenda and scope of this part.
We will try to explore this process, from the http watch slide I added before this slide, to understand the flow, please refer to the red circled areas in the slide. 1.User enters the URL for the trunk in the browser 2.For this new session, user is presented with login.asp. 3.User enters the credentials and submits them using logon button, which is grabbed by validate.asp 4.Processing of credentials with other ASP files and UAG components(explained in the next slide) to authenticate the user. 5.User is then redirected to the original URL requested. Steps in this process
Validate.asp the server side script accepts these credentials and processes them and validate them. The validation is performed by User Manager, a service running on the UAG server. User manager communicates with the authentication servers configured for the trunk, it forwards the user credentials for validation to the authentication server and authentication server responds to this request after authentication after which it grabs this response. After successful validation PostValidate.asp is executed on UAG. This asp does post-authentication tasks e.g. changing the session status to an authenticated session. Processing of the credentials
Repository, authentication server settings. Trunk and application authentication settings. User manager service. Components of Authentication
Pictorial representation Authentication server UAG Server Client Components Repository, authentication server settings. Trunk and application authentication and authorization settings. User manager service. User on the browser, enters URL
Repository (from one of my lab UAG servers.)
Repository allows UAG to check the credentials of connecting users with authentication providers. To configure, click Add, and enter the authentication provider details. Type in the name of the server in front of Server name, which is just a name for the repository and click on Define, to configure the names of the servers. In this scenario we are using active directory server as authentication provider so we will fill in the name of the AD Server. If the UAG server is part of the domain then we can simply use the Use local AD forest authentication option. We will then get back to the Repository add page, then choose Base DN. We shall use Base DN as per our active directory requirements, keeping performance in mind. Options chosen here can have performance impact. We have the option of Include subfolders. This option allows UAG to check the permissions for a user that is logging in, it can also check if the user belongs to a group that has permissions. To do that, we must enable subfolder search, and set the appropriate nesting level. By default, it is 0, it should be set to 1 or 2 for actual folder search to happen as value of 0 does not actually do a search. Higher value can cause performance impact. Then in the server access section enter the credentials of a account(domain service account) that will interact with the authentication server to authenticate the user. In default domain section,enter the domain’s name this will be used for SSO for the published applications. Configuration and Usage
Trunk authentication settings.
We can configure trunk authentication from the Advanced Trunk Configuration window, on the Authentication tab. The option Require users to authenticate at session logon checkbox, forces a user to authenticate, in case we want to configure full pass through authenticate we need to uncheck this option. We have Select authentication servers list in the settings. Here we can assign multiple authentication servers to a single trunk, we can also change the order of repositories in the list, by using the up and down arrows. If we have more then one repository in this list, Then settings Multiple authentication server settings decide what options a user get while authenticating. We can configure these settings here so that a user can get either a list of authentication servers to choose from to authenticate or he would get an option where he has to authenticate each server in the list. Main configuration points that we will discuss
Application level authentication
This feature provides single sign on to the users, here UAG performs authentication on behalf of the user, against the backend published application server. Here We need to configure UAG to either use KCD or User credentials., Which further depends on the fact if the published application server is configured to process the Kerberos tickets or its configured to process the user credentials In case we select Use credentials for SSO option then we have to Select authentication servers from the list of authentication server. If we choose same repository as used at the time of trunk authentication then that repository will have the user credentials cached while login and they will be used during this SSO process. Another part we should look at is the way these credentials are submitted to the published application server. Simple rule is the method selected here should match the method used on the published application server. If our published server uses basic or NTLM authentication then we can choose the option 401 request method. UAG server,while performing SSO, it expects 401 response from the published application server,in the same response header it also expects to see if it’s a Basic or NTLM, Which ever method is used by the published server it uses that method to send the credentials. In case both methods are supported by the published server then it uses NTLM as its more secure. Configuration
I will discuss these two special methods in my next presentation or blog post. HTML Form and KCD
For any application published through a UAG trunk, we can decide which users can gain access to the application. We can do that using the Authorization tab of the Application Properties window, by default we have Authorize all users. We can restrict access by selectively authorizing the users and groups by first un- checking the Authorize all users setting. By doing that we get the Users and groups list and the buttons under it and the Add button. Using this Add button we can select users and groups we want to authorize specific access. Add button, gives us the Select users and Groups window on clicking it. In this new window, we have the Look in drop-down list, which has all the repositories that we have configured on the UAG server, as well as Local Groups. We can select the repository from this list as per our requirement and choose our user group in it for which we want to provide specific access. For AD repository the Users and Groups in Repositories window will be populated with user groups. We can choose different groups or users for which we want to provide specific access. We highlight the user or group in this list and then add it in the authorize list and provide specific access i.e. allow, deny or view. Explanation and usage
We know that we can authorize users and user groups to access certain type of access on applications. While doing that we need to be careful about what we are choosing for our search settings “ search root and scope “ i.e. BaseDN. As UAG’s User manager service makes search queries from that root and depending upon customer infrastructure, this search can create huge amount of data transfers between UAG and domain controller. Impacts of authorization(Repository configuration considerations)- A scenario
Issue: if we point Base DN 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. Scenario
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.
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. 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.
After seeing this, I made the include subfolder to 2 and asked customer 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 customer has set up his active directory. We redesigned active directory infrastructure little bit after detailed discussions with customer 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. 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. Action plan/workaround/solution
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 customer 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. Few ideas
Part2 will cover the parts I did not cover in part1. Few revisions of this presentation for improvisation. What next.