AzureAD nachträglich um lokale Domäne erweitern
Hallo Leute,
meine neue Firma setzte bisher immer auf Cloud. Dabei vornehmlich Microsofts Office365 (volle Palette von Office über Sharepoint, Skype/Teams, bis hin zu Exchange), sowie AzureAD. Letztes wird hauptsächlich für Security wie 2FA genutzt.
Das MDM via Intune wurde scheinbar nie richtig konfiguriert, und ich bekomme es bis heute nicht hin ALLE Clients dort zu registrieren. Nur 17 werden mir dort als verwaltbar angezeigt.
Da die Firma in den letzten Jahren gut gewachsen ist (> 70 Mitarbeiter), reicht die Cloud m.M.n. nicht mehr aus. In den wenigen Monaten hier musste ich sehr viele Einschränkungen hinnehmen, die ich durch das nachträgliche Erstellen einer lokalen Domäne (die mittels Connector an die AAD gekoppelt wird) minimieren will. Normalerweise ist es ja anders herum, dass man seine on-prem AD um die Cloud erweitern will :D
Die eigentliche Frage: hat jemand Erfahrungen damit eine Cloud-Only-Infrastruktur um eine lokale AD zu erweitern? Windows Server Lizenz + CALs sind schon gekauft. Jetzt fehlt nur noch eine klare Linie, welche Schritte ich bei der Einrichtung in welcher Reihenfolge erledigen sollte. Betriebssystem auf Clientseite ist fast ausschließlich Windows 10.
Mein Plan bisher:
1.) Windows Server 2019 Standard installieren inkl. AD / DNS / DHCP (DNS und DHCP laufen momentan über die pfSense)
2.) "lokalen" Domänen-Admin erstellen, mit dem ich alles aufbauen kann
3.) OU-Struktur ausdenken / vorbereiten (aber soweit noch leer lassen) --> wichtg: kann ich mir hier eine neue Stammdomäne ausdenken, oder sollte die mit der vorhandenen ExchangeOnline-Domäne (xyz@firma.de) übereinstimmen?
4.) AzureAD Connector installieren + mittels extra zu erstellendem Sync-Konto irgendwie mit der Cloud verknüppern
5.) Nutzerkonten & Gruppen abgleichen
6.) grundlegende GPOs einpflegen (bisher quasi keine vorhanden)
7.) RADIUS installieren + konfigurieren und mit bestehendem WLAN verheiraten
8.) SCCM / MECM installieren + konfigurieren
9.) Print Server (für zwei Geräte) einrichten
Macht das aus eurer Sicht Sinn? Fehlen wichtige Schritte?
Meine größten Zweifel bis hierher:
a.) Ist es überhaupt erforderlich/sinnvoll ERST einen Forest zu definieren und sich danach mit der AAD zu syncen, oder gibt die AAD schon Bäume vor, die ich anschließend weiter nutzen kann?
b.) Kann es Konflikte zwischen lokalen und Cloud-Admin Konten geben?
c.) Sollte man alles auf einmal aus der Cloud "runter syncen", oder sollte man das in kleine Pakete aufstückeln? Reihenfolge wichtig?
d.) Wie lässt sich verhindern, dass eine Synchronisation in die falsche Richtung (on-prem -> cloud) irgendwelche Sachen löscht oder überschreibt?
d.) Die Server Lizenz ermöglicht mir ja eine zweite Win VM. Wie würdet ihr das aufsplitten? AD / DNS / DHCP auf den Domain Controller und RADIUS, SCCM, PrintServer, PowerBI Gateway, etc. auf den zweiten? Oder anders? Oder teilen die sich alle die gleiche Datenbank und können deswegen gut zusammenarbeiten?
Ja ja, ich weiß: normalerweise ein Server pro Dienst. Für den Anfang wird es etwas "kuschelig" auf den zwei VMs, das ist mir bewusst und hoffentlich kein Dauerzustand.
Ein Problem: alle Nutzer sind aktuell die alleinigen Nutzer auf ihren jeweiligen Laptops und verfügen somit über Admin-Berechtigungen! Es gibt keinen lokalen Standard-Admin, den ich für Bulk-Aufgaben missbrauchen könnte. Bitte hinterfragt nicht die Gründe für diesen Umstand. Es ist leider so
Ach und übrigens: Redundanz & Hochverfügbarkeit ist fürs erste irrelevant, weil ja bisher auch immer die Cloud als Primärverwaltung gereicht hat. Die neuen Server sind quasi nur ein Komfort-Gewinn, um ein paar Sachen zu automatisieren.
Wäre euch dankbar für ein paar Denkansätze.
Beste Grüße
Robert
meine neue Firma setzte bisher immer auf Cloud. Dabei vornehmlich Microsofts Office365 (volle Palette von Office über Sharepoint, Skype/Teams, bis hin zu Exchange), sowie AzureAD. Letztes wird hauptsächlich für Security wie 2FA genutzt.
Das MDM via Intune wurde scheinbar nie richtig konfiguriert, und ich bekomme es bis heute nicht hin ALLE Clients dort zu registrieren. Nur 17 werden mir dort als verwaltbar angezeigt.
Da die Firma in den letzten Jahren gut gewachsen ist (> 70 Mitarbeiter), reicht die Cloud m.M.n. nicht mehr aus. In den wenigen Monaten hier musste ich sehr viele Einschränkungen hinnehmen, die ich durch das nachträgliche Erstellen einer lokalen Domäne (die mittels Connector an die AAD gekoppelt wird) minimieren will. Normalerweise ist es ja anders herum, dass man seine on-prem AD um die Cloud erweitern will :D
Die eigentliche Frage: hat jemand Erfahrungen damit eine Cloud-Only-Infrastruktur um eine lokale AD zu erweitern? Windows Server Lizenz + CALs sind schon gekauft. Jetzt fehlt nur noch eine klare Linie, welche Schritte ich bei der Einrichtung in welcher Reihenfolge erledigen sollte. Betriebssystem auf Clientseite ist fast ausschließlich Windows 10.
Mein Plan bisher:
1.) Windows Server 2019 Standard installieren inkl. AD / DNS / DHCP (DNS und DHCP laufen momentan über die pfSense)
2.) "lokalen" Domänen-Admin erstellen, mit dem ich alles aufbauen kann
3.) OU-Struktur ausdenken / vorbereiten (aber soweit noch leer lassen) --> wichtg: kann ich mir hier eine neue Stammdomäne ausdenken, oder sollte die mit der vorhandenen ExchangeOnline-Domäne (xyz@firma.de) übereinstimmen?
4.) AzureAD Connector installieren + mittels extra zu erstellendem Sync-Konto irgendwie mit der Cloud verknüppern
5.) Nutzerkonten & Gruppen abgleichen
6.) grundlegende GPOs einpflegen (bisher quasi keine vorhanden)
7.) RADIUS installieren + konfigurieren und mit bestehendem WLAN verheiraten
8.) SCCM / MECM installieren + konfigurieren
9.) Print Server (für zwei Geräte) einrichten
Macht das aus eurer Sicht Sinn? Fehlen wichtige Schritte?
Meine größten Zweifel bis hierher:
a.) Ist es überhaupt erforderlich/sinnvoll ERST einen Forest zu definieren und sich danach mit der AAD zu syncen, oder gibt die AAD schon Bäume vor, die ich anschließend weiter nutzen kann?
b.) Kann es Konflikte zwischen lokalen und Cloud-Admin Konten geben?
c.) Sollte man alles auf einmal aus der Cloud "runter syncen", oder sollte man das in kleine Pakete aufstückeln? Reihenfolge wichtig?
d.) Wie lässt sich verhindern, dass eine Synchronisation in die falsche Richtung (on-prem -> cloud) irgendwelche Sachen löscht oder überschreibt?
d.) Die Server Lizenz ermöglicht mir ja eine zweite Win VM. Wie würdet ihr das aufsplitten? AD / DNS / DHCP auf den Domain Controller und RADIUS, SCCM, PrintServer, PowerBI Gateway, etc. auf den zweiten? Oder anders? Oder teilen die sich alle die gleiche Datenbank und können deswegen gut zusammenarbeiten?
Ja ja, ich weiß: normalerweise ein Server pro Dienst. Für den Anfang wird es etwas "kuschelig" auf den zwei VMs, das ist mir bewusst und hoffentlich kein Dauerzustand.
Ein Problem: alle Nutzer sind aktuell die alleinigen Nutzer auf ihren jeweiligen Laptops und verfügen somit über Admin-Berechtigungen! Es gibt keinen lokalen Standard-Admin, den ich für Bulk-Aufgaben missbrauchen könnte. Bitte hinterfragt nicht die Gründe für diesen Umstand. Es ist leider so
Ach und übrigens: Redundanz & Hochverfügbarkeit ist fürs erste irrelevant, weil ja bisher auch immer die Cloud als Primärverwaltung gereicht hat. Die neuen Server sind quasi nur ein Komfort-Gewinn, um ein paar Sachen zu automatisieren.
Wäre euch dankbar für ein paar Denkansätze.
Beste Grüße
Robert
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 551809
Url: https://administrator.de/contentid/551809
Ausgedruckt am: 14.11.2024 um 19:11 Uhr
3 Kommentare
Neuester Kommentar
Auweia ....
Lass auf jeden fall die Finger davon ...
Konfiguriere lieber dein Intune richtig, dann brauchst du deinen onprem Kram nicht ...
Mit Intune kannst du deinen SCCM in die Tonne treten und die GPOs aus dem AD direkt hinterher.
RADIUS brauchst du auch nicht, schau dir lieber Aruba und Clearpass für dein WLAN an.
Außerdem (und das hast du scheinbar gar nicht auf dem Schirm) wird dein lokales AD durch einen AD-Sync der Chef im Ring.
Bedeutet, dein lokales AD gibt alles vor und dein Exchange Online kann z.B. keine Attribute mehr in die User schreiben.
Das heißt für dich: Du musst auch noch einen Exchange onprem installieren und dort auch einen Hybrid-Connect zu Exchange Online bauen.
Und nun der finale Schlag: Du kannst dein AzureAD nicht in ein lokales AD pumpen ;)
Dazu gab es auch schon mal ein UserVoice, der wurde von MS abgelehnt:
https://feedback.azure.com/forums/169401-azure-active-directory/suggesti ...
Lass auf jeden fall die Finger davon ...
Konfiguriere lieber dein Intune richtig, dann brauchst du deinen onprem Kram nicht ...
Mit Intune kannst du deinen SCCM in die Tonne treten und die GPOs aus dem AD direkt hinterher.
RADIUS brauchst du auch nicht, schau dir lieber Aruba und Clearpass für dein WLAN an.
Außerdem (und das hast du scheinbar gar nicht auf dem Schirm) wird dein lokales AD durch einen AD-Sync der Chef im Ring.
Bedeutet, dein lokales AD gibt alles vor und dein Exchange Online kann z.B. keine Attribute mehr in die User schreiben.
Das heißt für dich: Du musst auch noch einen Exchange onprem installieren und dort auch einen Hybrid-Connect zu Exchange Online bauen.
Und nun der finale Schlag: Du kannst dein AzureAD nicht in ein lokales AD pumpen ;)
Dazu gab es auch schon mal ein UserVoice, der wurde von MS abgelehnt:
https://feedback.azure.com/forums/169401-azure-active-directory/suggesti ...
GPOs in dem Sinne gibt es nicht mehr, ja.
Das läuft über Intune Policies und ADMX Vorlagen ab.
Und ja ... Aruba ist eine 3rd-Party Komponente, allerdings hast du da auch Vorteile wie eine integrierte Cloud-CA, was auch was wert ist.
Es gibt keinen Weg ein lokales AD mit einem AAD zu syncen, also zu mindestens nicht, wenn erst das AAD da ist und dann das AD dazu kommt.
Microsoft will alles und jeden in der Cloud haben, wenn sowas supportet wäre, würde das gegen ihre eigene Stratgie sprechen.
Und nein man kann auch nicht umgehen, dass das lokale AD Master wird.
Mach dich lieber in Intune schlau, bei mir funktioniert alles und ich bin dabei vom SCCM wegzugehen ;)
Das läuft über Intune Policies und ADMX Vorlagen ab.
Und ja ... Aruba ist eine 3rd-Party Komponente, allerdings hast du da auch Vorteile wie eine integrierte Cloud-CA, was auch was wert ist.
Es gibt keinen Weg ein lokales AD mit einem AAD zu syncen, also zu mindestens nicht, wenn erst das AAD da ist und dann das AD dazu kommt.
Microsoft will alles und jeden in der Cloud haben, wenn sowas supportet wäre, würde das gegen ihre eigene Stratgie sprechen.
Und nein man kann auch nicht umgehen, dass das lokale AD Master wird.
Mach dich lieber in Intune schlau, bei mir funktioniert alles und ich bin dabei vom SCCM wegzugehen ;)