7
Azure AD lokale Synchronisation
Hallo zusammen,
wir haben einen User in unserem Azure AD erstellt.
Dieser wird jedoch nicht automatisch mit unserem On-Premise AD synchronisiert.
Die andere Richtung, also der Sync von On-Premise nach Azure funktioniert hingegen.
Bei dem entsprechenden Benutzer habe ich die Eigenschaft "lokale Synchronisation" gefunden
Diese ist deaktiviert.
In den Einstellungen des Users kann ich dies nicht ändern.
An welcher Stelle muss ich die Synchronisation für den Benutzer ins On-Premise AD aktivieren?
wir haben einen User in unserem Azure AD erstellt.
Dieser wird jedoch nicht automatisch mit unserem On-Premise AD synchronisiert.
Die andere Richtung, also der Sync von On-Premise nach Azure funktioniert hingegen.
Bei dem entsprechenden Benutzer habe ich die Eigenschaft "lokale Synchronisation" gefunden
Diese ist deaktiviert.
In den Einstellungen des Users kann ich dies nicht ändern.
An welcher Stelle muss ich die Synchronisation für den Benutzer ins On-Premise AD aktivieren?
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: 5979395096
Url: https://administrator.de/contentid/5979395096
Ausgedruckt am: 25.11.2024 um 07:11 Uhr
7 Kommentare
Neuester Kommentar
Hallo,
ich glaube, in diese Richtung geht es nicht, bzw. nur gewisse Sachen.
Auch bei meiner MS Schulung hieß es immer nur von onPrem-> Cloud, aber nicht in die andere Richtung. Schulung war aber nicht zu diesem Thema, bin daher kein experte.
Viele Dinge kann man in der Hybridstellung auch nur onPrem bearbeiten.
Aber hast du einen Full Sync im AzureAD Konnektor ausgeführt?
LG
ich glaube, in diese Richtung geht es nicht, bzw. nur gewisse Sachen.
Auch bei meiner MS Schulung hieß es immer nur von onPrem-> Cloud, aber nicht in die andere Richtung. Schulung war aber nicht zu diesem Thema, bin daher kein experte.
Viele Dinge kann man in der Hybridstellung auch nur onPrem bearbeiten.
Aber hast du einen Full Sync im AzureAD Konnektor ausgeführt?
LG
Hi
Leg ihn on Prem an mit allen Attributen aus dem Azure AD und Mailadressen etc und das Azure AD Merged die dann.
Zumindest war es bei mir bisher bei ein paar Usern so.
Gab es erst nur im AzureAD und ich habe Sie im on Prem AD angelegt und dann waren die via Sync verknüpft.
Mit freundlichen Grüßen Nemesis
Leg ihn on Prem an mit allen Attributen aus dem Azure AD und Mailadressen etc und das Azure AD Merged die dann.
Zumindest war es bei mir bisher bei ein paar Usern so.
Gab es erst nur im AzureAD und ich habe Sie im on Prem AD angelegt und dann waren die via Sync verknüpft.
Mit freundlichen Grüßen Nemesis
1
Moin,
wir syncen auch ausschließlich on Prem -> Azure. Ich meine mich aber erinnern zu können, dass der UPN Kriterium ist. Sprich: Wenn du ihn in deinem AD nun mit dem gleichen UPN anlegst, erfolgt beim nächsten Sync das Matching.
Gruß
Doskias
wir syncen auch ausschließlich on Prem -> Azure. Ich meine mich aber erinnern zu können, dass der UPN Kriterium ist. Sprich: Wenn du ihn in deinem AD nun mit dem gleichen UPN anlegst, erfolgt beim nächsten Sync das Matching.
Gruß
Doskias
Zitat von @newit1:
wir haben einen User in unserem Azure AD erstellt.
Dieser wird jedoch nicht automatisch mit unserem On-Premise AD synchronisiert.
Die andere Richtung, also der Sync von On-Premise nach Azure funktioniert hingegen.
Dieser wird jedoch nicht automatisch mit unserem On-Premise AD synchronisiert.
Die andere Richtung, also der Sync von On-Premise nach Azure funktioniert hingegen.
Und mit welchem unbekannten Tool wird dies durchgeführt?
Moin,
ich gehe davon aus, dass AD-Connect verwendet wird,
Es gab mal vor langer Zeit ein Vorschaufeature, welches "User Writeback" zur Verfügung gestellt hat.
Das wurde allerdings schon vor einiger Zeit ersatzlos gestrichen.
Zum anderen:
Selbst wenn die Funktion gegeben wäre, halte ich das Vorhaben für ziemlich gefährlich. Wenn Du dein Azure AD via AD-Connect "in Teilen" authoritativ ausbaust "publishst" Du dein internes AD in das Internet.
Wenn ich dein Azure AD infiltrieren kann erstelle ich mir einfach die Benutzer die ich on-prem brauche mit den gewünschten Berechtigungen und kann (fast) loslegen. Am besten hast du dann noch ein VPN Gateway in Azure stehen, welches den Zugriff von einer Azure VM in dein lokales Netz ermöglicht.
Dann geht die Show los und zwar so richtig
Dein lokales AD ist und bleibt deine Identitätsplattform, dass Azure AD ist nur eine Erweiterung dazu.
Heißt in anderen Worten: Alle Onprem User werden weiterhin auch onprem gemanaged, alle Clouduser logischerweise in der Cloud.
Ansonsten AD abschalten und Cloud Only arbeiten, dann wird das Azure AD deine neue Identitätsplattform.
ich gehe davon aus, dass AD-Connect verwendet wird,
Es gab mal vor langer Zeit ein Vorschaufeature, welches "User Writeback" zur Verfügung gestellt hat.
Das wurde allerdings schon vor einiger Zeit ersatzlos gestrichen.
Zum anderen:
Selbst wenn die Funktion gegeben wäre, halte ich das Vorhaben für ziemlich gefährlich. Wenn Du dein Azure AD via AD-Connect "in Teilen" authoritativ ausbaust "publishst" Du dein internes AD in das Internet.
Wenn ich dein Azure AD infiltrieren kann erstelle ich mir einfach die Benutzer die ich on-prem brauche mit den gewünschten Berechtigungen und kann (fast) loslegen. Am besten hast du dann noch ein VPN Gateway in Azure stehen, welches den Zugriff von einer Azure VM in dein lokales Netz ermöglicht.
Dann geht die Show los und zwar so richtig
Dein lokales AD ist und bleibt deine Identitätsplattform, dass Azure AD ist nur eine Erweiterung dazu.
Heißt in anderen Worten: Alle Onprem User werden weiterhin auch onprem gemanaged, alle Clouduser logischerweise in der Cloud.
Ansonsten AD abschalten und Cloud Only arbeiten, dann wird das Azure AD deine neue Identitätsplattform.
Write Back geht nicht bzw. ist nicht vorgesehen soweit ich weiß. War zwar mal vorgesehen wurde dann aber wie oben bereits geschrieben ersatzlos gestrichen.
Das Einzige was sich zurückschreibt sind Gruppen, wenn denn aktiviert. User nicht - die werden nur Verknüpft von INTERN nach AZURE AD
Ziel des ganzen Konzeptes ist es ja das der LOKALE AD die Plattform ist für alles was Management ist und auch bleiben soll.
Soweit ich es getestet habe sollte es aber funktionieren wenn beide User den gleichen UPN haben.
Nebenbei bemerkt das der UPN eine "vollwertige" routbare DNS Adresse sein muss also kein .home/.local/.netz......
sonst geht es nicht. Der Lokale User ist dann aber der Führende heißt dessen Einstellungen und Gruppenzugehörigkeiten werden dann übernommen.
Das Einzige was sich zurückschreibt sind Gruppen, wenn denn aktiviert. User nicht - die werden nur Verknüpft von INTERN nach AZURE AD
Ziel des ganzen Konzeptes ist es ja das der LOKALE AD die Plattform ist für alles was Management ist und auch bleiben soll.
Soweit ich es getestet habe sollte es aber funktionieren wenn beide User den gleichen UPN haben.
Nebenbei bemerkt das der UPN eine "vollwertige" routbare DNS Adresse sein muss also kein .home/.local/.netz......
sonst geht es nicht. Der Lokale User ist dann aber der Führende heißt dessen Einstellungen und Gruppenzugehörigkeiten werden dann übernommen.
