HOWTO_Active_Directory

Introduction

This guide will give instructions on how to make a Gentoo Linux client authenticate with an existing Windows Active Directory server and auto-mount home directory using Samba/Winbind.

Requirements

This guide uses Microsoft Windows 2003 Server configured as a domain controller. Active Directory should already be implemented and working.

To use smbfs for mounts, you need to disable SMB signing (instructions follow).

Packages

samba - it is much preferred to use v. 3.0.23 or later, as the net command is revised and no longer required a password to join the domain.

openssl

openldap - needed for client ldap searches

cyrus-sasl - Simple Authentication and Security Layer - for basic encryption of ldap binds and searches

mit-krb5 - the MIT Kerberos

pam - the Pluggable Authentication Module base

pam_mount - makes automounting possible. Pam_mount is not in the official portage, get the ebuild from bugs.gentoo.org.

ntp - We will use the ntp-client for time synchronization (for proper Kerberos functioning)

There are versions 4 from KTH and 5 from MIT of the Kerberos client. The one we want is version 5. Samba needs specific flags turned on (may be already on if you're using a binary distro). See the Samba installation guide for meaning of various USE flags.

Enable the following USE flags:

# echo net-fs/samba ldap acl kerberos pam winbind >> /etc/portage/package.use
# echo net-nds/openldap sasl samba kerberos >> /etc/portage/package.use
# echo dev-libs/cyrus-sasl authdaemond -java kerberos pam ldap >> /etc/portage/package.use

Then emerge:

# emerge samba mit-krb5 pam_mount openldap openssl cyrus-sasl ntp -va

Note: This is known to cause circular-dependencies, here is a workaround.

Time service

Ntp is needed to keep computer clock in sync with the Windows Server.

# rc-update add ntp-client boot && rc

Example network configuration

Active Directory Server

Servername: win2003

DNS Name: win2003

FQDN: win2003.open.ad.local

Domain: open.ad.local

Pre 2000 Domain: open

AD Domain: DC=OPEN,DC=AD,DC=LOCAL

Server's IP address: 10.160.0.8

• If you plan to use SSL, also Enterprise Certification Authority would be handy (to issue certificates for SSL).

Certificate Server

You will need to install at least one Microsoft Enterprise Certificate Server and allow automatic computer enrollment for the domain, or at least the domain controller. Under Start > Control Panel > Add or Remove Programs > Add/Remove Windows Components:

1. Install the IIS Service
2. Install the CA Service

1. On the CA Type page, click Enterprise root CA, and then click Next.
2. On the CA Identifying Information page, in the Common name for this CA box, type the name of the server, and then click Next.
3. On the Certificate Database Settings page, accept the defaults in the Certificate database box and the Certificate database log box, and then click Next.
4. You will get a prompt to stop Internet Information Services, click Yes.
5. Enable Active Server Pages (ASPs), by clicking Yes.

Turning off SMB signing

There are three steps:

1. Disable SMB policies in the 'Default Domain Controller Policy".
2. Disable SMB policies in the 'Default Domain Policy'.
3. Apply the policies to the server and the workstations.

The four settings in each policy are:

• Microsoft Network server: Digitally sign communications (always) - Disable
• Microsoft Network server: Digitally sign communications (if client agrees) - Disable
• Microsoft Network client: Digitally sign communications (always) - Disable
• Microsoft Network client: Digitally sign communications (if server agrees) - Disable

Open Default Domain Controllers Policy from the Administrative tools. Right click on Local policies and expand security options. Change the policy by double-clicking on it. Once you have changed the settings in the 'Default Domain Controllers Policy' you must do this also for the 'Default Domain Policy'.

Once done, you either need to reboot the server twice, or push the policy application using 'gpudate /force /boot' and then reboot. Can check with "gpedit.msc" On Windows 2000 run "secedit /refreshpolicy machine_policy /enforce" and reboot.

Allowing Anonymous Searches in Active Directory

To enable anonymous searches on your Active Directory, follow these steps:

1. On your Windows 2000 Active Directory server, run the Active Directory Users and Groups administration tool.
2. Select the top level of the directory from the tree view in the left hand panel, and right click. A menu will appear. Select the first item, which should be "Delegate Control..."
3. Click "Next"
4. In the next window, titled "Users or Groups", click "Add ..."
5. In the next list, select "ANONYMOUS LOGON" and click "Add". You may also need to select "Everyone" and the "Guests" group, depending on how you have Active Directory configured. Click OK when this is done.
6. Click "Next"
7. Select "Create a custom task to delegate" and click "Next".
8. Click "Next"
9. In the next list, select "Read". "Read All Properties" will be selected at the same time. Click "Next" when this is done.
10. Click "Finish".

Winbind configuration

Kerberos

Kerberos is an authention method developed in the 80's at Massachusetts Institute of Technology (MIT), US. The preferred implementation is MIT version 5. In Windows Server 2003, Kerberos policy is defined in the Default Domain Group Policy object and implemented by the domain’s KDC. Basically Kerberos allows users and services to demonstrate their identity to each other.

The key innovation underlying Kerberos is the notion that the password can be viewed as a special case of a shared secret--something that the user and the service hold in common, and which (again ideally) only they know. Establishing identity shouldn't require the user to actually reveal that secret; there ought to be a way to prove that you know the secret without sending it over the network. In the simplest case, the user takes something like a timestamp, and encrypts it with the shared secret key. If the user used the wrong key, the timestamp won't decrypt properly, and the service can reject the user's authentication attempt.

After the user sends an authentication request to the server, the server sends the user a two-part message. One part contains the user's credentials, the latter message the ticket granting ticket (TGT). TGT is good only for a fairly short period, typically eight or ten hours.

See [1] for more basic information of Kerberos.

You may use this configuration file /etc/krb5.conf as the basis:

[libdefaults]
        default_realm = OPEN.AD.LOCAL
        ticket_lifetime = 36000
        clockskew = 300

[realms]
        OPENAD.LOCAL = {
        kdc = 192.168.0.30:88
        admin_server = 192.168.0.30:749
	default_domain = 192.168.0.30
        }

[domain_realm]
        .openad.local = OPEN.AD.LOCAL
        openad.local = OPEN.AD.LOCAL

[logging]
        kdc = FILE:/var/log/krb5kdc.log
        admin_server = FILE:/var/log/kadmin.log
        default = FILE:/var/log/krb5lib.log

Request a ticket to ensure you can contact the OPENAD realm:

$ kinit Administrator@OPENAD.LOCAL     <- YES, the case is IMPORTANT
Password for Administrator@OPENAD.LOCAL:

It will ask for the password as shown above; if you type in correctly; then you will be returned to the prompt which means it worked. See troubleshooting if you receive any errors.

You can check the active tickets with the klist command and destroy them with kdestroy.

$ klist
$ kdestroy

The tickets have a lifetime, usually less than a day. Within this time it is possible to use OpenLDAP or Winbind to get the records from the userbase. Each user issues a personal krb ticket before logging in.

Security & the certificate

Simple Authentication and Security Layer (SASL) is a standard that allows other protocols to use a wide range of extensible security mechanisms. SASL is security mechanism-independent. SASL-aware applications can use any security mechanism that is available on a specific platform and that has been complied into the SASL libraries. Cyrus-SASL is the layer between OpenLDAP and Kerberos.

During the bind phase, the client requests a specific security mechanism from SASL. OpenLDAP supports TLS and SSL. The client and server then use the SASL protocol to carry out any additional steps required by the agreed upon security mechanism.

The Start TLS operation establishes Transport Layer Security (the descendant of SSL) on the connection. It can provide data confidentiality protection (hide the data) and/or data integrity protection (protect from tampering). The START_TLS mechanism uses the standard ldap port (tcp/389) to negotiate using TLS after the connection has been initiated.

During TLS negotiation the server sends its X.509 certificate to prove its identity. The client may also send a certificate to prove its identity. After doing so, the client may then use SASL/EXTERNAL to have this identity used in determining the identity used in making LDAP authorization decisions.

Servers also often support the non-standard "LDAPS" ("Secure LDAP", commonly known as "LDAP over SSL") protocol on a separate port, by default 636. The LDAPS differs from LDAP in that it connects to a special port, ldaps (tcp/636). The client and server establish TLS before any LDAP messages are transferred (without a Start TLS operation). The LDAPS connection must be closed upon TLS closure.

Fetching the certificate

If you are running Microsoft Certificate Server on your Active Directory server, you can download the CA cert from http://win2003/certsrv/. You should save it on your hard drive and move it to the appropriate location:

$ chmod +644 adcert.pem
# mv adcert.pem /etc/ssl/certs/

If your Active Directory server doesn't have certificate from Verisign, Thawte, etc., then you will need to convert the CA Certificate to PEM format:

$ openssl x509 -in certnew.cer -inform DER -out /etc/ssl/certs/adcert.pem -outform PEM

OpenLDAP configuration files

Once we are able to authenticate, the next step is to get the user information from the AD server. OpenLDAP has two two configuration files- /etc/openldap/ldap.conf for the LDAP client libraries and tools. /etc/ldap.conf is used by the NSS and PAM and does not need to be configured.

LDAP client (/etc/openldap/ldap.conf)

First configure just the client side, so that use can use ldapsearch to test and debug basic connectivity.

URI     ldap://192.168.0.30
BASE    dc=open,dc=ad,dc=local
HOST    win2003

TLS_CACERT     /etc/ssl/certs/adcert.pem
TLS_REQCERT     never

The TLS_CACERT variable should point to the certificate you have obtained. TLS_REQCERT tells the client not to request the certificate since we have already installed it on the local client.

Testing the LDAP connection

Let's the check if the connection is working properly. Remember to always check out a valid Kerberos ticket.

$ kinit Administrator@OPEN.AD.LOCAL

Your friend here is ldapsearch. You may test different things if the communication works, whether you can establish a secure tunnel and your certificate is ok.

If the admin account is unavailable, you may try to search rootDSE, for which the anonymous operation should be permitted. By default, the Windows Server 2003 Active Directory does not allow anonymous operations on the LDAP directory.

$ ldapsearch -x -s base -b "" 

The Winbind daemon

We will ask Samba to use the user database in the Active Directory. An additional daemon will take care of that: winbindd. Winbind is a component of the Samba suite of programs that maps the users and groups that live inside the Active Directory to UID's and GID's on the linux machine. Winbind uses a UNIX implementation of Microsoft RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS) to allow Windows NT domain users to appear and operate as UNIX users on a UNIX machine.

