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 schema level
- The domain (or forest) preparation level
- The functional 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.
With new versions of Windows, applications may require new objects whose schema description is not stored in Active Directory. Newer domain controllers might want to provide extra functionality which is specific to that controller and is not broadly available (or advertised) across the domain. Similarly newer versions available to client machines may also wish to record additional details and provide additional functionality. Therefore, the most basic requirement for these applications is an updated schema which supports classes and attributes that allow this information to be stored in the directory.
In practice, domain controllers seem to rely on both the schema level and the preparation level before they will even interact with domain controllers running other versions. Updating schema versions should be compatible with every version of Windows (for instance, 2012 R2 schema should work on 2008 DCs), as they do not imply functionality across the domain (only behaviour local to the instance).
From Samba 4.11, our default schema is 2012 R2. Prior to Samba 4.11, our default schema was 2008 R2. For those running 2008 R2 schema and want to upgrade to 2012 R2 schema, you may run the domain schema upgrade command.
While Windows versions require newer schema when joining to a domain of a previous version (e.g. 2012 R2 join to 2008 domain), Samba has no such requirement to join Windows domains (and likely isn't ever going to).
Where schema defines what objects can be created in the domain, the preparation step ensures that any directory differences required by a newer functional level are enforced. For instance, certain containers or users might be necessary in newer functional versions (of Active Directory).
Joining a 2012 R2 DC to a 2008 domain requires not only the schema, but also this step too (Windows also requires this step, but should be done remotely by adprep during the process).
Functional level basically describes what version of Active Directory you are running (which in Windows is tied to the OS version, but with newer OS able to run at earlier functional levels). Setting the functional level simply sets a number stored in the directory which DCs will read and alter their behaviour accordingly. All the work required to exhibit the functional level behaviour is either done beforehand (as schema or preparation), or done as a runtime switch.
|Samba does not currently support any attempts to update the functional level|
The samba-tool command to raise your functional level is not safe to use against Samba (and probably not even safe against Windows either). The tool is currently incomplete in that it does not check for the appropriate schema version or preparation level before deciding to change the functional level. Please do not run this! If changing the functional level is necessary, using Windows to perform the change is required.
This section lists the overall status of our FSMO roles. Although Samba does not implement all of them entirely, such operations that go through the FSMO may be quite rare, or in the case of only Samba, perhaps impossible. Not many people would be running (large) mixed domains in the long term and if they are, their domain should be primarily Windows or primarily Samba to avoid issues in compatibility but also with their expectations.
Schema master (forest)
Samba handles the schema master role but certain aspects of Windows may assume that the schema master is running Windows (or rather all components of Active Directory and their associated management protocols). This causes issues with adprep and schema upgrades trying to run against Samba still. If you are updating the schema, use Samba tools against Samba schema masters and Windows tools against Windows schema masters. In general, Samba does not implement as many checks to schema as Windows does, and so it is probably easier to corrupt your database by incorrectly updating schema with Samba.
Domain naming master (forest)
Currently no behaviour is implemented in regards to this role in Samba. Partition creation is not functional in Samba (or is only partly functional).
PDC emulator (domain)
Most of the functionality should be implemented at a 2008 R2 level. However, notably we currently do not implement certain aspects of authentication and password changes (including urgent replication) which would normally forward to the PDC emulator in Samba. In this case, the issue not with the PDC (which presumably does nothing special but respond as per normal) but it is that we don't respect the PDC emulator in the rest of the domain. Normally the PDC is considered authoritative, but in Samba, the replication must propagate naturally before certain logins may work. As long as the domain is at 2008 R2 functional level (regardless of the OS versions), this should function mostly as expected.
RID master (domain)
Samba implements the RID master role and the associated forwarding to the RID master to ensure every DC in the domain does not run out of RIDs (and pre-allocates before it does so). This role should be the same regardless of functional level, but it was implemented for 2008 R2. Certainly at 2008 R2 functional level (regardless of OS versions), this should work as expected.
Infrastructure master (domain + domain DNS + forest DNS)
Currently no behaviour appears to be implemented for these roles in Samba. This role is normally responsible for maintaining certain cross realm links and aspects of the recycling bin (neither have official support in Samba).
Joining Windows as a domain controller in a Samba domain
2008 and 2008 R2 Windows DC
This should work without any special preparation.
2012 and 2012 R2 Windows DC
Yes, this works but not yet by default. In order for this to work, you need to have the latest schema levels as well as the preparation level.
In Samba 4.11, the schema is now 2012 R2 and so only the functional preparation step needs to be done.
|This tool may error out when a live server is running, but it has actually succeeded. There is also a bug in 4.11.0rc1 in the LDAP server preventing the actual Windows domain join.|
samba-tool domain functionalprep --function-level=[2012|2012_R2]
2016 and above
Not yet complete. All the infrastructure is in place, but the work needs to be done/funded.
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.
Other missing features
Some noticeable omissions in our feature set for 2008 R2 are:
- Recycling bin
- DFSR (sysvol replication)
- Various pieces of trust/forest support
For 2012 and 2012 R2:
- Group managed service accounts
- Newer Kerberos features including claims based access control, authentication policy silos, FAST armoring
- Temporary (time-limited) group memberships