Ándale! arriba! Faster logon!
A topic that comes up a lot with UAG is slowness in logging on to the UAG portal. For most users, this happens pretty fast – less than 10 seconds, but some see delays that can be as long as 2 minutes.
Since most users don’t log in to the UAG portal all the time, this kind of thing can go unnoticed, but if it does, it can be very annoying. However, you may be able to do something about it!
There are two things that happen during portal logon, which could affect the login time. The 1st is the endpoint component initialization and endpoint detection, which happens before the user reaches the portal login page. The client components contain several pieces of code that have to run, and the Endpoint detection runs a special VBScript on the endpoint, which collects various bits of information about the computer, and sends it to UAG. It’s pretty rare for this to go wrong, so it normally takes only a few seconds. One key fact to remember about this is that the endpoint components are sensitive to many things on the client, and that could affect the speed of performance. For example, verification of the portal certificate could take a while, and if the client is not Internet Explorer, then the Java VM on the computer can also have a significant effect. There are no magical solutions to a situations where endpoint components are slow, but you should start the analysis process by narrowing down the behavior to client types – check other OS platforms, various browsers and as many computers as you can, to be able to define this clearly.
The 2nd thing that can affect the speed is the authentication process. When a user logs in, UAG verifies his credentials against the selected repository, so the authentication settings have a significant effect on that. These settings are visible in the configuration of the repository, as well as in the application’s authorization settings. Here are a few settings that can affect the speed of the authentication process:
1. Authorization
The authorization settings on the applications have the most drastic effect on performance, as UAG needs to check to which applications to allow access-to. By default, applications are set to “Authorize all users”, but some organizations set this to a granular authorization mode, where they specify certain users and/or groups. The thing is that if even ONE application on the whole trunk is set to granular authorization, it will cause UAG to run a series of LDAP queries against the domain, and that takes time.
2. Networking
For UAG to be able to authenticate users, it requires full access to the domain controllers. This means that ports 53, 88, 135, 389, 445 and 3268 need to be open for both TCP and UDP between UAG and its DCs, as well as the RPC ephemeral ports from 1025-5000. If you have elected to use SSL/TLS with the DCs, than ports 636 and 3269 also need to be open (but keep 389 and 3268 open as well!). Also, routing to the DCs has to be configured correctly so that traffic coming back from the DCs can reach UAG.
3. Level of nested groups
There is a common misconception that setting this to a high level is good. While a high level is required in some situations, this is rarely the case, and we recommend setting this to a number as low as possible. 0 is ideal, and 1 is usually OK, but 2 is considered to be extreme, and anything above that would typically lead to extremely poor logon time performance, or even timeouts during logon.
4. Base DN
The Base DN controls how UAG searches for user’s permissions through AD. For most organizations, setting this to the user’s container is ideal (CN=Users, DC=Contoso, DC=com, for instance). If your domain is built differently, you may have no choice, but this setting should be one of the first to rule-out as a cause of a slow-down.
5. Connection settings (Define DC/Forest authentication)
Setting the configuration to “Use local Active Directory forest authentication” uses a different mechanism, by which UAG connects with the global catalog server for the domain to determine which DCs it has to work-with. This rarely has a noticeable negative effect on performance, but if the GCs are more remote, or busier, or there’s some networking issue with port 3268, this could cause a delay. Make sure your connection is good before using this mode.
6. Domain groups in use (universal/Global/domain local)
When checking users’ permissions, UAG queries active directory, and AD processes the various types of groups differently. This means that depending on the user’s group membership, and the domain structure, certain configurations can be slower than others. There’s no straight “recommend configuration” here…just something to keep in mind.
7. Network performance (latency, reliability, bandwidth)
When UAG communicates with AD, the connection speed has a significant effect, so it’s important to keep an eye out for that. If your DCs are at a remote site with a WAN connection, the WAN latency and bandwidth can cause issues. You might have no choice but to use the WAN, but if you do and there are problems, start with diagnosing the line quality (your ISP should be able to help). Sometimes, upgrading the link is the best thing to do to get things moving. Another thing to look at is your server’s NICs. Perhaps the NICs have been set to half-duplex, or to a speed setting that is lower than their maximum speed? It would also be a good idea to verify the NIC has the most recent drivers available, as some older drivers may have lesser performance.
8. AD Server Performance
As mentioned above, UAG queries AD as part of the logon, and the time it takes AD to response can decline if AD is busy, slow or badly configured. Sometimes, it’s just a matter of pointing UAG directly at a faster server (or one that is closer physically, as noted above), but it can also be affected if AD is in rough shape – has corruptions or unreliable sync. Tools like DCDIAG can help with troubleshooting this sort of thing, but one must be an expert at AD management before fiddling with this stuff.
9. Default domain FQDN vs short-name
If you specified a default domain for UAG, this can have an effect on the UAG query process, and also depends on the type of domain you are running (2000, 2003, 2008 etc, and if it’s a mixed mode or native for any). We recommend using the domain’s shortname, and not an FQDN, if possible.
10. DNS Name resolution
Naturally, as the authentication process relies on communications with the DC, the settings for DNS name resolution are important. One classic mistake is setting a DNS on the external NIC instead or in addition to the one set on the Internal NIC, so if that’s the situation, remove it. Also, make sure that both DNS servers configured on the internal NIC are responsive (perhaps the primary one is not accessible, and UAG is using just the secondary and this slows down everything).
11. CRL Checking
If your UAG server is not connected directly to the public internet, or access to websites from it is restricted, this could slow things down as some of UAGs component are digitally signed and require access to the public CRL of the signer (Microsoft). In this situation, the inability to access the CRL could cause the login process to halt for approximately 15 seconds. Ideally, you could help this along by provisioning access to the CRLs, or by downloading them regularly. More information is available on my friend Carsten Kinders blog here.
Having gone through all these, and optimized everything as much as you can, you might still find that login is not as fast as you would want. The bottom line is that the login process is laborious for UAG, and for Active Directory, and labor takes time. The 1st thing I mentioned above (authorization) is the easiest culprit because even if everything else is perfect, turning on granular authorization will introduce a noticeable slowdown. This is by design, and is just one of those tradeoffs we need to live with. If you require granular authorization, you’ll need to accept the fact that login takes a bit of time, and 25-35 seconds is pretty normal in this situation.
Comments
Anonymous
March 19, 2012
Hello Ben, I actually dealt with login times of about 45-60s (~9000 Users in AD, Kerberos only, the portal is not in production until now). After drilling down with your helpful blog, I was able to cut it to 30-45s. The setup is: OTP-Login via radius (Kobil-Systems), and for query of group membership we use two DCs as different servers for portal authorization. If I choose AD for login to the portal directly, everything takes just 2-3s, and query for the membership is fine. Login with radius takes the mentioned 30-45s. I tried everything to speed up the radius login, only disabling granular authorization helped until now (also just 2-3s). A query for users/groups at the application settings runs very fast, everything seems to be fine. Opening the OU with the corresponding users takes about ~15s - could this be the problem? Will there be any chance, to get the radius login with granular authorization faster significantly? With kind regards NicoAnonymous
March 20, 2012
Hello Ben, I just installed Rollup 1 for Update 1 (KB 2647899) and it works now as expected - 2-3s for login with radius-login and granaular auth to apps. Kind regards Nico