Namensänderung kommt nicht in der ID an

[Frank_B]

Hallo Zusammen,

habe hier schon gesucht, bin aber nicht wirklich fündig geworden:
Hier läuft ein Domino 9.0.1 FP10 mit IDVault

Seit geraumer Zeit haben wir das Problem, dass wir bei Namensänderungen ( bspw. Heirat ) zwar die Änderungen im Domino-Adressbuch sehen ( Feld Fullname enthält dann nur den neuen Nachnamen, der alte Nachname fällt raus )

Die Kollegen kommen jedoch nicht auf den Server, da in der ID weiterhin beharrlich der alte Nachname bleibt und der Server nur den neuen Namen kennt.

Namensänderung erfolgt mit Berücksichtigung im ID-Vault.
Nach Umbenennung nehmen wir ergänzend die notes.id aus unserem USB-Stick (backup) per ID-Wechsel um da den neuen Nachnamen zu aktualisieren. Das klappt. nur nicht beim Mitarbeiter selber ( ID dann in seinem data\ Verzeichnis )

Wir behelfen uns dzt. manuell mit ID vom USB-Stick, welche den neuen Namen ja hat. Aber das kann ja nicht die Lösung sein.

- Muss nicht im "Fullname" des Personendokuments auch der seitherige Name drinne stehen ?
- Wieso können wir admins einen ID-Wechsel machen und der Name ändert sich, jedoch beim Mitarbeiter nicht mehr?
- Im ID-Vault stehen an der ID sowohl der neue, als auch gefolgt der alte Name

In der Admin4 siehts soweit auch gut aus. Da ist nix offen.

Hat jemand bitte einen Tipp ? Danke vorab

[CarstenH]

Ist das Ablauf-Datum des neuen Zertifikates größer als das des bisherigen Zertifikates (siehe ID-Eigenschaften "Ablaufdatum der ID-Datei")?
Wenn nicht hast du die Ursache.

HTH
Carsten

[DomAdm]

Hallo,

Seit geraumer Zeit haben wir das Problem, dass wir bei Namensänderungen ( bspw. Heirat ) zwar die Änderungen im Domino-Adressbuch sehen ( Feld Fullname enthält dann nur den neuen Nachnamen, der alte Nachname fällt raus )

Wichtig:
In der ACL des names.nsf muss unter Erweitert bei Aktion "Namensfelder nicht ändern" drin stehen.
https://help.hcltechsw.com/domino/10.0.1/admn_modifyingtheactionfieldintheacldialogbox_c.html
Domino® Directory
By default, the Action field for the administration server for the Domino Directory (NAMES.NSF) is set to Do not modify names fields. Do not change the Action setting for the administration server for the Domino Directory. The purpose of this setting is to allow the Administration Process to update names (people, group, or server names) in critical areas of a database. The Administration Process automatically manages the names in the Domino Directory. Changing the Advanced ACL setting for this database can cause the removal of names which are critical to other Domino features, for example, mail routing and calendaring and scheduling.

[Frank_B]

Wichtig:
In der ACL des names.nsf muss unter Erweitert bei Aktion "Namensfelder nicht ändern" drin stehen.
https://help.hcltechsw.com/domino/10.0.1/admn_modifyingtheactionfieldintheacldialogbox_c.html
Domino® Directory

Treffer, das war falsch eingestellt. Danke

[Frank_B]

Ist das Ablauf-Datum des neuen Zertifikates größer als das des bisherigen Zertifikates (siehe ID-Eigenschaften "Ablaufdatum der ID-Datei")?
Wenn nicht hast du die Ursache.

Wir konnten ja die ID des users auf dem USB-Stick auf den neuen Nachnamen aktualisieren. Das dürfte dann auch ausscheiden. Für den Domino-Server gibt's den "alten" Nachname nicht mehr, mit welchem der User mit seiner seitherigen ID angeflogen kommt. --> Hängt das am Feld "Fullname" des Domino-Adressbuchs oder woanders ? Im Fullname habe ich den alten Namen mittlerweile manuell wieder eingetragen. Auch mal die Ansichten mit Strg-Shift-F9 refreshed. Klappt leider noch nicht. Ich probier weiter.

