Neues AD aufsetzen: Müssen interne AD-Domäne und Azure-Domäne gleich heissen?
Hallo,
ich habe die letzten Jahre immer ADs als Subdomäne einer bestehenden TLD aufgebaut, also extern contoso.com und intern dann ad.contoso.com oder contoso.net, wenn es so eine freie Domäne noch gab. Ich habe es vermieden, beide gleich zu nennen, um DNS-Problemen etc. aus dem Weg zu gehen.
Nun habe ich hier eine Firma mit 200 Mitarbeitern, die komplett ohne AD arbeitet. Alle Systeme laufen unter Linux in der AWS-Cloud, die Mitarbeiter nutzen Google GSuite und alles drumherum. Für ein paar wenige User gibt es aber Office 365 Lizenzen.
Für ein neues ERP-System wird nun zwingend ein AD benötigt. Es soll nichts on-prem laufen, daher baut ein Dienstleister das alles in Azure auf.
Kommen wir nun zu meiner Frage:
Der Dienstleister behauptet, die Azure-Domäne und die interne AD-Domäne MÜSSEN gleich heißen, das sei seit einiger Zeit von Microsoft so vorgegeben und mittlerweile Best-Practise. Da ich mit Azure noch nicht viel gemacht habe, kann ich das nicht verifizieren. Komischerweise finde ich aber auch keine Dokumente von Microsoft, die die Aussage des Dienstleisters bestätigen würden.
User, die sich jetzt per VPN zu der Azure-Umgebung verbinden, um mit dem ERP arbeiten zu können, haben nun keinen Zugriff mehr auf die Hauptwebseite contoso.com, da der DNS-Server den Server natürlich nicht kennt; und so haben wir wieder das typische Split-DNS-Problem, wenn man den externen Domainnamen auch für die interne Domäne verwendet.
Könnt ihr mir kurz auf die Sprünge helfen, was hier der aktuelle und offizielle Stand bzw. die Empfehlung ist?
Danke im Voraus
ipzipzap
ich habe die letzten Jahre immer ADs als Subdomäne einer bestehenden TLD aufgebaut, also extern contoso.com und intern dann ad.contoso.com oder contoso.net, wenn es so eine freie Domäne noch gab. Ich habe es vermieden, beide gleich zu nennen, um DNS-Problemen etc. aus dem Weg zu gehen.
Nun habe ich hier eine Firma mit 200 Mitarbeitern, die komplett ohne AD arbeitet. Alle Systeme laufen unter Linux in der AWS-Cloud, die Mitarbeiter nutzen Google GSuite und alles drumherum. Für ein paar wenige User gibt es aber Office 365 Lizenzen.
Für ein neues ERP-System wird nun zwingend ein AD benötigt. Es soll nichts on-prem laufen, daher baut ein Dienstleister das alles in Azure auf.
Kommen wir nun zu meiner Frage:
Der Dienstleister behauptet, die Azure-Domäne und die interne AD-Domäne MÜSSEN gleich heißen, das sei seit einiger Zeit von Microsoft so vorgegeben und mittlerweile Best-Practise. Da ich mit Azure noch nicht viel gemacht habe, kann ich das nicht verifizieren. Komischerweise finde ich aber auch keine Dokumente von Microsoft, die die Aussage des Dienstleisters bestätigen würden.
User, die sich jetzt per VPN zu der Azure-Umgebung verbinden, um mit dem ERP arbeiten zu können, haben nun keinen Zugriff mehr auf die Hauptwebseite contoso.com, da der DNS-Server den Server natürlich nicht kennt; und so haben wir wieder das typische Split-DNS-Problem, wenn man den externen Domainnamen auch für die interne Domäne verwendet.
Könnt ihr mir kurz auf die Sprünge helfen, was hier der aktuelle und offizielle Stand bzw. die Empfehlung ist?
Danke im Voraus
ipzipzap
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 603869
Url: https://administrator.de/forum/neues-ad-aufsetzen-muessen-interne-ad-domaene-und-azure-domaene-gleich-heissen-603869.html
Ausgedruckt am: 22.12.2024 um 01:12 Uhr
5 Kommentare
Neuester Kommentar
Moin,
Quelle: [ Clarification on Azure AD DS domain suffix vs on-prem Domain syncing? https://techcommunity.microsoft.com/t5/windows-virtual-desktop/clarifica ...]
Quelle: [Create and configure an Azure Active Directory Domain Services managed domain https://docs.microsoft.com/en-us/azure/active-directory-domain-services/ ...]
Gruß,
Dani
Könnt ihr mir kurz auf die Sprünge helfen, was hier der aktuelle und offizielle Stand bzw. die Empfehlung ist?
Yes you can use any domain like you can on prem but best practice is to use a sub domain of your on prem domain to avoid confusion and DNS issues. You login to AADDS as domain\user (i.e. sub.domain.com\first.last where your AD user is typically first.last@domain.com).
If you create a custom domain name, take care with existing DNS namespaces. It's recommended to use a domain name separate from any existing Azure or on-premises DNS name space.
For example, if you have an existing DNS name space of contoso.com, create a managed domain with the custom domain name of aaddscontoso.com. If you need to use secure LDAP, you must register and own this custom domain name to generate the required certificates.
You may need to create some additional DNS records for other services in your environment, or conditional DNS forwarders between existing DNS name spaces in your environment. For example, if you run a webserver that hosts a site using the root DNS name, there can be naming conflicts that require additional DNS entries.
In these tutorials and how-to articles, the custom domain of aaddscontoso.com is used as a short example. In all commands, specify your own domain name.
Gruß,
Dani
nein sie dürfen nicht gleich heißen. das wäre tödlich. Absoolut. Zwei parallele ADs mit derselben Domain? OMG. OMG. OMG. Jobsicherung bis zur Rente weil das hinzukriegen ist eine LEbensaufgabe an der man scheitern wird. Sowas ging mal gaaanz früher, Workgroups mit dem Netbios Domänenname einrichten und schon gingen NEt Use Befehle und Anders. Aber Schnee von (vor) gestern
Also entweder auf Azure einen DC für das eigene AD installieren
oder eine Federation einrichten
oder eine Vertrauensstellung einrichten
oder im managed AD das eingene irgendwie einbinden, also entweder Root im eigenen AD behalten oder das eigene AD als OU in einem Azure managed AD.
Bin aber kein Azure Architekt, sondern eher auf AWS unterwegs und da gibts sowas bzw man regelt das im AWS über eine SAML Federation.
Also entweder auf Azure einen DC für das eigene AD installieren
oder eine Federation einrichten
oder eine Vertrauensstellung einrichten
oder im managed AD das eingene irgendwie einbinden, also entweder Root im eigenen AD behalten oder das eigene AD als OU in einem Azure managed AD.
Bin aber kein Azure Architekt, sondern eher auf AWS unterwegs und da gibts sowas bzw man regelt das im AWS über eine SAML Federation.