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

[wznutzer 35]

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

 

 

[MurdocX 954]

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?

[cj_berlin 1.329]

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.

[NilsK 2.958]

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

 

[NorbertFe 2.065]

vor 23 Stunden schrieb wznutzer:

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

Ja aber nicht wenn da der aadc zusätzlich mit drauf ist. Ich wär da bei Dienstetrennung. Ein dc ist ein dc und ein aadc ist ein aadc.

[cj_berlin 1.329]

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.

[NilsK 2.958]

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

[wznutzer 35]

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.

[NilsK 2.958]

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

 

[testperson 1.711]

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. 

[NilsK 2.958]

Moin,

 

"gar nicht" in Windows-Dimensionen, natürlich. 

 

Gut, vielleicht etwas hoch gegriffen. Ich wollte nur dem Eindruck entgegentreten, dass man ständig Ärger damit hätte und alles mögliche mit den Bach runtergeht. So ist es ja nun nicht.

 

Gruß, Nils

 

bearbeitet 27. Juni 2022 von NilsK

[FatguyReno 0]

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