Haikos Blog Blog von Haiko Hertes zu allen Themen rund um Microsoft und Datacenter

28Jun/170

Office 365 – E-Mail-Adresse enthält einen Unterstrich (“_”)

Heute bin ich über folgendes Problem gestolpert: Bei einem neuen Mitarbeiter enthielt die E-Mail-Adresse im Office 365 einen Unterstrich (“Underscore”) an erster Stelle:

underscore1

(Zusätzlich wurde nicht die reguläre Domäne sondern eine “@*.onmicrosoft.com” verwendet…)

Die Benutzer werden mittels “Azure AD Connect” vom lokalen Active Directory nach Azure AD synchronisiert und bilden dort die Grundlage für die Office 365 Benutzer. Daher kann man die E-Mail-Adressen auch nicht online ändern, sondern nur on-premise. Im lokalen AD war aber auf den ersten Blick alles in Ordnung:

underscore2

Nach kurzer Recherche fand ich einen Microsoft KB Artikel, der mich auf die Lösung brachte:

In this scenario, after directory synchronization is run, the special character is replaced by an underscore character. Therefore, the user’s Office 365 email address contains an underscore character instead of the special character.

Dabei wird eine Liste mit “verbotenen” Zeichen aufgeführt (die merkwürdigerweise auch das @-Zeichen enthält…), zu denen auch das Leerzeichen gehört. Bezogen ist das ganze auf die AD-Attribute “mail” und “proxyAddresses”. “Mail” war in Ordnung, aber “proxyAddresses”…

underscore3

…nicht! Hier war ein Leerzeichen zwischen “SMTP:” und der eigentlichen E-Mailadresse. Nach dem ich dieses entfernt hatte und schnell noch den DirSync mit

Start-ADSyncSyncCycle -PolicyType Delta

angestoßen hatte, war der Benutzer mit seiner korrekten E-Mail-Adresse in Office 365 vorhanden!

26Apr/172

Office 365 – E-Mail-Adressen von neuen Benutzern aus on-premise AD falsch

Wenn man mit Azure AD Sync arbeitet und einen neuen Mitarbeiter im lokalen on-premise Active Directory anlegt, dann kann es einem passieren, dass dieser im Office 365 Portal eine *.onmicrosoft.com E-Mail-Adresse als primäre Mailadresse bekommt, selbst wenn man im AD-Konto die richtige Adresse eingetragen hat:

o365_1

Das lässt sich über das Office 365 Admin-Portal auch nicht ändern, da der Benutzer eben aus dem lokalen AD synchronisiert wird:

o365_2

Der Trick besteht darin, im lokalen AD das Attribute “proxyAddresses” zu erweitern (entweder ist es leer oder es enthält bereits einen Eintrag “x500:/o=…”).

Der neue Eintrag muss mit “SMTP:” (Großbuchstaben und den Doppelpunkt nicht vergessen) gefolgt von der gewünschten E-Mail-Adresse (ohne Leerzeichen) bestehen:

o365_4

Nach der nächsten Synchronisierung sollte es dann auch in Office 365 passen! Viel Spaß damit…

 

Nachtrag: In meinem Fall existiert kein on-premise Exchange Server! Wenn ihr einen solchen doch habt, dann verändert ihr mit der Änderung des AD-Attributes natürlich auch dort die Mailadresse...

10Jan/170

Active Directory: Benutzer GPOs mit Sicherheitsfilterung funktionieren nicht

Ja, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:

Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:

gpo1

Das Problem

Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.

Die Ursache

Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:

Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:

Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.

Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.

Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!

Die Lösung

Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:

gpo2

Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:

https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/

14Dez/161

Hyper-V auf Windows Server 2012 R2 / 2016: VMs mittels Kerberos verschieben

Im Windows Server 2012 R2 und 2016 steckt ja nun schon seit einer Weile die so genannte “Shared Nothing Live Migration”, die es möglich macht, VMs zwischen Hyper-V-Hosts zu verschieben (auch im laufenden Betrieb), ohne, dass die VM auf einem Hyper-V-Cluster laufen muss, entsprechend ist hier auch kein Storage nötig.

Für die Shared Nothing Migration gibt es zwei Protokolle zur Authentifizierung: CredSSP und Kerberos.

