UserPrincipalName (UPN)

Es ist eine gute Idee, wenn der UPN, die primäre Mailadresse und auch die SIP-Adresse des Benutzers identisch sind. Ansonsten können diverse Integrationsfunktionen, Autodiscover etc. nicht automatisch funktionieren.

Beachten Sie dazu auch Office 365:UPN / Anmeldename

2475891 Description of the Office Outlook 2007 hotfix package (Outlook-x-none.msp): February 22, 2011
2412171 Description of the Office Outlook 2007 Update: January 11, 2011
Hotfix 2412171 ändert das Standardverhalten, dass Outlook den UPN statt der primären SMTP-Adresse für Autodiscover verwendet.
Hinweis: Addieren Sie einfach den UPN als zusätzliche sekundäre SMTP-Adresse, damit Autodiscover wieder funktioniert
2512788 Description of the Office Outlook 2007 hotfix package (Outlook-x-none.msp): April 26, 2011

Viele Administratoren legen Benutzer an und geben wie schon seit vielen Jahren auch einen Kontonamen ein. Auch die meisten Anwender können schon lange das Anmeldeschema mit DOMÄNE\UserNAME. Aber seit Windows 2000 kann man sich auch über einen "UserPrincipalName" anmelden, welcher die Form "User@upnsuffix" hat. Das sehen Sie schon immer auf der Karteikarte beim Benutzer:

UPN beim Benutzer

Der User Logon Name ist der Teil vor dem UPN-Suffix und eine Zeile darunter steht der alte NT4 Anmeldename (SamAccountName). Interessant sind hier zwei Dinge:

  • UPN Suffix ist änderbar, die Domäne nicht
    Firmen ändern vielleicht ihren Namen oder werden konsolidiert. Den UPN kann man sogar bei Migrationen beibehalten und auch an aktuelle Namen anpassen, ohne dass Profil, Berechtigungen o.ä. verloren gehen würden.
  • UPN Suffix und Mailadresse können gleich sein
    Der UPNSuffix ist nicht an den Namen des Active Directory oder die Domäne gebunden, sondern kann ziemlich frei vergeben werden. Es bietet es sich gerade zu an, hier die Mailadresse des Benutzers zu verwenden, um dem Anwender die Anmeldung zu vereinfachen. Normalerweise kennt ein Anwender seine Mailadresse.

Gültige Zeichen

Auch wenn in der MMC die Eingabe des UPN in zwei Felder aufgeteilt ist, wird das Ergebnis im Active Directory in einem Feld "userPrincipalName" gespeichert, für das es Regeln gibt:

"The userPrincipalName is a single-valued and indexed property that is a string that specifies the user principal name (UPN) of the user. The UPN is an Internet-style login name for the user based on the Internet standard RFC 822. The UPN is shorter than the distinguished name and easier to remember. By convention, this should map to the user's e-mail name. The point of the UPN is to consolidate the e-mail and logon namespaces so that the user need only remember a single name."
Quelle: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/netdir/ad/naming_properties.asp 

Wenn man sich die RFC 822 anschaut, dann steht da:

addr-spec   =  local-part "@" domain

local-part = word *("." word)
word = atom / quoted-string
atom = 1*<any CHAR except specials, SPACE and CTLs>
CTL = <any ASCII control ; ( 0- 37, 0.- 31.) character and DEL> ; ( 177, 127.)

domain = sub-domain *("." sub-domain)
sub-domain = domain-ref / domain-literal
domain-ref = atom
domain-literal = "[" *(dtext / quoted-pair) "]"
dtext = <any CHAR excluding "[", "]", "\" & CR, & including linear-white-space>
quoted-pair = "\" CHAR

Genaugenommen sind für den Userpart sehr viele Zeichen möglich aber nicht alle Zeichen sind "sinnvoll". Wenn ein Anwender sich mit der Adresse anmelden will, dann sollten sie Sonderzeichen vermeiden. Spezielle Effekte können Sie z.B.: mit "runden Klammern" bekommen, wie ich auf Sonderzeichen in Userprofile beim Displayname bzw. SamAccountName beschrieben habe. Aber auch beim UPN gibt es nette Effekte. Versuchen Sie mal in der MMC für Active Directory und Benutzer einen UPN mit einer "(" anzulegen:

Wenn Sie aber die Klammer wieder schließen, dann kommt kein Fehler und der Wert wird gespeichert. Da macht die MMC wohl einfach einen LDAP-Query mit dem String ohne Escape-Zeichen

Anmelden mit UPN

Wenn Sie sich an einem PC anmelden, sehen sie gewöhnlich den klassischen Anmeldedialog.

Anmeldedialog ohne Domäne

Der normale Anwender sieht also nicht einmal die Domäne, was besonders in Umgebungen mit mehreren Domains natürlich zu Fehlern führen kann. Wenn Sie "Options" auswählen oder die Anmeldung fehlschlägt, dann zeigt ihnen Windows den erweiterten Anmeldedialog. Oft erkennen die dann hier, dass der vorherige Anwender vielleicht die falsche Domäne hinterlassen hat. (Tipp: per Gruppenrichtlinien können Sie die "DefaultDomain" vorgeben).

Anmeldedialog mit Domain

Interessant wird es aber, wenn Sie im Feld für den Anmeldenamen nach dem ersten Teil ein "@" eintippen. In dem Moment wird die Domäne "grau" und damit nicht mehr auswählbar.