The best part of using winbind is that you don't need to define the mapping yourself, you just need to specify a range of uid's and gid's. That's exactly what we did in the smb.conf file.

You need to edit the file /etc/nsswitch.conf. You need to change two lines to look like this (other lines removed to keep this short as possible):

passwd:      compat winbind
shadow:      compat
group:       compat winbind

We are performing various tests to ensure that AD can be seen. If a test fails, stop and go back to verify you've done every step correctly before continuing as you may make things worse by proceeding.

Let's reboot the Win2003 server if we can. Then the linux client. Boot both back up.

Let's now join the AD domain by typing in this command:

# net ads join -U Administrator
Administrator's password:
Using short domain name -- OPEN
Joined 'GENTOO.LINUX' to realm 'OPEN.AD.LOCAL'

To verify that the process worked, go to your Windows Server, open Active Directory Users And Computers, and look at the entries. You should see an entry in this list with the name of your Linux server.

Now you should be able to retrieve information from the Active Directory PDC with

$ net ads info
# net ads lookup
# net ads status

See if we can get some user information:

$ wbinfo -u              # See the users in Active Directory
$ wbinfo -g              # See the groups in Active Directory

We can now use the getent utility to get a unified list of both the local and PDC users and groups. These utilities will generate a list of data similar in format to the /etc/passwd and /etc/group files respectively.