[CarstenH]

Für den Domino-Server gibt's den "alten" Nachname nicht mehr, mit welchem der User mit seiner seitherigen ID angeflogen kommt. --> Hängt das am Feld "Fullname" des Domino-Adressbuchs[...]?

Ja, der Fullname ist nach Abschluss des Prozesses die einzig verbleibende Möglichkeit den alten Namen zuzuordnen.
Wenn das nicht funktioniert tippe ich auf einen nicht aktuellen Index oder einen Schreibfehler, über das Eigenschaftsfenster (ALT+ENTER) kann man kontrollieren ob im Fullname auch die kanonische Form (CN=xxxxx xxxxxx/OU=yyyyy/O=zzzzzzz) korrekt ist.

Was mich hier aber, mal abseits der Tatsache dass die Einstellung falsch gesetzt war, viel mehr wundert:

Die Änderung von Namensfeldern oder selbst des Personendokuments erfolgt erst nachdem der Nutzer den neuen Namen in seine ID übernommen hat. Erst dieser Schritt triggert alle weiteren Schritte, ohne ID-Übernahme bleibt der Prozess hängen. Es sei denn, die Nutzer sind reine Webuser - dann hätten sie aber gar keine ID (was ebenfalls das Auslassen der Namensübernahme in eine ID erklären würde).
 
Der alte Name wird danach nur noch als Alias für den Mailverkehr verwendet oder, wenn man keinen ID-Vault hat, eine alte ID liegt noch irgendwo und möchte sich beim Authentifizieren aktualisieren.

Damit kann es also [eigentlich] gar nicht passieren, dass der alte Name im Personendokument verschwindet bevor er in die ID übernommen wurde. Eigentlich.

Just wondering.
Carsten

[Frank_B]

Die Änderung von Namensfeldern oder selbst des Personendokuments erfolgt erst nachdem der Nutzer den neuen Namen in seine ID übernommen hat. Erst dieser Schritt triggert alle weiteren Schritte, ohne ID-Übernahme bleibt der Prozess hängen. Es sei denn, die Nutzer sind reine Webuser - dann hätten sie aber gar keine ID (was ebenfalls das Auslassen der Namensübernahme in eine ID erklären würde).
 
Der alte Name wird danach nur noch als Alias für den Mailverkehr verwendet oder, wenn man keinen ID-Vault hat, eine alte ID liegt noch irgendwo und möchte sich beim Authentifizieren aktualisieren.

Wir haben ja die ID auf dem USB-Stick per ID-Wechsel auf den neuen Nachnamen refreshed. Wir Admins waren da quasi schon der User vorab.

Wir haben den alten Nachnamen auch im Personendokument gesehen. Als ich dann gestern bei einigem rumprobieren mal den "tell adminp process all" manuell ausgelöst habe, verschwand dieser und dadurch hatte ich nur noch den neuen Nachnamen im Personendokument. gut, diese Stelle ist ja durch den Hinweis bzgl. der ACL nun behoben. Sollte also nicht mehr passieren.

Ich gehe mal auf den user jetzt zu und seh mal obs "einfach über Nacht" hat sein müssen.

[CarstenH]

Wir haben ja die ID auf dem USB-Stick per ID-Wechsel auf den neuen Nachnamen refreshed. Wir Admins waren da quasi schon der User vorab.

Wir haben den alten Nachnamen auch im Personendokument gesehen. Als ich dann gestern bei einigem rumprobieren mal den "tell adminp process all" manuell ausgelöst habe, verschwand dieser und dadurch hatte ich nur noch den neuen Nachnamen im Personendokument.

Danke für die Auflösung des Rätsels.

Das sind Dinge, die vielleicht im Eröffnungspost hätten erwähnt werden sollen...damit hätte ich mir meinen ersten Post sparen können und die Antwort von DomAdm war dann tatsächlich naheliegend.

