Samba authentication in a Windows domain
1. Introduction. Review of existing publications
Recently, system administrators are faced with the task of uniting heterogeneous operating systems in an enterprise network. In particular, one of the problems is the use of GNU / Linux servers in conjunction with workstations and servers running Windows of different versions.
Typically, a small business network includes about 20-30 workstations running Windows 7, a domain controller based on Windows Server 2008 R2, a router and several specialized servers. Next, we will consider the inclusion of such servers based on GNU / Linux in the Windows Server 2008 R2 domain and the procedure for working with such servers.
As the first task, let's consider the organization of the Samba file server in the Windows Server 2008 R2 domain. The problem of creating file servers based on Samba is the subject of many articles and publications in various forums. As an example, the documentation on Samba, published on the official website of the project
www.samba.org/samba/docs . Here are a variety of materials, starting with the second edition of the famous book “Using Samba” written by Jay Ts, Robert Eckstein and David Collier-Brown and published by O'Reilly & Associates. The third edition of this book, which was published in 2007, is not yet available on the site. Of note is the excellent set of HOWTO guides and configuration examples presented on the site.
A considerable amount of additional information on the work of Samba can be obtained on the websites of manufacturers of major Linux distributions.
It is worth noting various author materials published in online and print publications; for example, the article by Alexander Farkhutdinov in the Linux Format magazine (http://wiki.linuxformat.ru/index.php/LXF123:Samba), the blog of the experiment lover (http://www.k-max.name/) and a number of articles on such well-known resources like
www.opennet.ru and
habrahabr.ru . Readers can see this for themselves by searching for the phrase “Enabling samba in the Windows domain” or “Enabling Linux in the Windows domain” and eventually receiving tens and hundreds of thousands of links.
The purpose of this article is not only to give specific recommendations on the inclusion of GNU / Linux servers in the Windows domain structure, but also to consider the operation of a test network that emulates a small enterprise network. We will try to consider most aspects of work in such a network and make recommendations on how to organize the interaction of all its elements.
2. Description of test network, Windows domain
To organize a test network, we will use the VMware VSphere 5 virtual environment, which is based on the ESXi hypervisor architecture. However, one could use the well-proven Microsoft Hyper-V, as well as any other similar solution.
The test environment is an Active Directory-based domain network (Active Directory Domain Services - AD DS), which consists of two infrastructure servers running MS Windows Server 2008 R2 EE and one client machine — MS Windows 7 Professional. IP addresses from subnet 192.168.7.0/24 are used
')

Domain Name - LAB.LOCAL Domain Controller - LAB-DC1.lab.local Forefront Threat Management Gateway (TMG) 2010 Server - LAB-TMG.lab.local Client - LAB-CL1 .lab.local
Roles installed on LAB-DC1
- Active Directory Certificate Services (AD CS)
- Active Directory Domain Services (AD DS)
- DHCP server (Scope name: LAB.LOCAL; Address pool: 192.168.7.20-192.168.7.70)
- DNS server (Type: AD-Integrated; Dynamic updates: Secure only)
- Web Services (IIS)
Note
Installation of AD DS Domain Service is performed in accordance with the recommendations set forth in the article technet.microsoft.com/en-us/library/dd378801 (v = ws.10) .aspx3. Windows Domain Authorization Mechanisms

An extremely important part of the SMB protocol are authentication methods. Their incompatibility on the client and server sides causes a significant number of network access problems. There are four basic authentication methods.
Source -
wiki.linuxformat.ru/index.php/LXF123 : Samba
Open textFor obvious reasons, this authentication method is both the easiest and most unreliable. This authentication was used by older versions of Samba. In the current version, the password is encrypted by default. To disable encryption, you must change the value of the encrypted password parameter in the smb.conf file to false. This method was also used in MS DOS clients as well as in older versions of Windows NT. Already in Windows 95 (and newer versions) to activate it, you must edit the registry. For Windows 2000 and above, it is possible to enable this authentication method through local security policies. To do this, set the value “Yes” of the “Send unencrypted password to third-party SMB servers” switch. Note once again: the use of this method today is not justified by anything and is highly discouraged.
LM method (LAN manager)Used in Windows 95/98. Samba defaults to LM authentication. If you experience problems with access to resources running Windows NT 4.0 and above, you need to adjust the local security policies on the Windows server — set the “LAN Manager authentication level” switch to “Send LM and NTLM responses”.
NTLM methodAppeared in Windows NT 3.5. Currently used in a slightly revised and improved form - NTLMv2. NTLMv2 works according to the "request-response" scheme. An interesting feature of this method is that the server does not store the password not only in the open, but also in the encrypted form. Only its hash is stored, but it is not transmitted over the network either, which is very good from a security point of view.
Windows 95/98 can work with NTLMv2 after installing the Directory Services client. Samba also supports this authentication method.
Using the Kerberos serviceKerberos is a powerful system that performs user authentication and authorization, which is used in the Active Directory (AD) domain as the main one. It also provides encryption for intranet traffic. The Kerberos protocol offers a mechanism for mutual authentication of the client and the server before establishing a connection between them, and the protocol takes into account the fact that the initial exchange of information between the client and the server occurs in an unprotected environment, and transmitted packets can be intercepted and modified. In other words, the protocol is ideal for use on the Internet and similar networks. Starting with the third version, Samba can be a full-fledged client of the Active Directory domain.
We will pay special attention to this method, since our article is dedicated to integrating a Samba server on Linux into an AD domain, which means you need to work with Kerberos.
In Windows Server 2008 R2, the Key Distribution Center (KDC) is implemented as a domain service. It uses Active Directory as the account database. In addition, some user data comes into it from the global catalog (Global Catalog).
The KDC, like the Active Directory directory service, is in every domain. Both services are automatically started by the LSA subsystem (Local Security Authority), which is installed on the domain controller. They work in the process space of this manager. None of these services can be stopped. To ensure constant access to the KDC and Active Directory, Windows provides the ability to deploy multiple peer domain controllers in each domain. At the same time, requests for authentication and ticket issuance addressed to the domain’s KDC service can be received by any domain controller.
The KDC (Key Distribution Service) is a single process that combines two services: the Authentication Service Authentication Service (AS) and the Ticket-Granting Service (TGS). In general terms, the process is as follows:
When entering the network, the client contacts the authentication service of the domain where the user account is located, providing her with a username and password. In response, the client issues a TGT ticket - Ticket-Granting Ticket, of course, if the login and password are correct. After this, the TGS comes into play. This service issues tickets for access to other services of your domain or to the service of issuing tickets to a trusted domain. To contact the TGS service, the customer first needs to get in touch with the ticket issuing service of the domain where the service account is located, submit their TGT ticket and request the right ticket. If the client does not have a TGT ticket that allows access to this ticket issuing service, he can use the referral process. The starting point of this process is the service of the domain where the user account is located, and the final point is the ticket issuing service of the domain where the account of the required service is located.
In many sources, tickets are called “tickets”, “receipts” and even “mandates”. But the meaning does not change; this is a “document” confirming the right to use the service.
In a Windows environment, Kerberos policy is defined at the domain level and is implemented by the KDC domain service. It is stored in the Active Directory as a subset of domain security policy attributes. By default, only members of the domain administrators group have the right to make changes to the Kerberos policy.
Kerberos policy provides for:
The maximum validity of the user ticket (Maximum user ticket lifetime). By “user ticket” here is meant a ticket issuance ticket (TGT ticket). The value is set in hours and the default is 10 hours.
The maximum time during which a user ticket can be renewed (Maximum lifetime that user ticket can be renewed). Set in a day; default is 7 days.
Maximum service ticket lifetime. By "service ticket" here is meant a session ticket. The value of this parameter must be more than 10 minutes, but less than the value of the Maximum user ticket lifetime. The default is 10 hours.
Maximum tolerance in computer clock synchronization (Maximum tolerance for synchronization of computer clocks). Indicated in minutes; default is 5 min.
Enforce user logon restrictions check. If this item is checked, the KDC service analyzes each request for a session ticket and checks whether the user has the right to log on locally (Log on Locally privilege) or access the requested computer through the network (Access this computer from network privilege). Such verification takes additional time and may slow down the provision of network services, so the administrator is entitled to disable it. By default, it is enabled.
Immediately it is worth mentioning several pitfalls that can be encountered. First of all, the discrepancy between the hours on the client and server side should be no more than a few minutes (by default, as mentioned above, no more than five), otherwise the server will recognize the client's receipt as invalid and deny it access. In this case, the message “Access denied” will be displayed on the client’s Windows machine immediately, or Windows will ask the login-password time after time without any visible result. Secondly, it should be remembered that the core of Active Directory is four technologies: DNS, LDAP, SMB, and Kerberos. All of them work within the domain, but each of them can be addressed as an independent service. Despite such independence of services, the incorrect work of at least one of them will make the inclusion of a client in the domain impossible. Special attention should be paid to the fact that if on the client side the DNS server, client name or domain name are incorrectly specified, then it will not be included in the AD domain. The reason for this is the fact that the DNS server in the Active Directory domain stores SRV records indicating the location of the KDC and LDAP servers.
4. Required GNU / Linux Packages
All the packages listed below are needed to deploy OpenLDAP, Kerberos and Samba on a server running Ubuntu Linux 10.04.4 LTS 64 with Xfce graphical shell. It also provides information on the required pre-installed packages for installation in accordance with the official documentation for OpenLDAP, Kerberos and Samba.
The following packages are required to build OpenLDAP:
- C compiler, for example gcc (required)
- Reentrant POSIX REGEX software (required)
- Cyrus SASL 2.1.21+ (recommended)
- OpenSSL 0.9.7+ (recommended)
Required packages can be installed with the command sudo apt-get install package_name.
Oracle Berkeley DB version 4.4 - 4.8 or 5.0 - 5.1 is also required. How to build it from source, we’ll tell you a little later when we talk about building OpenLDAP.
To build Kerberos, we need the flex and bison packages (sudo apt-get install flex bison), otherwise you will get the error “yacc - command not found” when building. Then we will need g ++ (sudo apt-get install g ++), because otherwise Kerberos will not build again, saying that “g ++ is command not found.”
By the time Samba is built, we should already have OpenLDAP and Kerberos installed, in which case installation of additional packages will not be required.
To install the gcc, g ++, flex, bison packages, you can use the package managers installed on your GNU / Linux distribution. Usually you just need to mark these packages during the initial installation of the system.
5. Build packages from source.
So, we proceed to the part itself - building packages from sources. Of course, building from source is not common practice for modern Linux distributions, and is more likely to be of research interest. We will consider the build from source, as this process is, in general, universal for any Linux distribution. In the future we will work with repositories, which is somewhat simpler.
OpenLDAP Build
First, from the Oracle site, download the Berkeley DB source files (hereinafter referred to as BDB) from the Oracle site.
www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html In our case, everything
worked out with BDB 4.8
Compile and install BDB:
tar xvzf db-4.8.30.tar.gz cd db-4.8.30/build_unix ../dist/configure
Download OpenLDAP source code
www.openldap.org/software/downloadIn our case, it was version 2.4.30.
Compile and install OpenLDAP:
tar -xzvf openldap-2.4.30.tgz cd openldap export CPPFLAGS="-I/usr/local/BerkeleyDB.4.8/include -D_GNU_SOURCE" export LDFLAGS="-L/usr/local/BerkeleyDB.4.8/lib" export LD_LIBRARY_PATH="/db-4.8.30.NC/build_unix/.libs/" ./configure --with-tls=no
That's all with OpenLDAP. Finally I would like to mention a few of the most common mistakes:
configure: error: Berkeley DB version mismatch Solution: most likely you did not export the LDFLAGS and LD_LIBRARY_PATH variables, as mentioned above.
getpeereid.c: 52: error: storage size of 'peercred' is not known You most likely forgot about the -D_GNU_SOURCE flag, which is needed to bypass incompatibility with glibc.
And once again carefully check all whether the necessary packages are installed on your system.
Kerberos build
Download Kerberos
web.mit.edu/kerberos/dist/index.html We used current release.
After that, unpack, build and install the program:
t
ar -xzvf krb5-1.10.1.tar.gz cd /krb5-1.10.1/src ./configure --with-ldap=yes
If you get the error “yacc - command not found”, it means that you forgot to install the flex and bison packages.
sudo apt-get install flex bison
If “g ++ - command not found”, then forgot about the g ++ compiler.
sudo apt-get install g++
Build samba
Download the Samba source from
www.samba.org/samba/download . We need the latest version, so download samba-latest.tar.gz.
Unzip, build and install Samba:
tar -xzvf samba-latest.tar.gz cd samba-3.6.3 cd source3 ./configure --with-ldap=yes --with-ads=yes make make install
Most likely, if all the previous steps were completed correctly, the assembly and installation of Samba will take place without problems. If not, first check if all the dependencies are installed correctly. If Samba misses something, it will make it very clear.
Of course, assembling all the packages from source texts is a time consuming procedure with low efficiency. Therefore, it is best to install the required packages using the package manager of your GNU / Linux distribution.
So, all the packages are installed and it's time to move on to the configuration.