Sonderzeichen in Userprofile

Diese Seite beschäftigt sich mit erlaubten und verbotenen Sonderzeichen in AD-Feldern und Dateisystemen. Diesmal durch ein Ticket bei dem Microsoft Teams im Dez 2022 nicht mehr starten konnte.

Auslöser

Auslöser war ein Ticket bei einem Kunden, bei dem von heute auf morgen Microsoft Teams (Electron, Version 1.5.00.34154) nicht mehr starten konnte. Nach gefühlt mehreren Minuten ohne Aktivitäten hat Teams folgende Fehlermeldung geliefert. Einige Wochen vorher hat sich schon die WhiteBoard-App nicht mehr nutzen lassen aber nun war der Teams Client unbrauchbar.

Wobei der Begriff "Fehlermeldung" so nicht stimmt, denn es wurde ja erst mal gar nichts angezeigt.

Die Gegenprobe mit "Teams im Browser" war weiterhin nutzbar. Leider ist Teams im Browser nicht 100% identisch, z.B. CallQueue Steuerung über Kanäle geht nicht.

Es musste als etwas mit der App oder dem Client und der lokalen Installation sein. Aber selbst nachdem alle Daten gelöscht und Teams neu installiert wurde, konnte Teams nicht mehr starten. Hier muss es sich um einen Bug handeln, aber was war die Ursache?

Umgebung

Die Umgebung bei dem Kunden war aus Sicht von Microsoft schon sehr fortschrittlich, denn es gab zwar noch ein lokale AD, welches aber in dem Fall nicht relevant war. Der "Sonderfall" war hier, dass gleich mehrere Dinge zusammen gekommen sind.

  • AzureAD Joined Client
    Die Computer waren nicht Mitglied einer lokalen AD-Domäne sondern nur im AzureAD registriert und wurden per InTune verwaltet.
  • CloudOnly User
    Die Anmeldekonten wurden nicht mit ADSync aus einem lokalen AD erstellt sondern direkt in der Cloud angelegt. Das ist durchaus ein sinnvoller Weg für externe Mitarbeiter, Dienstleister oder freischaffende Personen, die nicht als Angestellte einer Firma arbeiten sondern nur Cloud-Dienste nutzen. Diese Konten hatten daher auch keine "On-Premises-*"-Attribute im Azure AD:
  • Displayname mit Abteilung in Klammern
    Auch die Festlegung des Displaynamens auf das Format "%Vorname% %Nachname% (%Firma%)" ist gar nicht mal so unüblich in Firmen, damit z.B. im Outlook Adressbuch direkt schon die Firma oder Abteilung sichtbar ist.

Diese drei Voraussetzungen sind nicht zwingend notwendig, aber führen unter anderem dazu, dass das Profil-Verzeichnis des Anwender etwas "komisch" aussieht:

Das sieht schon mal komisch aus aber hat monatelang niemand gestört. Aber das war der einzige Unterschied zwischen Benutzern, bei denen Teams weiter genutzt werden konnte und wo Teams nicht mehr genutzt werden konnte.

Testserie HomeDirectory

Also habe ich in meinem Labor einige Testbenutzer angelegt. Ich wollte so verschiedene Benutzer zum experimentieren haben und zudem mehr darüber erfahren, wie Windows den Pfad zum Userprofil ermittelt. Daher habe ich einige AzureAD-User angelegt aber auch einen Benutzer im lokalen AD erzeugt und mit ADSync replizieren lassen.

In meinem AzureAD habe ich folgende Benutzer angelegt und dabei auch unterschiedliche Längen für den Displaynamen verwendet. Der SamAccountName ist ja auch 20 Zeichen beschränkt. Alle Benutzer konnten sich problemlos am AzureAD-Joined Desktop anmelden und bekamen ein Userprofil

Displayname UPN MailNickname On-Premises SAM account name HomeDir Status

