22
Active Directory mit fester Wan IP
Hallo Forum,
ich habe jetzt über die Telekom im DSL Business Tarif eine feste IP Adresse erhalten. Da eine umstrukturierung ansteht, möchte ich meinen Windows 2003 Server mit AD komplett erneuern.
Zur Zeit läuft er mit einer .local Domain. Die Domain die ich im DSL Paket mit dabei habe wird von der T-Com auf meine feste IP umgeleitet.
Da ich zwischenzeitlich auch mit meinem Notebook unterwegs bin und darüber mit einem UMTS Stick in's Internet gehe, ist meine Frage, ob es Sinn macht den DC jetzt auf MeineDomain.de zu setzen oder ob es da, wie hier und da gelesen, zu DNS Problemen kommen kann.
Die Homepage zur Domain wird auf einem im lokalen netzt stehenden Webserver gehostet. Abgesichert ist das ganze über eine M0n0wall die als Router und Gateway fungiert.
In der Hoffnung auf Hilfe.
Tom
ich habe jetzt über die Telekom im DSL Business Tarif eine feste IP Adresse erhalten. Da eine umstrukturierung ansteht, möchte ich meinen Windows 2003 Server mit AD komplett erneuern.
Zur Zeit läuft er mit einer .local Domain. Die Domain die ich im DSL Paket mit dabei habe wird von der T-Com auf meine feste IP umgeleitet.
Da ich zwischenzeitlich auch mit meinem Notebook unterwegs bin und darüber mit einem UMTS Stick in's Internet gehe, ist meine Frage, ob es Sinn macht den DC jetzt auf MeineDomain.de zu setzen oder ob es da, wie hier und da gelesen, zu DNS Problemen kommen kann.
Die Homepage zur Domain wird auf einem im lokalen netzt stehenden Webserver gehostet. Abgesichert ist das ganze über eine M0n0wall die als Router und Gateway fungiert.
In der Hoffnung auf Hilfe.
Tom
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 143994
Url: https://administrator.de/forum/active-directory-mit-fester-wan-ip-143994.html
Ausgedruckt am: 27.12.2024 um 07:12 Uhr
22 Kommentare
Neuester Kommentar
Hi Tom,
bleib bei .local... gibt später mit dem DNS weniger Sorgen. Deine Domain kann trotzdem auf deine WAN-IP-Adressen zeigen. Das hat direkt nichts meinander zu tun.
Grüße,
Dani
bleib bei .local... gibt später mit dem DNS weniger Sorgen. Deine Domain kann trotzdem auf deine WAN-IP-Adressen zeigen. Das hat direkt nichts meinander zu tun.
Die Homepage zur Domain wird auf einem im lokalen netzt stehenden Webserver gehostet. Abgesichert ist das ganze über eine M0n0wall die als Router und Gateway fungiert.
Hängt eher davon ab... wie viele Zugriffe hast und die dick ist deine DSL-Leitung. Des Weiteren benutzt du einen Linux- oder Windowsserver für deine Homepage. Ich empfehle eine DMZ aufzubauen und dort eine Linuxkiste plazieren. Somit kann es keine Probleme mit den LAN geben - vorrausgesetzt die Firewall ist richtig konfiguiert. In Normalfall ist ein Webhoster günstiger um eine Website zu publizieren. Da du dich technisch um nichts kümmern musst.Grüße,
Dani
Zitat von @2P:
@Dani
Kannst du den Gedanken etwas präzisieren?
Welche Probleme/Sorgen schweben dir da vor?
@Dani
Kannst du den Gedanken etwas präzisieren?
Welche Probleme/Sorgen schweben dir da vor?
Die üblichen "freunde", die früher ein .ru kennung hatten und heute cn.xxx
Einen Server ohne DMZ in beide Netze zu stellen ist brandgefährlich, und wenn es ein AD Server - der kein Honeypot ist - sehr unklug.
Dazu muß man aber wirklich nicht viel schreiben, das ist doch allgemeingut in der Bäckerbranche ;-(
Gruß
Was verstehst du von meinem Kommentar nicht?!
du schreibst: "bleib bei .local... gibt später mit dem DNS weniger Sorgen."
Mich würde interessieren, was eben bei diesem Vorgehen für "Sorgen" auftreten können.
Könntest du das vielleicht ein wenig konkretisieren? Hättest du vielleicht mal ein Beispiel parat?
thx
2P
Mich würde interessieren, was eben bei diesem Vorgehen für "Sorgen" auftreten können.
Könntest du das vielleicht ein wenig konkretisieren? Hättest du vielleicht mal ein Beispiel parat?
thx
2P
Hallo @all,
Danke erstmal für Eure Antworten.
Was die DMZ angeht habe ich ja schon im Eingangs Thread geschrieben, das der AD hinter einer m0nowall hängt. Neben router und gateway fungiert diese auch als firewall mit inbound nat und vpn server.
Bei der Namenswahl für den AD geht es mir im Grunde darum, das ich später per wan mit meinem Notebook , den "Luxus" habe, auf meine Daten zugreifen zu können. Weiter "arbeite" ich in einer kleinen Gruppe mit Leuten, die auf Projektdateien zugreifen sollen (VPN).
Der Webserver wird in erster Linie ein Entwicklungsserver für mysql , php und java Anwendungen. Die eigen HP zu hosten ist nur ein Gimmik. Ich habe verschiedene Domains bei einem Hoster liegen und kenne daher schon das Preis-Leistungs Verhältnis.
Da ich die jetzige Domain aber bei der T-Com verwalten müsste, ist da der Aufwand, auf Grund der etwas "bescheidenen" Benutzerfeunlichkeit, deutlich höher.
Ich wollte mit der Frage hier keinen "Krieg" aus lösen.
@timobreil
Die Bäckerbranche ist eine ehrenwerte, hart arbeitende Brange. Ich lese leider häufiger, wenn IT Fachleute etwas einen "minderwertigen" Stempel, auf drücken wollen, das es mit dem Handwerk verglichen wird. Ich selber habe bis vor ca. 10 Jahren in einem handwerlichen Beruf gearbeitet.
Ich kann nicht verstehen, wie intelligente, meist studierte Menschen, so eine Aroganz und Respektlosigkeit an den Tag legen können, alles andere ausser IT den "minderwertigeits" Stempel auf zu drücken.
War jetzt zwar nicht zum Thema, musste aber mal geschrieben werden.
Gruß
Tom
Danke erstmal für Eure Antworten.
Was die DMZ angeht habe ich ja schon im Eingangs Thread geschrieben, das der AD hinter einer m0nowall hängt. Neben router und gateway fungiert diese auch als firewall mit inbound nat und vpn server.
Bei der Namenswahl für den AD geht es mir im Grunde darum, das ich später per wan mit meinem Notebook , den "Luxus" habe, auf meine Daten zugreifen zu können. Weiter "arbeite" ich in einer kleinen Gruppe mit Leuten, die auf Projektdateien zugreifen sollen (VPN).
Der Webserver wird in erster Linie ein Entwicklungsserver für mysql , php und java Anwendungen. Die eigen HP zu hosten ist nur ein Gimmik. Ich habe verschiedene Domains bei einem Hoster liegen und kenne daher schon das Preis-Leistungs Verhältnis.
Da ich die jetzige Domain aber bei der T-Com verwalten müsste, ist da der Aufwand, auf Grund der etwas "bescheidenen" Benutzerfeunlichkeit, deutlich höher.
Ich wollte mit der Frage hier keinen "Krieg" aus lösen.
@timobreil
Die Bäckerbranche ist eine ehrenwerte, hart arbeitende Brange. Ich lese leider häufiger, wenn IT Fachleute etwas einen "minderwertigen" Stempel, auf drücken wollen, das es mit dem Handwerk verglichen wird. Ich selber habe bis vor ca. 10 Jahren in einem handwerlichen Beruf gearbeitet.
Ich kann nicht verstehen, wie intelligente, meist studierte Menschen, so eine Aroganz und Respektlosigkeit an den Tag legen können, alles andere ausser IT den "minderwertigeits" Stempel auf zu drücken.
War jetzt zwar nicht zum Thema, musste aber mal geschrieben werden.
Gruß
Tom
Salve,
wie die Kollegen bereits angemerkt haben, hat der offizielle Webseitenname mit dem internen AD-Domänennamen herzlich wenig am Hut.
Was den Domänennamen anbetrifft, hast du folgende Möglichkeiten:
1. Der Active Directory-Name lautet so wie die Internetdomain. Der Nachteil an dieser Variante ist: Die externen Ressourcen
(z.B. www. ftp, bzw. alles andere, was extern von intern erreichbar sein soll) können intern nicht aufgelöst werden.
Das lässt sich dann (mühsam) so lösen, in dem im internen DNS die externen Ressourcen mit der externen IP-Adresse eingetragen werden.
Das ist durchaus möglich wenn es nicht zu viele externe Ressourcen sind und sich nicht permanent die IP-Adresse ändert.
2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt.
Das bedeutet, wenn der Internet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante wäre auch meine empfohlene!
3. Der Active Directory-Name ist ein anderer als die Internetdomain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn
damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.).
4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net.
Dabei sollten natürlich beide Domains beim ISP registriert werden.
5. Die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ.
http://de.wikipedia.org:80/wiki/ISO_3166
6. Einen abstrakten AD-Domänennamen, unabhängig vom Firmennamen. Das hat den Vorteil, wenn sich die Firma umbenennt, muss nicht sofort
die AD-Domäne wegen einem Namen unbenannt werden.
Viele Grüße
/ > Yusuf Dikmenoglu
wie die Kollegen bereits angemerkt haben, hat der offizielle Webseitenname mit dem internen AD-Domänennamen herzlich wenig am Hut.
Was den Domänennamen anbetrifft, hast du folgende Möglichkeiten:
1. Der Active Directory-Name lautet so wie die Internetdomain. Der Nachteil an dieser Variante ist: Die externen Ressourcen
(z.B. www. ftp, bzw. alles andere, was extern von intern erreichbar sein soll) können intern nicht aufgelöst werden.
Das lässt sich dann (mühsam) so lösen, in dem im internen DNS die externen Ressourcen mit der externen IP-Adresse eingetragen werden.
Das ist durchaus möglich wenn es nicht zu viele externe Ressourcen sind und sich nicht permanent die IP-Adresse ändert.
2. Der Active Directory-Name ist eine Subdomäne zum externen Internet-Auftritt.
Das bedeutet, wenn der Internet-Auftritt "Contoso.com" lautet, so wäre der AD-Name "intra.contoso.com". Diese Variante wäre auch meine empfohlene!
3. Der Active Directory-Name ist ein anderer als die Internetdomain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu Problemen führen, denn
damit könnten Probleme mit Apple-PCs auftreten. Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.).
4. Oder der Webauftritt lautet contoso.de und die interne AD-Domäne lautet contoso.net.
Dabei sollten natürlich beide Domains beim ISP registriert werden.
5. Die TLD AA, ZZ und die Bereiche QM–QZ und XA–XZ.
http://de.wikipedia.org:80/wiki/ISO_3166
6. Einen abstrakten AD-Domänennamen, unabhängig vom Firmennamen. Das hat den Vorteil, wenn sich die Firma umbenennt, muss nicht sofort
die AD-Domäne wegen einem Namen unbenannt werden.
Viele Grüße
/ > Yusuf Dikmenoglu
@ Yusuf-Dikmenoglu
entschuldige wenn ich nochmal nachfrage .... offensichtlich steh ich heute etwas auf der Leitung. Du schreibst:
"Der Active Directory-Name lautet so wie die Internetdomain. Der Nachteil an dieser Variante ist: Die externen Ressourcen
(z.B. www. ftp, bzw. alles andere, was extern von intern erreichbar sein soll) können intern nicht aufgelöst werden."
Das will ich irgendwie nicht verstehen ... warum sollte der Name nicht aufgelöst werden können? Wenn das so wäre, würde im ganzen Netz doch nix mehr funktionieren!
Ich verstehe die Aussage nicht.
entschuldige wenn ich nochmal nachfrage .... offensichtlich steh ich heute etwas auf der Leitung. Du schreibst:
"Der Active Directory-Name lautet so wie die Internetdomain. Der Nachteil an dieser Variante ist: Die externen Ressourcen
(z.B. www. ftp, bzw. alles andere, was extern von intern erreichbar sein soll) können intern nicht aufgelöst werden."
Das will ich irgendwie nicht verstehen ... warum sollte der Name nicht aufgelöst werden können? Wenn das so wäre, würde im ganzen Netz doch nix mehr funktionieren!
Ich verstehe die Aussage nicht.
Hallo Yusuf,
Danke für deine ausfürlichen Informationen.
Mein erster Gedanke war den AD wie die Domain zu nutzen.
Da der AD hinter dem monowall PC hängt, wollte ich im monowall DNS
z.B. alle Anfragen über Port 80, 443, 21,22 an der internen Webserver routen.
Anfrage von außen an den AD, z.B. Clienten registrierung an den AD vom Notebook aus, per DNS Forwarding von monowall an den DNS der AD.
Wenn aber die bessere Lösung z.B. standort.domain.de ist, kann ich damit auch gut leben.
Grüße
Tom
Danke für deine ausfürlichen Informationen.
Mein erster Gedanke war den AD wie die Domain zu nutzen.
Da der AD hinter dem monowall PC hängt, wollte ich im monowall DNS
z.B. alle Anfragen über Port 80, 443, 21,22 an der internen Webserver routen.
Anfrage von außen an den AD, z.B. Clienten registrierung an den AD vom Notebook aus, per DNS Forwarding von monowall an den DNS der AD.
Wenn aber die bessere Lösung z.B. standort.domain.de ist, kann ich damit auch gut leben.
Grüße
Tom
Zitat von @2P:
entschuldige wenn ich nochmal nachfrage .... offensichtlich steh ich heute etwas auf der Leitung.
entschuldige wenn ich nochmal nachfrage .... offensichtlich steh ich heute etwas auf der Leitung.
Ich würde sagen, dir fehlen noch ein paar Grundlagen.
Das will ich irgendwie nicht verstehen ... warum sollte der Name nicht aufgelöst werden können?
Wenn der interne Domänen so wie der externe Interauftritt lautet (z.B. www.contoso.com), wie soll denn der Client wissen wie er dort hin kommt?
Um das zu verstehen muss man sich natürlich mit dem Thema DNS auskennen. Der Client glaubt ja, dass er die Domain contoso.com kennt,
da der interne Domänenname so lautet. Er kennt lediglich wie in diesem Beispiel den Host "www" in der Domain "contoso.com" nicht. Also müsste
man im internen DNS den Host-Eintrag "www" mit der externen IP-Adresse der Webseite erstelllen, damit der Client von intern die Firmenwebseite aufrufen kann.
Wenn das so wäre, würde im ganzen Netz doch nix mehr funktionieren!
Ich verstehe die Aussage nicht.
Ich verstehe die Aussage nicht.
Nimm es mir bitte nicht übel, aber du verstehst die Aussage deshalb nicht, da dir die Grundlagen fehlen.
Du solltest dich mehr mit DNS auseinandersetzen.
Gruß, Yusuf Dikmenoglu
Das was du geschrieben hast hört sich "wild" und nicht fundiert an.
Wenn du mit dem Thema DNS vertraut bist, kannst du die interne AD-Domäne so wie den externen Webauftritt nennen.
Wenn du dir jedoch nicht sicher bist, vermeidest du Fehler in dem du die interne AD-Domäne anders benennst.
Mein Favorit eben: Die interne Domäne soll quasi als Subdomäne zum externen Webauftritt lauten.
Gruß, Yusuf Dikmenoglu
Wenn du mit dem Thema DNS vertraut bist, kannst du die interne AD-Domäne so wie den externen Webauftritt nennen.
Wenn du dir jedoch nicht sicher bist, vermeidest du Fehler in dem du die interne AD-Domäne anders benennst.
Mein Favorit eben: Die interne Domäne soll quasi als Subdomäne zum externen Webauftritt lauten.
Gruß, Yusuf Dikmenoglu
Zitat von @Yusuf-Dikmenoglu:
Salve,
3. Der Active Directory-Name ist ein anderer als die Internetdomain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu
Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten.
Salve,
3. Der Active Directory-Name ist ein anderer als die Internetdomain z.B. contoso.local usw. Sogar die Endung LOCAL kann zu
Problemen führen, denn damit könnten Probleme mit Apple-PCs auftreten.
Ave Yusuf,
das hab ich auch schon zu oft gelesen, aber in meiner ganzen W2K Domain Admin Laufbahn ist mir noch nie ein konkreter Fall untergekommen, wo es denn wirklich so ist.
Hast du da einen speziellen Fall - den man nachvollziehen könnte?
Gruß
grrrrrrr ... stimmt. Richtig lesen hilft.
Wenn ein Dienst - wie in deinem Beispiel ftp - extern (!!!) gehostet wird, scheitert die Namensauflösung, da die Ressource intern erwartet wird.
Ich habe wohl das "extern" überlesen.
Unabhängig davon - und obgleich eine untergeordnete Domäne elganter scheint - sehe ich in der oben Beschriebenen Konstellation keine grossen Hindernisse für den AD-Namen die Internetdomain zu verwenden. Von extern gehosteten Diensten war bisher nicht die Rede ... und selbst wenn, so sind die entsprechenden HostA und PTR Einträge sicher schnell gemacht.
Nichts desto trotz werde ich jetzt erst einmal an meinen Grundlagen arbeiten.
Gruß
2P
Wenn ein Dienst - wie in deinem Beispiel ftp - extern (!!!) gehostet wird, scheitert die Namensauflösung, da die Ressource intern erwartet wird.
Ich habe wohl das "extern" überlesen.
Unabhängig davon - und obgleich eine untergeordnete Domäne elganter scheint - sehe ich in der oben Beschriebenen Konstellation keine grossen Hindernisse für den AD-Namen die Internetdomain zu verwenden. Von extern gehosteten Diensten war bisher nicht die Rede ... und selbst wenn, so sind die entsprechenden HostA und PTR Einträge sicher schnell gemacht.
Nichts desto trotz werde ich jetzt erst einmal an meinen Grundlagen arbeiten.
Gruß
2P
das hab ich auch schon zu oft gelesen, aber in meiner ganzen W2K Domain Admin Laufbahn ist mir noch nie ein konkreter Fall
untergekommen, wo es denn wirklich so ist.
untergekommen, wo es denn wirklich so ist.
Ich muss das noch ergänzen: Bis MacOS < 10.1/oder2 gabe es das Problem in Apples Rendezvous-Protokoll.
Ab der Version 10.3 ist dieses Problem behoben worden. Ich kann dir aber nicht mehr sagen,
als das was ich geschrieben haben bzw. was genau das Problem war.
Gruß, Yusuf
Natürlich: Wenn du fit im Thema DNS bist, kannst du die interne AD-Domäne so wie den Webauftritt nennen.
Das funktioniert technisch ja auch und ist supportet. Es ist aber aufwändig. Einfacher ist die Variante zwei
von meinen genannten Möglichkeiten.
Gruß, Yusuf
Das funktioniert technisch ja auch und ist supportet. Es ist aber aufwändig. Einfacher ist die Variante zwei
von meinen genannten Möglichkeiten.
Gruß, Yusuf
Ich hatte letztes Jahr ein Problem mit einem IPhone, welches partout nicht dazu zu bewegen war eine Website in einem *.local Netz aufzurufen; respektive den servernamen aufzulösen. Ich kann die damals gefundene Erklärung leider nicht mehr korrekt reproduzieren. Ich meine aber, das Apple in seinem Bonjour-Protokoll bzw. zerokonf (ähnlich apipa) technik die top level domain local reserviert und es daher zu problemen in *.local netzen kommen kann ...
ich meine aber auch gelesen zu haben, das dieses problem mittlerweile gelöst ist.
will man auf nummer sicher gehen, so kann man als tld
.test
.example
.invalid
.localhost
verwenden. ( http://rfc-ref.org/RFC-TEXTS/2606/index.html )
ich meine aber auch gelesen zu haben, das dieses problem mittlerweile gelöst ist.
will man auf nummer sicher gehen, so kann man als tld
.test
.example
.invalid
.localhost
verwenden. ( http://rfc-ref.org/RFC-TEXTS/2606/index.html )
Auch wäre es denkbar, dass die Endung LOCAL offiziell wird (sowie info, biz usw.).
Ich würde
.local schon als offiziell bezeichnen. Die TLD gehört zu mDNS (das derzeit noch mit RFC Draft Status ist).Wie du schon bemerkt hast wird mDNS aber primär nur von Apple und von Printservern (Marketingname "Bonjour") eingesetzt.
Das "Problem" ist die Überschneidung die entsteht, wenn ein mDNS-fähiges Gerät korrekterweise versucht einen .local Host über Multicast aufzulösen.
Die "Lösung" ist der entsprechende Hack "Wenn Multicast halt keine Antwort liefert dann probieren wir danach einfach den normalen DNS".
Ich würde auch zu 2 raten, wobei man mit 5 ein relativ geringes Risiko eingeht, da xa-xz reserviert ist und großen Raum zum Ausbreiten bietet
Ein simples Beispiel wäre das du einen Webserver beim Carrier stehen hast. Dieser läuft unter www.DeineDomain.de. Solang du den nicht manuell in den DNS einträgst wirst du aus deinem internen Netz auf diesen nicht zugreiffen können. Dein DNS meint er ist für "deinedomain.de" zuständig -> und kennt den Rechner nicht. Da er aber ja für diese Domain zuständig ist fragt er gar nicht beim Provider an -> sondern gibt dir nen Host not found zurück.
Die Frage ist aber ja auch umgekehrt: Welchen VORTEIL bringt es dir die Namen gleichzustellen? Du kannst von Extern ja beim Provider problemlos www.deinedomain.de auf deine IP legen lassen -> der Internet-Domain-Name hat ehrlich gesagt mal so rein gar nix mit dem Windows Domain Namen zu tun... (du kannst wenn du lustig bist auch deine Domain mircosoft.com nennen -> glaub mir, das gibt zwar einige Probleme für dich, MS wird das aber nichtmal im Ansatz stören...)
Die Frage ist aber ja auch umgekehrt: Welchen VORTEIL bringt es dir die Namen gleichzustellen? Du kannst von Extern ja beim Provider problemlos www.deinedomain.de auf deine IP legen lassen -> der Internet-Domain-Name hat ehrlich gesagt mal so rein gar nix mit dem Windows Domain Namen zu tun... (du kannst wenn du lustig bist auch deine Domain mircosoft.com nennen -> glaub mir, das gibt zwar einige Probleme für dich, MS wird das aber nichtmal im Ansatz stören...)
Wie sieht das denn dann ganz praktisch betrachtet aus?
Beim Installieren des AD´s entscheide ich mich dann für "Vorhandene Gesamtstruktur" >>> "neue Domäne in vorhandener Gesamtstruktur erstellen".
Als nächstes wähle ich den Namen der untergeordneteten Domäne und muss jetzt die Anmeldeinformationen für den DC der übergeordneten Donäne angeben.
Und hier scheitere ich ... den kenn ich doch gar nicht. D.h. die verwalte ich doch gar nicht.
Wie realisiert man so etwas ganz praktisch betrachtet????
Vielen Dank
Oscar
Beim Installieren des AD´s entscheide ich mich dann für "Vorhandene Gesamtstruktur" >>> "neue Domäne in vorhandener Gesamtstruktur erstellen".
Als nächstes wähle ich den Namen der untergeordneteten Domäne und muss jetzt die Anmeldeinformationen für den DC der übergeordneten Donäne angeben.
Und hier scheitere ich ... den kenn ich doch gar nicht. D.h. die verwalte ich doch gar nicht.
Wie realisiert man so etwas ganz praktisch betrachtet????
Vielen Dank
Oscar
Und hier scheitere ich ... den kenn ich doch gar nicht. D.h. die verwalte ich doch gar nicht.
Ist ja auch falsch.
Du musst "Neue Domäne in neuer Gesamtstruktur" auswählen.
Das wäre dann doch aber nicht die oben genannte untergeordnete Domäne.
Eine untergeordnete Domäne nutzt doch einen gemeinsamen fortlaufenden Namensraum.
Die oben genannte Domäne intra.contoso.com ist doch eine untergeordnete Domäne der Domäne contoso.com.
Eine untergeordnete Domäne nutzt doch einen gemeinsamen fortlaufenden Namensraum.
Die oben genannte Domäne intra.contoso.com ist doch eine untergeordnete Domäne der Domäne contoso.com.
Streng genommen, ja.
In diesem Fall aber: Nein, denn
In diesem Fall aber: Nein, denn
contoso.com ist nur eine DNS-Domain und keine AD-Domain und darum geht es hier primär.
