GetUserNameEX Generates a 1212 Error Code When It Is Called from an Impersonation Thread (280766)
The information in this article applies to:
- Microsoft Windows 2000 Server SP1
- Microsoft Windows 2000 Server SP2
- Microsoft Windows 2000 Advanced Server SP1
- Microsoft Windows 2000 Advanced Server SP2
- Microsoft Windows 2000 Professional SP1
- Microsoft Windows 2000 Professional SP2
This article was previously published under Q280766 SYMPTOMS
When GetUserNameEx is used to make an SSL call to a Microsoft Internet Information Server-based server, you may receive a 1212 error code that is translated to:
The format of the specified domain name is invalid.
When an ADSGetObject Active Directory Service call is made, it may generate the following 0x80005000 error:
E_ADS_BAD_PATHNAME
CAUSEAdsGetObject does not work because of delegation. The call goes as anonymous during communication to the domain controller (DC). Because of this, during the search for a Fully Qualified Domain Name (FQDN), the server returned success with no entries.
The client uses schannel certificate mapping to authenticate to the server that is running Internet Information Server (IIS). Schannel builds a token that cannot be delegated on the IIS server (SSL/TLS is a non-delegatable protocol), and schannel uses pass through and sends only certificates and names.
The IIS server impersonates the client token, and makes an ADSI call to the DC. Negotiation routes to NTLM because no Kerberos credentials exist, and NTLM drops to anonymous because no primary credentials exist.
RESOLUTIONTo resolve this problem, obtain the latest service pack for Windows 2000. For additional information, click the following article number to view the article in the
Microsoft Knowledge Base:
260910 How to Obtain the Latest Windows 2000 Service Pack
The English version of this fix should have the following file attributes or later:
Date Time Version Size File name
-----------------------------------------------------------------
6/13/2001 05:32p 5.0.2195.3738 501,520 Lsasrv.dll (56-bit)
6/13/2001 05:51p 5.0.2195.3649 130,320 Adsldpc.dll
6/13/2001 05:51p 5.0.2195.3737 355,088 Advapi32.dll
6/13/2001 05:47p 5.0.2195.3738 519,440 Instlsa5.dll
6/13/2001 05:51p 5.0.2195.3738 142,608 Kdcsvc.dll
6/13/2001 05:43p 5.0.2195.3738 209,008 Kerberos.dll
5/29/2001 09:26a 5.0.2195.3649 69,456 Ksecdd.sys
6/13/2001 05:32p 5.0.2195.3738 501,520 Lsasrv.dll
6/13/2001 05:32p 5.0.2195.3738 33,552 Lsass.exe
6/13/2001 05:31p 5.0.2195.3738 112,128 Msv1_0.dll
6/13/2001 05:51p 5.0.2195.3727 909,072 Ntdsa.dll
6/13/2001 05:51p 5.0.2195.3678 382,736 Samsrv.dll
5/29/2001 09:53a 5.0.2195.3649 128,784 Scecli.dll
5/30/2001 02:19a 5.0.2195.3649 299,792 Scesrv.dll
6/13/2001 05:51p 5.0.2195.3738 46,864 Secur32.dll
6/13/2001 05:51p 5.0.2195.3649 123,664 Wldap32.dll
WORKAROUND
To try to work around this problem, use any of the following methods.
- Use RevertToSelf before you make the call to the DC, restore the original token after the call, and then run IIS under a domain user account that has access to the objects in question.
- Adjust the ACLs on the appropriate objects to grant everyone the minimum-needed access (read).
- Run IIS on the DC. This works because it effectively avoids the second authentication process.
STATUSMicrosoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Windows 2000 Service Pack 3.
Modification Type: | Minor | Last Reviewed: | 9/26/2005 |
---|
Keywords: | kbHotfixServer kbQFE kbbug kbenv kberrmsg kbfix kbSecurity kbWin2000PreSP3Fix kbWin2000sp3fix KB280766 |
---|
|