This content has been marked as final. Show 33 replies
tick ALL the Windows login options. happy
you sir have the patience of a saint cause id say that you have had to dole that same advice out many times to newbies like me!
It also might not have helped that i was using domain\username as a endpoint user instead of just the username.
That seems to have worked.
I've been working with that set of options for 10 years, and I still don't understand the dependencies between them ;-)
You are right though, you need user names to match exactly unless you turn off the "must match username" option, but then that opens up the risk that a pre-boot user will get an administrators windows creds connected to them.
it's best to use the same user names throughout.
Your suggestion to check all of the options for the Windows Logon options isn't something I would recommend.
By ticking the "Require logon to Endpoint Encryption" and "Require re-logon to Endpoint Encryption", you are replacing the Windows GINA with the Safeboot GINA - thereby (given they have a locking screen saver or require unlock from standby, etc) when they need to log back/unlock they will need to put in both their username and password every time.
Far from ideal in our environment - users tend not to like having to add another step to something they do numerous times a day.
We have SSO running in our environment with 2nd, 4th, 5th, 6th, and 7th boxes checked and it usually works - inconsistently albeit. Often users passwords get "messed up" SOMEHOW.
Here's an example specifically from MY experience (I don't trust the end-users as far as I can throw them :-D)
My password is about to expire on the Windows domain. On my Windows XP SP3 box I Ctrl-Alt-Del and change the password and then:
1. I force a "sync" and watch the log say "Updating database with local changes", same goes for "Updating database with SSO changes".... so far so good, right?
a few minutes pass...
2. I go my test/dev box running Vista x64 SP2 and tell the machine to "sync". Instead of seeing it update the LOCAL machine with the DATABASE changes, it updates the DATABASE with LOCAL changes - therby screwing up my passwords.
It takes several iterations of back-and-forth changing before it finally settles on the new passwords across those machines or any other that I am added to in the MEE Machine Groups.
WHY can't it figure out that the DATABASE has the latest information about my passwords/SSO instead of messing up nearly EVERY time?
This isn't normally a problem for the rest of the user community that I can tell - but I still see it on the people who use only one machine too just not as often. Mostly it happens for developers who sign into multiple boxes.
I think the time is wrong between your boxes - it does indeed use the UTC timestamp to work out which way the change should flow.
what most people miss is that getting the password wrong is also a timed event, so if you change your password on one machine, then log on to another getting the password wrong, then log on getting it right, THAT machine will have the later timestamp.
the idea is to try to keep the password that the user knows promoted around the environment - it makes more sense if you consider the situation where the events described above are some days apart. If we didnt do it this way, you'd log on with your (old) password, then it would sync the password change from days or weeks ago to your machine, and then when you reboot it would have "magically" changed to something you probably forgot long ago.
over the last 10 years or so, the current system has proven to be the least-evil of all to most users.
"I think the time is wrong between your boxes - it does indeed use the UTC timestamp to work out which way the change should flow."
Our domain has our computer members set the system time the same as the domain controllers - this would be two machines talking to the same DC in the same location.
The times are accurate down to the second between these two machines. That being the case, even if I waited a few seconds instead of minutes before "syncing" the other machine (which, by the way, is where the machine is at, not at the PBA screen) - the new password on the database side should win out if it has the latest UTC timestamp. Instead the machine takes the password from the local machine and again updates the database with an old password.
"what most people miss is that getting the password wrong is also a timed event, so if you change your password on one machine, then log on to another getting the password wrong, then log on getting it right, THAT machine will have the later timestamp. "
I can guarantee you (since this was my experience, and not an end-user just telling me) that I typed the password in right the first time in this latest attempt.
"the idea is to try to keep the password that the user knows promoted around the environment - it makes more sense if you consider the situation where the events described above are some days apart. If we didnt do it this way, you'd log on with your (old) password, then it would sync the password change from days or weeks ago to your machine, and then when you reboot it would have "magically" changed to something you probably forgot long ago.
over the last 10 years or so, the current system has proven to be the least-evil of all to most users. "
It appears that the system is not working on a UTC timestamp - if it is, SOMETHING isn't working correctly. I have personally had this issue happen with my own username/password. Other IT staff and end users complain of the same issues.
recreate the user token and make sure it syncs to the machines - somewhere a future timestamp may have been set. It's the time >ZONE< and time which are important. Make sure each machine (EEM and clients) are all time and zone correct.
this works for everyone else, so it must too work for you.
Oh, and it's not just this login which is significant, it's EVERY login since the last sync.
Possibly I'm being dim, but that doesn't make sense to me. Let us take this scenario... I have two PCs, PC-A and PC-B, and PC-B is switched off. I log onto PC-A and change my password from password1 to password2 and synchronise. Two days later, I switch on PC-B and, because I know it hasn't synchronised, I use password1 to log on with. You seem to be saying that because I last used password1 to successfully authenticate to SafeBoot that on the next synchronise, my password will be changed from password2 to password1. Is this correct?
Is there some sort of flowchart to demonstrate how this works because I'm confused and so are some of my colleagues.
Every time I think I've got my head round the password/SSO sync process, I come across another tidbit of information which confuses the hell out of me. So, yes, I think a flowchart which defines the actual behaviour would be very useful.
Given that we're on 5.1.7 and this note says that password sync doesn't work properly for that build, it would be great if it covered that build as well.