Trusts and isolated names and logon performance

While bouncing around ideas with colleagues more intelligent than me I was reminded of a case I had with a customer 5 years ago.  The exact specifics of the problem aren’t important but the reason it became a problem are as follows:

• If a DC receives a Name2Sid query about an account that isn’t prefixed with a domain (DOMAINUSER) or contains a proper UPN suffix (user@domain.com) it will first search it’s local AD copy and then send a query to each domain it has a trust relationship with to try to resolve it.  This is also referred to as a query for an isolated username.

• If there is an issue with one or more of the trusts, you will see a delay in the response from the DC to the requesting client (up to 45 seconds per request).

• The issue can be that the trust isn’t functioning or the DC on the other side is unreachable (firewalled or just physically absent)

• Multiply this delay by the number of requests times the number of faulty trusts that you have and you have a serious delay during startup or logon or for any application making a Name2Sid request for an isolated name

So, something on the clients was making massive Name-to-Sid requests to the DC’s during logon for isolated usernames but this only became a problem when the DC’s on the other side of the 15+ trusts didn’t respond quickly.

In that case, we resolved the issue by fixing the client-side problem which was sending isolated account name requests (USER rather than DOMAINUSER). The customer also later discovered that several of his trusts were broken as well which was the catalyst for the problem to appear.

My impression was however that it would have been nice to be able to turn off this behaviour on the DC’s altogether and just assume that any request that didn’t explicitly specify a domain name should be treated as belonging to the local domain database.

At the time there was unfortunately no such method available on the Windows 2000 SP3 DC’s the customer was running.

....However, that brings me back full circle to the first point; it is now possible to turn this off via http://support.microsoft.com/default.aspx?scid=kb;EN-US;818024. 
Note that DC's still default to the old behaviour of chasing isolated names over trusts though.

To change whether lookup of isolated names is performed in external trusted domains by a DC, you can create the following on any W2k DC with SP4 SRP2 installed or any W2k3/W2k8 DC:

Under HKLMSystemCurrentControlSetControlLsa
DWORD: LsaLookupRestrictIsolatedNameLevel

• If this entry does not exist, or if the value is set to 0, lookup for isolated names is performed across external trusted domains (default behaviour)
• If this registry entry is set to 1, lookup for isolated names is not performed across external trusted domains.

In short; Consider turning this on if you have multiple trust relationships, the benefits from turning it on are increased performance while the drawbacks are potentially that a name may not be translated to a Sid.  The drawbacks can however be easily addressed by simply reconfiguring the application or service requesting it to use a proper format like DOMAINUser or UPN.

How to restrict the lookup of isolated names in external trusted domains by using the LsaLookupRestrictIsolatedNameLevel registry entry
http://support.microsoft.com/default.aspx?scid=kb;EN-US;818024

Comments

• Anonymous
  January 01, 2003
  The 32 bit and 64 bit versions of W2k3 are compiled from the same source so the registry value applies to both - the KB article shouldn't specifically mention the 32-bit version. I.e. it¨s a doc bug - the same registry value is present on the 64-bit version of W2k3...try it and you'll see :)

• Anonymous
  January 01, 2003
  If you're referring to LsaLookupRestrictIsolatedNameLevel it is the same format on all OS's post Windows 2000 SP4.

• Anonymous
  September 15, 2010
  Have you the valid parameter for 2003 64 bits server ? thanks

• Anonymous
  September 16, 2010
  the technote KB818024 just apply on 2003 32 bits os.