6
Azure AD Connect - erste Schritte
Hallo an alle!
Wie soll ich anfangen? Hier die Kurzfassung: wir haben einen Tenant mit drei Domains (der Einfachheit halber users.xyz.at, xyz.at und xyzyat.onmicrosoft.com). Diese waren mit AD verknüpft. Alter Admin gegangen, AD und Sync-Tool gelöscht.
Ich (=Microsoft365-Newbie) neues AD aufgesetzt und probiere gerade mit Azure AD Connect-Tool herum.
Meine Frage dazu, da die Doku auf der M$-Seite schrottig ist (und einen leeren Tenant annimmt): wenn ich eine Express-Installation mache und einen Sync durchführe, werden dann die bestehenden User im Tenant eh nicht gelöscht und bleiben unverändert? Meine Aufgabe von oben: ich muss neue User dazusyncen (in zwei der obigen Domains) und darf die alten nicht anrühren.
Ich hoffe ich habe mich trotz der Kurzfassung halbwegs klar ausgedrückt. Danke im voraus für konstruktive Beiträge!
Wie soll ich anfangen? Hier die Kurzfassung: wir haben einen Tenant mit drei Domains (der Einfachheit halber users.xyz.at, xyz.at und xyzyat.onmicrosoft.com). Diese waren mit AD verknüpft. Alter Admin gegangen, AD und Sync-Tool gelöscht.
Ich (=Microsoft365-Newbie) neues AD aufgesetzt und probiere gerade mit Azure AD Connect-Tool herum.
Meine Frage dazu, da die Doku auf der M$-Seite schrottig ist (und einen leeren Tenant annimmt): wenn ich eine Express-Installation mache und einen Sync durchführe, werden dann die bestehenden User im Tenant eh nicht gelöscht und bleiben unverändert? Meine Aufgabe von oben: ich muss neue User dazusyncen (in zwei der obigen Domains) und darf die alten nicht anrühren.
Ich hoffe ich habe mich trotz der Kurzfassung halbwegs klar ausgedrückt. Danke im voraus für konstruktive Beiträge!
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: 74090741632
Url: https://administrator.de/forum/azure-ad-connect-erste-schritte-74090741632.html
Ausgedruckt am: 23.12.2024 um 14:12 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
bitte hohl da mal etwas weiter genauer aus.
Mal ernsthaft das kpl. AD gelöscht? Wer macht so nen blödsinn?
Du willst ein neues AD auf nen bestehen Entra (Azure) Tenant Syncen? Ich kann mir nicht vorstellen, das das so lustig wird.
Da wird erstmal ein kpl. Sauberes Mapping der bestehenden User passieren müssen.
bitte hohl da mal etwas weiter genauer aus.
Mal ernsthaft das kpl. AD gelöscht? Wer macht so nen blödsinn?
Du willst ein neues AD auf nen bestehen Entra (Azure) Tenant Syncen? Ich kann mir nicht vorstellen, das das so lustig wird.
Da wird erstmal ein kpl. Sauberes Mapping der bestehenden User passieren müssen.
Moin,
Die Doku ist nicht „schrottig“, erklär mal etwas ausführlicher was passiert ist und was du erreichen möchtest.
/Thomas
Die Doku ist nicht „schrottig“, erklär mal etwas ausführlicher was passiert ist und was du erreichen möchtest.
/Thomas
Hallo,
wenn das AD neu erstellt worden ist und du einen Sync startest, dann wird der AAD Connect die Benutzer doppelt erstellen. Es wird kein bestehender Benutzer gelöscht! Die Benutzer sollten „Cloud Only“-Benutzer sein, statt „synchronisierte“ Benutzer. Jeder Benutzer erhält bei einer Synchronisation eine „Immutable ID“.
Die Immutable ID in Azure Active Directory ist eine eindeutige Identifikationsnummer, die zur konsistenten Zuordnung von Benutzerkonten zwischen einem lokalen Active Directory und Azure AD dient. Du müsstest ggf. die Immutable ID über die PowerShell anpassen oder im AD die jeweilige ID dem Benutzer zuweisen. Du kannst die Immutable ID auf portal.azure.com unter Benutzer einsehen. Wähle einen Benutzer aus und dann findest du die „Immutable ID“ bei den Eigenschaften, im Deutschen „Unveränderliche ID (Lokal)“.
Wäre dein AD nicht gelöscht worden, sondern nur der AAD Connect, dann würde er die Benutzer nicht doppelt erstellen, sondern sie wieder zu „synchronisierten“ Benutzern machen.
Ich würde dir empfehlen, dass du den Microsoft Support kontaktierst.
Viele Grüße
Dream
wenn das AD neu erstellt worden ist und du einen Sync startest, dann wird der AAD Connect die Benutzer doppelt erstellen. Es wird kein bestehender Benutzer gelöscht! Die Benutzer sollten „Cloud Only“-Benutzer sein, statt „synchronisierte“ Benutzer. Jeder Benutzer erhält bei einer Synchronisation eine „Immutable ID“.
Die Immutable ID in Azure Active Directory ist eine eindeutige Identifikationsnummer, die zur konsistenten Zuordnung von Benutzerkonten zwischen einem lokalen Active Directory und Azure AD dient. Du müsstest ggf. die Immutable ID über die PowerShell anpassen oder im AD die jeweilige ID dem Benutzer zuweisen. Du kannst die Immutable ID auf portal.azure.com unter Benutzer einsehen. Wähle einen Benutzer aus und dann findest du die „Immutable ID“ bei den Eigenschaften, im Deutschen „Unveränderliche ID (Lokal)“.
Wäre dein AD nicht gelöscht worden, sondern nur der AAD Connect, dann würde er die Benutzer nicht doppelt erstellen, sondern sie wieder zu „synchronisierten“ Benutzern machen.
Ich würde dir empfehlen, dass du den Microsoft Support kontaktierst.
Viele Grüße
Dream
@wiesi200: das macht ein Admin, der einen speziellen Vertrag mit dem Unternehmen hatte. In der Klausel stand, dass mit seinem Abgang alle Tools von ihm zu löschen sind. Da er das Sync-Tool geschrieben hat und dazu eine eigene Verwaltungs-GUI, die fest mit dem AD verzahnt war, war nur ein Neuaufsetzen der Server die einzige Option. Zumindest haben alle Benutzer ihre Mails weiterhin in Microsoft365 und sind derweilen zufrieden, aber fürs Installieren/Syncen des neuen AD bin ich zum Handkuss gekommen.
@Th0mKa: wenn ich man-pages von Linux mit der M$-Doku vergleiche, dann ist letztere schrottig - keine Erklärung aller Optionen von Azure AD Connect auf einer Seite; keine Nutzungsbeispiele und wenn man nach "sync options" bzw. "deletion prevention while syncing" sucht, dann erhält man einen Powershell-String wie man einstellt, dass eine Warnung erscheint bevor 500 Objekte gelöscht werden - sehr vertrauenserweckend...
@Dreamnezz: Danke für die kompakte Antwort. Das heißt, ich checke mal ab, ob die Users "Cloud only" sind werde mich mal mit der Immutable ID auseinandersetzen. Wie oben geschrieben war das Vorgänger-Tool nicht AAD Connect, sondern eine C#-Eigenlösung des vorigen Admins *ohne* Deinstallationsroutine. Ach ja, der Microsoft-Support hat auf die besagte suboptimale Dokumentation verwiesen, weshalb ich eben hier im Forum nachgefragt habe.
greets
@Th0mKa: wenn ich man-pages von Linux mit der M$-Doku vergleiche, dann ist letztere schrottig - keine Erklärung aller Optionen von Azure AD Connect auf einer Seite; keine Nutzungsbeispiele und wenn man nach "sync options" bzw. "deletion prevention while syncing" sucht, dann erhält man einen Powershell-String wie man einstellt, dass eine Warnung erscheint bevor 500 Objekte gelöscht werden - sehr vertrauenserweckend...
@Dreamnezz: Danke für die kompakte Antwort. Das heißt, ich checke mal ab, ob die Users "Cloud only" sind werde mich mal mit der Immutable ID auseinandersetzen. Wie oben geschrieben war das Vorgänger-Tool nicht AAD Connect, sondern eine C#-Eigenlösung des vorigen Admins *ohne* Deinstallationsroutine. Ach ja, der Microsoft-Support hat auf die besagte suboptimale Dokumentation verwiesen, weshalb ich eben hier im Forum nachgefragt habe.
greets
Quote from @DerSud:
@Th0mKa: wenn ich man-pages von Linux mit der M$-Doku vergleiche, dann ist letztere schrottig - keine Erklärung aller Optionen von Azure AD Connect auf einer Seite; keine Nutzungsbeispiele und wenn man nach "sync options" bzw. "deletion prevention while syncing" sucht, dann erhält man einen Powershell-String wie man einstellt, dass eine Warnung erscheint bevor 500 Objekte gelöscht werden - sehr vertrauenserweckend...
@Th0mKa: wenn ich man-pages von Linux mit der M$-Doku vergleiche, dann ist letztere schrottig - keine Erklärung aller Optionen von Azure AD Connect auf einer Seite; keine Nutzungsbeispiele und wenn man nach "sync options" bzw. "deletion prevention while syncing" sucht, dann erhält man einen Powershell-String wie man einstellt, dass eine Warnung erscheint bevor 500 Objekte gelöscht werden - sehr vertrauenserweckend...
Man muß die Doku halt auch lesen.
Viel Erfolg.
/Thomas
So, hier mal ein Statusupdate, falls jemand über den Beitrag stolpert und ähnliche Probleme hat:
Alle bisherigen Benutzer (die vom selbstprogrammierten Sync-Tool) in Microsoft365 eingespielt wurden, waren "cloud-only" und besitzen keine Immutable-ID. Soweit so gut von unserer Seite.
Probleme gab es - wie kann es anders sein - mit der Installation von Microsoft Entra Connect. Beim ersten Mal ist ein Fehler bei der Synchronisation aufgetreten und mann konnte nur "Erneut versuchen" klicken. Dann konnte er die Test-OU mit einigen Usern tatsächlich in die Cloud syncen, aber der Synchronization Rules Editor startete nur mit ausgegrauten Buttons. Dieser Fehler ist zumindest auf Reddit dokumentiert, wonach eine Neuinstallation des Tools das einzige probate Mittel zu sein scheint.
Leider klappte es mit der Neuinstallation am 16.7. nicht, da Micrsoft einen Server-Error hatte. Heute stand eine neue Version des Tools bereit, allerdings brach das Setup jedes Mal mit einer Exception ("Fail - keine genaue Beschreibung für diesen Fehler vorhanden') ab. Laut Doku waren aber (wie bereits zuvor) alle Voraussetzungen erfüllt. Also Support bemüht und siehe hier 1: es muss TLS 1.2 mittels Registry-Key forciert werden. Das steht natürlich irgendwo in der offiziellen Doku, aber zumindest hat danach die Installation geklappt und der Rules Editor funkt auch.
Das sagte Nuff...
Alle bisherigen Benutzer (die vom selbstprogrammierten Sync-Tool) in Microsoft365 eingespielt wurden, waren "cloud-only" und besitzen keine Immutable-ID. Soweit so gut von unserer Seite.
Probleme gab es - wie kann es anders sein - mit der Installation von Microsoft Entra Connect. Beim ersten Mal ist ein Fehler bei der Synchronisation aufgetreten und mann konnte nur "Erneut versuchen" klicken. Dann konnte er die Test-OU mit einigen Usern tatsächlich in die Cloud syncen, aber der Synchronization Rules Editor startete nur mit ausgegrauten Buttons. Dieser Fehler ist zumindest auf Reddit dokumentiert, wonach eine Neuinstallation des Tools das einzige probate Mittel zu sein scheint.
Leider klappte es mit der Neuinstallation am 16.7. nicht, da Micrsoft einen Server-Error hatte. Heute stand eine neue Version des Tools bereit, allerdings brach das Setup jedes Mal mit einer Exception ("Fail - keine genaue Beschreibung für diesen Fehler vorhanden') ab. Laut Doku waren aber (wie bereits zuvor) alle Voraussetzungen erfüllt. Also Support bemüht und siehe hier 1: es muss TLS 1.2 mittels Registry-Key forciert werden. Das steht natürlich irgendwo in der offiziellen Doku, aber zumindest hat danach die Installation geklappt und der Rules Editor funkt auch.
Das sagte Nuff...
