This content has been marked as final. Show 17 replies
Do the 'cached' users on a device get updated at each sync?
Yes, as long as the SB server is aware of the user changes
Do password changes get sync'd from the server to other devices when they sync?
Yes, when a users details get changed every machine that could have that user logon to it will update that user when they next sync
Is there any communication between the boot 'client' authentication and the safeboot server? i.e. if a device boots and the safeboot server is accessible can it check the user/password against the server?
The client cant connect to the SB server at pre-boot level it has to wait untill windows has loaded
I must admit that documentation is pretty sparse for SB, the only docs I have seen are the ones that come with the installation CD.
Thanks for replying. I wish I could find out/see more...
Our testing thus far makes it look like the passwords aren't sync'd... Once a user is on a pair of devices they appear to diverge?!? I've been away for the past week or so and see that Build5400 is now available.
We are just about to pilot in the production environment, so we shall see how it goes...
Our 'solution' is a little cludgy, but we are being forced to progress...
If I find out more I shall post here
Regards and thanks
I too am having a similar 'issue'.
From what I can see, safeboot does not work too well in an environment where users log onto multiple laptops.
LaptopA & LaptopB
UserA Password = 12345
LaptopA is connected to the network.
UserA logs onto LaptopA and is prompted to change their password. They change it to EDCBA.
LaptopB is not connected to the network.
UserA logs onto LaptopB (EDCBA did not work, by chance they tried the old 12345 password) and is prompted to change their password. They change it to ABCDE.
Passwords are all out of sync!
Am i doing something completely wrong?
Unfortunately you're doing it right. It's not a SafeBoot flaw really, it is required to follow a predictable pattern for password changes and synchronization that ends up being an issue in these situations. Multiple users on multiple safeboot laptops can be very difficult to manage.
If you don't mind the SafeBoot password and the Windows/Novell/etc password being in sync then configuring Single Sign On can help with the overall problem. The SafeBoot password will be set to equal the Windows password at Windows login, this will synchronize to the SafeBoot server, eventually all the user passwords will end up where they should be. But if you want the SafeBoot and Windows passwords to be unrelated this is going to continue to be a problem for you. The only thing to really do in this case is train the users so they understand what's happening and why.
This is due to synch intervals.
When a user changes their password, it changes it locally for SafeBoot. That change is sent to the management server at its next synch. For users of multiple laptops, you could instruct them to synch SafeBoot after a password change.
As far as the other machine is concerned, it would pull down whatever information the Management server had at that time.
To reduce the frequency of these problems, reduce the time between synch intervals (or turn if on if you only synch at boot).
If user changes password on Laptop A, synch SB.
If user wants to immediately use Laptop B,null use old password, then synch SB. They can then use the current password on either machine.
Since SafeBoot needs to be able to operate in an offline state, it does not authenticate to the Management server at login.
Thanks for the replies.
Looks like we may have to just live with it for now, and make users aware of the limitation (remember their old password as well!).
Out of curiousity do all full disk encryption products suffer from this issue?
I don't know of any whole disk encryption solutions that allow for real-time authentication. They all work with an offline copy, because the network isn't available during pre-boot.
*** Begin Rant ***
The only exception to this is Vista BitLocker (where your token has nothing to do with your userID), which I don't believe to be an enterprise solution. Vista BitLocker is a solution for home users or small businesses, not an enterprise. I will take great delight in destroying the hopes and dreams of Microsoft loving fools at my company who place their faith in it. There are several points at which I can either get the key or force the system to decrypt the drive. Enterprise encryption needs to have better key management and an AUDIT TRAIL. If a machine is stolen, you can't point to the machine account and tell the lawyers/compliance officers that the stolen machine "should" be encrypted. You need to prove it, not wish for it to be true. Hell, Active Directory has trouble keeping time synched... why would I trust it to ensure end-point encryption.
*** End Rant ***
For those interested, the NSA have published some good advice on how to use Bitlocker to properly secure your machine.
as to the suitability of the solution, that's up to you to decide, but at least someone's gone to the effort of publishing some worthwhile information on how to use it securely rather than insecurely (if you choose to).
Here's a little "gotcha" when dealing with SB password sync and users being associated to multiple laptops.
We have a situation where a tech was required to change their Novell/Windows password. It sync'd with SB on the next login and all was well. A couple weeks later the tech powered up a laptop that had been off network since before the password change. When his current password failed, he didn't think much of it and booted the laptop via single boot machine recovery. When the laptop sync'd, the older password was sync'd into the SB server instead of the newer password being sync'd down to the laptop.
After opening an incident to try to understand why the older pw was sync'd instead of the newer one, we were told it was "by design". After pushing for more details here's what we've learned:
Safeboot does use a time stamp on user tokens. However, when a user has a failed login attempt it synchronizes the failed logins up to the SB server so that an unauthorized user wouldn't have a fresh set of attempts on every laptop the account was associated with. "By design" the way that information is synchronized is by resetting the time stamp which forces the token (failed login data AND PASSWORD) to be sync'd.
I'm hoping that changes can be made soon to sync failed login attempts associated with a token without synchronizing password and all. What is that.....about two lines of code?