How to provide self-serviced password management for SharePoint (WSS/SPS) with 0 lines of code
“Don’t reinvent the wheel.” This expression can always ring true when applied to devolpment. Unfortunately most developers have a tendency to over architect and over design their systems. In some instances we would rather re-write the functionality that has already been successfully written rather then take advantage of the existing code. There are a number of reasons to justify this sort of behavior. The most common one is to claim to have written the code from scratch. This post is about making the right decision when it comes to using the Built-in support for SharePoint self-served password management.
This spring I was at a client site assisting with a number of issues they were experiencing with their SharePoint implementation. One of the problems they ran into was self-serviced password management for Active Directory accounts of SharePoint users. Their customer support department had been receiving numerous calls asking to reset users expired passwords in order for them to log into the SharePoint Portal. Shouldn’t there be a better way to use a valuable resource such as customer service?
I have a two-step process on how I approach a solution to this kind of problem:
Turn to Google search for answers. I like to find as much information as possible about the subject matter.
Make a decision to:
Write everything from scratch based on the sample code found.
Utilize open-source code as is or with modification to help solve the issue.
When there is no free solution, turn to the product to purchase.
Running a Google search for “WebPart password change” returned a number of free WebParts to be downloaded that provide you with a desired functionality and even more. But if you remember the problem statement was clear that users were not able to login because their accounts expired. This means users will be denied access to the WebPart Page because the default page requires authentication to the site. The next step was to write custom ASP.NET application that access AD through DirectoryServices object model. I have to admit it was the worst object model I’ve ever had to work with. It had a number of memory leaks and was extremely hard for me to get up to speed.
So, after a day of frustrations with the DirectoryServices object model a colleague of mine, Don Kelly, suggested I look into the built-in solution for resetting expired passwords from Microsoft. He pointed me to this KB article “Using the Change Password feature with Outlook Web Access”. Of course I had to do more research to understand exactly what was applicable to my implementation and what was not. I ran across a number of forum posts and Microsoft KB articles on “IISADMPWD Virtual Directory”. Since WSS/SPS requires Windows 2003, I knew that the updated files were in the specified location and I didn’t have to install anything to make this solution work for me. The KB Article, “FIX: You experience various problems when you use the Password Change pages in IIS 6.0”, served as my guide to understanding all that was required to configure IISADMPWD Virtual Directory. By the way, this solution doesn’t require coding nor does it require installation of any kind.
The solution that I came up with solved the following issues:
In the case where the Active Directory accounts expired and the user were trying to log into the SharePoint (WSS/SPS) the user will now be redirected to a screen to change their password.
With the use of Content WebPart and IISADMPWD virtual directory to it will provide end- users of the WSS/SPS site with self-serviced password management solution
1. Find the folder [drive]\Windows\System32\Inetsrv\Iisadmpwd and register iispwchg.dll
Click Start, and then click Run.
In the Open box type the following, and then press ENTER:
2. Exclude IISADMPWD from WSS Managed path
1. Click Start, point to All Programs, point to Administrative Tools, and then click SharePoint Central Administration.
2. On the Central Administration page, under Virtual Server Configuration, click Configure virtual server settings.
3. On the Virtual Server List page, select the virtual server you want to configure.
4. On the Virtual Server Settings page, under Virtual Server Management, click Define Managed Paths.
5. Under Included Paths or Excluded Paths, select the check box next to the path you want to remove, and then click Remove selected paths.
Or STSADM.EXE can be used to do the same thing as:
You can also remove an included or excluded path by using the command line. For example, to remove an exclusion for the site at http://server1/hrweb/webapp, you would use syntax like the following:
stsadm -o deletepath -url http://server1/hrweb/webapp
3. Configure the PasswordChangeFlags property in the metabase to make sure that the Password Change functionality is enabled
1. Open command-line and Locate the C:\Inetpub\Adminscripts directory.
2. Type the following command, and then press ENTER:
cscript.exe adsutil.vbs set w3svc/passwordchangeflags 0
Note: 0 = This value indicates that you must use a Secure Sockets Layer (SSL) connection when you change the password.
4. Configure IISADMPWD virtual directory
When the Virtual Directory Creation Wizard starts, follow the instructions to create the virtual directory with the alias that is named “IISADMPWD.” Make sure that the path points to the Windows\System32\Inetsrv\Iisadmpwd directory. Make sure that both “Read” permissions and “Run Scripts (such as ASP)” permissions are selected
5. Creating Self-Serviced AD Password Management WebPart
Add Content Editor Web Part to the WebPart Page
Click on Modified Shared WebPart from WebPart Chrome menu then Source Editor and past URL that reflects your settings for example:
That’s it! Congratulations, you just configured Self-Serviced Password Management WebPart with 0 lines of code. Of course this solution is not as elaborate as a custom written code but with the amount of time it takes to enable this functionality I think it is well worth the minimal effort.
Until next time, Maxim