Weshalb Sonderzeichen im Active Directory uncool sind…!

Endlich habe ich ein stichhaltiges Argument gegen Sonderzeichen in AD-Objekten gefunden. Bisher war ich einfach nur vorsichtig und habe diese NIE in Erwägung gezogen. Mir war stets bewusst, dass es im Zusammenspiel mit mehrsprachigen Umgebungen zu unschönen Vorkommnissen kommen kann – jetzt habe ich jedoch auch ein weltlicheres Argument gegen Sonderzeichen… Naja: So absolut weltlich ist es vielleicht auf den ersten Blick nicht – aber jeder wird wohl in den nächsten Jahren einmal in diese Situation kommen, sobald eine Migration ansteht…

Bei einer Migration in eine neue Gesamtstruktur (Inter-Forest), mussten auch die entsprechenden Exchange-Mailboxen migriert werden. Dabei ist auch alles gut gegangen – immerhin haben wir ja auch extra dafür das Tool „CrossOrgMailboxMover“ programmiert, welches auf dieser Website zum Download bereit steht. Die Tests zeigten dann auch, dass der Mailfluss nach der Umschaltung von extern und auch von intern gewährleistet war und alles soweit funktionierte. In den folgenden Tagen haben wir jedoch vernommen, dass gewisse Benutzer intern spezifischen anderen internen Benutzern keine E-Mails schreiben konnten. Diese erhielten sofort einen NDR zugestellt, welcher besagte, dass die E-Mailadresse des Ziels nicht gefunden werden konnte:

Generierender Server: exchangeserver.domaene.com
IMCEAEX-_O=Exchange-Org_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=R+3Fmer+2C+20Andreas+20-+20ET11091@domaene.com
#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

Dies betraf jedoch ausschliesslich diejenigen Zielbenutzer, welche mindestens ein Sonderzeichen (einen Umlaut, etc.) im Namen hatten. Im obigen Beispiel wäre dies „Andreas Römer“ – das „+3F“ steht für ein „ö“…

Der Benutzer hatte jedoch lediglich eine SMTP-Adresse eingetragen – keine X.500-Adresse, noch sonst irgendwas spezielles. Von extern klappte die Zustellung der Mails an diesen Benutzer – nur andere interne Benutzer konnten keine E-Mails übermitteln. Was war nun der Fehler? Das Grundproblem ist, dass Exchange die interne Zustellung auch in der Version 2010 immer noch über das Attribut „LegacyDN“ eines Mail-Objekts vollzieht. Dieses sieht bei näherer Betrachtung eigentlich voll und ganz in Ordnung aus und hat in etwa das folgende Format:

/o=Exchange-Org/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Römer Andreas

Diese Schreibweise ist eigentlich auch für jegliche Konten so absolut i.O. – jedoch nicht bei Benutzern, welche ein Sonderzeichen im Namen enthalten. In diesen Fällen kreiert Exchange (der RUS – Recipient Update Server oder auch Empfängeraktualisierungsdienst genannt) einen speziellen CN (Common Name) im Format von „cn=user98738475“ – d.h. mit einer Zufallszahl hinten an den Wert „user“ angehängt. Dies geschieht auch dann, wenn ein Benutzerobjekt mit demselben CN mehrfach in einer Domäne vorkommen sollte (was in verschiedenen Organisationseinheiten grundsätzlich möglich ist).

Was ist nun passiert? Bei der Migration wurde das Attribut „LegacyDN“ korrekt neu zusammengesetzt und gespeichert. Es wurde jedoch dabei nicht beachtet, dass es sich um einen speziellen Benutzer (oder auch Verteilergruppe, Kontakt, etc.)  handelte. Den Wert mit der Zufallszahl kann sowieso nur von Exchange selbst erstellt werden (vom RUS). Somit war es nicht mehr möglich, intern eine E-Mail an diese Personen zu übermitteln.

Was ist die Lösung? Da der RUS den Wert unter „LegacyDN“ neu schreibt, sofern dieser nicht gesetzt sein sollte, kann dieses Attribut mittels „ADSIEdit.msc“ oder auch dem Attribut-Editor von ADUC (ab Windows Server 2008) gelöscht (zurückgesetzt) werden. Bei Bedarf kann der RUS neu angekickt werden, damit die Aktualisierung sofort erfolgt. Im Anschluss sollte bei den betreffenden Benutzer im Attribut „LegacyDN“ der korrekte Wert mit der Zufallszahl stehen und die E-Mails ergo auch intern korrekt ankommen.

Hier noch zwei interessante Links zum Thema:

http://support.microsoft.com/kb/925397
http://www.msxfaq.de/server/legacyexchangedn.htm

Die bessere Lösung: Sprecht mir nach: „Ich gelobe keine Sonderzeichen in meinem Active Directory zu erfassen“… ;-D

VN:F [1.9.22_1171]
Rating: 10.0/10 (4 votes cast)
VN:F [1.9.22_1171]
Rating: +1 (from 3 votes)
Weshalb Sonderzeichen im Active Directory uncool sind...!, 10.0 out of 10 based on 4 ratings

Schreib einen Kommentar