Windows 2012 Server compatibility
There are a number of different ways that Samba can be considered compatible with Windows and so this page attempts to try to explain some of them (and which ones might be regarded as important). A number of these details will obviously apply more generally to other Windows versions.
SMB protocol features
As Windows 2012 (and 2012 R2) ships with a particular version of SMB, clients which expect to negotiate a certain version may see differences between Windows and Samba. SMB allows for many optional features which are negotiated and servers generally support multiple versions of SMB for interoperability with different clients. This means that servers and clients will speak a wide variety of flavours of SMB, meaning interoperability issues with Samba are generally limited to individual applications and use-cases which have stricter requirements on their SMB connections (encryption and supported ciphers, resilient handles).
RPC server features
This is similar to SMB, many calls or structures have been deprecated over time. In many cases Samba does not implement every call, or has calls which do nothing. There may even be entire RPC pipes which are unimplemented, although their functionality is reproduced in some other way e.g. eventlog6 logging.
Joining Windows as a domain member to a Samba domain
The process for this is described in the following page:
This is generally expected to work without any special effort (compared to a Windows domain), with the supported versions listed here:
Joining Samba as a domain member to a Windows domain
The instructions for joining any Active Directory domain remain the same between a Windows AD and a Samba AD.
When considering the compatibility of domain controllers, there are least three initial aspects that must be considered:
- The functional level
- The schema level
- The domain (or forest) preparation level
On the Windows platform, all three of these are resolved by a tool called adprep.exe. In previous versions, this was run manually by administrators, but in newer versions (2012+), this is automatically run by domain controller promotion on Windows. Unfortunately, adprep itself and the newer methods they use to invoke it are both incompatible with Samba. As a standard workaround, administrators have been advised to join 2008 / 2008R2 versions of Windows (and transfer all of the FSMO roles to it) so that adprep can run on the 2008 DC when joining a 2012 DC.
In Samba, trust support isn't yet complete and so in general terms, the domain is often considered the forest.
Joining Windows as a domain controller in a Samba domain
Joining Samba as a domain controller in a Windows domain
2008 or 2008R2 functional level
Generally speaking, this should work. At times there have been replication issues (and workarounds for them), but stable versions of Samba should join without issue.
2012 functional level or above
This is currently not possible as it would require Samba to implement 2012 functional level (at least enough to operate most features).
Attempting to join will trigger this error message:
DsAddEntry failed with status WERR_ACCESS_DENIED info (8567, 'WERR_DS_INCOMPATIBLE_VERSION')
In reality, Samba could in fact join and pretend it ran the correct functional level, but this has security consequences and is not generally considered safe. The advice is to downgrade the forest (and domain) functional level on the Windows DC to 2008 R2 (and turn off all the associated features in 2012) before joining Samba.
Trusted domain environments
Samba still has a number of limitations to its trusted domain support. In a mixed environment, expect Samba to allow or disallow operations differently from Windows. More information needs to be provided here on exact scenarios.