C# Problem to set password to user with invoke("SetPassword"..

sorry but how i do this .. :s

i think it's wants you want:

'Active Directory.vshost.exe' (Managé) : 'C:\Documents and Settings\rolla\Mes documents\Visual Studio 2005\Projects\Active Directory\Active Directory\bin\Release\Active Directory.exe' chargé, symboles chargés.
'Active Directory.vshost.exe' (Managé) : 'C:\WINDOWS\assembly\GAC_MSIL\mscorlib.resources\2.0.0.0_fr_b77a5c561934e089\mscorlib.resources.dll' chargé, aucun symbole chargé.
Une exception de première chance de type 'System.Reflection.TargetInvocationException' s'est produite dans System.DirectoryServices.dll
Une exception de première chance de type 'System.Reflection.TargetInvocationException' s'est produite dans System.DirectoryServices.dll
Le programme '[292] Active Directory.vshost.exe: Managé' s'est arrêté avec le code 0 (0x0).

Hi,
try changing this DirEntry.Invoke("SetPassword", new object[] {"drs4ce69"});
to this DirEntry.Password = "drs4ce69";

Cheers
Pino

i have test to change DirEntry.Invoke("SetPassword", new object[] {"drs4ce69"}); to DirEntry.Password = "drs4ce69";

I have no error but the password wasn't create ( i have test to connect to the domain with the user )

for information i have create break point on the program and it find the user i have no problem at this level

Well looks like a strange issue. Try setting
                          DirEntry.UsePropertyCache = false
just after DirEntry is created. This will avoid caching problems (and the CommitChanges becomes useless).
Cheers
Pino

like this : ?


i have try and it's sames ..

try
                    {
                        DirectoryEntry Ldap = new DirectoryEntry("LDAP://192.168.4.5:389/OU=Compta,DC=ptiadoracle,DC=domain,DC=loc", "Admin_mrl", "toto", AuthenticationTypes.Secure);
                        DirectorySearcher MaJ_User = new DirectorySearcher(Ldap);
                        MaJ_User.Filter = "SAMAccountName=" + user_nom.Text.ToString() + "";
                        SearchResult Resultat = MaJ_User.FindOne();
                        DirectoryEntry DirEntry = Resultat.GetDirectoryEntry();
                        DirEntry.UsePropertyCache = false;
                        DirEntry.Invoke("SetPassword", new object[] { user_password.Text.ToString() });
                        DirEntry.CommitChanges();
                    }
                    catch (Exception ex)
                    {
                        MessageBox.Show(ex.Message);
                    }

                                              

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:

Hi,
not quite, you have to use
            DirEntry.Password = "drs4ce69";
instead of Invoke.

Cheers
Pino

well,
i have no error,the password is not create.
i think DirEntry.UsePropertyCache = false; remove all privilege,because now the user is invit to change is password at the next login ... it's better

Actually that means that the call works fine and the password has been correctly changed: I suppose the user logs in using the new password, right?

no it don't use the new password ...
by default it create user and he need to change it at new logon (the user have no password)

ok, so it works fine. What if you set a password instead of leaving it blank?

well if i set password manually ( under Active Directory , right click, etc .. ) it's ok but not by the program ..

Well,
as this is intriguing I've found a machine in my organization which has the same behaviour. I've also deeply browsed the Microsoft solutions and... there is nothing there... looks like when (and if) you got that error there is nothing known to do.
Tomorrow I'll open a support call with Microsoft, as this looks like a huge bug somewhere in their infrastructure. I let you know.

Cheers
Pino

P.S.: I was wrong about the .Password property, that's the authentication password used to authenticate your session... nothing to do with the user password!

ok thank a lot i waiting your answer :)

Support request opened, now waiting the call back ;)

thank a lot gdefrancesco :)

Hi,
that's unbelievable! get rid of the port and it will work!
Instead of
"LDAP://192.168.4.5:389/OU=Compta,DC=ptiadoracle,DC=domain,DC=loc"

just use
"LDAP://192.168.4.5/OU=Compta,DC=ptiadoracle,DC=domain,DC=loc"

and magically it works! I'm still checking with Microsoft the origin of this strange issue as it's not shown on any machines, just on few of mine and none of their machines. Weird!

Cheers
Pino

thank a lot gdefrancesco for your help thank a new time :)
thank,
fas3r :)

Hi, here the final diagnosis from Microsoft. As the documentation is misleading I also added a Community Content to this page http://msdn.microsoft.com/en-us/library/aa746344(VS.85).aspx ). Microsoft's diagnosis here:

==============================================================================
After taking some network traces, I could discover why our different scenarios work / do not work.
 
As a reminder, here is what works / do not work:
·         Setting the password specifying the server with a DNS name works, with or without a port number in the address.
·         Setting the password specifying the IP of the server works only if no port is specified.
 
In fact, it was all explained in the MSDN for the SetPassword method (http://msdn.microsoft.com/en-us/library/aa746344(VS.85).aspx) , but we missed the last part as it was tricky.
 
As I told you before, SetPassword ensures that some security policies are used when calling it:
·         It first tries to use SSL. As your server does not use SSL, this method silently fails.
·         Then, it tries to use Kerberos authentication and encryption capabilities. Kerberos works with a system of tickets which require a name based on DNS. Therefore it requires that you request a ticket *for a server name* and not for an IP address (as addresses could change). This is the reason why, in your case, it does not work: you are binding to an IP address and not a fully qualified DNS name. Putting the port, or not, has not influence since Kerberos do not use them. Youll see in the next point why ports make a difference.
·         At last, if all methods have failed, it falls back to calling NetUserSetInfo. This method has been around Windows for a long time and, its not mentioned in the doc, uses under the cover the old Directory protocols as a last resort. It uses the NetBios Name System (NBNS) protocol to make the changes (which is based on SMB protocol). As described in this article, AD, for backward compatibility reasons, still accepts request in NBNS http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/deploy/dgbd_ads_lqec.mspx?mfr=true:
For interoperability with computers that run earlier versions of Windows, Active Directory domains have NetBIOS names and Active Directory domain controllers register in NBNS and query NBNS when necessary.
I had a look at the network traces and did see NBNS in action. It does *not* work with a port because ADSI simply pass the full address (along with the port) of your server to NBSN, so a SMB request is made saying who has netbios name for x.x.x.x:389? which fails, because NetBios does not accept a port in the IP for name resolution (sounds logicial). Without the port, the IP address is associated a NetBios name and NBNS works.
 
Also, us being in the domain or not has little to no influence here. Being in the domain might have helped for Kerberos, but now Kerberos works fine with cross forests.
==============================================================================

Cheers
Pino

Same comment added to http://msdn.microsoft.com/en-us/library/system.directoryservices.directoryentry.invoke.aspx