June 5, 2019 at 17:05Samba DC as a second controller in the AD domain of Windows 2012R2 and roaming folders for clients on Windows and Linux
The realization that I was in the import mix did not come right away. Only when fresh supplies of PCs began to arrive stably from the parent organization with the Alt Linux distribution on board, I suspected something was amiss.
However, in the process of going through the stages of accepting the inevitable, I got involved and even started to enjoy the process a little. And at some point I thought that, at such a pace, sooner or later I would have to give up the decision to organize the Microsoft directory service and move towards something more exotic. Therefore, in order to prepare in advance for the inevitable, and if possible to catch more pitfalls, it was decided to deploy a test bench, which includes:
- DC1 - Windows Server 2012R2
- DC2 - Alt Server 8.2
- File Server - Windows Server 2012R2
- PC1 - Windows 7
- PC2 - Alt Workstation 8.2
Tasks of the stand:
- Deploy a domain based on w2k12r2. Create a minimal set of group policies (similar to those used in the work infrastructure), including a policy for transferring user working folders (Downloads / Documents / Desktop). In the end, I want that when a user changes his workplace from Windows to Linux and vice versa, he has comfortable access to his working documents.
- Entering Samba DC by the second controller. Checking Directory Service and DNS Replication
- Configuring Linux Clients with Roaming Folders
Implementation:
- Installing and entering a new controller
With the installation of MS Windows 2012R2, everything is simple and less clear. On the Internet there is a 1001 manual for deploying a domain on Windows using both the GUI and Powershell, so I won’t repeat it again, I’ll leave only a link to off. documentation for the curious and those who want to refresh their memory.
However, there is one important point in this paragraph. To date, Samba is not able to work with catalog schemes above 2008R2.Spoiler headingRather, the developers of this support is declared as experimental. But in practice, an attempt to enter samba as a second DC into an existing Windows domain with scheme 69 will meet you with the following errorDsAddEntry failed with status WERR_ACCESS_DENIED info (8567, 'WERR_DS_INCOMPATIBLE_VERSION')
The problem is that Windows 2012 and 2012R2 use WMI tools for working with domains and forests, stable support of which has been announced only for version Samba 4.11, which should be released before the end of this year.
It follows that the only option for introducing samba to the AD domain, deployed on 2012R2 server, is to lower the scheme from 69 to 47. Of course, this should not be done on the working infrastructure without good reason, but we have a test bench here, so why actually not.
We put Alt Server 8.2. During installation, select the profile "Samba-DC Server (AD Controller)." On the deployed server, we make a complete system update and install the task-samba-dc package, which will pull everything you need# apt-get install task-samba-dcIf task-samba-dc suddenly, contrary to the assurances of the documentation, Alta refuses to install everything necessary.# apt-get install python-module-samba-DC samba-DC-common samba-DC-winbind-clients samba-DC-winbind samba-DC-common-libs libpytalloc-devel
Next, proceed to configure Kerberos and receive a ticket. Open the krb5.conf file, go to the [libdefaults] section, and bring it to the following form:# vim /etc/krb5.confdns_lookup_kdc = true dns_lookup_realm = true default_realm = TEST.LOCAL
Request a ticket# kinit administrator Password for administrator@TEST.LOCAL:
Checking the list of received Kerberos tickets# klist Ticket cache: KEYRING:persistent:0:0 Default principal: administrator@TEST.LOCAL Valid starting Expires Service principal 16.05.2019 11:51:38 16.05.2019 21:51:38 krbtgt/TEST.LOCAL@TEST.LOCAL renew until 23.05.2019 11:51:35
Now delete or rename the existing samba config.# mv smb.conf smb.conf.bak1
Finally, we enter the second controller into the AD domain:# samba-tool domain join test.local DC -U"TEST\administrator"Successful entry will be followed by the following logFinding a writeable DC for domain 'test.local' Found DC DC1.TEST.LOCAL Password for [TEST\administrator]: Reconnecting to naming master e31d7da6-8f56-4420-8473-80f2b3a31338._msdcs.TEST. LOCAL DNS name of new naming master is DC1.TEST.LOCAL workgroup is TEST realm is TEST.LOCAL Adding CN=DC2,OU=Domain Controllers,DC=TEST,DC=LOCAL Adding CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC =TEST,DC=LOCAL Adding CN=NTDS Settings,CN=DC2,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN =Configuration,DC=TEST,DC=LOCAL Adding SPNs to CN=DC2,OU=Domain Controllers,DC=TEST,DC=LOCAL Setting account password for DC2$ Enabling account Calling bare provision Looking up IPv4 addresses Looking up IPv6 addresses No IPv6 address will be assigned Setting up share.ldb Setting up secrets.ldb Setting up the registry Setting up the privileges database Setting up idmap db Setting up SAM db Setting up sam.ldb partitions and settings Setting up sam.ldb rootDSE Pre-loading the Samba 4 and AD schema A Kerberos configuration suitable for Samba AD has been generated at /var/lib/sa mba/private/krb5.conf Provision OK for domain DN DC=TEST,DC=LOCAL Starting replication Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[402/1426] linked _values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[804/1426] linked _values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[1206/1426] linke d_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[1608/1426] linke d_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[1743/1426] linke d_values[0/0] Analyze and apply schema objects Partition[CN=Configuration,DC=TEST,DC=LOCAL] objects[402/2240] linked_values[0/ 24] Partition[CN=Configuration,DC=TEST,DC=LOCAL] objects[804/2240] linked_values[0/ 24] Partition[CN=Configuration,DC=TEST,DC=LOCAL] objects[1206/2240] linked_values[0 /24] Partition[CN=Configuration,DC=TEST,DC=LOCAL] objects[1608/2240] linked_values[0 /24] Partition[CN=Configuration,DC=TEST,DC=LOCAL] objects[1772/2240] linked_values[2 4/24] Replicating critical objects from the base DN of the domain Partition[DC=TEST,DC=LOCAL] objects[109/110] linked_values[26/29] Partition[DC=TEST,DC=LOCAL] objects[394/5008] linked_values[29/29] Done with always replicated NC (base, config, schema) Replicating DC=DomainDnsZones,DC=TEST,DC=LOCAL Partition[DC=DomainDnsZones,DC=TEST,DC=LOCAL] objects[42/42] linked_values[0/0] Replicating DC=ForestDnsZones,DC=TEST,DC=LOCAL Partition[DC=ForestDnsZones,DC=TEST,DC=LOCAL] objects[20/20] linked_values[0/0] Exop on[CN=RID Manager$,CN=System,DC=TEST,DC=LOCAL] objects[3] linked_values[0] Committing SAM database Adding 1 remote DNS records for DC2.TEST.LOCAL Adding DNS A record DC2.TEST.LOCAL for IPv4 IP: 192.168.90.201 Adding DNS CNAME record 6ff1df40-cbb5-41f0-b7b3-53a27dde8edf._msdcs.TEST.LOCAL for DC2.TEST.LOCAL All other DNS records (like _ldap SRV records) will be created samba_dnsupdate o n first startup Replicating new DNS records in DC=DomainDnsZones,DC=TEST,DC=LOCAL Partition[DC=DomainDnsZones,DC=TEST,DC=LOCAL] objects[1/42] linked_values[0/0] Replicating new DNS records in DC=ForestDnsZones,DC=TEST,DC=LOCAL Partition[DC=ForestDnsZones,DC=TEST,DC=LOCAL] objects[1/20] linked_values[0/0] Sending DsReplicaUpdateRefs for all the replicated partitions Setting isSynchronized and dsServiceName Setting up secrets database Joined domain TEST (SID S-1-5-21-3959064270-1572045903-2556826204) as a DC
A record about the new DC in the TEST.LOCAL domain should appear in the ADUC snap-in, and a new A record corresponding to DC2 should appear in the DNS manager. - Replication between controllers
First, let's check the operation of the Directory Replication Service (DRS)# samba-tool drs showreplAll replication attempts in output must be successful. In the list of KCC objects, within 15 minutes after entering, our DC1 on Windows should appearDefault-First-Site-Name\DC2 DSA Options: 0x00000001 DSA object GUID: 0e9f5bce-ff59-401e-bdbd-fc69df3fc6bf DSA invocationId: 017997b5-d718-41d7-a3f3-e57ab5151b5c ==== INBOUND NEIGHBORS ==== DC=ForestDnsZones,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:56:31 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:56:31 2019 MSK DC=DomainDnsZones,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:56:32 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:56:32 2019 MSK CN=Schema,CN=Configuration,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:56:32 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:56:32 2019 MSK DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:56:32 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:56:32 2019 MSK CN=Configuration,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:56:33 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:56:33 2019 MSK ==== OUTBOUND NEIGHBORS ==== DC=ForestDnsZones,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Thu May 23 16:40:03 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu May 23 16:40:03 2019 MSK DC=DomainDnsZones,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Thu May 23 16:40:03 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu May 23 16:40:03 2019 MSK CN=Schema,CN=Configuration,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Thu May 23 16:40:08 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu May 23 16:40:08 2019 MSK DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Thu May 23 16:40:08 2019 MSK was successful 0 consecutive failure(s). Last success @ Thu May 23 16:40:08 2019 MSK CN=Configuration,DC=test,DC=local Default-First-Site-Name\DC1 via RPC DSA object GUID: 60fb339d-efa3-4585-a42d-04974e6601b7 Last attempt @ Mon May 27 12:12:17 2019 MSK was successful 0 consecutive failure(s). Last success @ Mon May 27 12:12:17 2019 MSK ==== KCC CONNECTION OBJECTS ==== Connection -- Connection name: 6d2652b3-e723-4af7-a19f-1ee48915753c Enabled : TRUE Server DNS name : DC1.test.local Server DN name : CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=test,DC=local TransportType: RPC options: 0x00000001 Warning: No NC replicated for Connection!
The warning “No NC replicated for Connection!” Can be safely ignored. It appears due to the fact that when registering a new DC, samba incorrectly sets some replication flags.
Checking LDAP replication is also a good idea.# samba-tool ldapcmp ldap://dc1.test.local ldap://dc2.test.local -Uadministrator
The above command will compare the attribute values of the objects of the entire directory on DC1 and DC2.Successful Replication Example* Comparing [DOMAIN] context... * Objects to be compared: 249 * Result for [DOMAIN]: SUCCESS * Comparing [CONFIGURATION] context... * Objects to be compared: 1750 * Result for [CONFIGURATION]: SUCCESS * Comparing [SCHEMA] context... * Objects to be compared: 1739 * Result for [SCHEMA]: SUCCESS * Comparing [DNSDOMAIN] context... * Objects to be compared: 42 * Result for [DNSDOMAIN]: SUCCESS * Comparing [DNSFOREST] context... * Objects to be compared: 20 * Result for [DNSFOREST]: SUCCESS
In some cases, the attributes of objects on different controllers may differ, and the output of the command will let you know about it. But not in all cases this will be a sign of a replication problem.
The next step is to manually configure stable replication of the SysVol directory.
The fact is that samba does not yet support DFS-R, however, as it did not support the earlier FRS. Therefore, for replication between DC Samba and Windows, the only working solution today is one-way replication using the Robocopy utility from the Windows Server 2003 Resource Kit Tools .
Samba developers, in order to avoid compatibility problems, recommend first installing the utility kit on a regular workstation, and then copy Robocopy to the controller in the folder “C: \ Program Files (x86) \ Windows Resource Kits \ Tools \”
After installation, in the scheduler tasks on a Windows controller, we create a task to perform replication with the following parameters:
- Run for all users
- Run trigger Every 5 minutes every day for a day
- In the actions, specify the path to the robocopy utility, specify as arguments:\\DC1\SYSVOL\test.local\ \\DC2\SYSVOL\test.local\ /mir /sec
In a specific case, copy the contents of the SysVol directory from DC1 to DC2. - Portable user folders using the pam_mount configuration.
Experimentally, I found two viable options for solving this problem with its help.- Complete mounting of the profile folder from the network to the / home section
A simple option. It works fine if the folder names My Documents, Downloads, and Desktop are the same on both operating systems. It is understood that a Linux PC has already been entered into the domain and users are logged in under their domain accounts using sssd as the authentication and authorization mechanism.# vim /etc/security/pam_mount.conf.xml
Where:- uid = "100000000-2000000000" - the UID range assigned to domain users from SSSD
- server = "dfs" - file server name
- path = "Profile_Users /% (USER)" - a resource on the file server with the user profile hosted
- mountpoint = "~" - mount path to the user's home folder
The user's login is passed to the macro variable "% (USER)" used by pam_mount to connect our network resource, in the form in which it is entered in the display manager. Therefore, it is important that the DM login is entered without an explicit indication of the domain name.
In sssd.conf, this is solved by commenting, or by setting the False value to the use_fully_qualified_names option , which turns on full name mode (including domain) for users and groups. - The second method is less straightforward and clumsy, and in my opinion more convenient and preferred. The difference from the first only in the pam_mount configuration
# vim /etc/security/pam_mount.conf.xml
That is, we simply mount each of our folders separately in the corresponding directory
- Complete mounting of the profile folder from the network to the / home section
Conclusions
Over a half month of work on a test bench, this bunch successfully survived several alternating long-term and short-term shutdowns of both controllers, with practically no consequences for clients (once a client on Windows7 lost trust).
In general, I had a rather pleasant impression of working with this product, even despite all the nuances that I had to face both in the article and behind the scenes.
There are pitfalls, there are a lot of them, and in the course of work with samba they will have to be caught in large quantities. However, to date, there are no other solutions that allow you to organize a hybrid environment using directory services and without using Windows.