Azure Active Directory nachträglich mit Onpremise AD syncronisieren
Hallo Admins,
auf mich kommt folgendes Problem zu.
Kunde hat sich in O365 und in Onpremise jeweils einen User angelet. Ich Persölich bin eher dafür Onpremise die User anzulegen und dann mit Azure AD Connect zu O365 zu synchronisieren.
Da nun Postfächer auf den "Cloud-Benutzern" vorhanden sind ist ein löschen ersteinmal nicht denkbar.
Gibt es hier eine Lösung, wie man nachträglich die Cloudbenutzer auflöst, die lokalen AD-benutzer synchronisiert und dann die Postfächer auf diese überträgt ?
auf mich kommt folgendes Problem zu.
Kunde hat sich in O365 und in Onpremise jeweils einen User angelet. Ich Persölich bin eher dafür Onpremise die User anzulegen und dann mit Azure AD Connect zu O365 zu synchronisieren.
Da nun Postfächer auf den "Cloud-Benutzern" vorhanden sind ist ein löschen ersteinmal nicht denkbar.
Gibt es hier eine Lösung, wie man nachträglich die Cloudbenutzer auflöst, die lokalen AD-benutzer synchronisiert und dann die Postfächer auf diese überträgt ?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 591193
Url: https://administrator.de/forum/azure-active-directory-nachtraeglich-mit-onpremise-ad-syncronisieren-591193.html
Ausgedruckt am: 27.12.2024 um 19:12 Uhr
5 Kommentare
Neuester Kommentar
tja was man mit dem Postfach machen muß keine Ahnung... aber normalerweise richtet man ein ADFS ein, jedenfalls ham die das bei uns so gelöst... wir haben eine on-Premise Domäne in der aktuell aber nur Teams (als O365 Bestandteil), und eine SAML 2.0 Federation mit dem Cloud-AD gebaut. Noch besser wäres aber, sich vorher Gedanken zu machen wie man ein O365 mit gemanagtem AD mit dem eigenen AD verheiratet und DANN Postfächer u.s.w. migriert.
Moin,
dieses Szenario (AAD -> On-Premise AD) ist bis dato nicht supportet:
Some customers start with a cloud-only solution with Azure AD and they do not have an on-premises AD. Later they want to consume on-premises resources and want to build an on-premises AD based on Azure AD data. Azure AD Connect cannot help you for this scenario. It does not create users on-premises and it does not have any ability to set the password on-premises to the same as in Azure AD.
Quelle: Azure AD Connect: When you have an existent tenant
Gruß,
Dani
dieses Szenario (AAD -> On-Premise AD) ist bis dato nicht supportet:
Some customers start with a cloud-only solution with Azure AD and they do not have an on-premises AD. Later they want to consume on-premises resources and want to build an on-premises AD based on Azure AD data. Azure AD Connect cannot help you for this scenario. It does not create users on-premises and it does not have any ability to set the password on-premises to the same as in Azure AD.
Quelle: Azure AD Connect: When you have an existent tenant
Gruß,
Dani
@GrueneSosseMitSpeck
Gruß,
Dani
aber normalerweise richtet man ein ADFS ein, jedenfalls ham die das bei uns so gelöst...
inzwischen geht man den Weg über AADConnect/PHS. So ist bei einer möglichen Unterbrechnung die Cloud Services weiterhin nutzbar. Denn die meisten Firmen haben keine hochverfügbare Internetleitung bzw. AD FS/WAP Farm, feste IP-Adresse(n), DNS-Namen, Hardware, Lizenzen, etc.Gruß,
Dani
Hallo,
Du kannst lokale User zum Azure AD „matchen“ Zum Beispiel über die EmailAdresse.
https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-ma ...
Also: Benutzer lokal anlegen. Dann die Email-Adressen passend machen. Erst dann Azur ADSync installieren. Sobald die User erstmalig gemacht wurden, wird dann wieder der normale Sync-Mechanismus verwendet, und die Email ist wieder nur eine Email.
Grüße
lcer
Du kannst lokale User zum Azure AD „matchen“ Zum Beispiel über die EmailAdresse.
https://support.microsoft.com/en-us/help/2641663/use-smtp-matching-to-ma ...
Also: Benutzer lokal anlegen. Dann die Email-Adressen passend machen. Erst dann Azur ADSync installieren. Sobald die User erstmalig gemacht wurden, wird dann wieder der normale Sync-Mechanismus verwendet, und die Email ist wieder nur eine Email.
Grüße
lcer