Authentication###000-Default und PrimaryOrganisationID

[mplan]

Hallo,

nun muß ich doch zu einem Thema fragen, was eigentlich längst für uns erledigt schien.... ;-) 
In der SysConfig->Authentication###000-Default wurde die LDAP Authentifizierung eingerichtet. 
Bei der Synchronisation ist angegeben:

Code: [Auswählen]

"PrimaryOrganisationID":"departmentNumber" 
Leider wird bei der Anmeldung die Organisation angeblich nicht gefunden. Das Log sagt:

Code: [Auswählen]

[Wed Oct 19 16:35:03 2022][Notice][Kernel::System::Auth::LDAP::Auth] User: NutzerA (uid=NutzerA,cn=eineCN,cn=users,ou=Firma_A,dc=dieseFirma,dc=de) authentication ok (REMOTE_ADDR: ::ffff:172.24.0.6, Backend: "LDAP Kix Benutzer allgemein").
[Wed Oct 19 16:35:03 2022][Error][Kernel::System::Organisation::OrganisationGet][235] ERROR:  invalid input syntax for type integer: "Firma_A", SQL: 'SELECT id, number, name, street, zip, city, country, url, comments, valid_id, create_time, create_by, change_time, change_by FROM organisation WHERE id = ? LIMIT 1'
[Wed Oct 19 16:35:03 2022][Error][Kernel::System::Organisation::OrganisationGet][260] Organisation with ID Firma_A not found in database!
[Wed Oct 19 16:35:03 2022][Error][Kernel::System::Contact::ContactUpdate][790] No valid organisation found for primary organisation ID "Firma_A".
[Wed Oct 19 16:35:03 2022][Error][Kernel::System::Auth::Sync::LDAP::Sync][319] Unable to update contact for user "NutzerA" (uid=NutzerA,cn=eineCN,cn=users,ou=Firma_A,dc=dieseFirma,dc=de)!
[Wed Oct 19 16:35:03 2022][Notice][Kernel::System::Auth::Sync::LDAP::Sync] User: NutzerA not in GroupDN='cn=Gruppe_B,cn=groups,dc=dieseFirma,dc=de', Filter='(memberUid=NutzerA)'! (REMOTE_ADDR: ::ffff:172.24.0.6).
[Wed Oct 19 16:35:03 2022][Notice][Kernel::System::User::SetPassword] User: 'NutzerA' changed password successfully!
In dem LDAP Attribut "departmentNumber" steht bei uns ein String mit dem Kurznamen der Organisation, hier in dem Beispiel "Firma_A".
Das SQL Statement prüft das angegebene Attribut gegen die interne ID der Organisation-Tabelle. Da die ID der Organisations-Tabelle ein inkrementeller Wert ist, kann man schwer auf diese KIX ID abstimmen.Dabei ist "number" die Spalte, die hier besser passen würde, oder? 
   
Kann man das irgendwie anpassen? 
Diese Frage hatte ich in der Vergangenheit schon mal gestellt und dann die Zuweisung der korrekten Organisation über einen Sync-Job gemacht. 
Das wollte ich mir hier eigentlich ersparen....  ;-) 
 
 
Viele Grüße
Michael

[Torsten Thau]

Hallo Michael,


Du verwendest das vermutlich in einer AuthSync und nicht in einem Job (LDAP2Contact). Aus unbekanntem Grund ist dort (AuthSync) die Funktion nicht enthalten. Der Fehler ist bekannt (Issue: KIX2018-7881) und für v27 zur Korrektur vorgesehen.


CU, Torsten

[mplan]

Hallo Torsten,
 
Danke für die schnelle Antwort (und auch die Link-Korrektur).
Es ist richtig, dass AuthSync hier verwendet wird. Wenn man die Organisation über einen Job zuweist, funktioniert es (LDAP2Contact).
Gut zu wissen, dass das Verhalten in einem der nächsten Releases angepasst wird.

