n4ChgPassword and Strange Results

Keywords: 	 context	  N4ChgPassword

Question:

We are using the n4chgpassword command and are getting very strange results. We have tested against multiple servers and it has worked very well when we pass the fully qualified context included with the userID. We found one site however that never works, the only way we could get it to work was by just feeding the useriD only, with no contextual information at all. As listed below, the Flogin variable is what is in question here, and the comments show what works and what doesn't work.
What is the correct syntax to use?
AddExtender("wwn3x34I.dll") AddExtender("wwn4x34I.dll") ;This format works Flogin = "username" ;These work sometimes Flogin = ".username.Users.Company" Flogin = ".CN=Username.OU=Users.O=Company" context = "Users.O=Company" tree = "NovellTree" curserver = "\\server1" oldpass = "robot5" newpass = "robot6" DEBUG(@ON) n4SetContext(context, tree) retcode = N4ChgPassword(CurServer,Flogin,OldPass,NewPass)

Answer:

Can you fill us in on a few more details about the design or your NDS tree? I'm going to shoot from the hip here until I know a little bit more about the conditions surrounding this problem.

Are there any bindery contexts set on the various servers at the sites for which this script does or does not work? If so, what are the bindery contexts and on what servers are they set?

When you refer to a "site" that is experiencing this problem, which of the following scenarios best fits your configuration?

Remote site w/o a server. All workstations access a file server via a WAN connection.
Remote site with a server. Server does not have a partition replica holding the container in which the user objects exist that are to have their passwords modified.
Remote site with a server. Server does have a read-only partition replica holding the container in which the user objects exist that are to have their passwords modified.
Remote site with a server. Server does have a read-write or master partition replica holding the container in which the user objects exist that are to have their passwords modified.

The reason that I ask about this is that the n4ChgPassword() function takes the name of a specific server as a parameter. If you sent a password change request to a server that does not have a writeable partition replica on it that holds the container in which the user objects exist then the password change request will have to be referred to another server on the network. There could be some confusion as to where the password change request is getting referred to and where you are normally reading your NDS information from.

Another thing that looks vaguely suspicious is the value of the 'context' variable. You have mixed the typed and non-typed modes of specifying a context. Be consistent. Either specify the value as '.OU=Users.O=Company' or as '.Users.Company'. Please note the leading dot '.' that specifies this as an absolute context. Without the leading dot the context is specified as being relative to your current context. This works just like using the 'CD' command in DOS to change your working directory. You can change to a subdirectory just by specifying the subdir's name w/o going back up to the root of the drive or you can specify the complete directory starting with the '\'.

One more thing to consider. Your posting does not indicate what happens when this problem occurs. Do you get some sort of error code or error message in WinBatch or does this function complete w/o any messages? Are you really sure that the password change did not take effect? The reason that I ask is that all sorts of strange problems can happen if your NDS tree is not healthy. There can be situations where a server is not communicating properly with other servers and changes to objects in the NDS tree do not get properly synchronized between the servers. The result can be that you make a password change or add an account or change a group membership through a connection to one server and then the next time you try to read that information (through a connection to a different NDS server) you get the old information. The situation could occur if you have a read-only partition replica on the remote site's server. The password change request would be referred to a NDS server that has a read/write or master replica. If the changes do not get synchronized on the remote site's server that has the read-only partition replica then the password change will appear to have failed w/o any error messages being generated.

Article ID:   W14277

Filename:   n4ChgPassword and Strange Results.txt

File Created: 2001:03:01:13:47:50

Last Updated: 2001:03:01:13:47:50

Database Search

TechHome

n4ChgPassword and Strange Results

Question:

Answer: