Hauptmenü

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

Begonnen von danielwi, 03.08.2022 08:06:50

⏪ vorheriges - nächstes ⏩

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
select * from general_catalog where general_catalog_class='ITSM::ConfigItem::Class';

Die Ausgabe sieht dann z. B. so aus:

  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:

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:

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:

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

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