It didn't come to me at once that I had fallen into import substitution. Only when fresh shipments of PCs began to consistently arrive from the upper organization with the 'Alt Linux' distribution onboard, did I suspect something was amiss.
However, as I went through the stages of accepting the inevitable, I got drawn in and even began to enjoy the process a little. At some point, I thought that at this rate, sooner or later, I would have to part ways with Microsoft's directory service solutions and move toward something more exotic. Therefore, to prepare in advance for the inevitable and to catch as many hidden pitfalls as possible, it was decided to set up a test environment that includes:
- DC1 — Windows Server 2012R2
- DC2 — Alt Server 8.2
- File Server — Windows Server 2012R2
- PC1 — Windows 7
- PC2 — Alt Workstation 8.2
Objectives of the stand:
- Deploy a domain based on w2k12r2. Create a minimal set of group policies (similar to those used in the working infrastructure), including the policy for redirecting users' work folders (Downloads/Documents/Desktop). Ultimately, I want users to have comfortable access to their work documents when switching from Windows to Linux and back.
- Introducing Samba DC as a second controller. Checking replication of the directory service and DNS.
- Configuring Linux clients to work with redirected folders.
Implementation:
- Installing and introducing the new controller.Installing MS Windows 2012R2 is quite straightforward and more or less clear. There are countless manuals available online for deploying a domain on Windows, both using GUI and PowerShell tools, so I won't repeat that again; I'll just leave official documentation for the curious and those who want to refresh their memory.
However, there is one important point in this section. To date, Samba does not support directory schemas above 2008R2.
Spoiler Title In fact, this support is declared by developers as experimental. But in practice, attempting to introduce Samba as a second DC into an existing Windows domain with schema 69 will meet you with the following error:
DsAddEntry failed with status WERR_ACCESS_DENIED info (8567, ‘WERR_DS_INCOMPATIBLE_VERSION’)
The problem is that Windows 2012 and 2012R2 use WMI tools to work with domains and forests, stable support for which is only announced for Samba version 4.11, scheduled to be released by the end of this year.
This means the only option for integrating Samba into an AD domain deployed on a 2012R2 server is to downgrade the schema from 69 to 47. Naturally, this should not be done on a production infrastructure without good reason, but since we have a test environment here, why not.We install Alt Server 8.2. During the installation, we select the 'Samba-DC Server (AD Controller)' profile. On the deployed server, we perform a full system update and install the package task-samba-dc, which will pull in everything necessary.
# apt-get install task-samba-dcIf for some reason task-samba-dc, contrary to the assurances in Alt's documentation, doesn't install everything needed.
# apt-get install python-module-samba-DC samba-DC-common samba-DC-winbind-clients samba-DC-winbind samba-DC-common-libs libpytalloc-develNext, we move on to configuring Kerberos and obtaining a ticket. We open the krb5.conf file, go to the [libdefaults] section, and adjust it as follows:
# vim /etc/krb5.confdns_lookup_kdc = true dns_lookup_realm = true default_realm = TEST.LOCALWe request a ticket
# kinit administrator Password for administrator@TEST.LOCAL:We check 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:35Now we delete or rename the existing Samba config.
# mv smb.conf smb.conf.bak1And finally, we join the AD domain as a second controller:
# samba-tool domain join test.local DC -U"TESTadministrator"A successful join will be accompanied by the following log
Finding a writable DC for domain 'test.local' Found DC DC1.TEST.LOCAL Password for [TESTadministrator]: 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/samba/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] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[1608/1426] linked_values[0/0] Schema-DN[CN=Schema,CN=Configuration,DC=TEST,DC=LOCAL] objects[1743/1426] linked_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[24/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 on 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 DCThe ADUC tool should show an entry for the new DC in the TEST.LOCAL domain, and the DNS Manager should have a new A record corresponding to DC2.
- Replication between controllersFirst, let's check the functionality of the Directory Replication Service (DRS)
# samba-tool drs showreplAll replication attempts in the output should be successful. Within 15 minutes after entry, our DC1 on Windows should appear in the KCC object list.
Default-First-Site-NameDC2 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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-NameDC1 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!Warning «No NC replicated for Connection!» can be safely ignored. It occurs because when registering a new Samba DC, certain replication flags are incorrectly set.
It would also be wise to check LDAP replication.
# samba-tool ldapcmp ldap://dc1.test.local ldap://dc2.test.local -UadministratorThe command mentioned above will compare the attribute values of objects across the entire directory on DC1 and DC2.
Example of successful replication
* 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]: SUCCESSIn some cases, the attributes of objects on different controllers may differ, and the command output will indicate this. However, this is not always a sign of a replication issue.
The next step is to manually configure stable SysVol directory replication.
The fact is that Samba does not yet support DFS-R, just as it did not support the earlier FRS. Therefore, the only viable solution today for replication between Samba DC and Windows is one-way replication using the utility Robocopy from the set of .The Samba developers, to avoid compatibility issues, recommend first installing the utility kit on a regular workstation, and after that copying Robocopy to the controller in the folder "C:Program Files (x86)Windows Resource KitsTools"
After installation, create a task in the Task Scheduler on the Windows controller to execute replication with the following parameters:
— Run for all users
— Trigger to run Daily every 5 minutes throughout the day
— In the actions, specify the path to the robocopy utility, with the following arguments:DC1SYSVOLtest.local DC2SYSVOLtest.local /mir /secIn this specific case, we will copy the contents of the SysVol directory from DC1 to DC2.
- User folders transferred using the pam_mount configurationThrough trial and error, I identified two viable solutions to this task using it.
- Full mounting of the profile folder from the network to the /home directory. A simple option that works well if the folder names 'Documents', 'Downloads', and 'Desktop' match in both operating systems. It is assumed that the Linux PC is already joined to the domain, and users log in with their domain accounts using sssd as the authentication and authorization mechanism.
# vim /etc/security/pam_mount.conf.xml<volume uid="100000000-2000000000" fstype="cifs" server="dfs" path="Profile_Users/%(USER)" mountpoint="~" options="sec=krb5,cruid=%(USERUID),nounix,uid=%(USERUID),gid=%(USERGID),file_mode=0664,dir_mode=0775"/>where:
- uid="100000000-2000000000" — the UID range assigned to domain users by SSSD.
- server="dfs" — the name of the file server.
- path="Profile_Users/%(USER)" — the resource on the file server where the user profile is located.
- mountpoint="~" — the mount point in the user's home folder.
The user's login is passed to the macro variable «%(USER)», used by pam_mount to connect to our network resource, in the form it is entered in the display manager. Therefore, it is important that the login is entered in the DM without explicitly specifying the domain name.
In sssd.conf, this is resolved by commenting out or setting the value to False in the option use_fully_qualified_names, which enables the full names mode (including the domain) for users and groups.
- The second method is less straightforward and clumsy, and in my opinion more convenient and preferable. The difference from the first is only in the configuration of pam_mount.
# vim /etc/security/pam_mount.conf.xmlThat is, simply separately mounting each of our folders to its corresponding directory.
- Full mounting of the profile folder from the network to the /home directory. A simple option that works well if the folder names 'Documents', 'Downloads', and 'Desktop' match in both operating systems. It is assumed that the Linux PC is already joined to the domain, and users log in with their domain accounts using sssd as the authentication and authorization mechanism.
Conclusions
In half a month of operation on the test bench, this combination successfully survived several alternating long-term and short-term disconnections of both controllers, virtually without consequences for clients (once a client on Windows 7 lost trust relationships).
Overall, I have quite positive impressions from working with this product, despite all the nuances I encountered both in the article and behind the scenes.
There are many pitfalls, and you'll have to uncover them in large numbers while working with Samba. Nonetheless, as of today, there are no other solutions that allow for the organization of a hybrid environment using directory services without relying on Windows.
Source: habr.com
