This content has been marked as final. Show 5 replies
That's expected behavior as far as I've seen. SafeBoot SSO credentials are not tied directly to the password token, they're just additional information stored attached to the user's SB account. Even if you can fix your configuration so it updates the SB password on a Novell password change the SSO details will be incorrect at your next Novell login.
Does anyone have any ideas for a workaround? I would like to keep the login process as transparent as possible for 5000 end users!
User Password expires & is changed
SafeBoot does not recognize the changes
User enters old password at SafeBoot Screen
User enters new password at Novell Screen
SafeBoot replicates password change
What Windows Login options do you have ticked for your machines?
A genius coworker located the problem yesterday. Installation of the SafeBoot Admin Console on an encrypted machine breaks the SafeBoot windows client's ability to detect password changes. Admin console installation changes the default safeboot path from "c:\program files\safeboot" to "c:\program files\safeboot remote console" in registry location:
HKLM\Software\SafeBoot International\SafeBoot Device Encrpytion\ClientDir
After Admin Console installation all password change updates are broken because the system is looking for SbClientHelper.exe file in the wrong location.
Ah! - It's not so much installing the admin console, it's because you're using the unsupported MiniAdmin script in silent install mode (using the client installer module). If you used it in non-silent mode it uses the admin system install module.
Really, the only officially supported way of installing the admin system is to actually INSTALL the product from the official distribution. Miniadmin is a hack, and though useful, can cause this kind of malarkey.