Figure 2, page 123, shows the Change
PasswordEntry.asp form in action. In Figure 2, I've entered a username, current password, and new password. When I click Submit, ChangePassword1.asp executes. Figure 3 shows the results that the Response.Write statements return. If I enter an incorrect existing password, ADSI notifies me that the password isn't correct, as Figure 4 shows. ADSI won't let users without the proper credentials change their passwords.
When you use ADSI or any other technique to change a user's password through a Web interface, you need to set up the pages to run under HTTP over Secure Sockets Layer (HTTPS). HTTPS encrypts the user's account information so that it doesn't transmit in clear text.
Working with AD and NT Domains
ChangePasswordEntry.asp and ChangePassword1.asp contain few lines of code but provide the Web interface to let users change their passwords over the Web or an intranet. The code works if the server runs Win2K or NT 4.0 with users whose accounts are stored on the local server. However, the code doesn't work if the Web server is running Win2K AD or participates in an NT domain.
To make ChangePassword1.asp work for user accounts stored in Win2K AD, you need to use the Lightweight Directory Access Protocol (LDAP) provider for ADSI instead of the WinNT provider. The LDAP provider lets you perform tasks on a server that is part of an AD domain. To use the LDAP provider, you simply change the connection string in ChangePassword1.asp to
sConnectString = "LDAP://CN=" &
sUser & ",OU=users, " &
"DC=mycompany, DC=Com"
The changes adapt the connection string to the AD interface. Instead of just passing positional parameters, as the WinNT provider does, the LDAP provider code uses AD identifiers such as CN for common name and OU for organizational unit. After the GetObject function executes for the connection string, you can work with the LDAP provider just as you would the WinNT provider. Aside from the changes to the connection string, the code remains the same whether you use the WinNT provider or the LDAP provider.
For the ChangePassword1.asp code to work in an NT 4.0 domain, the connection string needs to specify the domain name instead of the computer name. For example,
sConnectString = "WinNT://" &
"MyDomain/" & sUser & ",user"
sets the connect string to point to the user object in MyDomain instead of the computer running the Web server. As you can see, the beauty of ADSI is that it lets you use virtually the same code to access user account objects on either Win2K or NT 4.0.
Interface Differences
You'll notice differences among various ADSI providers' objects and interfaces. Each provider's creator can implement unique objects and interfaces, which are pertinent to the type of resource that the provider accesses. The AD and WinNT providers have similar interfaces because they both expose the IADsUser interface. The WinNT implementation of the interface maps to user accounts in the SAM. Table 1 shows the user properties that the IADsUser interface lets you set or change.
To see the differences between various providers' interfaces, you can study the LDAP provider's IADsUser interface. The interface lets you set or change the ADSI properties that you see in Table 2. Table 2 also shows how ADSI proper-ties map to AD properties. For more information about ADSI properties, see the Microsoft Developer Network (MSDN) Online Library article "IADs
User" (http://msdn.microsoft.com/library/
default.asp?url=/library/psdk/adsi/if_
pers_488i.htm).
ADSI is a powerful programming interface for Win2K, NT 4.0, and other systems that providers can expose. You can use ADSI to let users change passwords through a Web interface, and you can use ADSI to maintain many other properties of AD or NT 4.0.