You can leave the AD with

# net ads leave
Removed 'GENTOO.LINUX' from realm 'OPEN.AD.LOCAL'

PAM

There are several login files, their names are corresponding to the names of the programs, which are performing the user authentication. These files are located in the /etc/pam.d/ directory. The common configuration file /etc/pam.conf is ignored when these files exist.

system-auth

#%PAM-1.0

auth       required     pam_env.so
auth       sufficient   pam_unix.so try_first_pass likeauth nullok
auth       optional     pam_mount.so service=system-auth
auth       required     pam_group.so try_first_pass
auth       sufficient   pam_winbind.so try_first_pass
auth       required     pam_deny.so

account    sufficient   pam_winbind.so
account    required     pam_unix.so

password   required     pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3
password   sufficient   pam_unix.so try_first_pass use_authtok nullok md5 shadow
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0022 silent
session    optional     pam_mount.so use_first_pass service=system-auth

If the users home directory does not exist, the contents of /etc/skel/ will be copies as the base for the user's $HOME. You can pre-configure window managers, desktop environments, .bashrc, applications and so on this way.

pam_group

Logins validated by the Windows server won't correctly pickup membership in local groups, making sound, USB devices, etc. inaccessible. To fix that configure the pam_group module.

 * ; * ; * ; Al0000-2400 ; floppy, audio, cdrom, video, usb, plugdev, users

