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

Andrew Martin amartin at xes-inc.com
Tue Jun 29 15:20:06 UTC 2021

----- 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:

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?

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



More information about the samba mailing list