7.10.3 - LDAP Import Probleme

Hallo,

eingespielt, angepasst - und gleich zwei Fragen aufgeworfen - aber vorab - Vielen Dank - es ist super jetzt auch in der LDAP-Auth einen User angeben zu können :slight_smile:

Frage/Problem 1)
Beim Import eines User ( vor dem Update tat es ) kommt die Meldung:

–LOG–
Create [UserA] failed
Das Feld Arbeitsplatz entspricht nicht der Notation

Nur bei einem User - und das Feld Arbeitsplatz haben wir weder definiert, noch zugewiesen. Nicht in den Variablen, nicht in der Struktur…

Frage/Problem 2)
Beim Import werden ( ca. 40 User ) Übernommen und auch gemerkt - bei 6 Stück allerdings scheint sich der Importer nicht so ganz so sicher zu sein, löscht diese und legt sie neu an. Was etwas störend ist, da sie dabei aus allen Teams, Rollen, etcpp rausgeworfen werden. Und ganz dummerweise ist einer der Betroffenen unser Geschäftsführer. Die User sind von “schon ewig” im AD ( Geschäftsführer ) bis hin zu “ganz neue” ( Azubi ) - haben keine Umlaute im Namen, sehen auch via LDAP-Browser wie ein ganz normaler User aus.
Gibts die Chance in irgend einem Log zu erkennen, warum der Connector meint, diese paar User löschen zu müssen?

–LOG–
import.io_identity: Delete record [nachname]

import.io_identity: Create [Nachname]
import.io_phonebook: Create [Vorname Nachname]

Einzig was mir aufgefallen ist, ist die Groß/Klein-Schreibung - er löscht einen komplett lowercase “nachname” und fügt einen “Nachname” ein. Ist das ein Ansatz?

Als Temporärer Workaround habe ich im Connector die Option abgeschalten, dass User gelöscht werden - generell finde ich das aber ein sehr schönes Mittel um die Vermüllung des VoIP-Servers zu verhindern.

MfG,
Jesko Mägle

Hallo Jesko,

zu Problem #1: Für jeden Benutzer wird beim Anlegen automatisch auch ein (sogenannter statischer) Arbeitsplatz erzeugt. Die 7.10.03 validiert das aus technischen Gründen wesentlich strenger, u. a. sind keine Umlaute mehr erlaubt. Vielleicht kommt es deswegen zu dem Problem?

zu Problem #2: Ja, da “nachname” != “Nachname” ist, kann das durchaus die Ursache sein. Ich nehme an das diese Benutzer mit einem Uppercase-Nachnamen im Active Directory eingetragen sind?

Grüße,
Jan

Hallo Jan,

zu Problem #1:
Der User hat lediglich im AD-Feld “displayName” einen Umlaut. sn, sAMAccountName, name … alles mit “oe” geschrieben. Ich habe jetzt im Importer statt dem Vorgegeben “displayName” “cn” genommen - und es tut. Schön ist das aber eigentlich nicht, da es im deutschsprachigen Raum durchaus Personen mit Umlauten im Namen geben soll…

zu Problem #2:
Ich habe damit heute morgen schon weiter getestet - und stimme zu, es hat damit zu tun, auch wenn ich das Verhalten auch hier komisch finde. Bei Usern die einen sAMAccountName “Nachname” hatten, hat die Mobydick einen User “Vorname Nachname” angelegt, und beim nächsten Lauf des Importers “nachname” gelöscht und “Vorname Nachname” wieder angelegt. Jetzt habe ich den sAMAccountname im AD auf “nachname” geändert. Nun legt er “Vorname Nachname” an - löscht aber beim nächsten Lauf nicht mehr.
Sprich - obwohl die MobyDick Uppercase-Namen anlegt, müssen sie im AD Lowercase geschrieben sein. Nur dann sieht der Importer die Kombi als gültig an.

Wenn man es weiß - OK - Intuitiv / Logisch ist das nicht :slight_smile:

