INFO: User Authentication Issues with ADSI WinNT Provider

ID: Q218497

The information in this article applies to:

Microsoft Active Directory Service Interfaces, versions 1.0, 2.0, 2.5

SUMMARY

The ADSI OpenDsObject method or the ADsOpenDsObject C helper function allow you to provide authentication credentials to the directory server when you open an object. There are a number of issues that you should be aware of when you use this technique with the ADSI WinNT provider.

MORE INFORMATION

The ADSI WinNT provider uses the WNetAddConnection2 API to make a connection to \\servername\IPC$ in order to establish these credentials with the remote server. This method is useful because it does not require special privileges for NT clients and it works on Windows NT, Windows 95, Windows 98 and it supports authentication across untrusted domains. Unfortunately there are several drawbacks inherent in the WNetAddConnection2 API and those are:

If any connection has already been established to the target server by any process running on the client machine, WNetAddConnection2 cannot make a new connection under any credentials other than those used for the existing connection. If you try to authenticate a new account, you will get a conflicting credentials error. If you try to authenticate the existing account, any password will work (valid or not). This is a particular problem when you are getting objects from a domain controller where many system processes establish connections to domain controllers. This is discussed further in Q183366 INFO: WNetAddConnection2 and Multiple User Credentials found in the Microsoft Knowledge Base.

If the Guest account is enabled on the target machine it is possible to pass both an invalid username and password and create a connection.

The system does not reference count connections, thus, if any process, including your ADSI client process, deletes the connection then all processes using that connection have to be written to re-establish it when they find it has been deleted.

When you are using the WinNT provider we recommend that, if at all possible, you authenticate with the target server by logging onto a domain account with appropriate credentials or using the LogonUser API (which requires elevated privileges) prior to executing your ADSI code. We also recommend that you do not use OpenDsObject to validate a user's credentials on any domain trusted by your client machine. If you need to validate credentials in this case, use the techniques outlined in Q180548 HOWTO: Validate User Credentials on Microsoft WinNT and Win95 found in the Microsoft Knowledge Base.

If you are attempting to validate accounts from untrusted domains use ADSI OpenDsObject, keeping the issues listed above in mind and understanding that you will be sending unencrypted passwords over the network. You can overcome these restrictions by running validation code as a service on at least one server in each set of untrusted domains using a SSL (or HTTPS) connection to provide encryption. Accomplish this by using a validation .asp file on an IIS server in each set of untrusted domains and connect to it over HTTPS using basic authentication. IIS authentication is discussed in Q158229 INFO: Security Ramifications for IIS Applications found in the Microsoft Knowledge Base.

REFERENCES

See Q180548 HOWTO: Validate User Credentials on Microsoft WinNT and Win95

See Q158229 INFO: Security Ramifications for IIS Applications

See Q183366 INFO: WNetAddConnection2 and Multiple User Credentials

Additional query words:

Keywords : kbADSI
Version : winnt:1.0,2.0,2.5
Platform : winnt
Issue type : kbinfo