CredSSP ist an sich sehr einfach in der Benutzung, bedarf es doch keiner echten Einrichtung. Lediglich den richtigen Radio-Button auswählen, einmal ab- und wieder anmelden und das war’s. Aber die Sache hat einen Haken: Bei CredSSP kann man nur dann eine VM verschieben, wenn man (lokal oder z.B. per RDP) an dem Hyper-V-Host angemeldet ist, von dem man die VM weg-verschieben will. MMC-Remoting mit dem Hyper-V-Manager geht hier nicht! Versucht man es doch, bekommt man folgende Fehlermeldung:

kerberos00

Im Wortlaut: “Failed to establish a connection with host HOSTNAME. The credentials supplied to the package were not recognized (0x8009030D).”

Insbesondere bei Core-Servern, auf denen es keinen Hyper-V-Manager gibt, wird das Verschieben also einigen Administratoren schwer fallen (wenngleich PowerShell eine nutzbare Lösung wäre).

Auch wenn man jetzt einfach im Hyper-V-Manager auf Kerberos umstellt:

kerberos7

..kommt es immer noch zu einem Fehler:

kerberos0

Im Wortlaut: “The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The specified target is unknown or unreachable (0x80090303).”

Was hier fehlt ist die sogenannte “Constrained Delegation”. Diese einzurichten ist an sich nicht kompliziert, bei steigender Host-Anzahl aber etwas aufwändiger (eine einfachere PowerShell-Lösung versuche ich zeitnah nachzuliefern).

Zur Einrichtung benötigt man Schreibrechte auf den Computer-Objekten der Hyper-V-Hosts im Active Directory oder einfacher gleich einen Domain-Admin-Account.

Über die “Active Directory Users and Computers” öffnet man sich nun der Reihe nach die Computerkonten aller Hyper-V-Hosts und führt dort folgende Einstellung durch:

kerberos1kerberos2kerberos3

kerberos4kerberos5

Im Ergebnis muss es auf jedem Host so aussehen:

kerberos6

Jeder Host muss jedem anderen bei den Diensten “cifs” und “Microsoft Virtual System Migration Service” vertrauen. Kerberos alleine genügt.

Danach muss man natürlich die Hyper-V-Hosts auf Kerberos-Migration umstellen (oder dies zumindest noch einmal überprüfen!)

kerberos7

Das war’s dann schon! Jetzt kann man von jedem Client oder Server aus mittels Hyper-V-Manager auf die Hosts zugreifen und eine Verschiebung initiieren. Viel Spaß dabei!

13Okt/160

Hürden bei der Office 365 Migration in Bezug auf AD Connect

Vor zwei Wochen habe ich nun endlich die E-Mail-Kommunikation meiner Firma auf Office 365 umstellen können. Diese eigentlich gar nicht so aufwändige Projekt war leider durch zu viele kleine Dinge im Alltag zeitlich in die Länge gezogen worden.

Aus den Erfahrungen bei der Migration möchte ich hier ein paar Hürden und Stolpersteine, die mir im Zusammenhang mit Azure AD Connect begegnet sind, erläutern, in der Hoffnung, dass andere diese so umgehen können.

Azure AD Connect zu früh benutzt I

Ich hatte Azure AD Connect bereits aktiviert, bevor ich den Migrationsendpunkt (Migration Endpoint) für die Cutover-Migration angelegt hatte. Danach ließ sich die Option “Übernahmemigration” (Das ist die Cutover-Migration) nicht mehr auswählen, diese war ausgegraut (siehe mein Blogpost vom 12.09.2016)

Erkenntnis: Azure AD Connect erst benutzen, wenn der Migrationsendpunkt angelegt ist. (siehe auch nächster Punkt!) Alternativ kann AD Connect auch wieder abgeschaltet werden: (kann ggf. einige Stunden dauern)

image

Azure AD Connect zu früh benutzt II

Ich hatte, bevor alle Postfächer durch Cutover-Migration umgezogen waren, schon Azure AD Connect (früher DirSync) auf unseren Systemen installiert und einige Benutzer aus unserem Active Directory zu Azure bzw. Office 365 synchronisiert. Für diese Benutzer konnte ich dann keine Postfächer mehr per CutOver-Migration migrieren, weil dann bemängelt wird, dass es bereits Objekte mit der selben Mailadresse gibt.

