AD Migration zu einer sauberen Hybrid Lösung

[ITCUB 0]

Hallo Allerseits.

Wir haben bei einem unserer größeren Kunden eine alte lokale Domain "DOMAIN.DE", welche mit Azure AD Connect mit einem Azure AD von MS365 synchronisiert wird.

Die lokale Domäne ist per Benutzerprinzipalname-Suffix mit der MS365 Exchange Online Domain (Maildomäne) verknüpft.

Leider gehört dem Kunden die lokal verwendete "DOMAIN.DE" nicht und kann deshalb nicht für Zertifikate verwendet werden.

Für eine einfachere Zertifizierung der unterschiedlichen Dienste und zum gerade ziehen der Altlasten möchten wir gerne die lokale Domain so migrieren, dass aus für das lokale AD aus "DOMAIN.DE" "intern.maildomäne" wird.

 

Da wir die Domäne nicht neu machen wollen, möchten ich gerne wissen, wie man das am besten per Migration hinbekommen kann.

 

Mit freundlichen Grüßen

ITCUB

[cj_berlin 1.478]

Doch, ihr wollt die Domain bzw. den Forest neu machen, denn anders wird es nichts. Je nachdem, wie groß das ganze ist, können 3rd Party Tools euch helfen, das relativ geräuschlos über die Bühne zu bringen. Wenn ihr das allerdings noch nie gemacht habt, werdet ihr Schiffbruch erleiden.

[NorbertFe 2.265]

vor 27 Minuten schrieb ITCUB:

Da wir die Domäne nicht neu machen wollen, möchten ich gerne wissen, wie man das am besten per Migration hinbekommen kann.

Eine Migration heißt aber neue Domain, oder übersehe ich hier was?

[ITCUB 0]

Da, nach meinen Recherchen vom Umbenennen der Domäne abgeraten wird (darauf spielt wahrscheinlich cj_berlin an), habe ich mir vorgestellt die MS365 Domäne (Maildomäne) als Master für das lokale AD zu verwenden.

Durch die Synchronisation mit dem Azure AD Connect kennen die sich doch schon, da muss doch eine Migration dahin machbar sein.

Das mit dem intern. war nur eine Idee das lokale AD von der Cloud unterscheiden zu können. wenn das nicht nötig ist, kann ich darauf auch verzichten.

bearbeitet 10. Mai 2023 von ITCUB

[cj_berlin 1.478]

vor einer Stunde schrieb ITCUB:

Da, nach meinen Recherchen vom Umbenennen der Domäne abgeraten wird (darauf spielt wahrscheinlich cj_berlin an),

Davon wird nicht nur abgeraten, das funktioniert auch in vielen Szenarien einfach nicht.

 

Aber: Dir geht's doch eigentlich nur um den UPN-Suffix, um den UPN=email setzen zu können. Das kannst Du zum vorhandenen Forest hinzufügen und für die User dort "einfach" ändern. Anführungsstriche können auch weg, wenn Du genau weißt, welche Anwendungen den UPN benutzen und damit angefasst werden müssen  

[ITCUB 0]

Mit dem Suffix haben wir nur die Benutzeranmeldung bzgl. MS365 vereinfacht.

Mir geht es darum, das wir mehrere Serverdienste für den Zugriff von Außen auf HTTPS umstellen müssen und das mit der Zertifizierung über seine jetzige interne Domäne nicht funktionieren wird. Denn der Vorbetreuer hat eine öffentliche Domain für intern verwendet. Die gehört dem Kunden aber gar nicht.

 

[cj_berlin 1.478]

Und? Auch DNS kannst Du unabhängig von der AD-Domäne fahren. Zone mit der "richtigen" Domain anlegen, fertig.

 

Computername: SERVER01.fremde-domain.de

DNS Alias: webapps.eigene-domain.de

SPN: HTTP/SERVER01.fremde-domain.de (falls Teile des Service intern zwingend den Hostname verwenden wollen) + HTTP/webapps.eigene-domain.de

Zertifikat: SAN=webapps.eigene-domain.de

[NilsK 3.021]

Moin,

 

am besten wäre es, sich mit einem kompetenten Dienstleister in Ruhe hinzusetzen und die Anforderungen sowie die Rahmenbedingungen in Ruhe zu besprechen. Das ist in einem Forum nicht zu leisten.

 

Gruß, Nils

 

[ITCUB 0]

vor 41 Minuten schrieb cj_berlin:

Und? Auch DNS kannst Du unabhängig von der AD-Domäne fahren. Zone mit der "richtigen" Domain anlegen, fertig.

 

Computername: SERVER01.fremde-domain.de

DNS Alias: webapps.eigene-domain.de

SPN: HTTP/SERVER01.fremde-domain.de (falls Teile des Service intern zwingend den Hostname verwenden wollen) + HTTP/webapps.eigene-domain.de

Zertifikat: SAN=webapps.eigene-domain.de

Das wäre ein Lösungsansatz für das Zertifikatsproblem und dürfte evtl. auch beim geplanten RDS-Farm Projekt mit RDS Gateway funktionieren.

 

Vielen Dank erst einmal.

vor 36 Minuten schrieb NilsK:

Moin,

 

am besten wäre es, sich mit einem kompetenten Dienstleister in Ruhe hinzusetzen und die Anforderungen sowie die Rahmenbedingungen in Ruhe zu besprechen. Das ist in einem Forum nicht zu leisten.

 

Gruß, Nils

 

Da gebe ich Ihnen grundsätzlich Recht.
Leider kenne ich da niemanden, der damit Erfahrung hat und uns, als Systemhaus kostengünstig beraten, oder unterstützen kann.

 

MfG

[Nobbyaushb 1.573]

vor einer Stunde schrieb ITCUB:

Leider kenne ich da niemanden, der damit Erfahrung hat und uns, als Systemhaus kostengünstig beraten, oder unterstützen kann.

Ich kenne alleine hier im Forum mindestens drei, die man auch gegen Einwurf kleiner Münzen buchen kann

Vielleicht ist das ja für den einen oder anderen Interessant und schreibt dich per PN an...

[daabm 1.410]

vor 5 Stunden schrieb cj_berlin:

Computername: SERVER01.fremde-domain.de

DNS Alias: webapps.eigene-domain.de

SPN: HTTP/SERVER01.fremde-domain.de (falls Teile des Service intern zwingend den Hostname verwenden wollen) + HTTP/webapps.eigene-domain.de

Zertifikat: SAN=webapps.eigene-domain.de

 

Zertifikat: SAN=webapps.eigene-domain.de,SERVER01.fremde-domain.de

Außer das spielt keine Rolle - sobald ein SAN vorhanden ist, wird der CN ignoriert.

[NorbertFe 2.265]

vor 3 Minuten schrieb daabm:

Außer das spielt keine Rolle - sobald ein SAN vorhanden ist, wird der CN ignoriert.

Ich dachte der CN muss als SAN mit auftauchen?

[daabm 1.410]

Ja, eben. Also "eben nicht" - wenn ein SAN da ist, wird der CN ignoriert. Und wenn man den CN dann noch braucht, muß er in die SANs mit rein.

[NorbertFe 2.265]

Muss ich mal bei Gelegenheit testen. ;)

[cj_berlin 1.478]

vor 4 Stunden schrieb daabm:

Zertifikat: SAN=webapps.eigene-domain.de,SERVER01.fremde-domain.de

Der Aufhänger war ja, dass sie für fremde-domain.de keinen Proof of Ownership beibringen können (weil Ownership nicht gegeben ist ).