Edith: Zwischen den Zeilen stand es, ich hab es nicht für voll genommen. Sorry.

Wieso können wir admins einen ID-Wechsel machen und der Name ändert sich, jedoch beim Mitarbeiter nicht mehr?

Dass ich hier bei eurer Vorgehensweise ein oder zwei Sicherheitsprobleme sehe ... okay, lassen wir das. Problem gelöst und alle sind glücklich.

Carsten

[Frank_B]

Edith: Zwischen den Zeilen stand es, ich hab es nicht für voll genommen. Sorry.

Wieso können wir admins einen ID-Wechsel machen und der Name ändert sich, jedoch beim Mitarbeiter nicht mehr?

Dass ich hier bei eurer Vorgehensweise ein oder zwei Sicherheitsprobleme sehe ... okay, lassen wir das. Problem gelöst und alle sind glücklich.

Carsten

Wir sind im 4-Augen-Prinzip seit Jahren damit revisionssicher aufgestellt. Das ist hier aber nicht das Thema.

Das Problem ist nicht gelöst !! Wir haben jetzt manuell die ID aus unserem Backup zurückgesichert, damit der User arbeiten kann. Das ist aber nicht wirklich die Lösung...

[CarstenH]

Wenn ihr ID-Vault einsetzt verstehe ich nicht, warum es (abgesehen von der falschen ACL-Einstellung, die ja jetzt wieder richtig sein sollte) überhaupt notwendig ist vom normalen Weg abzuweichen, der da sein sollte:

1) Admin stößt Umbenennung an. Idealerweise morgens bevor der Nutzer beginnt zu arbeiten, das erleichtert viele Dinge.
2) Benutzer startet normal sein Notes, authentifiziert sich und übernimmt im Hintergrund seinen neuen Namen in seine ID.
3a) AdminP wird durch (2) getriggert und läuft weiter und (mit oder ohne Nachhelfen) bis zum Ende durch.
3b) Client des Nutzers lädt im Hintergrund seine neue ID in den ID-Vault.

Spätestens am nächsten Tag ist alles durch und die neue Kopie der ID liegt auch im Vault.
Im Personendokument bleibt der alte Name als Alias zurück um Kompatibilität zu alten Mails und Adressen zu gewährleisten.
Eine eventuell vorhandene, alte Kopie der ID auf einem anderen PC wird durch Authentifizierung durch die aktuelle ID aus dem Vault überschrieben.

Wenn ihr mit eurer Vorgehensweise an der Position (2) eingegriffen habt vermute ich, dass z.B. (3b) nie stattgefunden hat.
Ohne euren Eingriff und mit dem Zusatz unter (1) "idealerweise morgens bevor der Nutzer beginnt zu arbeiten" wäre das vermutlich durchgelaufen, das geht auch "über Nacht" wenn man den AdminP entsprechend konfiguriert. Ohne extra ID-Kopie, die sich möglicherweise ohne euer Wissen von der des Nutzers unterscheidet und damit andere Probleme verursacht, wie zum Beispiel Probleme beim Rezertifizieren (Umbenennen).

HTH
Carsten

[Frank_B]

Eine eventuell vorhandene, alte Kopie der ID auf einem anderen PC wird durch Authentifizierung durch die aktuelle ID aus dem Vault überschrieben.

Wenn ihr mit eurer Vorgehensweise an der Position (2) eingegriffen habt vermute ich, dass z.B. (3b) nie stattgefunden hat.

Wahrscheinlich hast du da Recht. Im ID-Vault zeigts im "Owner" sowohl neuer Nachname als auch alter Nachname an.
Vermutlich existiert da wirklich ein Unterschied zwischen ID von unserem Stick und der im ID-Vault.

Das die ACL unserer names.nsf "verbogen" war habe ich bereinigt.
Danke trotzdem für eure Tipps, Tricks & Hinweise...