7 Replies Latest reply on May 3, 2018 3:29 PM by MarkLarvo

    LDAP/Employees - How have you handled LoginID changes?

    MarkLarvo Specialist

      Good day!

       

      We are preparing for a full rollout and recently began exploring a full LDAP integration of all employees. The short story is that we allow LoginID changes when people marry, divorce, etc... Our Employee number is our unique value for personnel.

       

      LDAP was creating new employee records for the new login ids which meant duplicate employee numbers. We changed LDAP to match on the employee number instead.

       

      LDAP has a checkbox to overwrite the LoginID but I have been warned about losing "history" and "assignments" for people since most screens, lists, etc use the CurrentUserLoginID.

       

      From Support:

      LoginID and PrimaryEmail are the two unique fields used to identify Employees. If you change the LoginID in the Employee record you risk losing all their 'history' (all old Incidents, email. notes, etc) as it will be treated as a new Employee. This is why it is not updated automatically.

       

      There is a setting to copy over the LoginID also, its the 'Override Employee Login (Warning: Employee will no longer be able to view existing assigned records like incidents, tasks etc)'  checkbox on the mapping page.

       

      If the Employee is not the Owner of any Incidents, Tasks, Service Requests, etc then changing the LoginID is not that tricky. They have no history to lose.

      If the Employee DOES own Incidents, Tasks, etc then those will need to be re-assigned to the new owner (new LoginID), which can be tricky but can be done.

       

      Checking the checkbox to 'Override Employee Login...' will do every record with a new LoginID in the LDAP import - so be careful doing this, and be prepared to re-assign Incidents, etc to a new LoginID should one of them get changed. Their old Incidents will no longer show on Searches or grids as most of those Searches use CurrentLoginID() or similar function.

       

      Looking for your creative solutions to deal with LoginID changes... Thanks - Mark.

        • 1. Re: LDAP/Employees - How have you handled LoginID changes?
          AlasdairRobertson ITSMMVPGroup

          Capture the old LoginId on change in a new field then run a workflow (run for search RecId = xxx then update fields as needed) to update all non closed objects (you could do closed as well but not sure its worth the effort on a large system) with the replacement values based upon RecId using Owner_valid or similar depending on object.  Do the main objects that you are using Incident etc. include Task and Journal.  As part of your workflow you can drop the employees External Login record and create with the new one.

           

          Its the cleanest way I have found of doing this currently but open to new ideas.

          1 of 1 people found this helpful
          • 2. Re: LDAP/Employees - How have you handled LoginID changes?
            ASandy Rookie

            You can add custom binary(20) field to Employee object, map one to LDAP AD GUID  and use AD GUID as key for synchronization.

            1 of 1 people found this helpful
            • 3. Re: LDAP/Employees - How have you handled LoginID changes?
              florian1 Expert

              An indexed string with 32 characters length storing the AD objectGUID works just fine for us.

              Just make sure the "HEAT Contact Field" name in the LDAP settings is set to objectGUID and "override employee login" is checked.

               

              For anything using the CurrentLoginId() functions you will have to create workflows as Alasdair said.

              If you are using WIS, make sure to delete & recreate an external login as well.

              1 of 1 people found this helpful
              • 4. Re: LDAP/Employees - How have you handled LoginID changes?
                IJU Apprentice

                Hi all,

                 

                to make it easy: why change the loginId at all? Just have it be a unique number or whatever and then don't worry about history being created with that login Id. :-)

                We have customers who just use their employee id to login which does not look like a combination of the first and lastname.

                 

                But other than thinking about leaving the login Id as it is I see no other option as what the others already suggested.

                 

                Beste Grüße / Best Regards

                 

                Immanuel Jungheim
                Consultant

                 

                ITSM Consulting GmbH |   Germany   |   D-55294 Bodenheim   |   Am Kuemmerling 21-25   
                Mobile: +49 151 29256681 |   Tel.: +49 6135 9334 0   |   Fax: +49 6135 9334 22   |   E-Mail: [email protected]   |   Web: www.itsmgroup.com

                 

                ITSM Group – Be Better

                Geschäftsführer: Siegfried Riedel, Amtsgericht Mainz HRB 47740

                Diese E-Mail ist vertraulich zu behandeln. Sie kann besonderem rechtlichen Schutz unterliegen. Wenn Sie nicht der richtige Adressat sind, senden Sie bitte diese E-Mail an den Absender zurück, löschen die eingegangene E-Mail und geben den Inhalt der E-Mail nicht weiter. Jegliche unbefugte Bearbeitung, Nutzung, Vervielfältigung oder Verbreitung ist verboten. / This e-mail is confidential and may also be legally privileged. If you are not the intended recipient please reply to sender, delete the e-mail and do not disclose its contents to any person. Any unauthorized review, use, disclosure, copying or distribution is strictly prohibited.

                • 5. Re: LDAP/Employees - How have you handled LoginID changes?
                  MarkLarvo Specialist

                  Alasdair,

                   

                  Thanks for breaking this out. I figured it was going to have to be something like this. Your explanation of the items to look out for is helpful!

                   

                  Now to explain this situation to management and why I need more development time! ;-)

                   

                  Many thanks! Mark.

                  • 6. Re: LDAP/Employees - How have you handled LoginID changes?
                    MarkLarvo Specialist

                    Thanks Florian & ASandy.

                     

                    I went with our employee number as we store that in AD. This number syncs back to our HR and Financial systems for extra tie in.

                     

                    Your responses are appreciated! Mark.

                    • 7. Re: LDAP/Employees - How have you handled LoginID changes?
                      MarkLarvo Specialist

                      Hi Immanuel,

                       

                      I am just a little cog in the machine. I am not in a position to tell 4000 people how to log in or retool our network. ;-)

                       

                      Thanks for the reply! Mark.