Erkenntnis: Azure AD Connect erst benutzen, wenn alle Postfächer migriert sind.

Azure AD Connect kommt mit multiplen Mail-Adressen im AD nicht so gut klar

Neben der finalen Mailadresse unserer Public Domain hatten die Exchange-Postfächer (und damit auch die AD Objekte der Benutzer) mehrere Mailadresse, u.a. die der lokalen internen AD Domäne. Diese sind u.a. im Attribut “ProxyAddresses” gespeichert. Die primäre Mailadresse hat dabei ein großgeschriebenes “SMTP:” vorangestellt, alle anderen ein kleingeschriebenes:

image

Daran aber stört sich anscheinend Azure AD Connect. Darauf deutet auch ein älterer Blog-Artikel bei Microsoft hin. Dort heisst es:

  • “SMTP:username@contoso.com” is an acceptable value.
  • username@contoso.com” and “smtp:username@contoso.com” are not acceptable values.

Als Fehler kommt “Das Objekt kann nicht aktualisiert werden, weil die folgenden dem Objekt zugeordneten Attribute Werte aufweisen, die möglicherweise bereits einem anderen Objekt in Ihren lokalen Verzeichnisdiensten zugeordnet sind” – und zwar für jeden User der Domäne.

Also habe ich vorübergehend alle kleingeschriebenen “smtp” durch großgeschriebene ersetzt (ACHTUNG: Das ist nur temporär, in der Zwischenzeit solltet ihr keine Exchange-Konsolen benutzen, da diese damit ein Problem haben, dass es mehrere primäre Adressen gibt! Alternativ könnte man auch alle sekundären Adressen entfernen – das kam für mich aber nicht in Betracht). Dies habe ich natürlich mit PowerShell erledigt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Get-ADUser -SearchBase "OU=SOMEOU,DC=MYDOMAIN,DC=local" -Filter * | 
    Get-ADObject -Properties proxyAddresses | 
        ForEach-Object 
        {
 
            $ProxyA = $_.proxyAddresses.Replace("smtp","SMTP") 
            ForEach($Adress in $_.proxyAddresses) 
            { 
                if($Adress -like "*@THEDOMAIN.COM") 
                { 
                   $ProxyA = $Adress 
                } 
            } 
            $_.ProxyAddresses = $ProxyA 
            Set-ADObject -Instance $_ 
        }

Selbst nach dem ich dies bei allen Benutzer gemacht hatte kam ausgerechnet für mein eigenes Konto noch immer der selbe Fehler:

image

Dabei hatte ich meinen Account ebenso behandelt wie alle anderen. Dieses Mal war die Ursache aber eine andere: Es gab noch einen gelöschten O365-Benutzer mit dieser Adresse! Also musst auch noch der gelöschte Benutzer endgültig gelöscht werden. Dies habe ich ebenfalls per PowerShell gelöst:

1
Get-MsolUser -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin –Force