Ergebnis - es läuft jetzt erst mal beides - glücklich macht es mich aber nicht ganz… Vielleicht sollte der Importer zur Validierung alles hart auf lowercase machen und dann testen. Würde vielleicht ein paar “falsepositives” beseitigen.

MfG,
Jesko

zum Thema “Das Feld Arbeitsplatz entspricht nicht der Notation”
Gibt es hier für auch eine andere Lösung?

Ich kann jetzt nicht noch ein extra Feld hierfür anlegen.

Hallo,

Die 7.10.03 validiert das aus technischen Gründen wesentlich strenger, u. a. sind keine Umlaute mehr erlaubt. Vielleicht kommt es deswegen zu dem Problem?

Das war eine schlechte Idee, wie sich recht schnell herausgestellt hat. In “neueren” 7.10-Versionen ist die Validierung hier wieder nicht so streng. Versuch also bitte mal auf die aktuellste 7.10-Version upzudaten, dann sollte es an dieser Stelle eigentlich keine Probleme mehr geben.

Grüße,
Jan

Es hat sich noch ein kleines “Luxusproblem” aufgetan.

Wir haben einen User, der bei jedem Lauf des Importers aktualisiert wird. Gibt es eine Möglichkeit herauszufinden, warum die MD denkt, dass dieser User-Account ein Update nötig hat? Es wird halt jedes mal dabei die Config neu durchgeladen. Ist nicht böse, müsste aber nicht sein - drum “Luxusproblem” :slight_smile:

Log:


2016-02-10 09:56:13 Die Daten wurden erfolgreich bearbeitet
2016-02-10 09:56:13 Child-Task 210908 wurde mit [1] beendet
2016-02-10 09:56:13 tsk200103: Starte Child-Task 200103 ‘Importieren’, Parameter: [/TARGET/SHARE/var/www/mobydickcmd//tmp/import-io-4.json|4|2]
2016-02-10 09:56:13 Importiere Datei: “/TARGET/SHARE/var/www/mobydickcmd//tmp/import-io-4.json”
2016-02-10 09:56:13 mod_importexport: Reading file /TARGET/SHARE/var/www/mobydickcmd//tmp/import-io-4.json
2016-02-10 09:56:13 Building import structures
2016-02-10 09:56:13 import.mdc_rootImporter: Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:13 Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:13 mod_importexport: Delete orphaned entries
2016-02-10 09:56:13 import.mdc_rootImporter: Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:13 Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:13 mod_importexport: Start import
2016-02-10 09:56:13 import.mdc_rootImporter: Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:14 import.io_identity: Update [mitarbeiter1]
2016-02-10 09:56:14 import.mdc_rootImporter: Cleaning up ImportMap using [18] plugins
2016-02-10 09:56:14 mod_importexport: Done
2016-02-10 09:56:14 count.importrow = 117
2016-02-10 09:56:14 count.skipupdate = 116
2016-02-10 09:56:14 count.update.003user = 1
2016-02-10 09:56:14 Writing context values to “/TARGET/SHARE/var/www/mobydickcmd//tmp/import-io-4.json.out”
2016-02-10 09:56:14 mod_identity: Applying telephony configuration because changed table '003user’
2016-02-10 09:56:14 tsk200103: Child-Task 200103 wurde mit [1] beendet
2016-02-10 09:56:14 tsk210905: Datenquelle CompanyAD wurde erfolgreich synchronisiert

Ich habe mir mit einem LDAP-Browser den User ziemlich genau angeschaut, und kann keine Unterschiede in Groß/Klein, Umlaut, oder sonstigen Dingen finden.

MfGrüßle,
Jesko

Hallo Jesko,

schau dir doch bitte mal unter “Informationen > Importierte Daten” bei der user-tabelle (da gibt es ein kleines dropdown) nach, was die sagt. Evtl. sind hier falsche Informationen hinterlegt?

Grüße,
Jan