Acht.Klammer(45678

Acht.Klammer45678@msxfaq.net

Acht.Klammer345678

<leer>

AchtKlammer(45678

Fail

Karl Klammer (Abteilung)

Karl.Klammer@msxfaq.net

Karl.Klammer

<leer>

KarlKlammer(Abteilun

Fail

CarlClippy(23456789

CarlClippy.23456789@msxfaq.net

CarlClippy.23456789

<leer>

CarlClippy23456789

Fail

Kurz (1

Kurz.Klammer@msxfaq.net

Kurz.Klammer

<leer>

Kurz(1

Fail

Kurz (2)

Kurz.Klammer2@msxfaq.net

Kurz.Klammer2

<leer>

Kurz(2)

OK

No Klammer

NoKlammer@msxfaq.net

NoKlammer

<leer>

NoKlammer

OK

ADsync Klammer (14)

ADsync.klammer@msxfaq.net

adsync.klammer

adsync(klammer  (der On-Premises Name)

adsync(klammer

Fail

COM1

COM1@msxfaq.net

COM1

<leer>

temp  (temporäres Profil!)

OK

Aus diese Testserie leite ich folgendes ab:

  • Windows 10/AzureAD/HomeDir
    Die Windows Installation leitet des Pfad des Heimatverzeichnisses aus dem AzureAD-Feld "On-Premises SAM account name" ab, wenn er gefüllt ist.
    Ist das Feld leer, dann wird der Displayname als Quelle genutzt und nicht erlaubte Zeichen werden entfernt und auf 20 Stellen abgeschnitten
  • Windows 10 / Lokales AD
    Bei der Anmeldung an einem Domain-Joined Computer mit einem AD-Konto ist der SamAccountName immer gefüllt und wird als Name für das Heimatverzeichnis genutzt. Auch hier ist ein "(" durchaus erlaubt aber wird vermutlich kaum von Firmen genutzt. Seit der Anmeldung per UPN wird der SamAccountName primär aus Kompatibilitätsgründen mitgeführt.
  • Teams/Win 1.5.00.34154 kann keine Klammern
    Sobald im Homeverzeichnis des Benutzers eine "runde Klammer" vorhanden ist, startet Teams nicht mehr. Allerdings nur, wenn es keine passende schließende Klammer gibt

Ich interpretiere das so, dass Teams eigentlich keine Probleme mit der Klammer an für sich hat, sondern nur, wenn diese nicht geschlossen sind.

Recherche

Nun mag eine "Runde Klammer" ungewöhnlich sein, aber sie Sie auch erlaubt? Eine kurze Recherche ergab:

Umgebung Beschreibung und Links

Windows Explorer

Mein erster Anlaufpunkt war der Windows Explorer. Ich habe versucht, ein bestehende Verzeichnis mit einem Sonderzeichen zu versehen. Die Fehlermeldung sagte direkt, welche Zeichen nicht erlaubt sind:

Das sind auch die gleichen "reservierten" Zeichen, die Microsoft hier dokumentiert hat. Hier sind die Zeichen "(" und ")" aber nicht aufgeführt und können damit problemlos genutzt werden.

Die älteren Administratoren kenne sicher noch besonders geschützte Zeichenketten wie "COM1", "LPT1" aus alten DOS-Zeichen. Sie können im Active Directory tatsächlich einen Benutzer mit dem SamAccountName "COM1" anlegen und sich sogar anmelden. Er bekommt aber nur ein temporäres Profil, was am Ende wieder gelöscht wird.

Nicht was alles möglich ist, sollte daher genutzt werden.

SamAccountName

Das Feld "SamAccountName" ist den alten NT4-Administratoren noch als "Anmeldenamen" bekannt. Damals gab es noch keinen UPN und die Anwender habe sich mit einem Anmeldename oder "User-ID" angemeldet. Der Name war auf 20 Stellen beschränkt und die meisten Administratoren haben hier wirklich deinen Teil des Namens verwendet. Aus meinem Frank Carius hatte ich je nach Kunden dann Anmeldenamen wie:

fcarius, frankc, fc, ext.carius, frank.carius, carius2

Sie können sich sicher noch mehr Konstruktionen vorstellen, wie längere Benutzernamen in die 20 Stellen gepresst werden. Damals waren Sie aber auch gut beraten, den Namen vielleicht auf acht Stellen zu kürzen. So konnte nicht nur der Anwender einen kürzeren Namen bei der Anmeldung verwenden sondern als Administrator konnten Sie auch das Heimatverzeichnis z.B. mit %USERNAME% per NET USE (Windows) oder "MAP.EXE (NetWare) verbinden. Damals galt ja durchaus noch die 8.3-Namenskonvention für FAT-Dateisysteme.

Das Feld "SamAccountName" spielt "On-Premises" eine wichtige Rolle bei der Benennung des Heimatverzeichnisses. Hier gibt Microsoft eine Größenbeschränkung von 20 Zeichen vor und verbietet auch einige Sonderzeichen. Hier sind auch die Zeichen "/", "=" und "+" verboten, die beim Dateisystem noch erlaubt sind.

Interessanterweise sind die hier neben "\" und "/" auch die "eckigen Klammern" und die "spitzen Klammern" ausgeschlossen aber die "runden Klammern" nicht. Das hat mich natürlich neugierig gemacht, welche Folgen dies hat. Auch die Sonderzeichen "$", die in der PowerShell eine Variable kennzeichnen oder "%" als Ganzzahldivision oder "!" (Not bei LDAP und PowerShell) etc. sind nicht verboten. Sie sehen also schon, dass einige Zeichen durchaus Konfliktpotential haben.

AzureAD UPN

Dann habe ich einen Benutzer direkt in der Cloud angelegt und auch hier wurden bestimmte Zeichen nicht akzeptiert:

Hier wird aber keine Deny-Liste aufgeführt, sondern gleich eine AllowListe beschrieben. Erlaubt sind also A-Z,0-9 und "_,-,'."

ADSync

Bei der Replikation zwischen lokalem AD und AzureAD werden sehr viele Felder abgeglichen und hier kommt es ganz schnell zu Konflikten oder unterschiedliche Einschränkungen. Microsoft beschreibt dazu die Voraussetzungen, die Sie vorab und im laufenden Betrieb einhalten sollten, da ansonsten ADSync einen Fehler generiert.

Verlassen Sie sich nicht darauf, dass die MMC für Benutzer und Computer alle Regeln kennt!

Bei den Tests ist mir On-Premises noch ein Verhalten (Windows 2016 DC) aufgefallen
UPN = "COM1(Klammer)" erlaubt
UPN = "COM1(Klammer" nicht erlaubt.

Da scheint auch eine LDAP-Abfrage intern mit den Klammern durcheinanderzukommen und ich kann durchaus eine runde Klammern im UPN eingeben, solange ich sie auch wieder schließe. ADSync fällt dann aber auf die Nase, denn runde Klammern sind im UPN in der Cloud nicht erlaubt.

Unable to update this object in Azure Active Directory, because the attribute [userPrincipalName], 
   is not valid. Update the value in your local directory services.
Tracking Id: <guid>
ExtraErrorDetails:
[{"Key":"ObjectId","Value":["b4a7ebaa-7f2f-443b-b498-28384f4f4728"]},{"Key":"InvalidAttributeName","Value":["userPrincipalName"]}]

Eine Klammer im UPN ist in der Cloud nicht möglich und OnPremise sollten Sie dies auch vermeiden.

Beschränken Sie die erlaubten Zeichen auf "A-Z,0-9, Punkt, Minus, Underscore", wenn Sie "sicher" sein wollen.
Ich persönlich würde auch "=" und "()" vermeiden, um z.B. LDAP-Anfragen nicht zu erschweren.

Homedir Rename

Wir wissen nun also, dass zumindest Microsoft Teams im Dez 2022 ein Problem mit der "runden Klammer" hat und da es sicher etwas länger dauert, bis Microsoft dies als Bug anerkennt und fixt und dann noch verteilt, müssen wir und um Lösungen kümmern. Der Root-Cause ist zwar der Displayname mit einer Klammer, aber der soll nicht geändert werden. Das würde jeder Anwender im Outlook Adressbuch sofort sehen. Das Feld SAMAccounName, welches Windows bei einer Anmeldung nutzt, gibt es bei CloudOnly-Konten nicht. Es ist weder bei "Set-AzureADUser" noch bei "Set-MSOLUser" ein gültiger Parameter:

Wir werden wohl damit leben müssen, dass auf einem PC durch Windows ein neues Profil anhand des "Displaynamens" angelegt wird und da eine Klammer erlaubt ist, ist der Fehler bei Teams zu suchen. Aber vielleicht kann dennoch zumindest temporär eine Funktion ermöglichen.

Zwischen dem Home-Verzeichnis und einem Anwender gibt es eine 1:1 Zuordnung. Wenn der Anwender angemeldet ist, dann bindet Windows aus dem Profilverzeichnis die NTUSER.DAT als "HKEY_CurrentUser"-Zweig ein. Damit das immer wieder sauber funktioniert, merkt sich Windows in der Registrierung, welche vorhandenen Heimatverzeichnisse zu welchem Benutzer gehören.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Den Ort finden Sie auch echt einfach durch eine Suche in der Registry nach dem "ProfileImagePath" oder dem verwendeten Anmeldenamen.

Interessant war in einem Lab dass ich bei einer kompletten Suche nach "adsync(klammer" nur genau einen Treffer hatte. Das ist zwar keine Garantie, dass der Anmeldename nicht irgendwo anders codiert hinterlegt ist, aber ein Rename ist einen Versuch wert.

Ich habe daher den Benutzer abgemeldet und dann zwei Dinge getan:

  1. Rename "C:\Users\adsync(Klammer" "C:\Users\adsyncKlammer"
  2. Anpassen des Werts von "ProfileImagePath" auf den geänderten Pfadnamen

Danach habe ich mich als Benutzer erneut angemeldet und ohne weitere Fehlermeldungen habe ich bisheriges Profil bekommen und konnte diesmal auch Microsoft Teams starten.

Temporär habe ich für mein Lab damit eine Lösung. Wie man einen "HomeDir-Rename" nun mit InTune auf allen Geräten durchführen kann, ohne dass Benutzer angemeldet sind, ist noch zu testen. Im Zweifel müsste man mit Intune ein Paket verteilen, welches per Taskplaner beim Start des PCs startet, während noch kein Benutzer angemeldet ist.

Aber auch dann könnte dieser Fix erst "nach" der Erstanmeldung eines Anwenders aktiv werden. Eine Lösung sieht anders aus. Wer ADSync hat, kann seine lokalen SAMAccountName entsprechend setzen aber wer nur das AzureAD nutzt, kann nur den Displaynamen anpassen. Da den aber auch die Anwender in Teams, Outlook und anderen Stellen sehen, ist das keine richtige Lösung.

Final Fix

Noch gibt es keine Lösung. Zuerst würde ich erwarten, dass Microsoft Teams mit diesem Sonderfall umgehen kann. Ich würde nicht erwarten, dass Windows zukünftig eine andere Bildungsregel für das Userprofile-Verzeichnis bekommt. Wer noch das Verzeichnis "Previous" auf seinem PC hat, kann Teams auf die vorherige Version zurückrollen und angeblich soll es auch helfen, Teams im "Windows 8 compatibility mode" zu starten. Aber das sind alles nur Einzellösungen und skalieren nicht.

Stay tuned: Ich bin gespannt, wie schnell die Eskalation hier gelingt. Es könnte ja schon viele Benutzer betreffen.

Lernkurve

Bei manchen Problemen kann man gar nicht glauben, dass Sie so lange unbemerkt geblieben sind. Seit dem Ende von 8.3-Dateinamenskonventionen haben wir immer wieder mit Störungen zu kämpfen, die auf den ersten Blick nicht auffallen. Im englischen Namensraum gibt es eben viel weniger Sonderzeichen und Umlaute aber die Anwender in China, Korea, Japan, Israel, die Gruppe der arabische Länder u.a. nutzen auch einfach ihre Sprache und Buchstaben bei der Benennung von Dateien. Die Liste der nicht erlaubten Zeichen ist schon relativ klein aber Hand aufs Herz: Welcher Entwickler prüft seine Software gegen alle möglichen Sonderzeichen und Kombinationen?

Eine runde Klammer im Homedir-Pfad ist bei einer On-Premises-Umgebung zwar möglich aber wer würde denn freiwillig eine Klammer in den SamAccountName schreiben? Hier gewinnt der Administrator und dem Anwender ist dieser Name seit der Anmeldung mittels UPN eh nicht mehr wichtig. Bei AzureAD-Konten sieht es aber anders aus, da hier der DisplayName zur Bildung des UserHomeDir genutzt wird und Windows muss aus dem "langen String" einen gültigen maximal 20-stelligen String generieren. Und in diesem Fall ist eine runde Klammer möglich und kann auch nicht vermieden werden.

Bei dem Kunden laufen aber viele Programme problemlos mit diesem Sonderzeichen im Pfad. Teams ist mein erstes Programm, welches mit der runden Klammer im Pfad ins Stolpern kommt.

Weitere Links