Hi all,
We are having some problems that are very difficult to diagnose using the SetPassword
method on IADsUser. Normally I'm pretty good at figuring these things out, but this
one is pretty weird. If anyone else has any ideas, I'd love to hear them. Here are
some of the key factors:
- Generally, the code works fine for days at a time
- When the problem starts, we get an error of "Access Denied" instead of a
"constraint violation" or "unwilling to perform"
- The problem appears to be associated between a particular process on the server and
a particular domain controller. Changing either the domain controller or using a
different process makes the problem go away.
- The problem doesn't fix itself after it starts.
Here are some environmental details:
Source machine (where the code executes) is a domain member web server running Win2K
Domain controllers are all Win2K
IP traffic is not restricted by a firewall between the two machines, so we don't
suspect any port blocking problems.
Domain controller has a valid 128 bit capable SSL cert. Password changes use SSL/LDAP
instead of Kerberos or NetAPI (as far as we can tell).
No interesting SChannel, Kerberos or IIS events end up in the event log as a result of
this problem
We haven't been able to find a method to trigger the problem, so it is difficult to
reproduce and test against
IIS security is set to anonymous with a local machine account as the IIS user. Users
of the site are authenticated via a forms authentication mechanism, not Windows/IIS
authentication.
Here is a bare-bones version of an ASP page that will exhibit the crash once the
process gets into this state:
------------
Dim objNamespace
Set objNamespace = GetObject("LDAP:")
Dim strUserDN, objUser
strUserDN = "cn=test.user,ou=peoplecontainer,dc=mydomain,dc=com"
Set objUser = objNamespace.OpenDSObject("LDAP://domaincontroller01.mydomain.com/"; &
strUserDN, "[EMAIL PROTECTED]", "adminpassword", 2)
objUser.SetPassword "Pa$$w0rd"
-------------
Note that we are binding with credentials specified, so we aren't relying on any
impersonation, default credentials or delegation scenarios here.
So far, we have done the following to troubleshoot the problem.
- If we change the code to talk to a different domain controller, say
domaincontroller02.mydomain.com, the code will work flawlessly again. And if we
change the code back to domaincontroller01.mydomain.com, the "Permission Denied" error
returns. This is how we concluded that the issue seems to be with the certain domain
controller.
- If we put the web page on a different server that is configured the same way
pointing to the same domain controller, domaincontroller01.accenture.com and same
target user and admin credentials, the code works fine. This leads me to conclude
that is has something to do with that specific web server server.
- If we restart the inetinfo.exe process on the web server, the problem goes away.
This is one of the things that leads us to believe the problem is with a specific
process talking to the DC.
- If we put the exact same code in a VBScript, on the same web server talking to the
same domain controller, it also works. This is the other thing that leads us to
believe the problem is with the particular process (inetinfo.exe) since it runs under
the windows scripting host just fine.
- We have double checked again to make sure "adminname" and "adminpassword" is
correct and has permission to change password and that the account isn't getting
locked out.
- Using a different username and password with appropriate permissions DOES NOT make
the problem go away, even though changing domain controllers did (see the first point).
- The problem is isolated to setting password via SetPassword. After binding to the
user with "adminname" and "adminpassword", we can read and write to attributes
normally as expected, so the user doesn't seem to have different permissions than
expected.
- The password that we am setting to conform with the domain password complexity
policy. Otherwise the code wouldn't work in the other situations.
- Changing binding flags (Secure, SSL, ServerBind, combinations of the above, etc.)
doesn't change the result. SSL binds generally always work from this server, so that
does not appear to be a problem. If it was, we'd expect to get some kind of "Refuse
to perform" error instead of an "Access Denied".
In conclusion, it looks like something gets cached or corrupted within ADSI in the
current process at some point. However, it doesn't seem to be normal ADSI connection
caching as explained in this article
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/adsi/adsi/connection_caching.asp?frame=true
because when substitute different credentials (which according to the documentation
will use a different connection handle), the problem does NOT go away. Only changing
DC's or restarting the process fixes the problem. Perhaps there is an issue with
connection caching in our server's version of ADSI where only the server name is used
for the cached handle and not the credentials. In any event, we aren't specifically
caching any handles by holding on to references, so I wouldn't expect this to be the
problem regardless.
Any suggestions would be greatly appreciated. The only thing I can think to do is to
switch to a lower level SSL LDAP call to set unicodePwd directly instead of relying on
ADSI, but obviously that complicates our site a bit.
Thanks in advance.
Joe Kaplan
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in error,
please notify the sender immediately and delete the original. Any other use of the
email by you is prohibited.
List info : http://www.activedir.org/mail_list.htm
List FAQ : http://www.activedir.org/list_faq.htm
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
