Yesterday evening, I installed SP1 for Windows Server 2003 on our Web Servers. This morning, we got reports that new users couldn't be created on our site. Upon investigation, it turned out that the code for creating users was failing on the following lines of code:
/// <summary>
/// Sets the password.
/// </summary>
/// <param name="userEntry">User entry.</param>
/// <param name="password">Password.</param>
public static void SetPassword(DirectoryEntry userEntry, string password)
{
object[] oPassword = new object[] {password};
userEntry.Invoke("SetPassword", oPassword );
userEntry.CommitChanges();
}
The error we were getting was 'Network path was not found'. It turns out that this service pack tightened security around invoking SetPassword on the ASDI, (which makes sense since this is usually what service packs do, tighten security).
In looking for an answer, I found the following gem on the microsoft.public.adsi.general group, specifically this post here.
I use ADSI to manage servers in different domains,
different networks (AD, NT DC's, standalone, servers, no
trusts, etc.) all managed from one point. I've observed
many problems where some ADSI properties/methods work and
others don't, in almost all cases it always came down to
Name Resolution.
Since these servers are in our DMZ, it made sense that this could be true for what we were experiencing.
The Solution?
The solution for us was to make sure the IP of the LDAP server was listed in our HOSTS file. Previously it was listed in LMHOSTS only. We have to use these files to give our inside IP addresses visibility on our DMZ (or so our network admin tells me). Just wanted to put this out there, because this was something that worked before, pre SP1, when the IP to the LDAP server was listed in the HOSTS file only.
-Brendan