LDAP ANbindung - CustomerKey und Auth UID nachträglich ändern

[danielwi]

Hallo zusammen,


leider ist mir bei der Ersteinrichtung unserer Kix-Instanz ein dummer Fehler passiert. Unsere Kundenauthentifizierung läuft über LDAP, das funktioniert soweit auch problemlos. Leider habe ich mich stark an diversen Tutorials orientiert, die im Internet kursieren und diese nutzen alle als CustomerKey den sAMAccountName.:


CustomerKey => 'sAMAccountName',


Für die Authentifizierung der Agenten gilt das gleiche:
$Self->{'Customer::AuthModule::LDAP::UID'} = 'sAMAccountName';


Das ist natürlich bescheuert, wenn sich der Name des Users ändert und damit auch der sAMAccountName. Denn dann sind alle zugeordneten Tickets und Config-Items noch mit dem alten Benutzer verknüpft. Ich würde gern die UID des AD-Benutzers nutzen:


CustomerKey => 'uid',
$Self->{'Customer::AuthModule::LDAP::UID'} = 'uid';


Damit würden zwar alle neuen Tickets korrekt verknüpft, aber alle bisherigen Einträge wären dann tot. Ich muss also auf Datenbankebene einen ganzen Haufen
Änderungen machen, damit die Zuordnungen bleiben. Wo muss ich da ansetzen? In welchen Tabellen und Feldern muss ich den sAMAccountName gegen die UID tauschen, damit die Zuordnung erhalten bleibt?


Vielen Dank schonmal im Voraus.
VG
Daniel

[danielwi]

Hallo,


hat denn bisher niemand so eine Umstellung vornehmen müssen bzw. gibt es aus dem Team niemanden, der mir die entsprechenden Felder nennen kann?


VG

[Benedikt Geißler]

Hallo Daniel,

du musst in der Tabelle 'ticket' jeweils das Attribut 'customer_user_id' anpassen. Darin muss die uid aus dem LDAP eingetragen werden, damit die Zuordnung weiterhin passt.

Viele Grüße
Benedikt

[danielwi]

Danke, das werde ich mal ausprobieren.
Wie verhält es sich mit den CIs, wenn ich das mache? Wie werden die Daten denn dort in den XML-Daten verknüpft?

[Benedikt Geißler]

Bei den ConfigItems gestaltet sich das schwieriger. Ich skizziere daher mal nur grob, was zu tun wäre – in diesem Beispiel nutze ich PostgreSQL und KIX Pro:

Jede CI-Klasse im GeneralCatalog hat eine ID. Eine Übersicht dazu erhält man mit dem SQL-Statement

Code Auswählen Erweitern

select * from general_catalog where general_catalog_class='ITSM::ConfigItem::Class';

Die Ausgabe sieht dann z. B. so aus:

Code Auswählen Erweitern


  id |  general_catalog_class  |    name     | valid_id |          comments          |     create_time     | create_by |     change_time     | change_by
-----+-------------------------+-------------+----------+----------------------------+---------------------+-----------+---------------------+-----------
  22 | ITSM::ConfigItem::Class | Computer    |        1 |                            | 2022-10-20 16:49:16 |         1 | 2022-10-20 16:49:16 |         1
  23 | ITSM::ConfigItem::Class | Hardware    |        1 |                            | 2022-10-20 16:49:16 |         1 | 2022-10-20 16:49:16 |         1
  24 | ITSM::ConfigItem::Class | Location    |        1 |                            | 2022-10-20 16:49:16 |         1 | 2022-10-20 16:49:16 |         1
  25 | ITSM::ConfigItem::Class | Network     |        1 |                            | 2022-10-20 16:49:16 |         1 | 2022-10-20 16:49:16 |         1
  26 | ITSM::ConfigItem::Class | Software    |        1 |                            | 2022-10-20 16:49:16 |         1 | 2022-10-20 16:49:16 |         1
