Endpoint Encryption

We're fairly new to running SEE on our laptops and one thing that keeps coming up is the sync. of AD and SEE passwords. When a user changes his/her password in windows/AD, the new password doesnt work for SEE. If they enter their old password it works fine. Is there something that we're doing wrong? What should the normal behavior be in this scenario?
Thanks
David

 If you are resetting password from AD Users and Computers then you need to check the option -- "user needs to change password at next logon" -- check if this resolves the issue ???

No there is no admin resetting of passwords, its simply when a users password expires and they have to change it (on their client machine).

 For environments with Single Sign On there should be a popup when the user changes the Windows password that says SEE Framework has detected a password change and synchronized.

For environments without Single Sign On there will be no sync and no popup. SEE password is managed separately from Windows Password in this case.

SSO has been working fine for users until their passwords expires and they need to reset it -- is that correct ?? 

is this happening for specific machines and specific users or for all of them ?? also which version you have for see ??

Hi all,

To clarifiy, we're running as follows;

- Auto-logon for the pre-boot environment
- Standard windows logon

Normal operation is fine but then the user changes their AD password and reboots. Sometimes the autologon continues to work but more often it doesnt and they have to complete the pre-boot authentication manually using their OLD AD password (despite the fact that they still have to specify the domain as the AD).

So is the answer basically that this won't work?

 
you've mentioned that first user will authenticate to see after POST and then they'll authenticate to windows -- that means sso is not enabled ..... with see if sso is not enabled then if you change password in windows it will not sync with see ...... 

if you want see should sync with windows password then sso needs to be enabled ..... here to change password for see you need to edit a policy and then go to comp config >> see framework >>> password authentication >>> click on change these settings and choose the option minimum password change ....


let me know if this helps u

OK thanks.. so why does the SEE client use domain accounts even though it can't sync?

Anyway, is there any way of having the following scenario;

- No pre-boot password
- Standard windows logon password
- Password sync with AD.

Or is it that SSO MUST be enabled to have any kind of sync?

Otherwise the other problem then is that the pre-boot password request randomly appears even when set to autologon indefinately..

 you can bypass the initial see authentication window and no Pre boot password too for this you need to do the following ---- when you create see client framework package >> on the second screen i.e. framework installation settings -- registered users >> choose the first option under authentication method i.e. donot require users to authenticate at see platform ...... 

I've just tried that but it didnt help - nothing changed infact!

I then tried enabling SSO but setting auto-logon to active for ever. This seems to cause SSO to sync passwords but present the windows logon box too. So i have

Auto-logon at pre-boot > windows boots > windows logon screen

Am I correct in assuming that the windows password prompt will always appear if autologon in PBE is active and SSO is active? Are there any risks in doing this?

I think you might have deployed the new packages on a client machine that already had see on it ...... if you create the above packages and deploy them on a fresh xp machine then will it work ???

If you enable sso then windows logon screen will not come up ---- after authenticating to see you'll be on working desktop directly ..... as such there is no risk however generally if sso is enabled then you bypass windows logon screen

I spoke to Symantec support on this and basically the 'indefinate autologon' option shouldn't actually be used for indefinate auto logon (so why is it there?!). They also suggested that the password sync problems were a known issue in 7.0.3.