Hintergrund dafür ist das Problem/die Frage, was passiert, wenn Benutzer nicht mehr Mitglied der LDAP Gruppe sind.
Über die AuthSync hat man m.E. eine "Live-Abfrage" des Mitglied-Status und kann das Login sperren, wenn der Benutzer nicht mehr Mitglied der Gruppe ist.
Bei einem Job geht das nicht, da ja kein Live-Abgleich erfolgt und einmal gesetzte Rechte bleiben, bis man sie manuell wieder entfernt.

Viele Grüße
Michael

[Torsten Thau]

Hallo Michael,

Dank Herbstferien und Kinder bei Großeltern hatte ich ein paar Stunden Gelegenheit "zu basteln". Wenn Du magst, kannst Du die Dateien im Anhang ausprobieren. Sie beinhalten einige Änderungen die dafür sorgen, dass

• (1) die Auflösung von Werten aus dem LDAP/AD zur PrimaryOrganisationID auch bei AuthSync erfolgt (nicht mehr nur im KIXPro MAcroAction LDAP2Contact)
• (2) auch die mehrfachen OrganisationIDs gesetzt (und von Org.-Nummern zu Org.-IDs aufgelöst) werden können (dazu ist aber das AuthMapping ein wenig anzupassen siehe unten)
• (3) das vollständige Weglassen von GroupDNBasedUsageContextSync im Sync-Mapping dazu führt, dass autom. die Nutzungskontexte der zugeteilten Rollen vergeben werden
• (4) in GroupDNBasedUsageContextSync nicht zugeteilte UsageContexts entzogen werden
• (5) der Entzug von allen UsageContexts den Nutzer ungültig setzt (sollte zuvor schon so sein, war ein Fehler und ist auch in v26 gefixt)

Zum Ausprobieren reicht es erstmal die Dateien in das Backend zu kopieren. Sollte es nicht wie erwartet funktionieren werden die Änderungen durch einen Neustart des Stacks zurück gerollt.

(i) Dateien in den Stack kopieren
Das könnte je nach Stackbenennung bei Dir auch anders aussehen. Ferner ist angenommen, dass das Archiv in /tmp entpackt wurde.

Code: [Auswählen]

usr@dockerhost:/tmp$ docker cp /tmp/LDAPAuth/Kernel/System/Auth/Sync/LDAP.pm kix_backend_1:/opt/kix/Kernel/System/Auth/Sync/LDAP.pm
usr@dockerhost:/tmp$ docker cp /tmp/LDAPAuth/Kernel/System/Contact.pm kix_backend_1:/opt/kix/Kernel/System/Contact.pm

(ii) Konfiguration anpassen

Der Übersichtlichkeit halber ist hier nur der Ausschnit mit dem ContactUserSync dargestellt. Wenn bei Dir nur eine Organisation zugeordnet werden soll und deren Org.-Nummer bspw. in LDAP-Attribut "o" enthalten ist, entferne alle anderen Einträge aus dem Array "OrganisationIDs". Kann keine Nummer gefunden werden, wird versucht den Wert als ID zu interpretieren. Gelingt das auch nicht wird auf den Fallback 1 (Org.-ID) zurück gefallen.

Code: [Auswählen]

          "ContactUserSync": {
            "OrganisationIDs": [
              "SET:2", "SET:12", "SET:23", "o", "l", "SET:9999"
            ],
            "PrimaryOrganisationID": "o",
            "Email": "mailPrimaryAddress",
            "Firstname": "givenName",
            "Lastname": "sn",
            "UserCity": "l",
            "UserLanguage": "st",
            "UserLogin": "uid",
            "UserMobile": "mobile",
            "UserPhone": "telephoneNumber",
            "UserStreet": "street",
            "UserZip": "postalCode",
            "DynamicField_Source": "SET:Test Organizations Sync & PrimaryOrg-Lookup"
          },

...und dann sollte es auch schon funktionieren.

Das ist eine "Freizeitanpassung". Die Bereitstellung erfolgt ohne jegliche Garantie, Gewährleistung oder Haftung. Ich habe es mit einem Test-LDAP geprüft, es sollte auch mit anderen oder einem AD funktionieren. Dazu hatte ich jedoch keine Gelegenheit. ich bitte um Rückmeldung ob es funktioniert und Verständnis, dass eine Übernahme in das Produkt ggf. eine Weile dauern wird, da die Anpassungen n.n. offiziell getestet wurden. Vielleicht hilft es ja dennoch derweil.


