ADSync mit Samba

Es mag verwegen klingen aber es gibt durchaus Firmen, die statt eines Windows Server als Domaincontroller mit Samba arbeiten. Samba kann seit der Version 4 auch einen "DomainController" darstellen und damit stellt sich natürlich die Frage einer Kopplung mit Office 365. Natürlich können Sie auch per LDAP/CSVDE/LDIFDE die Benutzer aus einem beliebigen LDAP-Verzeichnis exportieren und mit eigenen Skripten oder Tools per Powershell oder Graph die Identitäten in der Cloud verwalten. Aber das ist nicht mal eben gemacht und wenn ADSync funktionieren würde, müsste man nichts selbst machen.

Anforderungen und Fragen

Damit gibt es gleich einige Fragen die zu klären sind:

  • Kann ADSync mit Samba4 sprechen?
    ADSync nutzt eigentlich nur LDAP aber schreibt natürlich auch in einige Felder wie "msdsonsitencyGUID" zurück, die im LDAP-Schema vorhanden sein müssen. Zudem muss das Dienstkonto die Berechtigungen erhalten.
  • Kann ADSync ggfls. einen anderen DC nutzen?
    Sambar4 kann zusammen mit einem Windows DC in der gleichen Domäne genutzt werden. Sollte ADSync mit Samba4 selbst nicht funktionieren, könnte man ADSync ja auf einen auch nachträglich installieren Windows DC verweisen lassen.
  • Authentifizierung: mit PHS, PTA oder ADFS
    Es wäre schon schön, wenn die Benutzer keine separaten Kennworte in der Cloud hätten, Microsoft sieht hierzu ja Password Hash Sync (PHS), Pass-Through Authentifizierung (PTA) oder Federation (ADFS 2012 R2) vor. Federation sollte mit einem passenden SAML-Server funktionieren PHS wäre mein Favorit.

Ehe ich eine Test-Umgebung aufgebaut habe, wurde natürlich erst mal im Internet gesucht. Tatsächlich habe ich Quellen gefunden, die vielversprechend klingen:

... We have a Linux server with Samba 4 configured as Active Directory, where we need to synchronize users to the Microsoft Office 365 AD. We are trying to use the AAD Connect tool, however, the software can synchronize the objects with no problems, but the password hash is not being synchronizing. We configure AD Connect to synchronize only a single OU (Organization Unit) of our local AD, that have only 2 user objects. We have already activated the AD Connect debugging log (miiserver.exe.config file) to verify what is happening, but analyzing it  seems that AAD Connect is constantly restarting reading all objects from Local AD, and does not synchronize the password , even configured to synchronize only a single OU. If we force a synchronization with troubleshooting option of AAD Connect with an specific user, so the password is synchonized with no problems too.
Quelle: AAD Connect does not synchronize hash password with Linux server with Samba 4 (Mai 2018)
https://social.msdn.microsoft.com/Forums/azure/en-US/c7bf042f-9e96-4912-a849-309712b5de41/aad-connect-does-not-synchronize-hash-password-with-linux-server-with-samba-4?forum=WindowsAzureAD

We setup the microsoft azure AD Connect on a windows 2012 server, to start using (testing) office 365 in the future. We're running a samba 4.4.4 AD. all worked, in the portal.office.com admin section we can see that:
Quelle: [Samba] azure AD Connect | passwords not syncing (Noc 2016) https://lists.samba.org/archive/samba/2016-November/204564.html

...On the other hand, I can tell you that Azure AD Connect works really well with Samba against Office 365. In this scenario you just sync your (Samba) AD users to a new AD setup by Microsoft in Azure and you can run Exchange / Office 365 against the the ADDC in the cloud.
Quelle [Samba] Samba 4 with Microsoft Exchange (Dez 2018) https://lists.samba.org/archive/samba/2018-December/219991.html

Das sieht ja schon mal so aus, als ADSync tatsächlich per LDAP nicht nur einen Samba Domain Controller abfragen kann sondern unter bestimmten Umständen sogar die Hashwerte der Kennworte bekommen kann. Da war meine Neugierde mal geweckt.

DC mit Samba auf Linux

