objectSID als UID?

[Marvin G. - FZJ]

Hallo zusammen,


aktuell überlege ich, wie ich eine Eindeutigkeit der Benutzer aus unserem anzubindenden AD gewährleistet bekomme. Hintergrund ist, dass bei uns Mailadressen neu vergeben werden können. Scheidet also ein Anwender aus, wird seine Mailadresse gesperrt, nach einer gewissen Zeit gelöscht und ggf. neu vergeben. Das sorgt bei einer AD-Anbindung ans KIX natürlich für Probleme, weil dann ggf. ein Anwender die Tickets eines anderen Anwenders sieht, der vorher die Mailadresse hatte. Am liebsten würde ich daher eine Eindeutigkeit über die objectSID herstellen, da diese nicht neu vergeben werden. Jetzt habe ich mich gefragt, ob ich als UID bei der AD-Synchronisation das Attribut [/font][/size]objectSID aus dem AD angeben könnte und für AuthAtt dann z.B. die Mailadresse damit der Login auch hiermit funktioniert. Und ob das möglicherweise an anderer Stelle für Probleme sorgt.


Oder kann ich möglicherweise alternativ beim Sync eine Anonymisierung/Löschung von Nutzern vor nehmen, wenn diese im AD nicht mehr gefunden werden?


Vielen Dank im Voraus
Marvin

[Torsten Thau]

Hallo Marvin,


OK, hier muss ich etwas weiter ausholen. Es gilt zu beachten, dass ein Kontakt in KIX nicht zwingend auch ein Nutzer sein muss. Nutzer müssen hinsichtlich ihres Loginnamnes eindeutig sein. Kontakte müssen hinsichtlich ihrer Emailadresse eindeutig sein. Ein Nutzer ist (in den allermeisten Fällen) auch einem Kontakt zugeordnet. Im beschriebenen Szenario muss also nicht nur die Eindeutigkeit des Kontakts sondern auch des Nutzers sichergestellt werden. 


Zu den Nutzern: Zusätzlich kommt also die Eindeutigkeit des Nutzerkenners ins Spiel. Um dieses Problem zu lösen, könnte statt UserLogin, wie vorgeschlagen, die objectSID verwendet werden. Damit sich solch ein Nutzer an KIX anmelden können, ist die Verwendung eines "alternativen" Authorisierungskenners möglich (falls jemand seine objectSID nicht aus dem Kopf kennt...). Dafür kann wie erfragt die Mailadresse oder auch der sAMAccountName herhalten. Das alternative Auth.-Attribute wird im Parameter "AuthAttr" einer LDAP-Auth-Sync.-konfiguration angegeben - siehe auch https://docs.kixdesk.com/display/K18AdminDECommunity/Verzeichnisdienste+nutzen


Die "Herausforderung" für ein laufendes System besteht darin dafür zu sorgen, dass bereits bestehende Nutzer im Zuge des Wechsels sAMAccountname => objectSID als KIX-interner Nutzerkenner korrekt aktualisiert werden.


Zu den Kontakten: Ohne Änderung eines Kontakteintrages in KIX z.B. auf eine andere Mailadresse, wird auch die Verwendung der objectSID keinen Nutzen bringen. Im beschriebenen Szenario führt kein Weg daran vorbei einen Kontakt der nun keine gültige Mailadresse mehr hat zu aktualisieren und z.B. eine noreply123@example.com Mailadresse zuzuordnen. Das kann durch Eintragung einer "noreply123@example.com"-Mailadresse im AD erfolgen wenn der UserLogin gleich bleibt. Ein LDAP-Sync würde dann die Mailadresse des Kontakts zum Nutzer aktualisieren. Alternativ kann das auch manuell erfolgen. Ein bloßes Mailadresse-ungültig-setzen reicht nicht aus. Dann kann dessen zuvor verwendete Mailadresse auch wieder für die Anlage eines Kontakts verwendet werden.




Ich hoffe das war jetzt nicht so sehr verwirrend...


CU, Torsten

[Marvin G. - FZJ]

Hallo Torsten,


soweit habe ich das verstanden, vermute ich. Vielen Dank für die Erklärung.


Wenn ich beim Ausscheiden eines Kunden bei uns (und die damit verbundene Löschung in unserem AD - inklusive Mailadresse) hingehe und den Nutzer lösche, dem Kontakt eine andere Mailadresse zuweise, kann der Nutzername und die Mailadresse wieder für einen neuen Kontakt (und Nutzer) verwendet werden?   
Oder gibt es dann auch Probleme, weil am Ticket der Nutzer hängt, und der Kontakt nur optional ist? Bzw. gibt es Probleme mit Fremdschlüsseln in der Datenbank?




Viele Grüße 
Marvin

[Torsten Thau]

Hallo Marvin,


sorry - habe Deine Antwort-Rückfrage nicht mitbekommen.  Nutzer und Kontakte können derzeit nur über die REST-API getrennt gepflegt werden. Aber grundsätzlich wäre Dein Vorgehen OK.

Falls der Nutzer aber auch als Agent tätig war, ist das Löschen nicht so einfach, da es zahlreiche FK-Verweise gibt. Bei den "reinen Kontakt-Nutzern" ist es unkritisch.

CU, Torsten