Jump to content

Azure ADConnect auf Domänen-Controller installieren - eher nicht?


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Guten Abend,

 

lt. Doku ist es problemlos möglich AADConnect auf einem Domänencontroller zu installieren, aber ist das eine gute Idee?

 

Lt. Microsoft muss der Server ohnehin so "beschützt" werden wie alle Member in Tier 0.

Es muss ein SQL-Server installiert werden, da ist jetzt eher so mittelgut auf einem DC, aber ist es so schlimm?

Bei Problemen mit AADConnect müsste ich vielleicht mal den Server starten, dann ist auch der DC weg, aber ich habe ja sowieso mehrere.

Der DC ist nicht mehr identisch zu den anderen, wäre aber auch egal. Ein DC ist ja schnell installiert und hinzugefügt.

 

In einer sehr großen Umgebung ist das vielleicht etwas anderes, aber bei < 200 User will mir kein trifftiger Grund einfallen das nicht zu tun. Evtl. irre ich mich, aber deswegen frage ich.

 

Danke und Grüße

 

 

Link zu diesem Kommentar

Hallo,

 

der DC ist mit unter der wichtigste Server im Unternehmen, ohne den nichts mehr geht. Dieser ist bei kleinen wie bei großen Firmen wichtig. Natürlich ist das technisch möglich. Und ja, es mag auch ab und an problemlos funktionieren. Es bleibt fraglich warum man freiwillig ein Risiko eingehen möchte? Jemanden einkaufen, der sich um Probleme im AD kümmert, kostet mehr als eine neue Serverlizenz. Wirtschaftlich und risikotechnisch ist das damit keine gute Idee.

 

Ein Grund von vielen: Wie machst du es bei einem Restore der Anwendung?

Link zu diesem Kommentar

Moin,

 

unpopular opinion: In Kleinstumgebungen, wo Server nach wie vor als "Pets" statt als "Cattle" behandelt werden, ist ein DC sogar der beste Ort für Azure AD Connect, denn dort ist immerhin die Wahrscheinlichkeit noch am Geringsten, dass jemand per Zufall Adminrechte bekommt, der es nicht soll.

 

Die SQL-Instanz, die nur lokale Verbindungen akzeptiert, ist wurscht.

 

Das schwerwiegendste Argument ist in meinen Augen tatsächlich das von @MurdocX angeführte Backup-/Restore-Thema. Du nimmst Dir damit im Prinzip die Möglichkeit, AADC nach einem fehlgeschlagenen Update per VM Restore wieder ans Laufen zu bringen. Das muss jeder für sich selbst bewerten. Ich würde sogar argumentieren, dass man in diesem Fall den "DC + AADC" am besten gar nicht erst sichern sollte.

Link zu diesem Kommentar

Moin,

 

Ich bin Anhänger der "In-sehr-kleinen-Umgebungen-ist-vieles-anders"-Ansicht, aber anscheinend geht es hier um an die 200 User. Das würde für mich nicht darunter fallen.

 

Hier würde ich dem Argument anhängen: Es ist nicht super unsicher, aber warum ein unnötiges Risiko eingehen, wenn man nur eine einzige kleine VM zusätzlich braucht?

 

Gruß, Nils

 

Link zu diesem Kommentar
vor 22 Stunden schrieb NilsK:

Ich bin Anhänger der "In-sehr-kleinen-Umgebungen-ist-vieles-anders"-Ansicht, aber anscheinend geht es hier um an die 200 User. Das würde für mich nicht darunter fallen.

Aber es geht doch eigentlich eher um Reife als um Größe! Auch in einer Umgebung mit 30 Usern wäre eine separate VM für AADC dringend anzuraten, wenn dort der Begriff "Tier 0-System" eine technische Umsetzung erfahren hat und gelebt wird - Admin-Trennung, PAW, Netzsegmentierung usw. 

 

vor 22 Stunden schrieb NilsK:

Hier würde ich dem Argument anhängen: Es ist nicht super unsicher, aber warum ein unnötiges Risiko eingehen, wenn man nur eine einzige kleine VM zusätzlich braucht?