135 | ITSM::ConfigItem::Class | Workpackage |        1 | added by package installer | 2022-11-24 09:04:38 |         1 | 2022-11-24 09:04:38 |         1
136 | ITSM::ConfigItem::Class | Project     |        1 | added by package installer | 2022-11-24 09:04:38 |         1 | 2022-11-24 09:04:38 |         1
137 | ITSM::ConfigItem::Class | Beispiel    |        1 |                            | 2022-12-02 10:16:01 |        34 | 2022-12-02 10:16:01 |        34
138 | ITSM::ConfigItem::Class | Beispiel2   |        1 |                            | 2022-12-02 10:40:18 |        34 | 2022-12-02 10:40:18 |        34
139 | ITSM::ConfigItem::Class | Beispiel3   |        1 |                            | 2022-12-02 11:25:29 |        34 | 2022-12-02 11:25:29 |        34
(10 rows)


Für jede dieser CI-Klassen gibt es bei KIX Pro dann noch 4 Tabellen, die jeweils die Daten dazu beinhalten. Für die CI-Klasse Computer wären das ci_22_content, ci_22_content_archive, ci_22_dict_key und ci_22_dict_value. Also immer ci_<ID der CI-Klasse>_*. Mit diesen beiden SQL-Statements erhält man eine Übersicht der Daten aus der CI-Klasse Computer:

Code Auswählen Erweitern


select * from ci_22_dict_key as dk join ci_22_content as c on dk.id=c.dict_key_id join ci_22_dict_value as dv on dv.id=c.dict_value_id;
select * from ci_22_dict_key as dk join ci_22_content_archive as c on dk.id=c.dict_key_id join ci_22_dict_value as dv on dv.id=c.dict_value_id;


In der Ausgabe erhalte ich u. a. eine Zeile wie diese, die einen Verweis auf einen Kundennutzer enthält:

Code Auswählen Erweitern


id |                      xml_content_key                       | dict_key_id | dict_value_id | xml_key | tmp | id | xml_content_value
----+------------------------------------------------------------+-------------+---------------+---------+-----+----+-------------------
11 | [1]{'Version'}[1]{'Owner'}[1]{'Content'}                   |          11 |             3 |       2 |   0 |  3 | Alma.Plate


Um nun dieses Vorkommen etwa von Alma.Plate in Berthold.Brecht zu ändern, wäre z. B. ein solches SQL-Statement geeignet:

Code Auswählen Erweitern


update ci_22_dict_value set xml_content_value='Berthold.Brecht' where id in (
    select dict_value_id from ci_22_dict_key as dk join ci_22_content as c on dk.id=c.dict_key_id join ci_22_dict_value as dv on dv.id=c.dict_value_id where xml_content_key like '%Version%{_Owner_}%Content%' and xml_content_value='Alma.Plate'
);


Nach diesem Schema ist dann pro CI-Klasse und darin wiederum pro Verwendung eines Kundennutzerverweises ein Update-Statement nötig.

Bei KIX Start liegen die Informationen zu den CIs alle in der Tabelle "xml_storage" und nicht nach CI-Klassen verteilt in separaten Tabellen, da entfällt dann das Subquery im Update-Statement. Also in etwa

Code Auswählen Erweitern


update xml_storage set xml_content_value='Berthold.Brecht' where xml_content_key like '%Version%{_Owner_}%Content%' and xml_content_value='Alma.Plate' and xml_type='ITSM::ConfigItem::22';


Viele Grüße
Benedikt

[danielwi]

Ja, durch die XML-Strukur hatte ich mir schon gedacht, dass das ein ziemlicher Knüppel wird und hohes Fehlerpotential beinhaltet. Deine Ausführungen helfen mir auf jeden Fall schonmal weiter und ich werde das auch mit Sicherheit angehen, wenn ich die Zeit dazu habe. Klarer Fall von falscher Design-Entscheidung am Anfang, der sich am Ende richtig rächt.


Danke für die Mühe und die ausführliche Erklärung. :)


VG
Daniel