CU, Torsten

PS: wenn es funktionieren sollte, können die beiden Dateien mittels bind-mount in das Backend eingehangen werden. Das wäre dann auch "durchstart-stabil", muss aber nach einem jedem Release ggf. nachkontrolliert werden

[mplan]

Hallo Torsten,
vielen Dank für die Antwort und die "Ferienarbeit" ;-)
Nun konnte ich es endlich testen. Die Zuweisung der Organisation funktioniert jetzt wie gewünscht! Vielen Dank!! 

Der Test zum Entzug von Privilegien war leider nicht möglich. Bei uns wird der Benutzer aus der entsprechenden LDAP Gruppe entfernt. Bei der Anmeldung wird er dann abgewiesen.
Da das vor dem Update der Benutzerrechte erfolgt, können zu diesem Zeitpunkt keine Rechte im Kix entzogen werden.
Das ist wirklich etwas "tricky". Man müsste ja eigentlich bei der Anmeldung zusätzlich prüfen, ob der Benutzer bereits  im Kix existiert und prüfen, ob die Ablehnung aufgrund fehlender LDAP Berechtigungen erfolgt und dann die Berechtigungen in KIX entziehen bei der Ablehnung der Anmeldung. 
Weiß nicht, ob das zu bewerkstelligen ist und wie sinnvoll das auch ist.

Was allerdings passiert ist -
Wir haben in dem Abschnitt für die Agenten keine "GroupDNBasedUsageContextSync" vewendet und statt dessen bei "ContactUserSync" gesetzt: "IsAgent": "SET:1", "IsCustomer": "SET:1". 
Die Anmeldung der Agenten ist damit geblockt worden:
   User: 'xxx' changed password successfully! 
   [Kernel::System::Auth::Auth] Login failed. User is not allowed for usage context "Agent".
   [Kernel::System::Auth::LDAP::Auth] User: xxx (uid=xxx,cn=users,dc=meindc,dc=de) authentication ok (REMOTE_ADDR: ::ffff:172.18.0.6, Backend: "LDAP SySC"). 

Die Agenten werden auch über einen LDAP2Contact-Job synchronisiert, was bei der Anmeldung keine Wirkung hatte. 
Erst nachdem der Abschnitt "GroupDNBasedUsageContextSync" mit ""IsAgent": 1, "IsCustomer": 1" eingefügt wurde, konnte man sich wieder anmelden.  (Agenten sollen auch Zugriff auf SSP haben, deswegen IsCustomer=1)
Habe ich da den Punkt (3) falsch interpretiert? Die MA haben alle die "TicketAgent" Rolle.

Wenn man übrigens ein LDAP Attribut angibt, dass es nicht im LDAP gibt, wird dafür die Org-ID 1 gesetzt.  Ist das so gewollt?
Ich hatte gesetzt:

Code: [Auswählen]

"OrganisationIDs": ["departmentNumber","o"], wobei das LDAP Attribut "o" hier an dem User-Objekt nicht existiert.
Es wurde dann dafür die ORG-ID 1 verwendet und der Benutzer wurde zwei Organisationen zugewiesen.
Eventuell könnte man die Zuweisung überspringen, wenn das Attribut nicht gefunden wird und erst bei einer komplett leeren Liste die ORG-ID 1 zuweisen als (dann) primäre Organisation.

Eine Frage hätte ich doch noch.
Wenn bei uns Benutzer mehreren Organisationen zugewiesen sind, gibt es im LDAP einen Eintrag in departmentNumber und mehrere bei "organisations", also

Code: [Auswählen]

departmentNumber: Firma_A
organisations: FIRMA_A
organisations: FIRMA_B


In Authentication###000-Default ist gesetzt:

Code: [Auswählen]

