Environment
Novell Client 2 SP2 for Windows 7
Situation
If a user has configured Forgotten Password / Challenge/Response questions and then attempts to use them to reset a forgotten password, they are never given an option to select other resources to apply the password change.
The "Synchronize this password with" box displays but it is empty.
The Active Directory password does not get changed.
The "Synchronize this password with" box displays but it is empty.
The Active Directory password does not get changed.
Resolution
This is working as designed. Since the Windows password is unknown when the Forgotten Password process is completed, it is not possible to synchronize passwords during this operation.
Additional Information
Synchronizing passwords in the case where the forgotten password functionality is being used never has happened, even on Windows XP/2003. When using the "Did you forget your password?" link, you're only performing an eDirectory login (as this is the only login which supports challenge/response), and once you successfully login to eDirectory (i.e. if you successfully answer the challenge/response questions) you're able to change your eDirectory password.
No Windows login has occurred, nor has any eDirectory or Windows password been collected with which to perform a Windows logon, because you're only going through the NMAS Challenge/Response method login to eDirectory.
In this situation, we don't know "the old Windows password", just as the user doesn't know "the old eDirectory password." NMAS Challenge/Response lets us get past that for the eDirectory login (by logging into eDirectory with some other method besides NDS password). But we can't change the Windows password from an end-user workstation without knowing the old Windows password.
It is necessary to either 1) use password recovery options provided by Windows, or, 2) use an administrator to override the Windows password (which is how you're able to change the Windows password without knowing the old password.)
Elaborating on this, the first hurdle is that we we can't just change the user's password to whatever we want during login. The APIs Windows provides still require that you're either an administrator trying to change someone else's password, or you know the existing password on the account. If you're a user attempting to login who has forgotten your password, you can't achieve either of those even if you're an Administrators-member account. (Since even if you're an Administrators account with permission to change a password arbitrarily, you have to get logged on before you have those permissions. And if you've forgotten your password, you can't get logged on.)
The "synchronize with" is not expected in this case, as the Forgotten Password handling code knows that only a single eDirectory login (via Challenge Response) has been performed. It knows no other eDirectory logins, and no Windows login has been performed.
"Synchronize with" is an action that makes sense only when you know what the "old password" was, and want to sync with other resources that were using the same "old password".
In addition to not knowing the "old password" making it so you can't change the password on other resources (you can only change the password for the resource which permitted you to login via Challenge/Response), not knowing the old password means you don't know what other resources were in sync with this resource to begin with.
This feature works ideally when there is something that will cause the eDirectory password change to be synchronized to the Windows account "on the back end." e.g. DirXML / IDM sync between a eDirectory tree and a Windows domain-based account, or ZENworks DLU being able to reset the password of a managed local Windows account.
No Windows login has occurred, nor has any eDirectory or Windows password been collected with which to perform a Windows logon, because you're only going through the NMAS Challenge/Response method login to eDirectory.
In this situation, we don't know "the old Windows password", just as the user doesn't know "the old eDirectory password." NMAS Challenge/Response lets us get past that for the eDirectory login (by logging into eDirectory with some other method besides NDS password). But we can't change the Windows password from an end-user workstation without knowing the old Windows password.
It is necessary to either 1) use password recovery options provided by Windows, or, 2) use an administrator to override the Windows password (which is how you're able to change the Windows password without knowing the old password.)
Elaborating on this, the first hurdle is that we we can't just change the user's password to whatever we want during login. The APIs Windows provides still require that you're either an administrator trying to change someone else's password, or you know the existing password on the account. If you're a user attempting to login who has forgotten your password, you can't achieve either of those even if you're an Administrators-member account. (Since even if you're an Administrators account with permission to change a password arbitrarily, you have to get logged on before you have those permissions. And if you've forgotten your password, you can't get logged on.)
The "synchronize with" is not expected in this case, as the Forgotten Password handling code knows that only a single eDirectory login (via Challenge Response) has been performed. It knows no other eDirectory logins, and no Windows login has been performed.
"Synchronize with" is an action that makes sense only when you know what the "old password" was, and want to sync with other resources that were using the same "old password".
In addition to not knowing the "old password" making it so you can't change the password on other resources (you can only change the password for the resource which permitted you to login via Challenge/Response), not knowing the old password means you don't know what other resources were in sync with this resource to begin with.
This feature works ideally when there is something that will cause the eDirectory password change to be synchronized to the Windows account "on the back end." e.g. DirXML / IDM sync between a eDirectory tree and a Windows domain-based account, or ZENworks DLU being able to reset the password of a managed local Windows account.