Anmeldung mit UPN

Das ist auch nicht erforderlich, da Windows nun einen UPN erwartet. Und den passenden Benutzer dazu findet der Anmeldedienst sowieso im globalen Katalog.

UPN Suffix auf Forest eintragen

Für den Administrator stellt sich nun natürlich die Frage, wo die UPNs gepflegt werden, welche dann beim Benutzer ausgewählt werden können. Dazu muss man "Enterprise Administrator" sein, um über die Active Directory Domänen und Vertrauensstellungen" die UPN Suffixe für die Gesamtstruktur (Forest) zu pflegen:

UPN Suffix pflegen

Achtung
Die UPNSuffix-Liste wird im Feld UPNSuffixes an dem Objekte CN=Partitions,CN=Configuration,DC=rootdomain,DC=tld angelegt. Theoretisch sind hier 3937 Einträge möglich. Praktisch aber eher 1200. Quelle: https://blogs.technet.microsoft.com/askds/2015/10/29/administrative-limit-for-this-request-was-exceeded-error-from-active-directory/.
In Office 365 gibt es eine Obergrenze von 900 Domains (Stand Jan 2019)

UPNSuffix beim Benutzer ändern

Erst dann tauchen nach einer kurzen Zeit (Replikation abwarten) auch die neu eingegebenen UPN Suffixe bei den Benutzern zur Auswahl auf:

Allerdings kann ein Benutzer immer nur "GENAU EINEN" Anmeldenamen haben. Es gibt also keine Option, mehrere Anmeldenamen zu verwenden.

Die Information steht im Active Directory Feld "UserPrincipalName", welches eigentlich ein Freitext ist. Es ist daher denkbar, direkt beim Anwender auch andere Namen zu verwenden, aber davon rate ich natürlich ab.

UPN pro OU vorgeben

Die MMC für Benutz und Computer kann über einen Eintrag in der OU gesteuert werden. Sie können dort die UPN-Suffixe für die Anwender in dieser OU vorgeben, so dass ein Mitarbeiter beim Anlegen eines neuen Benutzers nur aus den UPN-Domains auswählen kann, die auf dieser OU hinterlegt sind.

Wenn Sie also genau eine UPN-Domain auf der OU hinterlegen, bekommen alle neuen Anwender diese Domain. Die Änderung ist per ADSIEDIT oder auch über dsa.msc mit der erweiterten Ansicht möglich:

Hinweis: Die MMC prüft nicht, ob sie die UPN-Domain auch in die Forest-Liste eingetragen haben. Sie können damit als auch einen UPN angeben, der nicht im Forest explizit freigegeben ist.

Bestandskonten werden durch diese Änderung nicht angepasst. Das können Sie aber per PowerShell nachholen, wenn Sie den Localpart z.B. aus dem SAMAccountname ableiten.

Get-ADUser `
   -Filter * `
   -SearchBase ‘ou=firma1,dc=msfaq,dc=de‘ `
   -Properties userPrincipalName `
| foreach {`
     Set-ADUser $_ `
         -UserPrincipalName "$($_.samaccountname)@firma1.tld" `
}

UPN prüfen

Es bietet sich natürlich an, regelmäßig die Einträge von MAIL und UserPrincipalName zu prüfen. Dazu habe ich ein kleines PowerShell Skript geschrieben, welches Sie z.B. per Taskplaner regelmäßig starten können.

check-upn.1.0.ps1

Sie können es einfach auf der PowerShell aufrufen. Es verbindet sich mit dem GC und sucht alle "normalen" Benutzer mit einer Mailadresse und vergleicht diese mit dem Feld "MAIL", welches in der Regel die primäre SMTP-Adresse enthält. Die Daten werden in eine PIPE ausgegeben, so dass Sie mit " | export-csv datei.csv" die Liste auch in einer CSV-Textdatei schreiben können.

Konsoleausgabe von Check-UPN

Unstimmigkeiten werden mit "Write-Warning" sowohl auf die Konsole geschrieben, als auch in das Eventlog.

Check-UPN Eventlog meldung

So können Sie das Skript auf dem Server regelmäßig laufen lassen und die Events mit einer Überwachungssoftware kontrollieren. Natürlich können Sie das Skript noch erweitern, so dass Sie eine Mail bekommen.

Das Skript ändert aber nicht die Einträge und prüft auch nicht, ob die verwendeten UPNs global konfiguriert sein. Mit ADModify.NET können solche Felder aber sehr einfach für viele Personen gesetzt werden.

Eine einfachere Version mit Hilfe der Exchange Commandlets und weniger Funktionen fällt etwas kürzer aus:

foreach ($User in get-User) {
   write-host processing $User.samaccountname -nonewline
   [string]$sam = $User.samaccountname
   [string]$upn = "$sam@meinedomain.tld"
   if ($User.UserPrincipalName -eq $upn){
      write-host " UPNOK: $upn" -background green -foreground black
   }
   else {
      write-host " UPNFIX:$upn" -backgroundcolor yellow
      set-User -identity $sam -UserPrincipalName $upn
   }
}

Das Skript setzt einfach stumpf den UPN auf den SAM-Accountname und ergänzt ihn um "@meinedomain.tld". Das muss natürlich angepasst werden.

Aber auch mit Bordmitteln lassen sich erste einfache Checks durchführen:

REM Anzeige von doppelten UPNs mit SetSPN
c:\>setspn.exe -T * -x

Weitere Links