6 Replies Latest reply on Mar 11, 2011 3:41 PM by SafeBoot

    Sync issues with multiple encrypted laptops

      User changes his password on one encrypted laptop, goes to the second encrypted laptop does a sync, logs off and has issues loging back on.


      It appears that the SSO changes did not get to the second laptop during sync.


      We have ver 5.2.8

        • 1. Sync issues with multiple encrypted laptops

          Do you mean the pre-boot password did not get replicated, or the SSO data? They are two very different things.


          The correct process is


          1. change your pw on Laptop 1.


          2. Sync laptop 1 - you should see "updating database token data with local changes" in the log


          3. sync laptop 2 - you should see "updating local token data with database changes" in the log.

          1 of 1 people found this helpful
          • 2. Sync issues with multiple encrypted laptops

            I am talking about being able to log in to multiple laptops after changing the Windows Password.


            1.  User logs in to encyrpted laptop #1

            2.  Changes Windows Password thru widows doing Alt+Ctrl+Del

            3.  User does a sync on laptop

            4.  Admin logs in to encrypted Laptop #2 and does a sync

                 Eventhough we did see on the logs that is updating the user ID SSO and password information, the user can not log in once the admin logs off

            4.  User tries to log in to encrypted laptop #2 and fails, User has to use 12345 to get in


            My work around that problem is to have both laptops logged in at the same time before changing the Windows password.

            • 3. Sync issues with multiple encrypted laptops

              it's really not possible for user A to change their password to "blah" on one machine 1, and have another sync it locally and have that password be "12345" on machine 2 after seeing a "updating database" on machine 1 and "updating local" on machine 2.


              The database can't change the password in the middle.


              Are you sure the password for user A is not "12345" on both machines? That would indicate that the EEPC password template or history is blocking the change.


              If you are using SSO, you really REALLY need to make sure the EEPC password restrictions are less leniant than Windows - for me this means turning off the history and length requirements completley, as well as all the content rules.


              Let Windows manage password strength if SSO is important to you, otherwise this kind of stuff occurs.

              • 4. Sync issues with multiple encrypted laptops

                What I am trying to say that once they change their windows password on #1 laptop, they want to log in to #2 laptop with the same password after the admin does a sync, they can not log in with the new password that was changed to on Laptop #1.


                In other words user changes password, syncs #2 expecting to use the password that he changed to on #1.

                • 5. Sync issues with multiple encrypted laptops

                  I am sorry, I know this is the right sequence, but what I am trying to say is that the second machine is not getting updated, so when you are trying to log in it will not take the new password you set on laptop 1.

                  • 6. Sync issues with multiple encrypted laptops

                    you need to break the problem down to properly analyse it.


                    First, make sure the password is being captured for the user on Laptop 1 and sent to EEM.


                    Second, Make sure the password is correct in EEM


                    Third, Make sure the password is sent to Laptop 2.


                    This works everwhere else, so it will work for your customer as well. Just follow the password change through the environment to find out where the probiem is. I've seen it be everything from the user not actually even changing their password, to using two different user IDs, to machines not even connected to the same DB...


                    So, follow the process, and capture the logs so you have evidence of what's going on at each stage.