I think I've got everything set up in IIS for using IIS 5.0's password
change scripts. However, when I submit a form I get the following
error:

Error: An invalid Active Directory pathname was passed

Debugging the scripts a little, what I find is that none of the
request.form field values are being passed by the browser, or else IIS
isn't seeing them.

Any ideas what may be causing this?

Describe in detail how you've set up the pages, including authentication
methods enabled and ACLs on the password change files. Also, are you using
the .ASP version of the password change scripts?

We're talking about password changing here, which is a privileged operation
walking a fine-line in security. Any mistake, and it's over.

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]
I think I've got everything set up in IIS for using IIS 5.0's password
change scripts. However, when I submit a form I get the following
error:

Error: An invalid Active Directory pathname was passed

Debugging the scripts a little, what I find is that none of the
request.form field values are being passed by the browser, or else IIS
isn't seeing them.

Any ideas what may be causing this?

On Thu, 30 Oct 2003 22:10:16 -0800, "David Wang [Msft]"
[quoted text, click to view]

Here goes:

Yes, I'm talking about the .ASP version.

- The server is runnning Windows 2000 Server (standard) with SP4. All
recent patches have been applied. Not running URLScan.

- The server is a member server in a Windows 2000 AD domain in native
mode.

- The site I'm trying to enable this on is not the Default Web Site,
but another virtual web site.

- There is no SSL cert installed for this web site, although I plan to
install one and require SSL connections when this functionality is
in place.

1. Mapped the .htr extension to asp.dll on this web site only.

- "All Verbs" selected, "Script engine" checked off

Under Application Settings, the Default Application has:

- Execute Permissions: Script Only

- Application Protection: Medium (Pooled)

Under Directory Security:

- Anonymous access is checked
- Basic authentication: unchecked
- Digest authentication: unchecked
- Integrated Windows authentication: checked


2. Created a virtual directory named IISADMPWD

- Local Path: C:\WINNT\System32\inetsrv\iisadmpwd

Under Application Settings:

- Application name: (none)

- Execute Permission: Scripts and Executables

- Application Protection: Medium (Pooled)

- Application (extension) Mappings inherited from parent (see #1)

Under Directory Security:

- Anonymous access is checked
- Basic authentication: unchecked
- Digest authentication: unchecked
- Integrated Windows authentication: unchecked


3. Permissions on C:\WINNT\System32\inetsrv\iisadmpwd are all
inherited and haven't been changed

- Administrators: Full control
- CREATOR OWNER: Full control
- Power Users: Modify
- SYSTEM: Full control
- Users: Read & Execute


4. Using Metabase Editor 2.2.3, added a PasswordChangeFlags value to
this web site, with

- Attributes: none checked
- User Type (UT): Server
- Data: 1


I've tried a couple variations on this, such as checking Basic
authentication in #1 for the web site itself. Same behavior. I'm not
positive that PasswordChangeFlags should have a User Type of Server or
if one of the other choices is required. Also whether or not
Attributes, Inherit should be set.

I'm testing this using a simple domain user account with "User must
change password..." checked off. Web browser used is the latest IE
6.0.

Thanks.

On Thu, 30 Oct 2003 22:10:16 -0800, "David Wang [Msft]"
[quoted text, click to view]

I did a little bit more debugging and it appears that the only thing
not working is that the form fields aren't making it to the achg.htr
script.

If in that script I do something like hard coding:

domain = "MYDOMAIN"
username = "myuser"

and

pUser.ChangePassword "somepassword", "somenewpassword"

then the password is changed successfully and the user can then access
the protected web site.

Does http://support.microsoft.com/?id=251404 affect this?

--
//David
IIS
This posting is provided "AS IS" with no warranties, and confers no rights.
//
[quoted text, click to view]

I did a little bit more debugging and it appears that the only thing
not working is that the form fields aren't making it to the achg.htr
script.

If in that script I do something like hard coding:

domain = "MYDOMAIN"
username = "myuser"

and

pUser.ChangePassword "somepassword", "somenewpassword"

then the password is changed successfully and the user can then access
the protected web site.

On Fri, 31 Oct 2003 20:52:48 -0800, "David Wang [Msft]"
[quoted text, click to view]

Bingo!

Now, how best to work around the limitation? All users can be
expected to be running Internet Explorer, but some log in from home
computers on which I'd be unable to modify the registry.

My next step will be to set up a certificate and require SSL
connections to the web site. Can I safely disable Windows
authentication on the site, use only Basic authentication, and rely
solely on SSL encrypting usernames and passwords during the login
dialog?

Many thanks,
Jim