INFO: Difficulties Using Net APIs in ISAPI and ASP COM Objects

ID: Q217144


The information in this article applies to:
  • Microsoft Internet Information Server versions 3.0, 4.0


SUMMARY

Network APIs (such as NetUserAdd) may fail with the error 86 when called from an ISAPI Extension DLL or COM object instantiated on an Active Server Pages (ASP) page.

The specified network password is not correct


MORE INFORMATION

W3SVC (Inetinfo.exe) runs under the Local System security context. ASP COM objects and ISAPI DLLs are loaded in the thread that impersonates either the IUSR_machinename user for anonymous requests, or the user whose credentials were submitted with the HTTP request. For OOP applications, the surrogate process, Mtx.exe, runs under the IWAM_machinename. However, individual threads still impersonate the IUSR_machinename, or the user whose credentials were submitted with the HTTP request.

If a thread runs in the security context of the user (say, user JoeB) who has administrator or account operator permission in the domain, then it's possible to call Net API, such as NetUserAdd, from an ISAPI extension DLL or from a COM object created in an ASP page.

When network APIs are called the first time after Internet Information Server (IIS) is started, an authenticated named pipe is opened to the SAM database on the Primary Domain Controller in the security context of the authenticated user JoeB. You can see the pipe in the list of open files and pipes opened on the PDC by issuing the "net files" command. The pipe will be displayed as \PIPE\samr on the PDC machine.

For performance reasons the Windows NT operating system holds this named pipe open as long as the IIS process (Inetinfo.exe) is running. This poses a problem when subsequent requests submitted in the security context of a different user (say, JaneB) call the Network APIs again. The user JaneB cannot access a named pipe open for user JoeB. Therefore, NetUserAdd will fail as mentioned for the user JaneB.

Workarounds

The following are workarounds for this problem.
  • Use the workaround suggested in Q155601 INFO: Understanding SAM Active Contexts Under Windows NT.


  • Create a custom IIS authentication filter (similar to AuthFilt from the IIS SDK. Such a filter can map requests from different users to the security context of a single user. Therefore the ISAPI or COM object will always be invoked in the security context of the same user.


  • In an ISAPI or COM object, use impersonation code similar to the code below so that calls always occur in the same security context. Be aware that the security context that the code is running in must have "Act as Part of the Operating System" privileges to successfully call LogonUser.

    
       // Get current security token 
       hToken1 = OpenThreadToken(GetCurrentThread(),
                                 TOKEN_READ | OKEN_IMPERSONATE,
                                 TRUE,...);
    
       hToken2 = LogonUser();   // Obtain security token
                                // for some user
       ImpersonateLoggedOnUser(hToken2, ...);
       NetUserAdd();  // At this point NetAPI is alway called
                      // in the same security context
       ImpersonateLoggedOnUser(hToken1, ...);
       CloseHandle (hToken1);
       CloseHandle (hToken2);
       ... 



REFERENCES

For more information, see the following articles in the Microsoft Knowledge Base:

Q155601 Understanding SAM Active Contexts Under Windows NT
Q158229 Security Ramifications for IIS Applications
Q172925 Security Issues with Objects in ASP and ISAPI Extensions
Q207671 Accessing Network Files from IIS Applications

Win32 Platform SDK documentation

© Microsoft Corporation 1999, All Rights Reserved.
Contributions by Leon Braginski, Microsoft Corporation

Additional query words: Net 86 \pipe\samr

Keywords :
Version : winnt:3.0,4.0
Platform : winnt
Issue type : kbinfo


Last Reviewed: October 20, 1999
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.