[Samba] Azure AD Connect but domain functional level 2012_R2 not yet supported?

[ralph strebbing]

> Hi MJ and Ralph,
>
> Thanks for the additional information! I went back and read this thread and
> this bug report:
> https://www.spinics.net/lists/samba/msg166681.html
> https://bugzilla.samba.org/show_bug.cgi?id=10635
>
> Is the following correct that there are two different working methods for
> syncing from Samba to Azure AD with these tradeoffs?
> * Azure AD Connect (old tool) can be used but only in pass-through mode until
> the above bug is fixed (password hash mode is not reliably working, except
> maybe with a brand new domain). Moreover, it is a more complex setup and
> requires a local SQL server, agents running to handle the authentication, etc
So I followed the wiki link listed below, except I used the "old" tool
instead. IMO it was easier to setup than the connector and proved more
reliable results. I did NOT migrate from NT4 to new AD, but our UIDs
are from our old NT4 domain in a sense that the users were manually
created. I'm only using this on a Windows 2019 (only license to
purchase) domain MEMBER, not a DC. My setup is not a Hybrid setup,
only samba with mixed domain member environment. The AAD Connect tool
syncs every 30 minutes and is syncing password hashes reliably after I
made the permission edits mentioned above. That seemed to be the only
thing outside of the documentation that needed done otherwise.

> Does Azure AD Connect Cloud Sync require that it be run on a Windows DC in the
> domain? MJ, your experience in this thread seems to indicate that it does, but
> the Samba wiki page seems to say that only a Windows Server 2016 domain member
> is needed?
> https://wiki.samba.org/index.php/Azure_AD_Sync
As mentioned above, I'm running on a Domain Member, not a Domain
Controller. From what I gather, the only reason to create a hybrid
setup and use a DC with AAD Sync is to allow 2-way password sync.
> Are there any other major pros and cons between the above two methods?
With my method, the biggest drawback is that any directory synced user
(on O365 from Samba) can not use the reset password features on O365,
they MUST reset their password through windows, or a custom written
tool that invokes samba-tool on the CLI. With my method however, you
can also manually run the sync if needed in-between the 30 minutes of
each sync by using the Synchronization service tool on the windows
domain member server.

Hope this helps clarify things.

Ralph