Natürlich habe ich grade keinen aktiven Samba-Server mit DC-Funktion in meinem Testpool. Das hat mir dann die Möglichkeit gegeben, mal eben schnell einen Server mit Samba als DC zu installieren. Ich habe also auf meinem HyperV-Server eine neue Type-1 VM mit 2GBRam, 20GB Disk und Netzwerk angelegt und eine Debian 10-ISO-Datei gestartet. Die Plattform ist aber eigentlich egal. Die Textinstallation lieft schnell durch

Auch für die Installation von Samba gibt es eine ganze Menge Tutorials und Anleitungen.

Leider sind die Kommandozeilen und Pfade je nach Linux-Derivat abweichend, so dass ich häufiger eine Suchmaschine anwerfen musste. Auch sollten Sie die Anleitungen von Samba genau folgen, denn einige per Default vorhandenen Dienste müssen deaktiviert oder zurückgesetzt werden. Das betrifft die Updates der resolve.conf durch den Debian Network Manager.

systemctl stop NetworkManager
systemctl disable NetworkManager

Auch die smb.conf musste ich erst mal wegwerfen, da nach der Installation den Server ein "Fileserver" ist.

Achtung:
Nur weil Samba ein DC mit LDAP und KDC darstellen kann, ist er keine problemlose Alternative zu einem Windows DC. Es gibt verschiedene Schnittstellen, die Samba noch nicht implementiert hat Meines Wissens ist z.B. NSPI (Siehe Outlook und GC (Globaler Katalog) nicht implementiert. Ein Exchange Server wird in so einer Welt aktuell nicht arbeiten.

Dennoch können Sie damit für einfachere Aufgaben einen Samba-Server als DC-Emulator aufsetzen und Windows Clients "in die Domäne" aufnehmen.

Bedenken sie, dass sie Windows Server CALs für alle Clients benötigen, sobald Sie auch nur einen Windows Server einsetzen. Die Server-Lizenz selbst ist in vielen Modellen aber der geringste Kostenblock, so dass Sie dann auch Windows DCs recht günstig aufbauen können.

Nachdem ich einige nicht weiter aufgeführte Fallstricke umschifft habe, konnte ich Samba konfigurieren.

root@debian:/etc/samba# samba-tool domain provision
Realm [SAMBA.CARIUS.DE]:
Domain [SAMBA]:
Server Role (dc, member, standalone) [dc]:
DNS backend (SAMBA_INTERNAL, BIND9_FLATFILE, BIND9_DLZ, NONE) [SAMBA_INTERNAL]:
DNS forwarder IP address (write 'none' to disable forwarding) [192.168.178.1]:
Administrator password:********
Retype password:********
Looking up IPv4 addresses
Looking up IPv6 addresses
More than one IPv6 address found. Using 2a00:6020:13fa:d300:215:5dff:fe4a:e1d
Setting up share.ldb
Setting up secrets.ldb
Setting up the registry
Setting up the privileges database
Setting up idmap db
Setting up SAM db
Setting up sam.ldb partitions and settings
Setting up sam.ldb rootDSE
Pre-loading the Samba 4 and AD schema
Unable to determine the DomainSID, can not enforce uniqueness constraint on local domainSIDs

Adding DomainDN: DC=samba,DC=carius,DC=de
Adding configuration container
Setting up sam.ldb schema
Setting up sam.ldb configuration data
Setting up display specifiers
Modifying display specifiers and extended rights
Adding users container
Modifying users container
Adding computers container
Modifying computers container
Setting up sam.ldb data
Setting up well known security principals
Setting up sam.ldb users and groups
Setting up self join
Adding DNS accounts
Creating CN=MicrosoftDNS,CN=System,DC=samba,DC=carius,DC=de
Creating DomainDnsZones and ForestDnsZones partitions
Populating DomainDnsZones and ForestDnsZones partitions
Setting up sam.ldb rootDSE marking as synchronized
Fixing provision GUIDs
A Kerberos configuration suitable for Samba AD has been generated at /var/lib/samba/private/krb5.conf
Merge the contents of this file with your system krb5.conf or replace it with this one. Do not create a symlink!
Once the above files are installed, your Samba AD server will be ready to use
Server Role:           active directory domain controller
Hostname:              debian
NetBIOS Domain:        SAMBA
DNS Domain:            samba.carius.de
DOMAIN SID:            S-1-5-21-1122779896-4030397727-2697658314
root@debian:/etc/samba#

Warum auch immer waren danach meine samba-ad-dc Dienste aber noch "blocked". Aber auch hier helfen Google und Co dem Windows Admin die richtigen Befehle für das verwendete Linux-Derivat zu finden. Die erste Verbindung habe ich per LDP.EXE gestartet:

Nach einer erfolgreichen Anmeldung konnte ich dann auch die OU-Struktur sehen

Das hat aber ADSync noch nicht gereicht.

ADSync mit Samba

Natürlich war ich neugierig, wie sich ADSync in dieser Umgebung verhält. Ein Blick auf die System Requirements kann da mal nicht schaden

Die Installation von ADConnect erfordert mindestens einen Windows 2012R2-Server. Damit ist das "Windows Server CAL"-Thema von eben schon wieder im Blickpunkt und auch das Setup verhindert die Installation z.B. auf einem Windows 10 1909 Client

Die Installation auf einem Windows Server läuft aber problemlos durch und ich kann mich natürlich mit meinem Office 365/AzureAD-Tenant verbinden und sogar mit dem Samba LDAP-Server.

Wenn ich administrator@samba.carius.de als Anmeldenamen versucht habe, bekam ich den folgenden Fehler

The domain specified in the credentials does not exist or cannot be contacted. 
Using credentials with a fully qualified domain may help to resolve this issue (Learn More)

Der "Learn More"-Link verweist auf:

Ein Blick in das Verzeichnis " C:\ProgramData\AADConnect\" liefert dann die Details. Die weitere Konfiguration ist dann wieder Standard: ADSync liest das Schema ein. Das Setup warnt mit, wenn der lokale UPN nicht im AzureAD als Domain gepflegt ist und sogar die OUs kann ich auswählen

Ohne Exchange Schema wird es natürlich nichts mit dem Hybrid Mode

Interessant ist, dass er per Default "Password hash synchronization" aktiviert. Darauf komme ich später noch mal. Nach einigen Minuten behauptet das Setup dass er "fertig" ist.

Es sieht alles wie gewohnt aus und sogar die Replikation funktioniert zwischen dem Samba-AD und Office 365.

Beim ersten Abgleich hat er 151 Objekte gelesen und ins Metaverse geschrieben. Alle sechs Tasks sind "erfolgreich" aber das ist nur die halbe Wahrheit. Es kommen nur wenige Objekte letztlich im Metaverse an.

Beachten Sie, dass die Benutzer in Debian und Samba getrennte Datenbanken sind. Sie müssen die Benutzer also schon in Samba anlegen, z.B.: mit

smbpasswd -a user

Allerdings hat mein Samba-AD natürlich keine Exchange Schema und entsprechend kann ich den Exchange Hybrid Mode nicht aktiviert. Das bedeutet in der Konstellation aber auch, dass ich so lokal keine Exchange Properties verwalten kann. Das ist natürlich unschön, da eine Verwaltung in Exchange Online auch nu eingeschränkt möglich ist. Für Schulen mag das noch in Ordnung sein, wenn UPN=MAIL=SIP ist. Weitergehende Anpassungen z.B. zusätzliche Mailadressen (ProxyAddresses) sind aber nur möglich, wenn das lokale Schema diese Felder kennt, ADSync diese auch überträgt, und sie eine lokale Verwaltungsoberfläche zur Änderung dieser Fälle haben.

PHS vielleicht, PTA ja

Das Thema "Kennwort" war ja noch offen. Ich habe dazu extra einen Benutzer in Samba mit einem neuen Kennwort versehen. Im Application Eventlog findet sich dann zeitnah die folgende Fehlermeldung:

Log Name:      Application
Source:        Directory Synchronization
Date:          18.08.2020 23:26:40
Event ID:      611
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.carius.de
Description:
Password hash synchronization failed for domain: samba.carius.de, 
   domain controller hostname: debian.samba.carius.de, 
   domain controller IP address: 192.168.178.35. Details: 
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. 
   ---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: 
   RPC Error 8420 : The naming context could not be found. There was an error calling _IDL_DRSGetNCChanges.
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnReplicateSingleObject(DsName directoryName)
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.ReplicateSingleObject(Guid objectGuid, String distinguishedName)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.<>c__DisplayClass9_0.<RetrieveObjectChangesFromAD>b__1(IDrsConnection c)
   at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1 operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.RetrieveObjectChangesFromAD(List`1 retryObjects)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   --- End of inner exception stack trace ---
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
   at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
   at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext syncExecutionContext)
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. 
   ---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException: 
   RPC Error 8420 : The naming context could not be found. There was an error calling _IDL_DRSGetNCChanges.
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnReplicateSingleObject(DsName directoryName)
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.ReplicateSingleObject(Guid objectGuid, String distinguishedName)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.<>c__DisplayClass9_0.<RetrieveObjectChangesFromAD>b__1(IDrsConnection c)
   at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1 operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.RetrieveObjectChangesFromAD(List`1 retryObjects)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   --- End of inner exception stack trace ---
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
   at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
   at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext syncExecutionContext)