(Achtung: Das löscht ALLE gelöschten Benutzer endgültig! Will man nur einen einzelnen Benuter löschen geht dies mittels:

1
Remove-MsolUser -UserPrincipalName Lynn@office365bootcamp.com –RemoveFromRecycleBin


Danach klappte auch die Synchronisierung des letzten Kontos problemlos…

30Jun/160

Exchange 2010: Viele merkwürdige Fehler und eine fast noch merkwürdigere Lösung

Auf einem produktiven Exchange 2010 SP3 mit aktuellem Patchstand begegnete mir heute folgendes Problem: Der Mailserver war weder über Outlook noch über OWA erreichbar und wenn man sich per RDP angemeldet hat, dann war nahezu nichts möglich, jede Aktion führte zu einem sich ewig drehenden Sanduhr-Symbol. Keines der Systemsteuerungswerkzeuge oder auch nur die Netzwerkwerk-Adapter-Verwaltung ließen sich öffnen.

Um zunächst erst mal mit dem Server arbeiten zu können, hatte ich ihn im abgesicherten Modus gestartet. Da hier aber auch sehr viele Werkzeuge nicht funktionieren, habe ich alle Exchange-Dienste deaktiviert und die Maschine neugestartet. Jetzt konnte man erst mal wieder arbeiten und mit der Fehlersuche beginnen.

Zunächst hatte ich mit ESEUTIL die Datenbank-Files geprüft, hier war aber alles in Ordnung. Netzwerk, DNS und co. sowieso, DC war auch erreichbar, auch Kerberos-Auflösungen waren kein Problem. Da ich am Vorabend das aktuellste Update Rollup 14 eingespielt hatte, hatte ich dieses im Verdacht und hab es wieder deinstalliert – ohne Erfolg. Der Server reagierte wieder so wie vorher.

Im Eventlog war mir vor allem dieser Fehler aufgefallen:

Exch2010_1

(Quelle: MSExchange ADAccess | Ereignis-ID: 2114 | Aufgabenkategorie Topologie)

Außerdem noch dieser Fehler:

Exch2010_2n

(Quelle: MSExchange ADAccess | Ereignis-ID: 2102 | Aufgabenkategorie Topologie)

Dort heisst es: “Keine Antwort von allen verwendeten Domänencontrollerservern”. Dies war merkwürdig, weil sämtliche Arten der von mir getesteten Kommunikation mit dem DC funktionierten tadellos, zur Sicherheit hatte ich noch ein dcdiag gegen den DC laufen lassen – ohne Auffälligkeiten. Zur Sicherheit hatte ich noch das Computerkonto sowie den Secure Channel zurückgesetzt die Mitgliedschaft des Computerkontos in den notwendigen Exchange-Gruppen im AD geprüft.

Symptomatisch war, dass sich der Dienst “Microsoft Exchange Active Directory-Topologie” und auch “Microsoft Exchange-Diensthost” relativ problemlos (wenn auch nur mit längerer Wartezeit) starten ließen, aber die “Microsoft Exchange-Systemaufsicht” ließ sich nicht starten!

Nach etwas Suche im Internet fand ich diverse Hinweise. Der erwarte war das Thema IPv6 – tatsächlich hatte mein Vorgänger dies am Exchange Server abgeschaltet. Also das Häckchen wieder rein:

Exch2010_3

Leider brachte dies – auch nach einem Neustart nichts.

Ein weiterer Hinweis der sich fand, schien mir etwas abwegig, aber da ich kurz vor dem Restore des gesamten Servers stand, habe ich es drauf ankommen lassen und das Computerkonto des Exchange-Servers in die Gruppe der Domänen-Admins aufgenommen. Und tatsächlich, nach einem Neustart des Servers kamen alle Dienste hoch. Damit war mein Kernproblem zwar gelöst, aber ich war mir sicher, die eigentliche Ursache nicht gefunden zu haben, denn es ist IMHO keine Bedingung für Exchange, dass der Server DomAdmin ist. Nach längeren Recherchen fand ich dann den “Übeltäter”:

Eine GPO hatte die Berechtigung für “Manage auditing and security log” (“Verwalten von Überwachungs- und Sicherheitsprotokollen”) auf einen zu kleinen Benutzerkreis festgelegt.

Exch2010_4

Laut diesem Artikel muss hier auch die Gruppe der Exchange-Server mit eingetragen werden – und zwar für die GPO die auf die DCs zielt!

Das war also das recht kleine Problem mit riesiger Auswirkung!

Jeden Tag fiebere ich nun der endgültigen Umstellung auf Office 365 entgegen – dann gehören derartige Probleme wohl der Vergangenheit an.

25Apr/160

Windows Server 2016: YouTube-Videos zum Aufbau und zur Administration einer Active Directory Domäne

Ich habe drei Videos rund um das Thema Active Directory erstellt und bei YouTube veröffentlicht.

Im ersten Video geht es um die Installation von Active Directory.

Das zweite Video behandelt die Verwaltung von Benutzern, Gruppen, Computern und OUs.

Im dritten Video zeige ich den Umgang mit Gruppenrichtlinien (GPOs).

Viel Spaß beim Ansehen!

Hier geht es zur gesamten AD-Playlist:

https://www.youtube.com/playlist?list=PLPK8RW8p4Ok9mJbpRzb0bq_OL7mfMm5hg

15Feb/160

AD Domänen Controller: Zeitdifferenz / Time Skew zum PDC-Emulator

Bei der Prüfung von SCOM-Warnungen fiel mir diese hier besonders ins Auge:

ADTime0

ADTime1

Die Meldung “The Time Skew latency is above the configured threshold” besagt im Wesentlichen, dass die Zeitdifferenz zwischen einem “normalen” DC und dem PDC-Emulator zu hoch ist, in diesem Fall bei 267 Sekunden liegt und damit über der Warnungs-Schwelle von 5 Sekunden. Und tatsächlich, die Server haben eine sichtbare Zeitdifferenz:

ADTime2

Nun ist es ja so, dass alle Server einer Domäne die Uhrzeit beim PDC-Emulator abholen – oder es zumindest sollten. Dieser wiederum sollte so konfiguriert sein, dass er die Zeit von einer gültigen externen Zeitquelle empfängt. Das erreicht man recht einfach mit folgenden Aufrufen:

w32tm.exe /config /manualpeerlist:”0.de.pool.ntp.org 1.de.pool.ntp.org 2.de.pool.ntp.org 3.de.pool.ntp.org” /syncfromflags:manual /reliable:YES /update

w32tm.exe /config /update

PS: Restart-Service w32time

Im festen Glauben, dass dies auch in meiner Umgebung so ist, habe ich dies dennoch gegengeprüft:

Der Aufruf

netdom query fsmo

liefert die Verteilung der FSMO-Rollen, u.a. erfährt man eben auch, welcher DC aktuell der PDC-Emulator ist.

ADTime3

Nun kann man mit

w32tm /monitor

auf einem der DCs prüfen, welcher DC woher seine Zeit bekommt:

ADTime4

Und siehe da – die beiden DCs, die nicht PDC-Emulator sind bekommen ihre Zeit von irgend einem Server “frei im Internet”. Dies kann z.B. daran liegen, dass diese DCs früher mal PDC-Emulator waren und daher noch auf die Synchronisierung mit einer externen Quelle eingestellt sind. Dies lässt sich sehr leicht auf den betreffenden DCs (also denjenigen, die kein PDC-Emulator mehr sind) beheben. Dazu ist lediglich der Aufruf

w32tm /config /syncfromflags:domhier /update

net stop w32time

net start w32time

notwendig:

ADTime5

Nach kurzer Zeit sollte die Uhrzeit dann wieder passen. Zur Sicherheit kann man dies nun noch einmal mit

w32tm /monitor

überprüfen:

ADTime6

Jetzt sieht man, dass die beiden ersten DCs (beide kein PDC-Emulator) von HVSRV10 (dem PDC-Emulator) synchronisieren und dieser wiederum von einer externen Zeitquelle (stammt aus dem NTP-Pool).

Nun stimmen auch die Zeiten aller DCs wieder überein:

ADTime7

7Apr/150

Wie ein guter Domänen-Name aussieht – und wie nicht.

Auf den ersten Blick klingt das für viele sicher nach einer trivialen Frage: “Wie soll die neue AD Domäne denn heißen?” – aber so trivial ist diese Frage gar nicht.

Zunächst einmal muss man sich natürlich an die Vorgaben halten:

  • Der volle Domänenname (“Fully Qualified Domain Name, FQDN”) darf maximal 255 Zeichen lang sein und darf dabei aus Kleinbuchstaben, Großbuchstaben, Zahlen und dem “-”-Zeichen bestehen. Pro Label sind 63 Zeichen zulässig.
  • Der NetBIOS Name der Domäne ist auf 15 Zeichen beschränkt sowie auf Unicode-Zeichen und ein paar wenige Sonderzeichen

Ein AD Domänen-Name ist immer auch ein DNS-Name. Ein Domänen-Name besteht daher in der Regel aus einem oder mehreren Präfixen und einem Suffix, nach dem Aufbau-Prinzip

Präfix1.Präfix2.Suffix

Nun findet man heute sehr viele Domänen-Name nach dem Aufbau “Firma.local”, “.site”, “.lan” und so weiter. Die Wahl dieses Namens ist in der Regel auf die frühere Empfehlung, als Suffix keine öffentlichen Internet-Toplevel-Domänen wie “.com”, “.net” oder “.de” zu verwenden, da es sonst zu dem Problem kommt, dass man eine gesplittete DNS-Verwaltung benötigt oder aus dem internen Netz heraus eine Webseite nicht erreichen kann, wenn diese aus dem selben Prä- und Suffix besteht.

Diese Empfehlung hat heute keine Gültigkeit mehr!

Erstens werden auch diese “selbsterdachten” Suffixe mittlerweile von den Anbietern als Toplevel-Domänen verkauft. Das von einem selbst verwendete “FIRMA.LOCAL” könnte also zeitnah Eigentum einer anderen Firma werden! Und zweitens gibt es in gewissen Szenarien ganz klare Vorgaben, die die Verwendung dieser selbsterdachten Suffixe verbieten. Eines davon ist, dass keiner der großen SSL-Zertifikat-Anbieter Zertifikate für derartige Domänen- oder Hostnamen mehr ausstellt! (Vergleich dazu auch: https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf)

Also, wir halten zunächst fest: “.site”, “.local” oder ähnlich sind keine guten Suffixe! Besser ist es, offizielle TLD-Suffice wie “.com”, “.net” oder “.de” zu verwenden.

Aber was ist dann mit dem oder den Präfix(en)?

Wie wäre es, wenn man nun als “Firma Foo”, die “www.foo.com” als Webseite verwendet, “foo.com” als internen Domänennamen wählt? Das kann (besser: wird) zu Problemen führen. Hierzu ein kleines Beispiel:

Wenn ein Benutzer sich an einer Workstation innerhalb einer Domäne anmeldet, dann ist hierbei der Name (z.T. auch nur der NetBIOS-Name) der Domäne angegeben. Der Computer muss aber einen Domänencontroller kontaktieren können. Daher wird der Domänen-Name in den Namen eines DCs und dieser wiederum in eine IP-Adresse eines DCs übersetzt. Also, aus “foo.com” wird dann die IP eines DCs, hinter “foo.com” verbirgt sich ebenso die interne DNS-Zone.

Und was passiert, wenn nun jemand in dieser Firma “foo.com” in seinen Browser eingibt? Seine Browser würde versuchen, einen DC per HTTP anzusprechen, was in der Regel scheitert, weil ein DC kein Webserver ist!

Nun gibt es für den (ersten) Präfix zwei Optionen:

  • Man registriert eigens für diesen Zweck eine öffentliche Domäne, die aber nicht öffentlich sondern nur für die interne AD Domäne genutzt wird
  • Man nutzt eine Subdomäne einer bereits existierenden Domäne, die man auch öffentlich verwendet, im Idealfall die, die auch für die Webseite genutzt wird.

Wenn also “Firma Foo” die Domäne “foo.com” als Domäne für ihre Webseite nutzt, dann müsste der Name der obersten (ersten) interne AD-Domäne ABC.foo.com heissen. Dabei sollte “ABC” ein möglichst kurzes Wort sein, um die FQDN aller kommenden AD-Objekte nicht unnötig lang zu machen. Eine Option wäre z.B. “AD.FOO.COM”.

Damit nun bei der Anmeldung nicht “AD\User” sondern “FOO\User” genutzt wird, muss man einfach bei der Installation des ersten (!) Domänencontrollers der Domäne als NetBIOS-Namen anstatt des vorgeschlagenen “AD” das Wort “FOO” verwenden. (Achtung: Das nachträgliche Ändern des NetBIOS-Namen ist nicht trivial!)

Die Verwendung eines solchen DNS- und Domänen-Namens hat viele Vorteile:

  • Es muss nur ein einziger Domänen-Name (auf oberster Ebene) genutzt und verwaltet werden
  • Eine Trennung zwischen intern und extern ist problemlos möglich
  • Jeder interne Domänen- und Hostname ist weltweit einmalig (wer kann das bei “SERVER1.corp.local” schon behaupten?)
  • Für Zertifikate, E-Mail und co., wo naturgemäß externe Domänen nötig sind, ist bereits alles passend
  • Eine Anmeldung an den Systemen des Unternehmens kann mit der (öffentlichen) E-Mail-Adresse der Benutzer erfolgen. Niemand muss sich neben seiner Mail-Adresse noch einen (u.U. komplizierten) Benutzernamen merken.

Als Referenz und zum Weiterlesen empfehle ich folgende Links: