samba - Jun 2021 - Azure AD Connect but domain functional level 2012_R2 not yet supported?

> 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

----- Original Message -----
> From: "samba" <samba at lists.samba.org>
> To: "samba" <samba at lists.samba.org>
> Sent: Tuesday, June 29, 2021 10:51:19 AM
> Subject: Re: [Samba] Azure AD Connect but domain functional level 2012_R2
not yet supported?
>> 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.
Do you happen to have another copy of that documentation? The link you posted 
earlier (http://haste.thegamingcorner.net/awizipedez.sql) doesn't appear to
be
working now and I couldn't find a copy of it on archive.org.
> 
>> 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.
> 
Thanks; it's clear to me that Azure AD Connect (the "old" tool)
doesn't require
a DC, but can the new Azure AD Connect Cloud Sync tool be run on a Domain 
Member also or does it require running on a DC too (or only if you want to do 
two-way password sync)?

Did you set up the "old" tool on 3 different Domain Members as the
docs
recommend for redundancy? If so, was the setup process easier on the subsequent
two ( all of the settings had already been configured on the first instance)?

Thanks,

Andrew