.

<forest-info>
  <partition-name>SAMBA.CARIUS.DE</partition-name>
  <connector-id>b9003638-5303-480d-b2e8-3c43b0515e43</connector-id>
</forest-info>
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Directory Synchronization" />
    <EventID Qualifiers="0">611</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2020-08-18T21:26:40.134796000Z" />
    <EventRecordID>2979998</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DC01.carius.de</Computer>
    <Security />
  </System>

Es hätte mich auch etwas gewundert, denn die Kennwort rückt ein Windows Server natürlich nicht einfach per LDAP raus. Für diese Funktion muss sich ADSync einer anderen Schnittstelle bedienen, die es bei Samba anscheinend (noch) nicht gibt.

Es ist sogar schon seit 2014 (Samba 4.4) ein Bug offen.

Mein Debian 10.5 (1. Auf 2020) bringt leider nur "Samba 4.9.5-debian" mit, während auf der offizielle Seiten schon 4.12.6 zu finden ist. in den Release Notes habe ich aber keinen Hinweis gefunden, dass dieser Bug gefixt ist. Ich habe mir daher den Download der Quellen und eine eigene Kompilierung erst einmal gespart.

Von einem Leser wurde ich aber auf folgende Meldung einer Samba Mailingliste hingewiesen.

Today I tried again with these ingredients:
- fresh azure tenant
- fresh installed AD (samba 4.12.8 sernet)
- an azure "custom domain name" for our AD realm, status "verified"
- new Azure AD Connect Cloud Provisioning agent, using a "domain admins"
AD account
- with password-hash sync
 
