May 2, 2012 at 17:36

Authentication of GNU / Linux file servers in an AD-based Windows domain. Part 1

    Samba Authentication in a Windows Domain



    1. Introduction. Overview of Existing Publications

    Recently, system administrators have been faced with the task of combining heterogeneous operating systems in the enterprise network. In particular, one of the problems is the use of GNU / Linux servers in conjunction with Windows workstations and servers of various versions.
    Typically, a small enterprise network includes about 20-30 workstations with the Windows 7 operating system, a domain controller based on Windows Server 2008 R2, a router, and several specialized servers. Further we will consider the inclusion of such GNU / Linux-based servers in the Windows Server 2008 R2 domain and the procedure for working with such servers.
    As a first task, consider organizing a Samba file server in a Windows Server 2008 R2 domain. The problem of creating file servers based on Samba has been the subject of many articles and publications in various forums. An example is the Samba documentation published on the project’s official website www.samba.org/samba/docs . Here are various materials from 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 released 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 about the work of Samba can be obtained on the websites of manufacturers of the main Linux distributions.
    It is worth noting the various copyright materials published in online and print publications; for example, an article by Alexander Farkhutdinov in the Linux Format magazine (http://wiki.linuxformat.ru/index.php/LXF123:Samba), a blog of experimental lovers (http://www.k-max.name/) and a number of articles on such well-known resources as www.opennet.ru and habrahabr.ru . Readers can verify this themselves by searching for the phrase “Include samba in a Windows domain” or “Include Linux in a Windows domain” and get tens and hundreds of thousands of links.
    The purpose of this article is not only to give specific recommendations on including 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 working in such a network and give recommendations on the organization of interaction of all its elements.

    2. Description of the test network, Windows domain

    To organize the test network, we will use the virtual environment VMware VSphere 5, implemented on the basis of the ESXi hypervisor architecture. However, one could use well-established 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 operating under running MS Windows Server 2008 R2 EE, and one client machine - MS Windows 7 Professional. IP addresses are used from the 192.168.7.0/24 subnet.



    The domain name is LAB.LOCAL. The domain controller is LAB-DC1.lab.local. Forefront Threat Management Gateway (TMG) 2010 server is LAB-TMG.lab.local Client is 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 the AD DS domain service is performed in accordance with the recommendations in the article technet.microsoft.com/en-us/library/dd378801 (v = ws.10) .aspx

    3. Authorization mechanisms in the Windows domain




    An extremely important part of the SMB protocol is authentication methods. Their inconsistency on the client and server sides causes a significant number of network access problems. There are four basic authentication methods in total.
    Source - wiki.linuxformat.ru/index.php/LXF123 : Samba Clear

    Text
    For obvious reasons, this authentication method is both the simplest 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 encrypted password parameter in the smb.conf file to false. This method was also used in clients for MS DOS 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. For this, it is necessary to set the value “Yes” of the “Send unencrypted password to third-party SMB servers” switch. Once again, we note: the use of this method is not justified today and is highly discouraged.

    Method LM (LAN manager)
    Used in Windows 95/98. Samba allows LM authentication by default. If you encounter problems with access to resources running Windows NT 4.0 and higher, 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”.

    The NTLM method
    appeared in Windows NT 3.5. Currently used in a slightly revised and improved form - NTLMv2. NTLMv2 operates on a “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 encrypted form. Only its hash is stored, but it is not transmitted over the network, 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 Service

    Kerberos 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 intranet traffic encryption. The Kerberos protocol offers a mechanism for mutual authentication of the client and 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 insecure environment, and the transmitted packets can be intercepted and modified. In other words, the protocol is ideally suited 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 devoted to the integration of the Samba server on Linux into the AD domain, which means that it is necessary 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 database of accounts. In addition, some user data comes into it from the global catalog (Global Catalog).
    KDC, like Active Directory, is in every domain. Both services are automatically started by the LSA (Local Security Authority) subsystem, 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 continued access to 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 KDC service of this domain can be accepted by any domain controller.
    The Key Distribution Service (KDC) is a single process that combines two services: the Authentication Service (AS) and the Ticket-Granting Service (TGS). In general terms, the process is as follows:
    Upon entering the network, the client accesses the authentication service of the domain where the user account is located, providing it with a username and password. In response, she gives the client a TGT ticket - Ticket-Granting Ticket, of course, if the username and password are correct. After that, TGS enters the game. This service issues tickets for access to other services in its domain or to the ticket issuing service of a trusted domain. To contact TGS, the customer must first get in touch with the ticket issuing service of the domain where the service account is located, submit their TGT ticket and request the ticket. If the client does not have a TGT ticket that provides 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,
    In many sources, tickets are called “tickets”, “receipts” and even “mandates”. But the meaning does not change from this - it is a “document” confirming the right to use the service.
    In a Windows environment, Kerberos policies are defined at the domain level and implemented by the KDC domain service. It is stored in the Active Directory as a subset of the domain security policy attributes. By default, Kerberos policy changes are restricted to members of the domain administrators group.
    The Kerberos policy provides for:
    Maximum user ticket lifetime. By “user ticket” here is meant a ticket issuing ticket (TGT ticket). The value is set in hours and defaults to 10 hours.
    Maximum time that a user ticket can be renewed. It is set in days; The 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 Maximum user ticket lifetime. By default, it is 10 hours.
    Maximum tolerance for synchronization of computer clocks. Indicated in minutes; defaults to 5 minutes.

    Checking restrictions at user login (Enforce user logon restrictions). If this item is checked, the KDC service analyzes each request for a session ticket and checks whether this user has the right to log on locally (Log on Locally privilege) or to access the requested computer through the network (Access this computer from network privilege). Such verification takes extra time and may slow down the provision of network services, therefore, the administrator is given the right to disable it. By default, it is enabled.
    Immediately worth mentioning are several pitfalls that you may encounter. 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 recognizes the client’s receipt as invalid and denies him access. In this case, on the client Windows machine, either the message “Access is denied” will be displayed immediately, or Windows will repeatedly ask for the login password without any visible result. Secondly, remember that four technologies are the foundation of Active Directory: DNS, LDAP, SMB, and Kerberos. All of them work as part of a domain, but each of them can be accessed as an independent service. Despite such independence of services, incorrect operation of at least one of them will make inclusion of the client in the domain impossible. Particular attention should be paid to the fact that if the DNS server, client name or domain name are incorrectly specified on the client side, 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 packages for GNU / Linux

    All of the packages mentioned below are required 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 pre-installed packages required for installation in accordance with the official documentation for OpenLDAP, Kerberos, and Samba.

    To build OpenLDAP, the following packages are required:

    • C compiler e.g. gcc (required)
    • Reentrant POSIX REGEX software (required)
    • Cyrus SASL 2.1.21+ (recommended)
    • OpenSSL 0.9.7+ (recommended)


    The necessary packages can be installed with the sudo apt-get install package_name command.
    Oracle Berkeley DB versions 4.4 - 4.8 or 5.0 - 5.1 are also required. We will talk about how to assemble it from the source a bit 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 a “yacc - command not found” error during the build. Then we 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 must have both OpenLDAP and Kerberos installed, in which case no additional packages will 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 pass to the most part - assembly of packages from source codes. Of course, building from source is not common practice for modern Linux distributions, and is more of a research interest. We will consider the assembly from the sources, since this process is, in general, universal for any Linux distribution. In the future, we will work with repositories, which is somewhat simpler.
    Building OpenLDAP
    First, from the Oracle site, download the Berkeley DB source files (hereinafter - 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. We
    compile and install BDB:
    	tar xvzf db-4.8.30.tar.gz
	cd db-4.8.30/build_unix
	../dist/configure #Если необходимы специфические параметры - /configure 	--help
	make
	sudo make install

    Download the OpenLDAP source code www.openldap.org/software/download
    In 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 #если необходимы некие особенные опции установки — ./configure --help
make depend
make
make test #на этом шаге проверяется OpenLDAP. Времени это занимает много, можно смело попить кофе.
make install


    That's all with OpenLDAP. In the end, I would like to mention some of the most common errors:
    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' isn't known You most likely forgot about the -D_GNU_SOURCE flag, which is necessary to bypass incompatibility with glibc.
    And again, carefully check all the necessary packages are installed on your system.
    Building Kerberos

    Download Kerberos web.mit.edu/kerberos/dist/index.html We used the current release.
    After that, unpack, assemble and install the program:

    t
    ar -xzvf  krb5-1.10.1.tar.gz
cd /krb5-1.10.1/src
./configure --with-ldap=yes #здесь, если необходимо, указываем опции. Какие — можно поинтересоваться командой ./configure —-help.
make
make install
make check #проверяем результат наших трудов.

    If you get the error "yacc - command not found", then you forgot to install the flex and bison packages.
    sudo apt-get install flex bison
    If "g ++ - command not found", then you forgot about the g ++ compiler.
    sudo apt-get install g++

    Build Samba
    Download Samba sources 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 performed correctly, the assembly and installation of Samba will work without problems. If not, first check if all dependencies are installed correctly. If Samba misses something, she will make that clear.
    Of course, the assembly of all packages from source is a laborious procedure with a 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.
    Tags:

    Also popular now: