13
AD Domänennamen richtig wählen?
Hallo,
wie würdet Ihr bei einer neu Konfiguration eines Systems den Namen der AD wählen?
(Und warum?)
Ich habe früher noch gelernt: "Kunde.local" → da Local nicht im Internet geroutet wird.
Somit also eine reine Interne Domäne ist.
Jetzt bekommt mein Azubi beigebracht: "intern.Kunde.de"
Erklärung war mir nicht verständlich genug
Wie sind Eure Meinungen und Infos?
Vielen Dank
BpRaBa
wie würdet Ihr bei einer neu Konfiguration eines Systems den Namen der AD wählen?
(Und warum?)
Ich habe früher noch gelernt: "Kunde.local" → da Local nicht im Internet geroutet wird.
Somit also eine reine Interne Domäne ist.
Jetzt bekommt mein Azubi beigebracht: "intern.Kunde.de"
Erklärung war mir nicht verständlich genug
Wie sind Eure Meinungen und Infos?
Vielen Dank
BpRaBa
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: 7670458615
Url: https://administrator.de/forum/ad-domaenennamen-richtig-waehlen-7670458615.html
Ausgedruckt am: 31.12.2024 um 15:12 Uhr
13 Kommentare
Neuester Kommentar
Moin,
ja, mit *.local war einmal....
weshalb das heutzutage ungünstig ist, kannst du u. a. hier lesen:
https://en.wikipedia.org/wiki/.local
intern.kunde.de geht insofern, da die Domain kunde.de ja i.d.R. eh schon belegt ist und andere die Domain nicht "nutzen" können.
Man könnte aber auch überlegen, eine zusätzliche Domain zu buchen und diese unter kunde.biz zu nutzen. alles, was dann interne Unternehmensressourcen betrifft, würde unter kunde.biz laufen.
ja, mit *.local war einmal....
weshalb das heutzutage ungünstig ist, kannst du u. a. hier lesen:
https://en.wikipedia.org/wiki/.local
intern.kunde.de geht insofern, da die Domain kunde.de ja i.d.R. eh schon belegt ist und andere die Domain nicht "nutzen" können.
Man könnte aber auch überlegen, eine zusätzliche Domain zu buchen und diese unter kunde.biz zu nutzen. alles, was dann interne Unternehmensressourcen betrifft, würde unter kunde.biz laufen.
Zitat von @em-pie:
Moin,
ja, mit *.local war einmal....
weshalb das heutzutage ungünstig ist, kannst du u. a. hier lesen:
https://en.wikipedia.org/wiki/.local
intern.kunde.de geht insofern, da die Domain kunde.de ja i.d.R. eh schon belegt ist und andere die Domain nicht "nutzen" können.
Man könnte aber auch überlegen, eine zusätzliche Domain zu buchen und diese unter kunde.biz zu nutzen. alles, was dann interne Unternehmensressourcen betrifft, würde unter kunde.biz laufen.
Moin,
ja, mit *.local war einmal....
weshalb das heutzutage ungünstig ist, kannst du u. a. hier lesen:
https://en.wikipedia.org/wiki/.local
intern.kunde.de geht insofern, da die Domain kunde.de ja i.d.R. eh schon belegt ist und andere die Domain nicht "nutzen" können.
Man könnte aber auch überlegen, eine zusätzliche Domain zu buchen und diese unter kunde.biz zu nutzen. alles, was dann interne Unternehmensressourcen betrifft, würde unter kunde.biz laufen.
Verstanden → Dann intern.Kunde.de
und als NetBios Domänenname könnte ich dann wieder den Kundennamen machen, oder?
Moin,
wenn du das mit AzureAD koppeln möchtest, ist es sinnvoll direkt die Domain zu nehmen, über welche auch die Mails laufen wie z.B. firma.de
intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
Wenn die Firma aber mehrere Domains hat über die Mail laufen und Benutzern zugeordnet werden sollen, würde ich tatsächlich mit intern.firma.de o.ä. arbeiten.
z.B.
Mitarbeiter A ist bei firma1.de
Mitarbeiter B ist bei firma2.de
usw.
dann hätte man mit intern.firma.de tatsächlich einen gemeinsamen Nenner für die AD.
wenn du das mit AzureAD koppeln möchtest, ist es sinnvoll direkt die Domain zu nehmen, über welche auch die Mails laufen wie z.B. firma.de
intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
Wenn die Firma aber mehrere Domains hat über die Mail laufen und Benutzern zugeordnet werden sollen, würde ich tatsächlich mit intern.firma.de o.ä. arbeiten.
z.B.
Mitarbeiter A ist bei firma1.de
Mitarbeiter B ist bei firma2.de
usw.
dann hätte man mit intern.firma.de tatsächlich einen gemeinsamen Nenner für die AD.
Es gibt auch Unternehmen, die sich gerne umbennen, fusionieren, etc. Die Domain könnte man also auch völlg abstrakt halten. Einzige Bedingung ist, das man im Besitz der Domain ist. Technisch sind kurze Domainnamen angenehmer für den Admin.
In einer Ad-Domain hast Du in der Regel nichts mit Link Lokal, mDNS und Zeroconf und Apple-Geraffel zu tun.
Es wird hier, immer wieder dieser Blödsinn erzählt. Admin-Resterampe eben.
Due kannst auch irgendwas.local mit Azure und MS365 verbinden.
Früher war .local in den MS-Whitepapers die Schulungsgrundlage.
Heutzutage sollte man davon absehen.
Ich persönlich präfriere auch kürzel.domain.tld wenn es eine Single Site Sache ist.
Bei Multisite und Multi-Company domains ist sub.domain.tld von Vorteil, wenn man den Mehrauffwand am Anfang eingehen will und perpektivisch nciht immer mit nem It-Märchen um die Ecke kommt, wie das um .local hier im Thrad.
Es wird hier, immer wieder dieser Blödsinn erzählt. Admin-Resterampe eben.
Due kannst auch irgendwas.local mit Azure und MS365 verbinden.
Früher war .local in den MS-Whitepapers die Schulungsgrundlage.
Heutzutage sollte man davon absehen.
Ich persönlich präfriere auch kürzel.domain.tld wenn es eine Single Site Sache ist.
Bei Multisite und Multi-Company domains ist sub.domain.tld von Vorteil, wenn man den Mehrauffwand am Anfang eingehen will und perpektivisch nciht immer mit nem It-Märchen um die Ecke kommt, wie das um .local hier im Thrad.
1
wenn du das mit AzureAD koppeln möchtest, ist es sinnvoll direkt die Domain zu nehmen, über welche auch die Mails laufen wie z.B. firma.de
intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
2Zitat von @Drohnald:
wenn du das mit AzureAD koppeln möchtest, ist es sinnvoll direkt die Domain zu nehmen, über welche auch die Mails laufen wie z.B. firma.de
intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.intern.firma.de geht zwar auch, kann aber auch lästig sein und ich ärgere mich häufiger, dass ich das bei einem Kunden so gemacht hatte ...
DNS musst du auch einrichten wenn du intern.firma.de hast denn www.firma.de wird natürlich auch gegen den internen DNS laufen. Bei E-Mails geht es mehr um autodiscover, das ist schnell eine Bitch.
@8585324113
Es hat hier doch niemand behauptet, er solle zwingend auf *.local verzichten.
Alle haben ihm nur empfohlen, es nicht zu tun (du im übrigen auch)
Es hat hier doch niemand behauptet, er solle zwingend auf *.local verzichten.
Alle haben ihm nur empfohlen, es nicht zu tun (du im übrigen auch)
Zitat von @Drohnald:
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.
Wieso lästig? Das ist doch nur Eintrag? Und das ist dann sauber getrennt. ¯\_(ツ)_/¯
Zitat von @anteNope:
Wieso lästig? Das ist doch nur Eintrag? Und das ist dann sauber getrennt. ¯\_(ツ)_/¯
Zitat von @Drohnald:
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.
Warum das? Ich hatte die Erfahrung eher in die andere Richtung, weil firma.de dann den DC anspricht und nicht die Internet-Homepage des Unternehmens. Die muss man per DNS auf www. dann umbiegen was schon sehr lästig ist.
Wieso lästig? Das ist doch nur Eintrag? Und das ist dann sauber getrennt. ¯\_(ツ)_/¯
Naja weil man dann immer www.firma.de aufrufen und die IP der Website manuell up to date halten muss.
Zitat von @Drohnald:
Naja weil man dann immer www.firma.de aufrufen und die IP der Website manuell up to date halten muss.
Naja weil man dann immer www.firma.de aufrufen und die IP der Website manuell up to date halten muss.
Lästiger ist es wenn man den Benutzer unter der falschen Domain anlegt, das per AzureAD synchronisiert wird. Dann kannste den Benutzer in die Tonne treten und das neu machen. Und wenn man es doch wagt den Benutzer von intern.firma.de auf firma.de umzustellen, öffnet sich die Büchse der Pandora; ähnlich wie bei Änderungen der Nachnamen ...
Da halte ich tatsächlich lieber alle Jubeljahre den www-DNS-Eintrag aktuell. Der ändert sich deutlich seltener 😅
p.s. ich meine das mit dem firma.de als Domänennamen steht / stand bei MS als best practise?
State of the art für reine On Premise Lösungen:
1.) eine echte DNS Domäne wählen und registrieren. GGf noch den DNS auf einen Wincows DNS Server im eigenen AD delegieren, da im AD viele Sachen über Custom DNS Extensions gemacht werden, die nur ein Microsoft DNS Server versteht. Aber Bind z.B. nicht.
2.) darauf das AD aufbauen.
Vermeidet Namenskonflikte, Verwendung von reservierten Namen (.local wird im IoT Bereich verwendet) und man kriegt auch Zertifikate von richtigen Zertifizierungsstellen oder LetsEncrypt ohne langen Hickhack.
Oder man nimmt von vorneherein managed AD in Azure oder AWS falls es doch mal in die Cloud geht.
Natürlich will ich auch niemanden davon abhalten, test.local zu verwenden, aber heute würde ich strikt davon abraten, ein Netz als reine Insellösung zu konzipieren.
1.) eine echte DNS Domäne wählen und registrieren. GGf noch den DNS auf einen Wincows DNS Server im eigenen AD delegieren, da im AD viele Sachen über Custom DNS Extensions gemacht werden, die nur ein Microsoft DNS Server versteht. Aber Bind z.B. nicht.
2.) darauf das AD aufbauen.
Vermeidet Namenskonflikte, Verwendung von reservierten Namen (.local wird im IoT Bereich verwendet) und man kriegt auch Zertifikate von richtigen Zertifizierungsstellen oder LetsEncrypt ohne langen Hickhack.
Oder man nimmt von vorneherein managed AD in Azure oder AWS falls es doch mal in die Cloud geht.
Natürlich will ich auch niemanden davon abhalten, test.local zu verwenden, aber heute würde ich strikt davon abraten, ein Netz als reine Insellösung zu konzipieren.
Sieht Dell offenbar auch so:
https://www.dell.com/support/kbdoc/de-de/000134402/dns-uuml-berlegungen- ...
Ich zweifele noch und neige eher dem Kollegen Franky zu:
https://www.frankysweb.de/active-directory-name-fr-ein-neues-active-dire ...
Dort wird ausdrücklich davon abgeraten, den registrierten Domain-Name zu verwenden.
Auch der Kollege Carius scheint der Subdomain zuzuneigen:
https://www.msxfaq.de/windows/sicherheit/risiko_ad_domain.htm
Hier ebenfalls knapp, aber anschaulich (bzgl. der Thread-Frage dort nach unten scrollen):
https://www.active-directory-faq.de/ad-design/domain-name/
Die Kollegen @anteNope und @Drohnald haben das Thema Split-DNS ja oben schon andiskutiert. Ich denke, jede der beiden Varianten ist möglich.
Viele Grüße, commodity
https://www.dell.com/support/kbdoc/de-de/000134402/dns-uuml-berlegungen- ...
Ich zweifele noch und neige eher dem Kollegen Franky zu:
https://www.frankysweb.de/active-directory-name-fr-ein-neues-active-dire ...
Dort wird ausdrücklich davon abgeraten, den registrierten Domain-Name zu verwenden.
Auch der Kollege Carius scheint der Subdomain zuzuneigen:
https://www.msxfaq.de/windows/sicherheit/risiko_ad_domain.htm
Hier ebenfalls knapp, aber anschaulich (bzgl. der Thread-Frage dort nach unten scrollen):
https://www.active-directory-faq.de/ad-design/domain-name/
Die Kollegen @anteNope und @Drohnald haben das Thema Split-DNS ja oben schon andiskutiert. Ich denke, jede der beiden Varianten ist möglich.
Viele Grüße, commodity