And it works. :-)
Quelle: Samba Mailingliste

Da PHS wohl noch nicht möglich ist, können Sie die Anmeldung der Anwender aber weiterhin über ADFS oder natürlich Pass-Through Authentifizierung (PTA) realisieren.
Vielleicht haben Sie aber heute für ihre Anwender eine andere Plattform zur Verwaltung des Kennworts, z.B. eine Webseite. Dann könnte der Code natürlich nicht nur das Linux und Samba-Kennwort, sondern auch das Office 365 Kennwort einfach setzen.
Ein ganz anderer Weg ist natürlich der Verzicht auf ADSync und der Aufbau einer eigenen Synchronisationslösung.

Password Writeback

Wenn die bei der Einrichtung aufgepasst haben, dann hätte man da schon "Password WriteBack" aktivieren können. Wenn ADSync schon nicht das Kennwort des lokalen Samba-AD in die Cloud synchronisieren kann, dann könnte ja die Gegenrichtung interessant sind. Eine Änderung des Kennworts im Office 36 Tenant triggert auch sofort ADSync aber wirft die gleiche Fehlermeldung:

Log Name:      Application
Source:        Directory Synchronization
Date:          18.08.2020 23:52:55
Event ID:      611
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      DC01.carius.de
Description:
Password hash synchronization failed for domain: samba.carius.de, 
   domain controller hostname: debian.samba.carius.de, 
  domain controller IP address: 192.168.178.35. Details: 
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. 
   ---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException:
    RPC Error 8420 : The naming context could not be found. There was an error calling _IDL_DRSGetNCChanges.
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnReplicateSingleObject(DsName directoryName)
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.ReplicateSingleObject(Guid objectGuid, String distinguishedName)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.<>c__DisplayClass9_0.<RetrieveObjectChangesFromAD>b__1(IDrsConnection c)
   at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1 operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.RetrieveObjectChangesFromAD(List`1 retryObjects)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   --- End of inner exception stack trace ---
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
   at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
   at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext syncExecutionContext)
Microsoft.Online.PasswordSynchronization.SynchronizationManagerException: Recovery task failed. 
   ---> Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsException:
    RPC Error 8420 : The naming context could not be found. There was an error calling _IDL_DRSGetNCChanges.
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsRpcConnection.OnReplicateSingleObject(DsName directoryName)
   at Microsoft.Online.PasswordSynchronization.DirectoryReplicationServices.DrsConnection.ReplicateSingleObject(Guid objectGuid, String distinguishedName)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.<>c__DisplayClass9_0.<RetrieveObjectChangesFromAD>b__1(IDrsConnection c)
   at Microsoft.Online.PasswordSynchronization.RetryUtility.ExecuteWithRetry[T](Func`1 operation, Func`1 shouldAbort, RetryPolicyHandler retryPolicy)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.RetrieveObjectChangesFromAD(List`1 retryObjects)
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   --- End of inner exception stack trace ---
   at Microsoft.Online.PasswordSynchronization.RecoveryTask.SynchronizeCredentialsToCloud()
   at Microsoft.Online.PasswordSynchronization.PasswordSynchronizationTask.SynchronizeSecrets()
   at Microsoft.Online.PasswordSynchronization.SynchronizationExecutionContext.SynchronizeDomain()
   at Microsoft.Online.PasswordSynchronization.SynchronizationManager.SynchronizeDomain(SynchronizationExecutionContext syncExecutionContext)
