42
AD umbennen
Hallo zusammen,
frohes neues Jahr - neues Jahr neue Herausforderungen.
ich habe einen Kunden übernommen wo ein Server zu tauschen ist. Dzt. läuft noch ein Win2012R2 - also eine BareMetal Kiste für Alles. Diese wird jetzt weichen und und durch 4 Win2022 VM´s ersetzt.
Meine Frage:
die Interne Domain/FQDN heißt jetzt "firma.de" also gleich wie die externe Domain und der NetBios Name lautet "Firma".
ich hätte gerne die Domain/FQDN umbenannt zb. in "ad.firma.de". Der NetBios Name kann gleich bleiben.
Ich habe mir jetzt schon diverse Vorgehensweisen rausgesucht. Aber vielleicht hat hier noch der eine oder andere einen Tipp für mich oder eine besonders gute Anleitung. Vor alledem die Frage ob ich erst umbenennen sollte und dann die Domain migrieren soll oder umgekehrt.
Der Plan ist die Domain auf einen neuen W2022 DC zu migrieren und dann langsam alles Dienste auf die anderen Server aufzuteilen bis ich den alten abdrehen kann.
Ich habe zwar nur ca. 35 Clients intern und im Homeoffice aber es gibt diverse GPO´s und Roaming Profiles weshalb das Umbenennen möglicherweise der einfachere Weg ist als alles neu zu machen.
Man könnte natürlich die Domain auch so bestehen lassen allerdings muss ich dann die DNS Einträge immer doppelt führen extern und intern was schon zu seltsamen Fehlern geführt hat.
Was mein Ihr? Wie würdet Ihr vorgehen?
Danke und lg
J
frohes neues Jahr - neues Jahr neue Herausforderungen.
ich habe einen Kunden übernommen wo ein Server zu tauschen ist. Dzt. läuft noch ein Win2012R2 - also eine BareMetal Kiste für Alles. Diese wird jetzt weichen und und durch 4 Win2022 VM´s ersetzt.
Meine Frage:
die Interne Domain/FQDN heißt jetzt "firma.de" also gleich wie die externe Domain und der NetBios Name lautet "Firma".
ich hätte gerne die Domain/FQDN umbenannt zb. in "ad.firma.de". Der NetBios Name kann gleich bleiben.
Ich habe mir jetzt schon diverse Vorgehensweisen rausgesucht. Aber vielleicht hat hier noch der eine oder andere einen Tipp für mich oder eine besonders gute Anleitung. Vor alledem die Frage ob ich erst umbenennen sollte und dann die Domain migrieren soll oder umgekehrt.
Der Plan ist die Domain auf einen neuen W2022 DC zu migrieren und dann langsam alles Dienste auf die anderen Server aufzuteilen bis ich den alten abdrehen kann.
Ich habe zwar nur ca. 35 Clients intern und im Homeoffice aber es gibt diverse GPO´s und Roaming Profiles weshalb das Umbenennen möglicherweise der einfachere Weg ist als alles neu zu machen.
Man könnte natürlich die Domain auch so bestehen lassen allerdings muss ich dann die DNS Einträge immer doppelt führen extern und intern was schon zu seltsamen Fehlern geführt hat.
Was mein Ihr? Wie würdet Ihr vorgehen?
Danke und lg
J
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: 5207820464
Url: https://administrator.de/contentid/5207820464
Ausgedruckt am: 19.11.2024 um 02:11 Uhr
42 Kommentare
Neuester Kommentar
Ich würde Backups machen und prüfen, dass die gut funktionieren.
Dann würde ich ein Image der alten Hardware auf die neue Hardware bringen und dort auf einer Insel einen Test fahren.
Dann würde ich ein Image der alten Hardware auf die neue Hardware bringen und dort auf einer Insel einen Test fahren.
Was unbelanglos sagt plus:
Gibt es einen Exchange-Server? Wenn ja ist von einer Umbenennung abzusehen.
Gibt es einen Exchange-Server? Wenn ja ist von einer Umbenennung abzusehen.
Exchange gibt es keinen.
Evtl. ein wenig OT, aber die Frage interessiert mich trotzdem:
Wieso denn die Domäne von firma.de zu ad.firma.de umbenennen? Was ist der Vorteil?
Wieso denn die Domäne von firma.de zu ad.firma.de umbenennen? Was ist der Vorteil?
Zitat von @ludaku:
Evtl. ein wenig OT, aber die Frage interessiert mich trotzdem:
Wieso denn die Domäne von firma.de zu ad.firma.de umbenennen? Was ist der Vorteil?
Evtl. ein wenig OT, aber die Frage interessiert mich trotzdem:
Wieso denn die Domäne von firma.de zu ad.firma.de umbenennen? Was ist der Vorteil?
Einen richtig echten Vorteil gibt es nicht. Eher kosmetischer Natur.
Sich am Verzeichnis ad.* oder site.* oder int.* oder amt.* Anzumelden ist schon was anderes als sich an dem Verzeichnis z. B.: bad-toelz-wolfratshausen.de anzumelden.
Zitat von @2423392070:
Einen richtig echten Vorteil gibt es nicht. Eher kosmetischer Natur.
Sich am Verzeichnis ad.* oder site.* oder int.* oder amt.* Anzumelden ist schon was anderes als sich an dem Verzeichnis z. B.: bad-toelz-wolfratshausen.de anzumelden.
Einen richtig echten Vorteil gibt es nicht. Eher kosmetischer Natur.
Sich am Verzeichnis ad.* oder site.* oder int.* oder amt.* Anzumelden ist schon was anderes als sich an dem Verzeichnis z. B.: bad-toelz-wolfratshausen.de anzumelden.
Also für mich spricht aber aus kosmetischer Sicht eher firma.de.
Für ad.firma.de spricht für mich nur, dass die Splitbrain-DNS Thematik umgangen werden kann.
Und dann meldest du dich an ad.firma.de an? Wir melden uns an ad an.
DNS ist noch Mal ein Thema für dich, wobei man sehr viel falsch machen kann. Slitbrain ist ein Designfehler.
DNS ist noch Mal ein Thema für dich, wobei man sehr viel falsch machen kann. Slitbrain ist ein Designfehler.
Moin,
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Ha
Hatte ich schon erwähnt, dass man beim DNS viel falsch machen kann?
Zitat von @em-pie:
Moin,
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Moin,
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Hatte ich schon erwähnt, dass man beim DNS viel falsch machen kann?
Zitat von @2423392070:
Und dann meldest du dich an ad.firma.de an? Wir melden uns an ad an.
Du sprichst nun aber vom Netbios Namen, oder nicht? Selbst bei ad.firma.de wäre der Netbios ja dann doch FIRMA.Und dann meldest du dich an ad.firma.de an? Wir melden uns an ad an.
Slitbrain ist ein Designfehler.
Der aber nur mittels ad.firma.de umgangen werden kann. Oder sehe ich das falsch?Zitat von @em-pie:
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Ja und dann müsste das AD jedoch ad.firma.de heissen, ansonsten lässt sich diese Problem doch nicht lösen?wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Wir nutzen intern.domain.de und NETBIOS "INTERN". Ich kann mich nicht beklagen aber umbenennen würde ich es jetzt glaube ich lieber nicht 
PS: Firmen ändern sich schneller mal als einem lieb ist, INTERN ist neutral.
PS: Firmen ändern sich schneller mal als einem lieb ist, INTERN ist neutral.
Zitat von @ukulele-7:
Wir nutzen intern.domain.de und NETBIOS "INTERN". Ich kann mich nicht beklagen aber umbenennen würde ich es jetzt glaube ich lieber nicht
PS: Firmen ändern sich schneller mal als einem lieb ist, INTERN ist neutral.
Wir nutzen intern.domain.de und NETBIOS "INTERN". Ich kann mich nicht beklagen aber umbenennen würde ich es jetzt glaube ich lieber nicht
PS: Firmen ändern sich schneller mal als einem lieb ist, INTERN ist neutral.
Dies betrifft nochmals etwas anderes, eher organisatorischer Natur. Ich spiele hier aber eher technische Seite mit der Splitbrain Thematik an. (Und lasse deine Problem mit der Umfirmierung/Fusion/etc. mal aussen vor, welche aber in der Realitität auch noch einen Knackpunkt darstellt.)
@chaot1coz
@ludaku
@2423392070
Es hängt in erster Linie vom Design der Landschaft und des DNS Services ab.
Gruß,
Dani
Gibt es einen Exchange-Server? Wenn ja ist von einer Umbenennung abzusehen.
Ein Renaming ist trotzdem möglich. Es sind eben noch ein paar Dinge zu beachten und damit auch ein paar Schritte mehr zu tun.@ludaku
Für ad.firma.de spricht für mich nur, dass die Splitbrain-DNS Thematik umgangen werden kann.
Alternativ eine dedizierte Domain (firma.net, firma.org) hernehmen. Die ausschließlich für IT Services genutzt wird. Wir stufen hierbei nochmals ab, zwischen Service OnPremise und Cloud. Damit auch nochmals an Hand es FQDN deutlich wird wo das Zeugs läuft.@2423392070
DNS ist noch Mal ein Thema für dich, wobei man sehr viel falsch machen kann. Slitbrain ist ein Designfehler.
Das kann man meiner Meinung nach pauschal nicht sagen. Split-DNS kann Fluch und Segen zu gleich sein.Es hängt in erster Linie vom Design der Landschaft und des DNS Services ab.
Gruß,
Dani
1
Warum soll es überhaupt im DNS zu einem Slipt kommen, wenn man das DNS sauber designt und pflegt?
DNS im Haus ist eine Kette. Öffentlich ist es auch kein Zufall, was im DNS steht.
Übrigens sind www.domain.tld und domain.tld zwei verschiedene Hosts, die vielleicht die selbe IP haben und auch den selben Webserver.
Wenn es die selbe Sache ist, dann muss ich noch Mal erwähnen, dass man beim DNS viel falsch machen kann.
DNS im Haus ist eine Kette. Öffentlich ist es auch kein Zufall, was im DNS steht.
Übrigens sind www.domain.tld und domain.tld zwei verschiedene Hosts, die vielleicht die selbe IP haben und auch den selben Webserver.
Wenn es die selbe Sache ist, dann muss ich noch Mal erwähnen, dass man beim DNS viel falsch machen kann.
Zitat von @Dani:
Für ad.firma.de spricht für mich nur, dass die Splitbrain-DNS Thematik umgangen werden kann.
Alternativ eine dedizierte Domain (firma.net, firma.org) hernehmen. Die ausschließlich für IT Services genutzt wird. Wir stufen hierbei nochmals ab, zwischen Service OnPremise und Cloud. Damit auch nochmals an Hand es FQDN deutlich wird wo das Zeugs läuft.Egal welche der beiden Methoden (ad.firma.de oder dedizierte Domain für AD) man verwendet stellt sich mir aber eine Frage. Beide Methoden sind für den Endbenutzer, welche sich normalerweise an der AD mit benutzer@firma.de anmelden statt mit FIRMA\benutzer, umständlicher, da ersteres ja bisher einfach seine E-Mail-Adresse war. Nun müsste sich dieser User ja neu mit benutzer@ad.firma.de oder benutzer@ad-firma.de anmelden, seine E-Mail-Adresse wäre aber benutzer@firma.de. Kann man diese alternative Domain irgendwie im AD hinterlegen? (Wie z.B. im Exchange eine alternative SMTP-Adresse.)
Ja in AD Domains and Trusts kann man alternative UPN-Suffixe hinterlegen und diesen dann in AD Users and Computers auswählen.
Siehe z.B. https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-s ...
Siehe z.B. https://www.stephenwagner.com/2018/10/16/how-to-add-an-alternative-upn-s ...
1
Moin,
ja und? Wo ist da das Problem? Bei intern 35 Clients, wie viele Websites sind es dann wo du ein A-Rekord setzen musst, zumal ja kein Mailserver besteht. Das sollten nicht mehr als 2 oder 3 Websites sein. Das ist und bleibt in der Größe in meinen Augen überschaubar. Und davon abgesehen, muss man das Große und Ganze immer im Blick haben:
In meinem letzten Systemhaus in dem ich tätig war, haben wir alle Kunden von domain.local auf domain.de umgestellt. Bei jedem dieser Kunden (ca. 250) haben wir dann Split-DNS eingerichtet und es gab nie Probleme. Wenn man weiß wie DNS funktioniert und weiß was man macht, dann läuft es, genau so wie (auch wenn ich damit jetzt den einen oder anderen ggf. provoziere) domain.local bei entsprechender Konfiguration des DNS weiterhin problemlos funktioniert.
Gruß
Doskias
Zitat von @em-pie:
Moin,
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
Moin,
wenn das ad firma.de lautet, besteht immer das Problem, dass wenn man vom LAN heraus auf die Firmenwebsite zugreifen will, ein einfaches https://firma.de nicht klappt. Der DNS-Admin muss im internen Netz also immer einen A-Record www.firma.de anlegen. Die Anwender müssen im Anschluss dann immer www.firma.de aufrufen.
ja und? Wo ist da das Problem? Bei intern 35 Clients, wie viele Websites sind es dann wo du ein A-Rekord setzen musst, zumal ja kein Mailserver besteht. Das sollten nicht mehr als 2 oder 3 Websites sein. Das ist und bleibt in der Größe in meinen Augen überschaubar. Und davon abgesehen, muss man das Große und Ganze immer im Blick haben:
Zitat von @2423392070:
Übrigens sind www.domain.tld und domain.tld zwei verschiedene Hosts, die vielleicht die selbe IP haben und auch den selben Webserver.
Ganz genau. Und wenn man Firewall-Regeln erstellt ist das ungemein wichtig und relevant. Bei uns ist zum Beispiel in der Firewall wikipedia.de gesperrt und translate.google.de ebenso. Wieso? Weil die Website nun mal de.wikipedia.org und translate.google.com lauten. Und genau so siehts mit der Firmenwebsite aus www.unserefirma.de ist freigegeben, unserefirma.de nicht.Übrigens sind www.domain.tld und domain.tld zwei verschiedene Hosts, die vielleicht die selbe IP haben und auch den selben Webserver.
In meinem letzten Systemhaus in dem ich tätig war, haben wir alle Kunden von domain.local auf domain.de umgestellt. Bei jedem dieser Kunden (ca. 250) haben wir dann Split-DNS eingerichtet und es gab nie Probleme. Wenn man weiß wie DNS funktioniert und weiß was man macht, dann läuft es, genau so wie (auch wenn ich damit jetzt den einen oder anderen ggf. provoziere) domain.local bei entsprechender Konfiguration des DNS weiterhin problemlos funktioniert.
Gruß
Doskias
Zitat von @ludaku:
Zitat von @Dani:
Kann man diese alternative Domain irgendwie im AD hinterlegen? (Wie z.B. im Exchange eine alternative SMTP-Adresse.)Ja kannst du. Relativ einfach. Im Active Directory-Domänen und Vertrauensstellungen, rechtsklick Eigenschaften. Dort dann die Benutzerprinzipalnamen-Suffixe eintrage. Die dort eingetragenen Suffixe, sind dann hinterher in der Domäne auswählbar:
Siehe: https://www.windowspro.de/roland-eich/benutzerprinzipalname-upn-active-d ...
Also wenn man domain.intern hat, dann musst du dort domain.de eintragen. Im AD kann man dann zwischen user@domain.inter und user@domain.de auswählen.
Gruß
Doskias
Zitat von @ludaku:
Egal welche der beiden Methoden (ad.firma.de oder dedizierte Domain für AD) man verwendet stellt sich mir aber eine Frage. Beide Methoden sind für den Endbenutzer, welche sich normalerweise an der AD mit benutzer@firma.de anmelden statt mit FIRMA\benutzer, umständlicher, da ersteres ja bisher einfach seine E-Mail-Adresse war. Nun müsste sich dieser User ja neu mit benutzer@ad.firma.de oder benutzer@ad-firma.de anmelden, seine E-Mail-Adresse wäre aber benutzer@firma.de. Kann man diese alternative Domain irgendwie im AD hinterlegen? (Wie z.B. im Exchange eine alternative SMTP-Adresse.)
Zitat von @Dani:
Für ad.firma.de spricht für mich nur, dass die Splitbrain-DNS Thematik umgangen werden kann.
Alternativ eine dedizierte Domain (firma.net, firma.org) hernehmen. Die ausschließlich für IT Services genutzt wird. Wir stufen hierbei nochmals ab, zwischen Service OnPremise und Cloud. Damit auch nochmals an Hand es FQDN deutlich wird wo das Zeugs läuft.Egal welche der beiden Methoden (ad.firma.de oder dedizierte Domain für AD) man verwendet stellt sich mir aber eine Frage. Beide Methoden sind für den Endbenutzer, welche sich normalerweise an der AD mit benutzer@firma.de anmelden statt mit FIRMA\benutzer, umständlicher, da ersteres ja bisher einfach seine E-Mail-Adresse war. Nun müsste sich dieser User ja neu mit benutzer@ad.firma.de oder benutzer@ad-firma.de anmelden, seine E-Mail-Adresse wäre aber benutzer@firma.de. Kann man diese alternative Domain irgendwie im AD hinterlegen? (Wie z.B. im Exchange eine alternative SMTP-Adresse.)
Ja, kann man alles machen. Aber wozu?
Irgendwie quirlst du alles durcheinander.
@ludaku
@2423392070
Gruß,
Dani
Beide Methoden sind für den Endbenutzer, welche sich normalerweise an der AD mit benutzer@firma.de anmelden statt mit FIRMA\benutzer, umständlicher, da ersteres ja bisher einfach seine E-Mail-Adresse war.
wie Kollege @chaot1coz geschrieben hat, kann man problemlos weitere UPNs anlegen. D.h. bei uns melden sich die Leute nach wie vor mit der E-Mail-Adresse an.@2423392070
Übrigens sind www.domain.tld und domain.tld zwei verschiedene Hosts, die vielleicht die selbe IP haben und auch den selben Webserver.
Wenn es die selbe Sache ist, dann muss ich noch Mal erwähnen, dass man beim DNS viel falsch machen kann.
Ich glaub wir reden aneinander vorbei, meinem aber beide das Selbe. Wenn das AD domain.tld heißt und im Internet Service wie eine Webseite ebenfalls unter domain.tld veröffentlicht wurde, dann ist zwangsweise Split-DNS notwendig. Das heißt aber nicht, dass es schlecht ist.Wenn es die selbe Sache ist, dann muss ich noch Mal erwähnen, dass man beim DNS viel falsch machen kann.
Gruß,
Dani
Nö, Du hast was mit dem DNS falsch verstanden. DNS ist eine Kette, da splittet nichts.
Wenn man sich die Eier selbst einbaut, dann haben nicht andere etwas falsch verstanden
Wenn man sich die Eier selbst einbaut, dann haben nicht andere etwas falsch verstanden
Es heisst nun mal Splitbrain-DNS ...
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
Zitat von @ludaku:
Es heisst nun mal Splitbrain-DNS ...
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
Es heisst nun mal Splitbrain-DNS ...
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
Ist auch kein Designfehler, sondern durch Cloud-Hosting zunehmend erforderlich. Die Thematik hat aber eher nichts mit Split-DNS zu tun.
Du kannst natürlich in der intern gehosteten Zone Records für Ressourcen setzen, die auch extern bestehen - gewissermaßen "Split-DNS-Methodik". Diese Records sind dann aber mit den externen identisch. Also der Differenzierungsaspekt (ein Name löst auf unterschiedliche Ressourcen auf, abhängig vom Netzwerkkontext), der Split-DNS gewöhnlich ausmacht, entfällt.
Daher ist dies auch nicht die einzige Lösung, sondern die elegantere (da redundante Konfigurationen vermeidend) wäre, eine Zone wie www.firma.tld an den öffentlichen Nameserver zu delegieren.
Grüße
Richard
Ihr würdet also die interne Domain mit firma.de belassen und die Tatsache also Splitbrain-DNS akzeptieren das eben alle externen DNS Einträge auch intern angelegt werden?
Danke euch lg
J
Danke euch lg
J
Zitat von @ludaku:
Es heisst nun mal Splitbrain-DNS ...
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
Es heisst nun mal Splitbrain-DNS ...
https://learn.microsoft.com/de-de/windows-server/networking/dns/deploy/s ...
https://en.wikipedia.org/wiki/Split-horizon_DNS
Wir reden hier aber über kein Split Brain. Meine Güte, schlimmer als Freitag.
Zitat von @2423392070:
Wir reden hier aber über kein Split Brain. Meine Güte, schlimmer als Freitag.
Das der angesprochene Fall nicht unter Splitbrain-DNS fällt habe ich nach dem Beitrag von @c.r.s. auch gemerkt. Das habe ich falsch verstanden. Mein Fehler.Wir reden hier aber über kein Split Brain. Meine Güte, schlimmer als Freitag.
Dass du genau das meinst hättest du ja auch einfach von Anfang an genau so sagen können. Dann wäre das überflüssig gewesen.
Meine Güte
Na dann - Ihr würdet also die interne Domain mit firma.de belassen und die Tatsache akzeptieren das eben alle externen DNS Einträge auch intern angelegt werden?
Wie würdet ihr das handhaben?
Wie würdet ihr das handhaben?
Zitat von @Jacolo:
Na dann - Ihr würdet also die interne Domain mit firma.de belassen und die Tatsache akzeptieren das eben alle externen DNS Einträge auch intern angelegt werden?
Wie würdet ihr das handhaben?
Na dann - Ihr würdet also die interne Domain mit firma.de belassen und die Tatsache akzeptieren das eben alle externen DNS Einträge auch intern angelegt werden?
Wie würdet ihr das handhaben?
Genau so. Sehe keinen Vorteil einer Umbenennung, eher Nachteile.
Wer bitte, repliziert seine interne MS-AD-DNS-Zone direkt ins öffentliche Internet?
Das geht, aber wer bitte macht sowas?
Außerdem hat das eine mit dem anderen Kauf was zu tun.
Das geht, aber wer bitte macht sowas?
Außerdem hat das eine mit dem anderen Kauf was zu tun.
Zitat von @2423392070:
Wer bitte, repliziert seine interne MS-AD-DNS-Zone direkt ins öffentliche Internet?
Mal zum Verständnis (für mich, dich, alle), damit wir die selbe Sprache sprechen:Wer bitte, repliziert seine interne MS-AD-DNS-Zone direkt ins öffentliche Internet?
Das AD lautet firma.de. Der öffentliche Webauftritt lautet ebenfalls
firma.de- Mache ich intern ein
nslookup firma.deerhalte ich die IPs meiner DCs. - Mache ich extern ein
nslookup firma.de, antworten mir eben nicht die DCs, sondern ein Webserver/ öffentlicher Name-Server - so auch richtig.
Gibt es jetzt den DNS-Record cloud.firma.de, welcher auf einem vHost bei (von mir aus Hetzner) zeigt, klappt das von extern prima. Aber, wer wird mir aus dem internen Netz antworten bzw. WAS wird die Antwort sein, wenn ich manuell keinen Eintrag am lokalen DNS gesetzt habe!? Denn innerhalb von firma.de gibt es keinen Eintrag
cloudVielleicht hab ich hier auch einen Denk-/ Wissensfehler!?
Das ist doch schon wieder eine Konstruktion ohne Sinn.
Da sind viele Sachen offen und auch nicht fachmännisch.
Außerdem wer sagt, denn dass der öffentliche Webserver im Haus steht uns intern so angesurft wird?
Alles Spekulationen
Da sind viele Sachen offen und auch nicht fachmännisch.
Außerdem wer sagt, denn dass der öffentliche Webserver im Haus steht uns intern so angesurft wird?
Alles Spekulationen
Außerdem wer sagt, denn dass der öffentliche Webserver im Haus steht uns intern so angesurft wird?
der Server für die cloud steht ja eben nicht im eigenen Haus!Und wenn Projektteams über solche Plattformen Daten mit Partner austauschen, fahren die ja erst nicht nach Hause, rufe "cloud.firma.de" auf, laden das Zeug hoch und kommen wieder ins Unternehmen. Folglich werden die auch dort das Zeug entsprechend im Büro (bzw. von den dort platzierten Systemen) hochladen.
Aber wenn die Server eh außerhalb sind , dann 8st was genau das DNS Problem?
Aufruf von cloud.firma.de von "Unterwegs"
Die NameServer hinter der TLD .de werden nach der SLD firma befragt und zeigen auf den DNS von firma.de
Der DNS hinter firma.de wird nach cloud befragt und es wird auf die IP des Webservers verwiesen.
Ziel erreicht
(also genau deine weiter oben genannte Verkettung)
Aufruf von cloud.firma.de aus dem Firmen-LAN
Es wird der interne DNS-Server nach cloud befragt (weil ja firma.de auf die eigenen DNS-Server zeigt)
Die eigenen DNS-Server kennen cloud nicht und geben nichts zurück:
Edit: natürlich hängt noch der dem Client bekannte Resolver in der Kette drin
Die NameServer hinter der TLD .de werden nach der SLD firma befragt und zeigen auf den DNS von firma.de
Der DNS hinter firma.de wird nach cloud befragt und es wird auf die IP des Webservers verwiesen.
Ziel erreicht
(also genau deine weiter oben genannte Verkettung)
Aufruf von cloud.firma.de aus dem Firmen-LAN
Es wird der interne DNS-Server nach cloud befragt (weil ja firma.de auf die eigenen DNS-Server zeigt)
Die eigenen DNS-Server kennen cloud nicht und geben nichts zurück:
nslookup cloud.firma.de
Server: DC01.firma.de
Address: 10.20.30.1
*** cloud.firma.de wurde von DC01.firma.de nicht gefunden: Non-existent domain.Edit: natürlich hängt noch der dem Client bekannte Resolver in der Kette drin
Ich gebe besser auf und arbeite an der Umbenennung des Forums und des Berufes.
Unglaublich was hier schon wieder gedreht wird.
Unglaublich was hier schon wieder gedreht wird.
Zitat von @2423392070:
Ich gebe besser auf und arbeite an der Umbenennung des Forums und des Berufes.
Unglaublich was hier schon wieder gedreht wird.
Fühl dich frei und erkläre/ korrigiere. Genau das hast du nämlich bisweilen nicht getan. Du schreibst immer nur "ihr labert hier einen Mist" (überspitzt formuliert) aber eine Erklärung für dein "Wenn man es richtig macht, ist das kein Problem, wenn das AD genau so lautet wie der öffentliche Webauftritt" gibst du auch nicht Ich gebe besser auf und arbeite an der Umbenennung des Forums und des Berufes.
Unglaublich was hier schon wieder gedreht wird.
Sicherlich habe ich oben den dem Client bekannten DNS-Server (welcher DNS-Anfragen cached) ausgelassen, aber am "Grundproblem" ändert es nichts....
@2423392070
Nichts desto trotz gibt es von @Frank eine Definition dieser Plattform:
Ausführliche Kommentare von @Frank findest im Bereich OffTopic. Das Thema haben wir nämlich mehrfach besprochen.
Gruß,
Dani
Ich gebe besser auf und arbeite an der Umbenennung des Forums
Wir sind für Vorschläge grundsätzlich offen. Nichts desto trotz gibt es von @Frank eine Definition dieser Plattform:Administrator ein Ort, an dem IT-begeisterte User sich austauschen, auf dem Laufenden bleiben und ihre Karriere vorantreiben.Gruß,
Dani
2
Danke um die rege Diskussion aber ich wollte mich nur um eure Meinung bemühen ob man auf meinem Fall bezogen, wie ganz zu Anfang gefragt, umbenennen sollte oder eben nicht.
Die Benennenung hat in erster Linie kosmetische oder homöpatische Auswirkungen. Es gibt aber auch gute Gründe dafür. Technische und organisatorische Gründe.
Größere Domain-Netzwerke heißen z.b. de.emea.company.tld und da wird sich an "de" angemeldet mit der Synthax de\user-logon-name. Natürlich kann man auch auf andere Formate umstellen und teilweise werden auch andere Formate genutzt, auch in Hintergrund ohne dass der User das sieht, das hat aber nicht mit dem DNS, den FQDN der Hosts oder der benennung der Domain zu tun. Auch heißt die Email-Adresse nicht voellig.ungelanglos@de.emea.company.tld sondern voellig.ungelanglos@company.tld
Es ist eine sehr schlimme Manier hier im Forum, dass aus allen löchern alle möglichen Kleingeister kommen und alles in einen Topfs werfen und dann immer wieder durch rühren.
Ja es gibt en Fall, dass Firmen auch den Server für Ihre Webseiten inhouse haben und der Server selbst, sich in DNS und gar AD integriert. Das sagt aber noch lange nichts darüber aus, wie Browser auf dem Server Webservices auflösen und erreichen. Wer als Admin darin ein Problem hat, der hat wahrscheinlich auch darin ein Problem, dass die öffentliche Webseite sowohl mit als auch ohne www angesurft werden kann unabhängig ob aus dem LAN oder Public Internet.
Kleines Denkbeispiel für unsere IT-begeisterten User die ihre Karriere voran bringen wollen...
Dieses Forum ist unter administrator.de mit der IP: 82.149.225.19 erreichbar. Anfragen an www.administrator.de werden per 301 redirect des Webservers an adminstrator.de verwiesen. Somit sind beide Hosts mit der selben IP online, egal aus welchen Netz ich komme.
Die IP 82.149.225.19 ist im DNS sowohl mit als auch ohne www als A veröffentlicht.
Vermutlich, ich war jetzt zu faul zu suchen laufen unter dieser IP noch andere Domains, gut oder mittelmäßig aufgelöst um dann per 301 nachzuhelfen.
Einer meiner Server läuft bei all-inkl und hat den harten Namen: w0123456.kasserver.com. Auf dem Host sind 30 oder 50 andere Kunden mit in Summe über 1000 Topleveldomains und noch viel mehr Sub- uns Subsub-Domains.
Guckt mal wie Amazon AWS oder GCP Hosts heißen....
Alles Schall und Rauch...
Wer DNS verstanden hat, wer eine AD-DNS-Kopplung hat UND die public Webseite die selbe TLD hat und vor Problemen steht wie hier herbei geredet... der Hat DNS und AD nicht verstanden. Über Browser und Proxys habe ich jetzt bewusst nicht gesprochen.
Merksatz: DNS in House ist eine Kette. (Die Kette muss nicht zur Firewall laufen die dann alles ins öffentliche Internet weiterleitet)
Das öffentliche DNS kann ich genau so zu 100% beeinflussen nur nicht wo abgefragt wird, wenn die Clients außer Haus sind.
Übrigens: Für viele IT-Berufe sollte DNS eigentlich zu 99% sitzen.
Größere Domain-Netzwerke heißen z.b. de.emea.company.tld und da wird sich an "de" angemeldet mit der Synthax de\user-logon-name. Natürlich kann man auch auf andere Formate umstellen und teilweise werden auch andere Formate genutzt, auch in Hintergrund ohne dass der User das sieht, das hat aber nicht mit dem DNS, den FQDN der Hosts oder der benennung der Domain zu tun. Auch heißt die Email-Adresse nicht voellig.ungelanglos@de.emea.company.tld sondern voellig.ungelanglos@company.tld
Es ist eine sehr schlimme Manier hier im Forum, dass aus allen löchern alle möglichen Kleingeister kommen und alles in einen Topfs werfen und dann immer wieder durch rühren.
Ja es gibt en Fall, dass Firmen auch den Server für Ihre Webseiten inhouse haben und der Server selbst, sich in DNS und gar AD integriert. Das sagt aber noch lange nichts darüber aus, wie Browser auf dem Server Webservices auflösen und erreichen. Wer als Admin darin ein Problem hat, der hat wahrscheinlich auch darin ein Problem, dass die öffentliche Webseite sowohl mit als auch ohne www angesurft werden kann unabhängig ob aus dem LAN oder Public Internet.
Kleines Denkbeispiel für unsere IT-begeisterten User die ihre Karriere voran bringen wollen...
Dieses Forum ist unter administrator.de mit der IP: 82.149.225.19 erreichbar. Anfragen an www.administrator.de werden per 301 redirect des Webservers an adminstrator.de verwiesen. Somit sind beide Hosts mit der selben IP online, egal aus welchen Netz ich komme.
Die IP 82.149.225.19 ist im DNS sowohl mit als auch ohne www als A veröffentlicht.
Vermutlich, ich war jetzt zu faul zu suchen laufen unter dieser IP noch andere Domains, gut oder mittelmäßig aufgelöst um dann per 301 nachzuhelfen.
Einer meiner Server läuft bei all-inkl und hat den harten Namen: w0123456.kasserver.com. Auf dem Host sind 30 oder 50 andere Kunden mit in Summe über 1000 Topleveldomains und noch viel mehr Sub- uns Subsub-Domains.
Guckt mal wie Amazon AWS oder GCP Hosts heißen....
Alles Schall und Rauch...
Wer DNS verstanden hat, wer eine AD-DNS-Kopplung hat UND die public Webseite die selbe TLD hat und vor Problemen steht wie hier herbei geredet... der Hat DNS und AD nicht verstanden. Über Browser und Proxys habe ich jetzt bewusst nicht gesprochen.
Merksatz: DNS in House ist eine Kette. (Die Kette muss nicht zur Firewall laufen die dann alles ins öffentliche Internet weiterleitet)
Das öffentliche DNS kann ich genau so zu 100% beeinflussen nur nicht wo abgefragt wird, wenn die Clients außer Haus sind.
Übrigens: Für viele IT-Berufe sollte DNS eigentlich zu 99% sitzen.
Kurz und knackig zusammen gefasst interpretier ich hier aus dem gesamten geschriebenen:
Von der internen und extern gleichlautenden Domain firma.de wäre die Umbenennung auf ad.firma.de am schönsten aber nicht unbedingt notwendig.
Eine Umbenennung kann aber muss nicht problemlos funktionieren daher wäre es noch sinnvoller alles neu zu machen.
Alles neu machen im Zuge des Servertauschs wäre eine Gelegenheit, würde aber den zeitlichen Ramen verdoppelten und eine nach und nach Übersiedelung der einzelnen Dienste erschweren.
Daher…. man übersiedelt jetzt einfach mal die interne Domain firma.de aus den neuen W2022 Server und befasst sich zu einem späteren Zeitpunkt mit der Umbenennung und legt jetzt weiterhin die nach extern zeigende DNS Einträge für firma.de am internen DNS an. Soviel sind das jetzt nicht.
Wie geschrieben einen Exchange gibt es ja nicht und so besteht ja die Möglichkeit.
Von der internen und extern gleichlautenden Domain firma.de wäre die Umbenennung auf ad.firma.de am schönsten aber nicht unbedingt notwendig.
Eine Umbenennung kann aber muss nicht problemlos funktionieren daher wäre es noch sinnvoller alles neu zu machen.
Alles neu machen im Zuge des Servertauschs wäre eine Gelegenheit, würde aber den zeitlichen Ramen verdoppelten und eine nach und nach Übersiedelung der einzelnen Dienste erschweren.
Daher…. man übersiedelt jetzt einfach mal die interne Domain firma.de aus den neuen W2022 Server und befasst sich zu einem späteren Zeitpunkt mit der Umbenennung und legt jetzt weiterhin die nach extern zeigende DNS Einträge für firma.de am internen DNS an. Soviel sind das jetzt nicht.
Wie geschrieben einen Exchange gibt es ja nicht und so besteht ja die Möglichkeit.
Kurz und knackig.
Es ist egal wie was heißt und man sollte sich her Gedanken machen richtig DNS zu verstehen und auch einzusetzen.
Es ist egal wie was heißt und man sollte sich her Gedanken machen richtig DNS zu verstehen und auch einzusetzen.
Ich glaube an kurz und knackig sind wir schon vorbei 
Aber es ist so wie unbelanglos und ich am 04.01 bereits geschrieben haben:
Gruß
Doskias
Aber es ist so wie unbelanglos und ich am 04.01 bereits geschrieben haben:
Zitat von @Jacolo:
Kurz und knackig zusammen gefasst interpretier ich hier aus dem gesamten geschriebenen:
Von der internen und extern gleichlautenden Domain firma.de wäre die Umbenennung auf ad.firma.de am schönsten aber nicht unbedingt notwendig.
Nein. Es ist völlig egal wie es heißt. Ich hab mal einen Kunden übernommen, da hieß die Domäne nach dem Dienstleister, wir nennen ihn jetzt einfach mal contoso.de und im internen Netz wurde 1.0.64.0/24 IP-Adressen verwendet. Das lief problemlos, zumindest was die DNS Auflösung anging. Das es zu Problem gekommen wäre, wenn entsprechend Seiten aus dem Japan (internes Netz) aufgerufen worden wäre, ist klar, hat der Kunde aber nicht gemacht. Wie @2423392070 sagt:Kurz und knackig zusammen gefasst interpretier ich hier aus dem gesamten geschriebenen:
Von der internen und extern gleichlautenden Domain firma.de wäre die Umbenennung auf ad.firma.de am schönsten aber nicht unbedingt notwendig.
Es ist egal wie was heißt und man sollte sich her Gedanken machen richtig DNS zu verstehen und auch einzusetzen.
Wenn du weißt was, wie und warum der DNS so arbeitet, wie er es macht, dann ist der Name egal. Eine Umbenennung ist also weder am schönsten, noch notwendig. In meinen Augen total überflüssig bei einer Größe von derzeit einem Server und 35 Clients.Eine Umbenennung kann aber muss nicht problemlos funktionieren daher wäre es noch sinnvoller alles neu zu machen.
Wie alles in der IT. Wenn du weißt was und wie du vorgehen musst, du nichts vergisst und wirklich an alles denkst, dann ist das kein Problem.Alles neu machen im Zuge des Servertauschs wäre eine Gelegenheit, würde aber den zeitlichen Ramen verdoppelten und eine nach und nach Übersiedelung der einzelnen Dienste erschweren.
Und vor allem: Überlege dem Kunden gegenüber wie du diesen Schritt rechtfertigen willst, für den es keine technisch zwingende Notwendigkeit gibt.Gruß
Doskias
