Migration Azure AD Connect - .local Domain zu einer FQDN umwandeln

Meine Güte, da hat aber jemand absolut keine Ahnung von dem Aufbau einer AD. Microsoft erwartet beim Aufsetzen eigentlich einen Domänennamen und eine TLD. Ich wüßte nicht wie man computername.local direkt hinkriegen sollte. Echt jetzt. Wer irgendwo einen echten Linix-DNS herumstehen hat, der kann sich das zurechtfummeln, denn nach dem RFC für das reine Internet-DNS ist das nicht verboten, aber bei Microsoft ist das nicht erlaubt. Du hast definitv irgendwo einen Netbios-Domänennamen stehen. .local ist reserviert für domänenlose iot Geräte die aus irgendwelchen Gründen eine Fake TLD brauchen. Check das mal bitte über Systemsteeuerung / System, da wird wohl ein Domänenname oder eine Arbeitsgruppe stehen.


Tja und was macht man dann? wie der Kollege sagt, "neu machen". Gemanagtes AD in Azure (und AWS) macht aus Prinzp her kein .local.... will man nicht das ganze AD migrieren, dann schlag ich dir mal vor, hier eine gegenseitige Vertrauensstellung der ADs untereinander einzurichten.

Die Königsdisziplin dazu heißt ADFS, aber für jemanden, der nicht mal weiß wie ein modernes AD aufgebaut ist, ist das erstmal höheres Latein.

Domainname.local ist ganz einfach hinzubekommen. Steht in jdem frühen MS-Lehrbuch und war früher "der Standard"!

lks

PS: Ja auch ich habe vor über 20 Jahren .local als TLD für AD benutzt - später sogar für Kunden.

Ist nicht nötig . Geht dabei wie schon von den Kollegen um eine öffentliche Domain ;)

Gruss

nein ich rede von rechnername.local nicht von Rechnerame.netbiosdomäne.local

In reinen Windows Umgebungen hatte ich mit FQDNs mit .local bisher auch noch nie Streß, und Windows 2000 hatte damals (ich meine mich zu erinnern) das .local sogar selbst vorgeschlagen.

Aber später lernt man halt dazu... einige Nicht-Windows Geräte mit .local am Ende können damit nicht umgehen, weil sie z.T. selber diese TLD für irgendwelche Zwecke mißbrauchen. MacOSX unterhalb einem bestimmten Patchlevel, NEtapp FAS2020 mit 7er Ontap Version, der eine oder andere Drucker mit eigener Printserver-Funktion ließ sich damit nicht nutzen (nur mit TCP-IP Port Direktanbindung) und eben ganz akteull das gemanagte AD in Azure (und in AWS vermutlich acuh). Und seitdem man TLDs für eine dreiviertel Million Dollar kaufen kann, ist man halt auch dem Risiko ausgesetzt, daß eine früher unbentutze TLD mit einem Mal Verwendung findet. Ich bin z.B. ein Fan von .demo, bei uns in der Firma war .nt dann der Ersatz für .local

Wenn man mal die ganzen Cloud-Tutorials durchliest dann findet man da auch immer wieder den Hinweis, daß es in Cloud-Umgebgungen mit gemanagten Diensten sehr vorteilhaft ist, eine eigene Domain zu registieren und die dann für sein AD zu verwenden.

Der Kumpel weiter oben kann natürlich eine VM mit einem Domänencontroller aufsetzen und sein AD da wie gehabt weiter managen... muß nur warten bis der neue DC im Sync mit dem On Premise DC ist und den dann abschalten.

@eastrocker:

Das geht unter Umständen auch, ohne die lokale Domäne "firma.local" unzuändern. Für die Änderung eines Domänennamens sollte man
genau wissen was man tut und das ist nichts für Anfänger, zu denen ich mich auch zähle.

Ich setze mal folgendes voraus:

Funktionierenes und fehlerfreies AD
Funktionierendes O365 im richtigen Abo-Plan
In O365 eingerichtete eigene Domäne (nicht "firma.onmicrosoft.com).
Du willst ggf. dein lokales AD behalten.

Ließ dir mal das hier durch:

MS - Vorbereiten eine nicht routingfähigen Domäne

Im Prinzip geht es darum, im AD ein alternatives UPN-Suffix anzulegen. Hast du also in O365 den Benutzer hans.meier@firma.com und lokal den Benutzer hans.meier@firma.local, dann legst du für firma.local das alternative Suffix firma.com im lokalen AD an. Alle neuen Benutzer erhalten dann das alternative Suffix im Benutzernamen, alle vorhandenen Benutzer musst du auf das neue Suffix umsetzen.

Ich stand vor kurzen vor der gleichen Aufgabenstellung und so funktioniert es einwandfrei. Azure AD Connect synchronisiert seit Wochen ohne jeden Fehler. Ließ dir aber unbedingt die Bereitstellungs-Docs von MS durch und überprüfe dein AD mit dem Idfix-Tool von MS. Das ist gut investierte Zeit die du später nicht mit Fehlerbereinigung vergeuden musst.

Einstieg hier: Installationsübersicht Azure AD Connect

@GrueneSosseMitSpeck: Die .local Endung wird noch beim Setup des Essentials 2016 vorgeschlagen, obwohl MS sicher bekannt ist, das dies Grütze ist. Ich habe auch noch eine .local Domäne im Einsatz. Das sind die Anfängerfehler, die man eben so gemacht hat.

Gruß Arno