.

<forest-info>
  <partition-name>SAMBA.CARIUS.DE</partition-name>
  <connector-id>b9003638-5303-480d-b2e8-3c43b0515e43</connector-id>
</forest-info>
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Directory Synchronization" />
    <EventID Qualifiers="0">611</EventID>
    <Level>2</Level>
    <Task>0</Task>
    <Keywords>0x80000000000000</Keywords>
    <TimeCreated SystemTime="2020-08-18T21:52:55.195323100Z" />
    <EventRecordID>2980257</EventRecordID>
    <Channel>Application</Channel>
    <Computer>DC01.carius.de</Computer>
    <Security />
  </System>

Auch dieser Weg ist damit noch nicht möglich.

Gruppen

Ich habe als letzten Test in Samba eine "Windows Gruppe" angelegt und den Benutzer USER1 addiert

# samba-tool group add sambagroup1
# samba-tool group addmembers sambagroup1 user1

# samba-tool group listmembers sambagroup1
user1

Per LDP konnte ich auch sehen, dass die Gruppe und Mitglieder per LDAP sichtbar wurden:

Allerdings hat ADSync diese Änderung erst einmal ignoriert. Die Gruppe selbst wurde eingelesen und auch im AzureAD angelegt, aber das Feld "Member" hat ihn nicht interessiert. Im Metaverse sind die Mitglieder schon nicht angekommen.

Die Sync Rules wurden aber angewendet und in der Regel "In from AD - Group Common" steckt der Abgleich der "Member" auch drin.

Selbst ein "Full Sync" hat nicht dazu geführt dass ADSync die Mitglieder korrekt aus dem Samba AD ausgelesen hätte.

Ich habe das Problem erst einmal nicht weiter verfolgt, da auch andere Probleme mich aktuell abhalten ADSync mit Samba einzusetzen. Vielleicht ändert sich das mit einer neueren Samba-Version.

Einschätzung

Die Funktion von ADSync ist im Hinblick auf Benutzer bezüglich der Basisfunktionen gegeben. Das Setup ist natürlich weit weg von jedem Standard und Support von Microsoft dürfen Sie hier nicht erwarten. Da Microsoft diese Kombination nicht testet, könnte ein Update von ADSync ihr schönes Modell zum Einsturz bringen. Der "evergreen IT"-Ansatz der Cloud führt dazu, das Updates nicht endlos verzögert werden können. Mir wäre das Risiko hier einfach zu groß, zu unpassender Zeit etwas grundlegend verändern zu müssen. Da sie für ADSync sowieso einen Windows Server benötigen, sparen Sie auch Lizenztechnisch nicht allzu viel ein.

Wer aber dennoch weiter mit einem eigenen lokalen Verzeichnisdienst arbeitet, der kein Windows AD ist, kann durchaus auch eigene Lösungen zum Provisionieren der Office 365 Identitäten umsetzen. Microsoft bietet hierzu mit der AzureAD-PowerShell und Microsoft Graph gut dokumentierte Schnittstellen an.

Weitere Links