Changing Novell Account Management Passwords

Question:

I'm having a problem where we are changing user passwords on several NDS trees. One of the NDS trees also hosts an NT domain using Novell Account Management 2.1 The nwChgPassword function does not appear to change the NT domain password for user accounts in that domain.
Our environment :
Netware Client 4.83 SP1 eDirectory 8.6.2 NAM 2.1 Samsrv.dll version 4.60 PTF 20020515_V21 Netware Extender 34005.0.2.1 Winbatch 2003g or 2004a

Sample code :

;BEGINS AddExtender('WWNWX34I.DLL') tree = nwServerList(6) ObjectSpec = nwWhoAmI(tree)
OldPwd = AskPassword('Change object password','Old password')
NewPwd = AskPassword('Change object password','New password')
PwdFlags = 3
ErrorMode(@OFF) Result = nwChgPassword(ObjectSpec,OldPwd,NewPwd,PwdFlags)
ResultCode = LastError() ErrorMode(@CANCEL)
TempMsg = StrCat('nwChgPassword("',ObjectSpec,'","',OldPwd,'","',NewPwd,'","',PwdFlags,'") RC = ',ResultCode) ;ENDS

The results are the same whether you use a Password Flag of 2 or 3, although with 3, the NDS user password does get changed, but the NT doesnt, and the error still gets reported. Using a Flag of 1 changes the NDS password as expected with no error.
The nwChgPassword returns error 291 which is: Failed authentication (bad password?)
The wwwbatch.ini contains:
[NetWare Extender] LastError=FFFFFD63 "NWDSChangeObjectPassword() : WWNWX_ChangeObjectPassword()"

Changing the password using the "Change password" button in the GINA /does/ change both passwords.

Answer:

That error indicates:

#define ERR_FAILED_AUTHENTICATION -669 /* 0xFFFFFD63 */

Usually this error means that the old password value you provided as input to NWDSChangeObjectPassword() [via nwChgPassword] was not valid, and thus the password change request [different from a password reset request] was unable to be processed.

Are you abosolutely positively 100% certain that your NDS and NT passwords were in fact in sync together before attempting to change the password?

The NWDSChangeObjectPassword() API function can only change a single password [NDS or NT] at a time. When nwChgPassword() has a flag value of 1 or 2, it simply makes a single call to the API function and then is done. However, when you pass in a flag value of 3 then the API function is called 2 times - once for NDS and once for NT. In that case, if either one of the password changes causes an error then the extender function reports an error, although it might be tough to figure out which particular call to that API function [for the NDS or NT password] actually caused the error.

I'd be somewhat concerned about password case, too. Although the Novell Client software forcibly converts your password to upper case, IIRC, the raw API functions that accept passwords do not do this so you have to be sure to do this in your code if you want to match the behavior of the Novell Client. Failing to do this can result in setting a password for a NDS/eDir user account that cannot be entered via the GUI login of the Novell Client, even though it is perfectly valid when passed directly to an API function.

Just for grins, can you use the GUI password change utility to change the password to a known value, preferably all upper case, and then repeat your test with nwChgPassword()? And, if you can, then repeat the test with an all lower case password?

User Reply:

OK so if the NT password is case sensitive, the Novell client cant change the new password to upper case when changing the NT domain password, otherwise your NT password would be different to what you expect. I can confirm this from testing.
What does appear to happen is when passing your old password, the API expects this to be upper case (even if your old NT domain password is lower case!) otherwise you get the authentication failed error!

So..the fix...place an strupper() around the oldpassword parameter when calling the API.

Answer:

OK, just to be certain that what is expected is what is really happening...

The NDS password, if changed via the GUI interface, is always converted to uppercase before it is passed to the underlying NWDSChangeObjectPassword(). This means that all NDS password values that are passed in to nwChgPassword() must be converted to upper case before they are used *if* you want to maintain compatibility with the Novell Client's GUI password processing [e.g. login, password change].

Your finding for the NT password was that it also had to be converted to upper case before passing it in to nwChgPassword() with a flag value of 2? Please confirm.

User Reply:

Here are my findings :
flag=1 (Change NDS)
NDS-only password changes work fine with lower or upper case old passwords
flag=2 (Change NT)
Authentication fails if the OLD password is in lower case. NT password is not changed.
Authentication works if the old password is passed in upper case.
flag =3 (Change both)
If the old password is passed in lower case the NDS password change succeeds, but the NT password change fails (cannot authenticate error again)
If the old password is passed in upper case both password changes succeed.
Note if you strupper() your NEW password, then your NDS password will be what you expect (as its case insensitive) but if the password you typed was in lower case,your NT Domain password will NOT be what you typed!
I note the current help says nothing about what exactly the NT password refers to, so it may be worth adding its for NDS for NT/Novell Account Management domains.

It might it be better if the Netware extender did the strupper before passing it to the API?

Answer:

Bingo! That's why I'm trying to make sure that I completely understand how the case sensitivity is being handled for both the NDS and NT passwords. Then I can decide whether to have the extender manipulate the case of the passwords of if the documentation should simply make a note of this issue and let the script developer deal with it.

User Reply:

Another thing to beware of - using Flag=3 when the user object in the NDS tree isnt a domain member makes the call fail, even though the NDS password change worked.

I guess I'm going to have to check the presence of the IWS:xxxx attributes first, and then set the flag to be 1 or 3 accordingly.

Answer:

OK, at least *that* behavior is expected to happen. The underlying NWDSChangeObjectPassword() function will cause an error to be raised if you attempt to change the NT password for a user object that is not part of an NT domain. This will also happen if you attempt to change the NT password for a user object in a tree where NDS4NT and/or Novell Account Manager is not already installed.

User Reply:

I now have the following code working reliably on both 4.8 and 4.9 clients: (error checking removed for clarity)
#DefineFunction changeNDSPassword(tree, oldpass, newpass) ErrorMode(@OFF) userid = nwWhoAmI(tree) ;Check for NT domain membership attrib = "IWS:Domain Membership" ntdomain = nwGetObjValue(userid,attrib,"","",1) If ntdomain <> 0 Then ;We are an NT domain member, so lets change the NT password first NTResult = nwChgPassword(userid, strupper(oldpass), newpass, 2) NTResultCode = LastError() End If ;Now change the NDS password Result = nwChgPassword(userid, oldpass, newpass, 1) ResultCode = LastError() ErrorMode(@CANCEL) #EndFunction

Article ID:   W16537

File Created: 2005:02:18:12:21:20

Last Updated: 2005:02:18:12:21:20

Database Search

TechHome