Das Argument ist aber nur in der Theorie so einfach und klar. In der Praxis sieht es doch so aus: Wenn man nach der Installation NICHTS gemacht hat, um die Umgebung zu härten, sind DCs durch die DDCP wenigstens etwas besser geschützt als normale Server, für die nichts höheres an Schutz gilt als für Workstations. Immerhin kann man sich als nicht-Domain-Admin nicht aus Versehen dort anmelden.

 

Zurück zum aktuellen Thread: Der OP mutet schon so an, als wäre ansatzweise Tier 0-Schutz in der Umgebung vorhanden. Ist dem wirklich so, dann würde ich allein schon aus Backup-/Restore-Gründen für eine separate Maschine plädieren. Beim Backup muss man aber genau so aufpassen wie beim Backup der Domain Controller - wer einen System State-Backup eines AADC-Servers ergattern kann, ist in 5 Minuten DA, wenn sie weiß, was sie tut.

Link zu diesem Kommentar

Moin,

 

Ja gut ... eigentlich habe ich nur eine Meinung geäußert, weil nach meinem Verständnis der TO nach einer Einschätzung gefragt hat. Weitere Schlussfolgerungen über seine Umgebung (außer der eingangs genannten Zahl der Anwender) kann ich nicht anstellen.

 

Wenn wir das Ganze auf eine grundsätzlich-wissenschaftliche Basis stellen, habe ich dem, was du sagst, wenig hinzuzufügen oder zu widersprechen. So war mein Beitrag allerdings auch gar nicht gemeint.

 

Gruß, Nils

Link zu diesem Kommentar
Am 24.6.2022 um 19:42 schrieb MurdocX:

Ein Grund von vielen: Wie machst du es bei einem Restore der Anwendung?

Guten Abend,

weil es hier angesprochen wurde, ja ich versuche schon ein Schutzkonzept (Tier 0 usw.) umzusetzen.

 

Den Restore habe ich mir nicht aus der Sicht, dass ein Update den AADC kaputt macht vorgestellt. Ich denke, dann habt ihr das schon erlebt. Mein Restore-Konzept wäre gewesen, neuer DC, replizieren lassen, alter raus aus der Domäne und AADC lt. meiner Doku neu installieren. Aber das will ich natürlich nicht jeden Monat machen, weil es ein Update von AADC gibt. Wenn es da ein erhöhtes Risiko gibt, habe ich darauf keine Lust und ich lasse das.

 

Meine Motivation war einfach, wegen so einem kleinen Programm nicht eine weitere VM haben zu müssen auf die ich aufpassen muss. Ab Herbst hätte ich auf einem Host eine Datacenter-Lizenz. Da würde die separate VM noch nicht einmal etwas kosten.

 

Vielen Dank für euren Input.

Link zu diesem Kommentar

Moin,

 

das Recovery von DC und AADC war genauso gemeint. Nicht so gemeint war das mit dem Update. AADC geht nicht jeden Monat kaputt. Eigentlich geht es gar nicht kaputt. Es könnte nur eventuell mal sein, und dann möchte man die Abhängigkeit nicht haben. Man bedenke auch, dass es sich um ziemlich komplexe Software handelt, schließlich ist das in Wirklichkeit ein MIM, wenn auch ein nachträglich beschränkter.

 

Am Ende Abwägungssache.

 

Gruß, Nils

 

Link zu diesem Kommentar

Ein wenig OT:

vor 37 Minuten schrieb NilsK:

AADC geht nicht jeden Monat kaputt. Eigentlich geht es gar nicht kaputt.

Microsoft Azure AD Sync service fails to start - event id 528 - Working Hard In ITWorking Hard In IT / Azure AD Sync Connect keeps getting corrupted (spiceworks.com) :-)

 

Aber gut, "mittlerweile" ist das ja gefixed. 

Link zu diesem Kommentar
  • 2 Monate später...

Hallo zusammen,

 

habe in einem kleinen Unternehmen einen DC, auf dem so ziemlich alles gestapelt ist aus Bugdetgründen. Und über die Jahre ist das immer wieder zur Falle geworden.

 

Den DC eigenständig lassen und alles andere auf Member auslagern ist nachwievor best Practice. Mittlerweile hab eich mich da auch durchgesetzt und bin heilfroh darüber, weil nun auch RDS usw im Einsatz ist usw.

 

Gruß, Reno

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...