Re: Invoke(SetPassword) in Active Directory, Works, Then Access is
- From: ptstesting <ptstesting@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 3 Apr 2006 06:38:03 -0700
I've included the output from connecting in LDP.exe below (the real domain
name is hidden). While the app seems to be working stable now with my custom
command line tool as backup, it would be nice to get rid of the hackish part.
Do you have a sample that you could post on how to change the password as you
described? Or would I have to wait for your book? =)
ld = ldap_open("mydomain.org", 389);
Established connection to mydomain.org.
Retrieving base DSA information...
Result <0>: (null)
Matched DNs:
Getting 1 entries:
1> currentTime: 04/03/2006 09:25:52 Eastern Standard Time Eastern DaylightDn:
Time;
1> subschemaSubentry:
CN=Aggregate,CN=Schema,CN=Configuration,DC=mydomain,DC=org;
1> dsServiceName: CN=NTDS
Settings,CN=mydomain-02,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=mydomain,DC=org;
5> namingContexts: DC=mydomain,DC=org; CN=Configuration,DC=mydomain,DC=org;
CN=Schema,CN=Configuration,DC=mydomain,DC=org;
DC=ForestDnsZones,DC=mydomain,DC=org; DC=DomainDnsZones,DC=mydomain,DC=org;
1> defaultNamingContext: DC=mydomain,DC=org;
1> schemaNamingContext: CN=Schema,CN=Configuration,DC=mydomain,DC=org;
1> configurationNamingContext: CN=Configuration,DC=mydomain,DC=org;
1> rootDomainNamingContext: DC=mydomain,DC=org;
22> supportedControl: 1.2.840.113556.1.4.319; 1.2.840.113556.1.4.801;
1.2.840.113556.1.4.473; 1.2.840.113556.1.4.528; 1.2.840.113556.1.4.417;
1.2.840.113556.1.4.619; 1.2.840.113556.1.4.841; 1.2.840.113556.1.4.529;
1.2.840.113556.1.4.805; 1.2.840.113556.1.4.521; 1.2.840.113556.1.4.970;
1.2.840.113556.1.4.1338; 1.2.840.113556.1.4.474; 1.2.840.113556.1.4.1339;
1.2.840.113556.1.4.1340; 1.2.840.113556.1.4.1413; 2.16.840.1.113730.3.4.9;
2.16.840.1.113730.3.4.10; 1.2.840.113556.1.4.1504; 1.2.840.113556.1.4.1852;
1.2.840.113556.1.4.802; 1.2.840.113556.1.4.1907;
2> supportedLDAPVersion: 3; 2;
12> supportedLDAPPolicies: MaxPoolThreads; MaxDatagramRecv;
MaxReceiveBuffer; InitRecvTimeout; MaxConnections; MaxConnIdleTime;
MaxPageSize; MaxQueryDuration; MaxTempTableSize; MaxResultSetSize;
MaxNotificationPerConn; MaxValRange;
1> highestCommittedUSN: 15767330;
4> supportedSASLMechanisms: GSSAPI; GSS-SPNEGO; EXTERNAL; DIGEST-MD5;
1> dnsHostName: mydomain-dc02.mydomain.org;
1> ldapServiceName: mydomain.org:mydomain-dc02$@mydomain.ORG;
1> serverName:
CN=mydomain-DC02,CN=Servers,CN=Default-First-Site,CN=Sites,CN=Configuration,DC=mydomain,DC=org;
3> supportedCapabilities: 1.2.840.113556.1.4.800; 1.2.840.113556.1.4.1670;
1.2.840.113556.1.4.1791;
1> isSynchronized: TRUE;
1> isGlobalCatalogReady: TRUE;
1> domainFunctionality: 2 = ( DS_BEHAVIOR_WIN2003 );
1> forestFunctionality: 2 = ( DS_BEHAVIOR_WIN2003 );
1> domainControllerFunctionality: 2 = ( DS_BEHAVIOR_WIN2003 );
-----------
"Joe Kaplan (MVP - ADSI)" wrote:
Try to find out if AD is 2003. If it is, then you can use an LDAP password.
modification using System.DirectoryServices.Protocols using Kerberos with
SSPI encryption as 2003 support 128 bit cipher strength. Otherwise, you
still need SSL/LDAP for an LDAP password mod.
I have a sample from my upcoming book that shows how to do this in C#.
To find out the server version, use a tool like LDP.exe (which you really
should be using if you plan to do any serious LDAP programming against AD or
ADAM) to check out what the server is advertising for its capabilities. LDP
shows you this as soon as you connect by default.
This will allow you to run the code inline without having to resort to the
external process, which is a little hackish. :)
Joe K.
"ptstesting" <ptstesting@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:3A7F3A12-6B2C-4FBA-B5CA-B603D93D32F8@xxxxxxxxxxxxxxxx
Joe,
Thanks for your help.
The server OS is Windows Server 2003, with .NET 2.0 installed. I'm not
sure which version of AD, but Microsoft Management Console is 2.0 Version
5.2
and ADSI Edit 5.2.
This is how I make the call:
internal static DirectoryEntry GetDirectoryObject(string UserName, string
Password)
{
DirectoryEntry oDE;
oDE = new DirectoryEntry(ADPath, UserName, Password,
AuthenticationTypes.Secure);
return oDE;
}
public static DirectoryEntry GetUser(string UserName)
{
DirectoryEntry de = Utility.GetDirectoryObject();
DirectorySearcher deSearch = new DirectorySearcher();
deSearch.SearchRoot = de;
deSearch.Filter = "(&(objectClass=user)(CN=" + UserName + "))";
deSearch.SearchScope = SearchScope.Subtree;
SearchResult results = deSearch.FindOne();
if (!(results == null))
{
de = new DirectoryEntry(results.Path, Utility.ADUser,
Utility.ADPassword, AuthenticationTypes.Secure);
return de;
}
else
{
return null;
}
}
//
// Actual call to set the password, which runs fine 10 minutes then begins
failing.
//
try
{
string Password = "password";
DirectoryEntry oDE = GetUser("Doe, John");
oDE.Invoke("SetPassword", new object[] {Password});
}
catch (Exception excep)
{
//
// "Access is Denied" error may occur here after 10 mins.
// Run the invoke from a console app, launched via Process.Start()
instead.
//
}
I believe I have found a work-around though. I created a command-line
console app, which uses impersonation as an admin user, and has a
SetPassword() function with the same code as above. The web app tries to
use
the Invoke(SetPassword) first, but if that fails, it does a
Process.Start()
to let the console app do the Invoke command. This seems to be reliable
and
(so-far) is working after the 10 minute failing from the web app's invoke.
Maybe some weird permissions bug?
ptstesting
"Joe Kaplan (MVP - ADSI)" wrote:
This depends on how the password modification is being done. SetPassword
tries 3 different approaches and they all have different failure modes.
The most reliable method involves using LDAP password modifications, but
that requires that your DCs have SSL certs so that you can connect to
LDAP
using SSL. This is not done in AD by default, though. You would need to
get your domain admins to configure it.
The other two methods, Kerberos set password and NetUserSetInfo, may not
be
as reliable. It is hard to tell which one is being used without sniffing
the network traffic.
What is the OS the ASP.NET runs on (with SP)? That determines the
version
of ADSI that .NET uses. Also, what version of AD are you using (2003 or
2000)?
Joe K.
"ptstesting" <ptstesting@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:F407D2D0-620E-4377-BAC9-1EC3D548CCA4@xxxxxxxxxxxxxxxx
My setup:
Using ASP.NET web app, have permissions setup properly, using
impersonation
as admin account before modifying active directory entry. I have the
latest
.NET 2.0 and service packs installed.
The problem:
I can call Active Directory's
myDE.Invoke("SetPassword", new object[] {Password});
successfully a few times, but after about 10 minutes, if I try the call
again, I receive "Access is Denied". I have to re-upload my web
application
files to restart the web application for it to resume working
correctly.
Why would this work several calls in a row, and then begin failing
after
10
minutes?
I read this post from a Microsoft techie:
http://www.gotdotnet.com/Community/MessageBoard/Thread.aspx?id=157773
It mentions something about a bug in .NET where the server stub runs
down
after several successful calls? Something about a Microsoft fix is
available,
but no download link?
Does anyone know more about this issue?
- Follow-Ups:
- Re: Invoke(SetPassword) in Active Directory, Works, Then Access is
- From: Joe Kaplan \(MVP - ADSI\)
- Re: Invoke(SetPassword) in Active Directory, Works, Then Access is
- Prev by Date: Get username in Win/anon web
- Next by Date: Padding is invalid and cannot be removed.
- Previous by thread: Get username in Win/anon web
- Next by thread: Re: Invoke(SetPassword) in Active Directory, Works, Then Access is
- Index(es):
Relevant Pages
|