pam_mount

The next step is to mount various users' home directories into /home/DOMAIN/$user. It seems that you cannot mount a sub-directory under a share with Samba, so depending on your AD server-side directory structure and naming conventions, use the --bind option of mount to re-mount a sub-directory of the mounted share to the individual user's home folder.

This really isn't very elegant so that's why we need to call each share on the Win2003 server by the users name. This way we can call the users share with pam_mount when user logs in.

Here are the necessary config files:

debug 0
mkmountpoint 1
luserconf .pam_mount.conf
 
options_allow   nosuid,nodev
options_deny    suid,dev
options_require nosuid,nodev
 
lsof /usr/sbin/lsof %(MNTPT)
fsck /sbin/fsck -p %(FSCKLOOP)
cifsmount /bin/mount -t cifs //%(SERVER)/%(VOLUME) %(MNTPT) -S -o "user=%(USER)%(before=\",\" OPTIONS)"
smbmount /usr/bin/smbmount //%(SERVER)/%(VOLUME) %(MNTPT) -o "username=%(USER)%(before=\",\" OPTIONS)"
smbumount /usr/bin/smbumount %(MNTPT)
umount   /bin/umount %(MNTPT)
mntagain /bin/mount --bind %(PREVMNTPT) %(MNTPT) 

volume * cifs win2003 &       /home/OPENAD/&     user=&,uid=&,dir_mode=0700 - -
#volume * smbfs win2003 &       /home/OPENAD/&     uid=&,gid=&,dmask=0700,workgroup=OPENAD - -

login

#%PAM-1.0

auth       required	pam_securetty.so
auth       include	system-auth
auth       required	pam_tally.so file=/var/log/faillog onerr=succeed no_magic_root
auth       required	pam_shells.so
auth       required	pam_nologin.so

account    required	pam_access.so
account    include	system-auth
account    required	pam_tally.so deny=0 file=/var/log/faillog onerr=succeed no_magic_root

password   include	system-auth

session    include	system-auth
session    required	pam_env.so
session    optional	pam_lastlog.so
session    optional	pam_motd.so motd=/etc/motd
session    optional	pam_mail.so

# If you want to enable pam_console, uncomment the following line
# and read carefully README.pam_console in /usr/share/doc/pam*
#session    optional	pam_console.so

gdm

#%PAM-1.0
auth       required   pam_env.so
auth       required   pam_stack.so service=system-auth
auth       required   pam_nologin.so
account    required   pam_stack.so service=system-auth
password   required   pam_stack.so service=system-auth
session    required   pam_stack.so service=system-auth
session    optional   pam_console.so

kdm

For kdm no needs any changes.

Samba configuration

In order to access any files on the Windows server, you need to configure Samba. You can use this example samba configuration /etc/samba/smb.conf as a base to work on:

[global]
        workgroup = OPEN
        realm = OPEN.AD.LOCAL
        server string = Linux client
        interfaces = eth0, lo
        bind interfaces only = Yes
        wins server = open.ad.local
        password server = open.ad.local
        encrypt passwords = true
        security = ADS
        log level = 3
        log file = /var/log/samba3/log.%m
        max log size = 50
        client signing = Yes
        printcap name = cups
        preferred master = No
        domain master = No
        wins proxy = no
        dns proxy = No
        template homedir = /home/OPENAD/%U
        template shell = /bin/bash
        winbind separator = +
        winbind enum users = No
        winbind enum groups = No
        winbind use default domain = Yes
        printing = cups
        load printers = yes
        cups options = raw
        print command =
        lpq command = %p
        lprm command =
        os level = 20
        preferred master = no