"ContactUserSync": {
                  "Email": "mail",
                  "Firstname": "givenName",
                  "Lastname": "sn",
                  "OrganisationIDs": ["departmentNumber","organisations"],
                  "PrimaryOrganisationID": "departmentNumber",
                  "Phone": "telephoneNumber",
                  "UserLogin": "uid"
               },
               "GroupDNBasedUsageContextSync": {
                  "cn=SSP-User,cn=groups,dc=meindc,dc=de": {
                     "IsAgent": 0,
                     "IsCustomer": 1
                  }Es wird hier nur eine Organisation hinzugefügt. Gibt es hier irgendeine Möglichkeit die gefundenen "organisations" mit aufzunehmen, die ungleich departmentNumber sind?

Hauptsache ist, dass jetzt auch in der AuthSync die Zuweisung der Organisation endlich funktioniert.
Könnte man deine Anpassungen in den Code mit aufnehmen? In welchem Release wäre das möglich (um die jetzt per BIND eingebundenen Dateien wieder zu entfernen)? 

Vielen Dank noch einmal und
Viele Grüße
Michael

[Torsten Thau]

Hallo Michael,

Sorry irgendwie ist das Quotieren abhanden gekommen daher nehme ich mal ">" als Kenner...

>Wir haben in dem Abschnitt für die Agenten keine "GroupDNBasedUsageContextSync" vewendet und statt dessen bei "ContactUserSync" gesetzt: "IsAgent": "SET:1", "IsCustomer": "SET:1".

OK. Das Weglassen des "GroupDNBasedUsageContextSync" hat aktuell den Effekt, dass die Nutzungskontexte der zugeordneten Rollen ausgewertet werden. Das statische Setzen ist womöglich dadurch "unter die Räder" geraten. Das Verhalten sollte sich dadurch korrigieren lassen, dass Du bspw. die Rolle "Customer" oder "Ticket Agent" zuordnest um dadurch indirekt auch die Nutzungskontexte zu setzen. Ich hielt das ausschließliche Verwenden der Rollenzuordnungen für die einfachste Lösung so etwas zu konfigurieren. Man muss sich nicht mehr zwingend um die Nutzungskontexte sorgen.

> Wenn man übrigens ein LDAP Attribut angibt, dass es nicht im LDAP gibt, wird dafür die Org-ID 1 gesetzt.  Ist das so gewollt?

Ja. Derzeit ist das der stumpfe Fallback von "irgendwas-was -es-nicht-gibt" auf Organisation 1. Wenn wir künftig Kontakte ohne Org.-Zuordnungen pflegen könnten, wird das entfallen. Bis dahin wäre noch eine Optimierung die 1 in der Liste der Organisationen wirklich nur dann zu setzen wenn nichts anderes aufgelöst werden konnte. Ich denke das ist durchaus machbar.


> Wenn bei uns Benutzer mehreren Organisationen zugewiesen sind, gibt es im LDAP einen Eintrag in departmentNumber und mehrere bei "organisations", also

OK. Array-Attribute im LDAP. Nein die werden derzeit noch nicht aufgelöst. Aber ich schaue mir das mal an.


> Könnte man deine Anpassungen in den Code mit aufnehmen? In welchem Release wäre das möglich (um die jetzt per BIND eingebundenen Dateien wieder zu entfernen)? 

Diese Anpassungen werden voraussichtlich in v27 enthalten sein.

CU, Torsten

[mplan]

Hallo Torsten, 
 
vielen Dank für die Antworten und Information zur Releaseversion! 
Ich werde die Rollenzuordnunng im AuthSync mal testen. Das klingt für mich nachvollziehbar. 
Wie gesagt, die Rollen für die Agenten haben wir über den Sync-Job (LDAP2Contact) bisher gesetzt und über das AuthSync die "Anmeldeerlaubnis" geprüft.   
Wenn es jetzt mit der Zuweisung der Organisationen funktioniert (und es evtl. eine Lösung für LDAP-Array Attribute geben wird), kann man die grundsätzlichen Rollen bei AuthSync zuweisen, evtl. sogar komplett. 
 
Danke ebenfalls für die Klarstellung zur Org-Zuweisung! 
 
Viele Grüße
Michael