We have had safeboot deployed for 18months now, and it has been very stable.
We have set our devices (WinXP SP3) to 'Set Safeboot password to Windows Password' so that Windows password changes are sync'd to safeboot. N.B. We do NOT use SSO.
In the past couple of days we have started having issues with Windows passwords not being sync'd with Safeboot. i.e. the user changes the password (either CAD:Change Password, or change though login due to expiry, etc.) and safeboot does not reflect this change. The sync log shows no 'token' change...
If we set the Safeboot 'Force password change at next logon' i.e. change at initial safeboot device logon - then it changes fine and we can see the chnaged token sync up to the safeboot server.
All was fine until 2 days ago, and we have not changed the safeboot configuration.
Anyone else seeing this situation? I shall log a call with McAfee, but thought i'd check here too...
Regards and thanks
Thanks for pointer, but I'm afraid none of that seems to help.
I have been tracing the password changes with Process Monitor and can only see safeboot (SbClientManager.exe) accessing the \Device\SafeBootFSVolumes\Disk0\DataStore\... files during the Windows password change process... This makes it look like it is aware of the password change happening...
I can actually see it reading an area that matched the safeboot user id e.g. \Device\SafeBootFSVolumes\Disk0\DataStore\00000001\00000367\ATTRIBS.DAT, however it doesn't appear to even try and write to this location, which I would assume would happen if the password change had been detected (and was going to be written to the local store)
As far as we are aware, nothing has changed. Our safeboot configuration has been stable for > 18months, and none of the device or user settings have been adjusted.
We have 350+ machines and 650+users andd haven't seen any issues until this week.....
I thought it might possibly be a recent MS update from our WSUS, but the issue happens on a freshly built machine which hasn't yet been updated by WSUS.... BTW the build process hasn't been modified in > 6months, so nothing changed their, either....
We have a call with McAfee, and have provided the logs and trace files... this has now been escalated... We'll have to await their repsonse but would appreciate anybody elses insights or suggestions
Thanks for your prompt replies (quicker than McAfee support !! ;-)
No password strength policies in either... We are actually a Novell eDirectory environment (with mirror sync'd AD, which the safeboot connector works with - all fine here, user updates and deletions sync fine). The password policy is configured solely in eDirectory, as this is our primary logon (AD is background)... Again, no changes in last couple of years!
As regards SBGINA.INI again, nothing has changed - we haven't updated the Novell Client or the Safeboot client in months, so I can't see any reason for a change there - same sbgina.ini as was...
99% of password changes are during login - grace logins, password expiry, etc. both novell and windows are changed at same time. Very occasional CAD:Change Password from workstation - again both changed. This has worked flawlessly for the past 18+ months!! Obviously something has changed, but nothing deliberate on our part...!
As I re-visited the forums I realised I hadn't completed this thread, sorry!
It turned out to be an issue with a bad 3rd party application install package... It was modifying the
and not keeping the SafeBootNP5 entry....
Fundamental issue is described in KB66709