Run testparm to see if your syntax is ok.

# testparm

On your Linux machine, you should be able to connect to Windows shares using Samba’s smbclient without a password (thanks to Kerberos). To test this, type

$ smbclient //win2003/share -k

smb: >

Environment preconfiguration

$HOME skeleton

Users can have a preconfigured $HOME from the local skeleton, if you include the right session line:

/etc/pam.d/common-session:session     required      /lib/security/pam_mkhomedir.so skel=/etc/skel/ silent

The contents of /etc/skel/ will be copies as the base for the user's $HOME. Set custom . (dot) files here. You can pre-configure window managers, desktop environments, .bashrc, applications and so on this way.

The Winbind daemon

We will ask Samba to use the user database in the Active Directory. An additional daemon will take care of that: winbindd. Winbind is a component of the Samba suite of programs that maps the users and groups that live inside the Active Directory to UID's and GID's on the linux machine. Winbind uses a UNIX implementation of Microsoft RPC calls, Pluggable Authentication Modules (PAMs), and the name service switch (NSS) to allow Windows NT domain users to appear and operate as UNIX users on a UNIX machine.

The best part of using winbind is that you don't need to define the mapping yourself, you just need to specify a range of uid's and gid's. That's exactly what we did in the smb.conf file.

You need to edit the file /etc/nsswitch.conf. You need to change two lines to look like this (other lines removed to keep this short as possible):

passwd:      compat winbind
shadow:      compat
group:       compat winbind

We are performing various tests to ensure that AD can be seen. If a test fails, stop and go back to verify you've done every step correctly before continuing as you may make things worse by proceeding.

Let's reboot the W2003 server if we can. Then the linux client. Boot both back up.

# /etc/init.d/samba start
# winbindd
$ ps fax | grep winbindd # check winbindd

You can also make winbindd run as two processes (which is faster; but for these purposes, let's run it as one). Winbindd runs in dual daemon mode by default.

Let's now join the AD domain by typing in this command:

# net ads join -U Administrator
Administrator's password:
Using short domain name -- OPENAD
Joined 'GENTOO.LINUX' to realm 'OPENAD.LOCAL'

To verify that the process worked, go to your Windows Server, open Active Directory Users And Computers, and look at the entries. You should see an entry in this list with the name of your Linux server.

Now you should be able to retrieve information from the Active Directory PDC with

$ net ads info
# net ads lookup
# net ads status

See if we can get some user information:

$ wbinfo -u              # See the users in Active Directory
$ wbinfo -g              # See the groups in Active Directory

Store your winbind credentials with

$ wbinfo --set-auth-user=OPENAD\\administrator%password

We can now use the getent utility to get a unified list of both the local and PDC users and groups. These utilities will generate a list of data similar in format to the /etc/passwd and /etc/group files respectively.

It is now a good idea to test to ensure your Active Directory usernames are valid on the system. Try the following:

$ touch testfile
$ chown "OPENAD+Guest" testfile

You can leave the AD with

# net ads leave
Removed 'GENTOO.LINUX' from realm 'OPENAD.LOCAL'

Winbind cheatsheet

 $ kinit Administrator@OPENAD.LOCAL     <- YES, the case is IMPORTANT
                          # Request a ticket to ensure you can see the AD domain

 $ wbinfo -u              # See the users in Active Directory
 $ wbinfo -g              # See the groups in Active Directory
 $ wbinfo –n <username>   # See the Active Directory SID for a particular named user

 $ wbinfo --set-auth-user=OPENAD\\administrator%password
                          # stores your winbind credentials 

 # List the derived UNIX GID values for Active Directory groups
 for gid in $(wbinfo -r <username>); \
 do SID=$(wbinfo -G $gid);GROUP=$(wbinfo -s $SID); echo $gid is $GROUP; done