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

----- Original Message -----
> From: "mj" <lists at merit.unu.edu>
> To: "Andrew Martin" <amartin at xes-inc.com>
> Cc: "samba" <samba at lists.samba.org>
> Sent: Tuesday, June 29, 2021 4:27:12 AM
> Subject: Re: [Samba] Azure AD Connect but domain functional level 2012_R2
not yet supported?
> Hi Andrew,
> 
> On 6/28/21 7:40 PM, Andrew Martin wrote:
>> * how exactly did you setup firewall rules to block other clients? Did
this
>> cause issues, e.g. with DNS records in AD?
> 
> So far so good: no issues. I put the WINDC on a seperate subnet to be
> able to firewall it. I also did some local firewalling on the WINDC. I
> DENY rather than DROP, to avoid having to wait for timeouts.
> 
> Not a windows guru, but perhaps you could also use the concept of
> "sites" to seperate the WINDC from your local LAN DCs. Perhaps
you could
> test that, and let us know.
> 
>> * when joining the Windows DC to the domain, did you need to do
anything to
>> tell it to create the 2012_R2 schema? I'm guessing it thought that
the AD was
>> at 2008_R2 since that's the Functional Level still, so how did you
replicate
>> the 2012_R2 schema objects to it from the other DCs (or maybe it just
worked)?
> 
> No, all we did was:
>  samba-tool domain functionalprep --function-level=2012_R2
>  samba-tool domain schemaupgrade
> This keeps the functional level at 2008_R2.
> 
> Then we were able to add a WIN2008R2 DC to the AD domain.
> 
>> * any other issues you ran into with turning your pure Samba AD into a
hybrid?
> 
> Yes, one. We tried to add a more recent (2012R2) windows DC as well.
> Never tried 2016 because of warning on the samba wiki. Adding a 2012R2
> DC caused problems which I was unable to resolve, namely:
> The number of objects reported by samba-tool dbcheck kept increasing
> every few minutes. So after a week of just letting it run/replicate with
> no client traffic, our total objects had almost doubled. I wrote about
> that on the list, but no solution.
> 
> After shutting down the 2012R2 DC, the number of objects stopped
> increasing. So I decided to continue to use the WIN2008_R2 DC for the
> time being. Perhaps in the future I will work on this again. I know we
> should not run a WIN2008 DC. (the strict firewalling is also because of
> that)
> 
>> Asking the list more generally (but also you too if you know), is the
>> combination of 2012_R2 for the Schema Level and Functional Prep but
2008_R2 for
>> the Functional Level really safe? Moreover, it seems that only 2003 is
required
> 
> It seems to work here for a couple of weeks now.
> 
>> Despite the warning below, is it safe to run "samba-tool domain
level raise" if
>> you have already made sure that the Schema Level and Functional Prep
have been
>> updated?
> 
> Would love an answer on that too.
> 
> Generally it would be nice to see more dialogue on those kinds of
> subjects, like: mixing windows/samba DCs, functional levels, interacting
> with azure/O365, etc.
> 
> MJ
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 Cloud Sync can be used for syncing password hashes and is 
simpler to setup and doesn't rely on your local DCs being online
* 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

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

Are there any other major pros and cons between the above two methods?

Thanks,

Andrew

> 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