From Gentoo Linux Wiki

It has been suggested that this article be split into multiple articles accessible from a disambiguation or index page.   (Discuss)

This work is published under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.

This guide will give instructions on how to add a Linux client into an existing Windows forest with open source utilities (on the Linux clients). The topology in this guide is assumed to be very simple, so in real life things may be a bit more complicated. However, the ingredients are discussed here.

The target of this guide is receive uid/gid information from the Active Directory and mount the Windows shares, so the Linux machine no longer is an 'island'.

[edit] Introduction

There are 2 ways to get authentication (uid/gid) data from Active Directory:

Kerberos + LDAP

Kerberos + Winbind from the Samba suite

Using LDAP is much cleaner, if the Windows server Schema can handle Unix users, which means that a schema change needs to be installed. Winbind is a bit more unreliable and slower. Therefore, if you have Active Directory it's recommended to use LDAP.

Regardless of Linux flavor, you'll work with the same elements:

• Kerberos: Winbind uses Kerberos to get tickets for accessing AD. A Windows domain controller acts as the Key Distribution Center (KDC).
• Name Service Switch (NSS): This is a set of capabilities built into the Linux C libraries that allow an application to select a source to validate authentication credentials.
• Pluggable Authentication Modules (PAM): This extends the standard Unix password authentication mechanism to include central authentication databases such as LDAP, Kerberos, AD and so on.
• Samba with/without Winbind: For AD interoperability, make sure your system is running a current version of Samba (3.05 or newer). Samba is required for network drive mounting. The winbind service uses Samba for configuration information. Samba 4 is supposed to be better just for this job. It's not yet released, see the release notes for smb4.0-tp2.

The figure below will give the outline of the communication in the forest.

http://us3.samba.org/samba/docs/man/Samba-Guide/images/chap9-ADSDC.png

Figure 1. Diagram of AD client/server communication.

Figure 2. -

• kerberos is missing.
• the connection isn't necessarily LDAPS:636, it can be LDAP, which is not less secure, but a standard. The LDAP:389 can handle a secure TLS tunnel.

[edit] Requirements

This guide uses Microsoft Windows 2003 Server R2 configured as a domain controller. Active Directory should already be implemented and working. If you need help, see the resources at the bottom. The following operating system components should be installed:

Group Management Policy

Server for NIS or Services for Unix or Identity Management for Unix

Windows Server 2003 Support Tools (download.microsoft.com)

Certificate server with IIS

Network monitor (optional)

Windows Server 2003 Resource Kit Tools (optional)

Windows script host for VBscripts

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

Packages

openldap - needed for client ldap searches

cyrus-sasl - Simple Authentication and Security Layer - for basic encryption of ldap binds and searches. You will also need cyrus-sasl-gssapi and libgssapi.

mit-krb5 - the MIT Kerberos

pam - the Pluggable Authentication Module base

pam_krb5 - kerberos pam module (note, that pam_ldap module will not be needed). There are some problems to emerge the 1.0 version, see other posts on these forums. It seems to have problems with password change, too.

pam_mount - makes automounting possible. Pam_mount was removed from official portage at one point but has been put back in.

nss_ldap - LDAP module for name switch system (enables redirection of searches for users, groups, etc. to ldap). Many distributions contain the libraries nss_ldap and pam_ldap. Unfortunately, they are sometimes not configured properly to work with Active Directory. It is necessary to configure nss_ldap with the options --enable-rfc2307bis and --enable-schema-mapping. On Gentoo you can check this with grep enable /var/db/pkg/sys-auth/nss_ldap-???/nss_ldap-???.ebuild In order to use sasl with nss_ldap you also have to make sure that you compile nss_ldap with --enable-configurable-krb5-ccname-gssapi. In the nss_ldap-254 version this is selected automatically by adding the kerberos use flag. If you don't do this, any non root user logging into your machine will get "GSSAPI Error: Miscellaneous failure (No credentials cache found)" in the error logs after logging in.

nscd - to get sudo working for ldap users

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

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 acl ldap 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 sasl >> /etc/portage/package.use

When pam_mount was not in official portage, you needed to add the sunrise overlay:

# layman -a sunrise

Then emerge:

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

• nscd is provided by current glibc versions such as as 2.5-r2

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-update add nscd boot
# rc

[edit] Ports

Table. Required TCP/UDP Ports for the Correct Operation of Kerberos 5.

[edit] Useful debugging tools

Ethereal or Wireshark - for tracing communication between your Linux machine and the AD Server

You should investigate packets to be sure that there are no unencrypted data relating to the LDAP information in the packets. You can also check if the LDAP bind is using the Kerberos authentication by looking at the packet containing the bind request. Expand the part named Lightweight Directory Access Protocol, Bind Request.

Luma - for accessing the AD through ldap and viewing information stored there.

strace - debugging utility, which intercepts and records the system calls called by a process and the signals which are received by a process. For example, to find out which files are opened during execution of the getent passwd command, you can use this command:

 # strace -e open getent passwd

[edit] Network configuration

This configuration is used thoroughout the document as an example.

MS Windows Server

Servername: win2003

AD Domain: DC=openad,DC=local

Users' OU: OU=Users,DC=openad,DC=local

DNS Name: win2003

Server's IP address: 192.168.0.30

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

Sample users

LDAP distinguished name: cn=aduser,ou=Users,dc=openad,dc=local

Linux client

Hostname: client21

IP address: 192.168.0.21

[edit] Windows server configuration

First of all, adsiedit.msc is your friend. If you dont have it installed already, it can be installed from your Windows CD-ROM\Support\Tools\SUPTOOLS.msi. You can use it to set attributes. Contact your Server sysadmin for more information.

Note that not all of these changes are required. For testing, you should at least have an active user with the correct set of attributes and an allocated share on the AD. The Windows server should also have Services for Unix or a similar extension to the schema installed.

For secure TLS communication also a Certificate Server should be configured an in use.

[edit] Schema Changes

When installing Windows 2003 Server R2 onto your domain controllers you should have already done a schema upgrade in that process. If you are not using R2 then you will need to download MicrosoftServices for Unix 3.5 (SFU). This document specifically focuses on the use of R2 not SFU. Most of the concepts are similar, but the NSS mapping of attributes will be different. These schema changes are used later on in this section to map Active Directory user attributes to UNIX attributes.

[edit] Object management

As is the case with any other authentication mechanism, we need to configure the user objects for the users that are to use the system. However, if you are implementing this solution, more than likely your users already have Windows accounts. In that case, all we need to do is to modify the objects to be POSIX compliant.

1. Open the Active Directory Users and Groups management tool.

a.) Modify a group object to function as a POSIX group.

b.) Right-click on the user group for assignment of a GID.

c.) Click on the Unix Attributes tab.

d.) Populate the NIS Domain dropdown and the GID number as appropriate.

2. Modify a user object to function as a POSIX user.

a.) Locate and activate the tab that says Unix Settings.

b.) Under Unix Settings, set the UID and GID for the user, as well as the home directory location (on the Linux filesystem /home/). Note: You will need to ensure that the directory exists with the appropriate user object having access to the directory.

c.) Reset the user's password. This causes the AD password and the Unix password attributes to synchronize.

3. Add the user as a Unix member of the group.

a.) After you have added the user as a Unix user, you will also need to come back to the group properties and add the user as a member on the Unix Attributes tab. Otherwise, the user will not be populated in the msSFU30PosixMember attribute.

4. This user should now be able to authenticate onto the Linux machine via any desired mechanism, including an SSH session.

One thing that can sometimes cause problems authenticating is to have the POSIX home directory be unavailable or not exist. Either you can create the directory manually, or you can run a script to collect the home directories and ensure that the directory exists.

[edit] Modifying existing user accounts

This batch lists all objects within the UNIT..

@Echo off

set UNIT="OU=Users,DC=openad,DC=local"

for /F "delims=!"  %%u in ('dsquery user %UNIT%') do echo %%u

This VBScript gets / sets the unix attributes for all users within one OU. It tries to set the uidNumber by the numbers it extracts from the user's cn attribute field. If it is not found, it uses the number set in freeUidNumber and increases the variable. The script has to be run separately for each OU. The script can easily be modified to suit your needs. This was written for actual deployment, and seemed to produce good results. For future accounts it is advisable to generate the attributes automatically when new accounts are created; that is beyond the scope of this document.

This script can be run from the Windows command line by calling it with cscript.exe.

> cscript mod_unix_attributes.vbs --set --unit staff --fake

' get/set unix attributes
' LGPL License
' This is free software; There is NO warranty; 
' not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE

' Set variables
domainBase = "DC=openad,DC=local"
unit = "OU=Users"
subUnitStaff = "OU=Staff"
msSFU30NisDomain = "openad"
loginShell = "/bin/bash"
homeDirBase="/home/OPENAD/"


Dim domainUsers
gidNumber = 20000
' first free uidNumber
freeUidNumber = 900
fake=0


' Parse command line parameters
Dim oArgs, ArgNum
Set oArgs = WScript.Arguments
ArgNum = 0
While ArgNum < oArgs.Count
 Select Case LCase(oArgs(ArgNum))
  Case "--get":
   ArgNum = ArgNum + 1   
   Operation = "get"
  Case "--set":
   ArgNum = ArgNum + 1
   Operation = "set"
  Case "--fake":
   ArgNum = ArgNum + 1
   fake = 1
  Case "--unit":
   ArgNum = ArgNum + 1
   if oArgs(Argnum) = "staff" Then
	   subUnit = subUnitStaff
   End if
   ArgNum = ArgNum + 1
'  Case "?","-h","/h:
'   Call DisplayHelp
 End Select 
Wend


main 


Function main

	WScript.Echo  subUnit & "," & unit & "," & domainBase 

	getUsersFromOU ( subUnit & "," & unit & "," & domainBase )

	If Operation = "set" Then
		setUserAttributes
	Elseif Operation = "get" Then
		getUserAttributes
	End If

End Function


Function setUserAttributes

	' this regexp extracts numbers from user's cn
	Set RegularExpressionObject = New RegExp
	With RegularExpressionObject
		.Pattern = "[a-z\-_\ ]"
		.IgnoreCase = True
		.Global = True
	End With

	' loop all users
	For Each userObject in domainUsers

		' get the kt-number
		ktNumber = userObject.cn
		uidNumber = RegularExpressionObject.Replace(ktNumber, "")

		' set free uidNumber, if kt-number isn't defined
		If len(uidNumber) < 4 Then
			uidNumber = freeUidNumber
			freeUidNumber = freeUidNumber + 1
		End If

		call setUnixAttributes _
			(userObject, uidNumber, gidNumber)

	Next
End Function


Function getUserAttributes
        For Each userObject in domainUsers
		call getUnixAttributes (userObject)
	Next
End Function


Function getUsersFromOU (objOU)
	Set domainUsers = GetObject("LDAP://" & objOU)
	domainUsers.Filter = Array("user")
End Function
getUserAttributes

Function setUnixAttributes ( userDN, uidNumber, gidNumber )
	unixHomeDirectory = homeDirBase & userDN.cn

	WScript.Echo uidNumber & ":" & gidNumber & ":" & _
	             userDN.displayName & ":" & unixHomeDirectory & ":" & _
		     loginShell & "  domain: " & msSFU30NisDomain

	userDN.Put "uidNumber", uidNumber
	userDN.Put "gidNumber", gidNumber
	userDN.Put "msSFU30NisDomain", msSFU30NisDomain
	userDN.Put "unixHomeDirectory", unixHomeDirectory
	userDN.Put "loginShell", loginShell
	If fake = "0" Then
		userDN.SetInfo
	End if
End Function


Function getUnixAttributes (userDN)
	WScript.Echo userDN.uidNumber & ":" & userDN.gidNumber & ":" & _
	             userDN.displayName & ":" & userDN.unixHomeDirectory & _
		     ":" & userDN.loginShell & "  domain: " & _
		     userDN.msSFU30NisDomain

End Function

[edit] Optional topics

Defining a share

Go to start-settings->control panel->administrative tools->domain controller security policies

Then local policies->security options->Microsoft Network Server: Digitally sign communications (always). Check Define this policy and select the Disabled radio button, then click apply then ok.

Create a folder c:/share and share it, call it "share" Create a normal user and assign his home folder under share.

Disable AD's world readable password hashes

On my brand new default install of Active Directory with SFU (I imagine this is for R2 as well) I noticed that the unix password hashes, the msSFU30Password or unixUserPassword attributes, are readable for all users by any authenticated user! Unacceptable. After much searching I discovered, via the adsiedit.msc tool, that these rights were being granted at the top level of the domain to the Pre-Windows 2000 Compatible Access group and inherited to the users. The quick and easy fix for me was to simply remove the only member of that group, the Authenticated Users group. After this the Default Security settings (view/change-able from the Active Directory Schema mmc snapin) for User objects only allowed Administrators, Account Operators, SYSTEM, and SELF to view them (as well as most other attributes). I figure this is good enough, since if you're admin account(s) are compromised you've got more to worry about than a rogue user being able to download all password hashes.

Another solution would be to modify the msSFU30Password/unixUserPassword attribute from adsiedit.msc and set the searchFlags attribute to 128. More info on this available here: [1] I haven't tested this one yet, but it seems to accomplish the same thing.

I don't think these problems exist for the unicodePwd attribute at all.

Changing the strong password policy

1. Click on Security Settings > Account Policies > Password Policy.
2. Right-click on Minimum password length in the right pane.
3. Click Properties from the context menu.
4. Do not remove the check from the Define this policy setting checkbox!
5. Enter a new minimum password length. Entering a Zero (0) will remove the password requirement.
6. Click the OK button.
7. Double-click on Passwords must meet complexity requirements in the right pane.
8. Do not remove the check from the Define this policy setting checkbox!
9. Select the Disabled option. (This will allow simpler passwords.)
10. Click the OK button.
11. Close the Default Domain Security Settings window.

Now, you need to put the new Password Policy into effect.

1. Click Start > Run... ; Type cmd into the Open: input box ; Click the OK button.
2. Type gpupdate /force

Configure the 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.

Creating a LDAP browser user

To create a user for browsing the Active Directory, you need first to create a standard user using the Active Directory Users and Computers MMC. Define User cannot change password and Password never expires.

After the user has been created, you need to set the UNIX attributes for the user. Give it the UID and GID 499, with home directory /dev/null and shell /bin/false.

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".

[edit] Linux client configuration

[edit] Kerberos clients

Kerberos is an authentication 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 [2] for more basic information of Kerberos.

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

[libdefaults]
        default_realm = OPENAD.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 = OPENAD.LOCAL
        openad.local = OPENAD.LOCAL

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

Verify that reverse DNS lookups work, otherwise krb won't work with realms that have several domain controllers.

$ dig openad.local +short
$ dig -x 192.168.0.30 +short     <- repeat for each ip listed by the above command

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.

[edit] Keytab: automatic ticket updating

Because the Kerberos ticket has a very short lifetime, and no one can login at the box from ldap without a valid system-wide ticket for LDAP (/tmp/krb5cc_0), we will create a cron job to update it. For this the password/encryption key has to be stored into the keytab where the cron job can read it.

Create a new user (for example krbcron_<client hostname>) for each Linux client in Active Directory. These Kerberos agents do not need any special attributes. Admit them the permissions to request Kerberos tickets and read the user attributes you need to map. You also need write access to the servicePrincipalName and userPrincipalName attributes, as well as change the password for the Kerberos agent. By default these attributes may not permitted to read/write. This user principal is then mapped to the particular client. It is not tolerable to create Kerberos Service Principal with the same name in more user accounts. In such case, Kerberos would not be able to authenticate it correctly.

Install the Support Tools package that has the ktpass utility. Save this small batch script (mapkeytab.bat) to your PATH on the Windows server.

@echo off

:: %1 is the username
:: %2 is the hostname
:: %3 is the realm

REM change the '*' character to the real password in case you want to loop this.
REM else you will be prompted for the password.

ktpass -princ nssldap/%2@%3 -mapuser %1@%3 -pass * -out %2.keytab

Test with one client, execute the script:

mapkeytab.bat krbcron_client21 client21 OPENAD.LOCAL

It should output something like this:

Targeting domain controller: openad.local
Successfully mapped nssldap/krbcron_client21 to krbcron.
Type the password for nssldap/krbcron_client21:
Type the password again to confirm:
Key created.
Output keytab to krbcron_keytab:
Keytab version: 0x502
keysize 55 nssldap/krbcron_client21@OPENAD.LOCAL ptype 1 (KRB5_NT_PRINCIPAL) vno 5 etype
0x3 (DES-CBC-MD5) keylength 8 (0xba1308b93ed97a54)
Account krbcron has been set for DES-only encryption.

For several clients at once:

for %a in (21,22,23,24) do mapktpass krbcron_client%a OPENAD.LOCAL

Copy the files through some secure medium to the Linux box. If your keytab is empty, just rename the file:

mv krbcron_client21.keytab /etc/krb5.keytab
chmod 644 /etc/krb5.keytab ; chown root /etc/krb5.keytab

Or use the command ktutil as follows:

# ktutil
ktutil:  rkt krbcron_client21.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------
   1    3 nssldap/krbcron_client21@OPENAD.LOCAL
ktutil:  wkt /etc/krb5.keytab
ktutil:  q

Create an init script to refresh the Kerberos TGT for the LDAP. After the execution, /tmp/krb5cc_0 will be updated.

TODO! Meanwhile, use this command:

# /usr/bin/kinit -k nssldap/krbcron_$HOSTNAME -c /tmp/krb5cc_0

# rc-update add krb5cron default

Set up your crontab to refresh your local service ticket cache every 10 hours using the keytab. Use the master ticket cache /tmp/krb5cc_0 so that the pam modules use the correct ticket. Later we will use another location for user tickets.

0 */10 * * * /etc/init.d/krb5cron

Note that this applies to any sort of unattended programs that you wish to run, not just cron. Of course, you have to evaluate whether or not this is acceptable to you; if the machine where you store this principal is compromised, then this principal is compromised.

[edit] 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). LDAP is a standard, and not less secure given that a secure TLS tunnel is used. 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://192.168.0.30/certsrv/. If Firefox does not work with the ASP Scripts, you may try to use Konqueror to download the certificate on the Linux client. 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

[edit] 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 (or /etc/libnss-ldap.conf) is used by the NSS and PAM.

[edit] 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=openad,dc=local
HOST    win2003 # This may need to be win2003.openad.local

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 if you don't run the cron job.

$ kinit Administrator@OPENAD.LOCAL

Your friends here are ldapsearch and s_client. 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 "" 

With a user account you should first try that the queries are working without SASL or TSL. Use the -W switch, or put your password into /etc/ldap.secret for a while (remember to remove it).

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -x -D "cn=Administrator,cn=Users,dc=openad,dc=local" -y /etc/ldap.secret

or try:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -x -D "Administrator@openad.local" -W

If successful, you should receive an output describing the Active Directory LDAP description. If you cannot perform simple top level searches on your Active Directory, then you should locate and fix any problems.

If you receive GSSAPI errors, you may need to examine the reverse DNS settings or add some lines to your /etc/hosts. Invalid name errors are caused by a problem with the reverse DNS of the AD server. Generic errors can be caused by an invalid DNS of the client computer. Below is a sample /etc/hosts file - the order of records is important:

 127.0.0.1       localhost.localdomain    localhost
 192.168.0.31    ad_client.openad.local   ad_client
 192.168.0.30    ad_server.openad.local 

Once that works try with SASL but without TSL:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -Omaxssf=0

Notice the '-Omaxssf=0' which should disable SASL security layers. This is also a feature with Active Directory: large queries with SASL will fail because Active Directory is not using the negotiated buffer size correctly. You can try this by omitting the switch and performing a large query. Ldapsearch should respond with, depending on the version and whether you are using TLS/SSL, "ldap_result: Can't contact LDAP server" or "ldap_sasl_interactive_bind_s: Inappropriate authentication".

You may also receive these errors (among others):

No credentials cache found: check (klist) that you have a valid TGT.

GSSAPI Error: An invalid name was supplied: add the server to /etc/hosts.

Cannot determine realm for numeric host address: check that reverse DNS works

If you use SSL, you can use the openssl s_client:

$ s_client -connect openad.local:636 -CAfile /etc/ssl/certs/adcert.pem

Finally, try with both SASL and TSL:

$ ldapsearch -Hldap://192.168.0.30 -b "" -s base -Omaxssf=0 -ZZ

If you get:

certificate verify failed. check your certificate status requirements.

[edit] Name Service Switch Module (/etc/ldap.conf)

Now as the LDAP client is working, you should move on to configuring the Name Service Switch module (nss_ldap). The are two configuration steps here: first one is rather easy- just add the keyword ldap to passwd, shadow, group in /etc/nsswitch.conf. Depending on your requirements, you may need to search other information from ldap as well, but this is sufficient for user accounts.

passwd:         compat ldap [notfound=continue]
shadow:         compat ldap [notfound=continue]
group:          compat ldap [notfound=continue]

The nss_ldap module contains the real magic, and can be configured in many different ways depending on your requirements. This configuration example is written to use SASL+TLS security layers and obtain users from the AD that have attributes set by the Server for NIS extension.

Let's first examine the connection section of this file. Stay away from spaces, LDAP doesn't like them.

### debug
#debug 256
#logdir /var/log/

### connection
uri             ldap://openad.local
port            389
#base            ou=users,dc=openad,dc=local
scope           one 
timelimit       30

### Reconnect policy:
bind_policy     soft # you may not be able to boot if you set this to hard
#binddn         cn=Administrator,dc=openad,dc=local

### Encryption (SASL+TLS)
use_sasl        on
sasl            start_tls
SASL_MECH       GSSAPI 
# Disable SASL security layers. This is needed for AD.
sasl_secprops   maxssf=0

tls_cacertfile  /etc/ssl/certs/adcert.pem
tls_checkpeer   no
tls_ciphers     TLSv1

krb5_ccname     FILE:/tmp/krb5cc_0

Base is used to define where in Active Directory to start looking for objects. This is good if you want to limit the ability of only certain users contained within a certain set of OUs to have the ability to login to a Linux workstation, or if you have a huge LDAP, less information is carried over the network.

The scope attribute confines the search to the base, one level below, or to search through all lower levels. This is done by entering the word base, one, or sub.

Binddn is not needed with SASL, but left here for posterity. Without a secure communication, a bind user is required in order to query the LDAP contents. This account is just a domain user with read access. The password for this user should be written to /etc/ldap.secret and should not be world-readable.

Attribute mapping

Next you will need to map some nss attributes, as the local unix LDAP attributes differ from what the attributes are called at the Windows server. The unix attribute names vary slightly on different version of the SFU packages, so these may not work out-of-the-box. You need to either have a print of your test users' attributes, or have access to one of the domain controllers, preferably with permissions to modify the attribute values.

The config file is continued with attribute bindings:

### NSS attributes
nss_schema              rfc2307bis

nss_base_passwd         ou=users,dc=openad,dc=local?one
nss_base_shadow         ou=users,dc=openad,dc=local?one
nss_base_group          ou=groups,dc=openad,dc=local?sub

nss_map_objectclass     posixAccount       User		
nss_map_objectclass     shadowAccount      User		
nss_map_objectclass     posixGroup         group		

nss_map_attribute       uid                sAMAccountName
nss_map_attribute       uidNumber          uidNumber
nss_map_attribute       gidNumber          gidNumber
nss_map_attribute       uniqueMember       member
nss_map_attribute       givenname          givenName
nss_map_attribute       ou                 description
nss_map_attribute       gecos              displayName
nss_map_attribute       homeDirectory      unixHomeDirectory
nss_map_attribute       loginShell         loginShell	
nss_map_attribute       shadowLastChange   pwdLastSet

The nss_base_passwd, nss_base_shadow, and nss_base_group will all need to be changed to suit your enviroment. In general, you can just use the value of the base variable. If your Active Directory authenticates for a sub-domain, you will need to adjust accordingly.

The userPassword line is not necessary when pam_password is set to ad. In this case, the pam_ldap module controls the management of password functions using the Active Directory password stored in the unicodePwd attribute. This will be covered later.

More information of the AD attributes that can be mapped, for various purposes, are found at [3] and [4].

Now getent should enumerate all user accounts and groups within the files, and then append all Active Directory accounts that have the correct UNIX attributes.

$ getent passwd aduser
aduser:*:10002:10000:test user:/home/OPENAD/aduser:/bin/bash

You can get the full attribute list for a user with ldapsearch:

$ ldapsearch -b "ou=users,dc=openad,dc=local" -s one "(cn=aduser)"

[edit] PAM

[edit] LDAP Attributes ( /etc/ldap.conf )

In order to make PAM_LDAP talk to Active Directory, you must map a few more Unix attributes to their equivalent Active Directory names. The configuration file is the same as for the NSS module, so it may be called /etc/libnss-ldap.conf on other distros than Gentoo.

### PAM attributes
pam_login_attribute     sAMAccountName
pam_filter              objectclass=User 
pam_password            ad
pam_member_attribute    uniquemember
pam_groupdn             OU=Groups,DC=openad,DC=local?sub
#pam_lookup_policy       nocal

# Template login attribute, default template user
# (can be overriden by value of former attribute
# in user's entry)
#pam_login_attribute userPrincipalName
#pam_template_login_attribute uid
#pam_template_login nobody

Pam_login_attribute defines what username the user will use to logon with. To ensure consistency with Active Directory and Services for UNIX, you use the sAMAccountName attribute. Pam_filter allows us to filter out just user accounts so that we are not trying to authenticate users against other Active Directory objects. Lastly, pam_password which allows us to define the password to be for Active Directory. This must be set to ad, otherwise issues may arise when you attempt to change your password from the Linux workstation.

[edit] Groups

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, burning, users

[edit] Login files

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.

You may configure everything by plain /etc/pam.d/login file, but that may mess up how other modules do their work. More common way to accomplish this is to make login to use the common-* files. Do not copy these files as-is, although it may work. Merge the necessary lines into your working setup, and adjust as needed. Pam_mount is already introduced here, and it requires it has been setup properly. See section 4: network shares.

Note that when you make changes to /etc/pam.d/login, you have to wait for a while (15 seconds or so) for the login manager to notice the changes. Knowing this will help you a lot if you make changes. :)

# The PAM configuration file for the Shadow `login' service

auth       requisite  pam_securetty.so
auth       requisite  pam_nologin.so
session    required   pam_env.so readenv=1

@include common-auth
@include common-account
@include common-session

session    required   pam_limits.so
session    optional   pam_lastlog.so
session    optional   pam_motd.so

@include common-password

# /etc/pam.d/common-auth - authentication settings common to all services

auth        required     /lib/security/pam_mount.so
auth        required     /lib/security/pam_group.so use_first_pass
auth        sufficient   /lib/security/pam_krb5.so use_first_pass ignore_root
auth        sufficient   /lib/security/pam_ldap.so use_first_pass
auth        required     /lib/security/pam_unix.so try_first_pass shadow likeauth nullok

# /etc/pam.d/common-account - authorization settings common to all services

account     sufficient   /lib/security/pam_krb5.so ignore_root
account     sufficient   /lib/security/pam_ldap.so
account     required     /lib/security/pam_unix.so

# /etc/pam.d/common-session - session-related modules common to all services

session     required      /lib/security/pam_mkhomedir.so umask=0000 skel=/etc/skel.savonia/ silent
session     optional      /lib/security/pam_mount.so shadow md5 use_authtok
session     optional      /lib/security/pam_krb5.so

# /etc/pam.d/common-password - password-related modules common to all services

password    optional     /lib/security/pam_krb5.so
password    required     /lib/security/pam_mount.so use_authtok shadow md5
password    required     /lib/security/pam_ldap.so use_authtok md5
password    required     /lib/security/pam_unix.so nullok md5 shadow use_authtok
password    required     /lib/security/pam_deny.so

The 'sufficient' control token, when successful, permits access, even if the authentication from a previous 'required' module in the stack failed. The try_first_pass parameter is instructing the pam module that the password supplied to the previous pam module should be tried first. This way the user will not be invoked another prompt asking for the password. To debug the pam modules, you can also add the debug parameter, which will cause logging of the debug messages into /var/log/auth.log.

The PAM docs say that "use_first_pass is used to lock the choice of old and new passwords to that dictated by the previously stacked password module," and that "use_authtok is used to force the module to set the new password to the one provided by the previously stacked password module." So use_authtok is designed to have the module use the new password but request the old one directly from the user. The reason for this option is that it is convenient when you use a password strength checking module like pam_cracklib.

• required is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
• requisite is equivalent to [success=ok new_authtok_reqd=ok ignore=ignore default=die]
• sufficient is equivalent to [success=done new_authtok_reqd=done default=ignore]
• optional is equivalent to [success=ok new_authtok_reqd=ok default=ignore]

Now go to the console and login with an AD username. If it doesn't work immediately, wait for a minute or two. Pam_login should mount your AD directory automagically.

client21 login: aduser
password:
You must be a msSFU30PosixMember of cn=Users,dc=openad,dc=local to login.
login(pam_unix)[14441]: session opened for user aduser by (uid=0)
pam_mount: realpath of volume "/home/OPENAD/aduser" is "/home/OPENAD/aduser"
login[14441]: pam_mount: realpath of volume "/home/OPENAD/aduser" is "/home/OPENAD/aduser"

pmvarrun: parsed count value 0
aduser@client21 ~ $ df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/hda3              8372704   4653376   3294008  59% /
udev                    256772       160    256612   1% /dev
shm                     256772         0    256772   0% /dev/shm
//win2003/aduser      15358136   5383352   9974784  36% /home/OPENAD/aduser

[edit] Sudo & nscd

To enable ldap users easy access to sudo, the sudoers table needs to contain the user group (LinuxUsers) in the AD. Sudo reads the entries from Name Service Cache Daemon (NSCD) that sits between the applications using name services and the mechanisms providing those name services. It caches name service data and improves response times.

Without NSCD, an application makes a call to one of the standard libc function calls: getxxnam(), getxxuid(), getxxent(), and getxbyy(). NSS then dynamically loads the correct module for the name service mechanism specified in /etc/nsswitch.conf. With NSCD, the application still makes the same call, but now the corresponding libc function actually calls NSCD through an Inter-Process Communication (IPC) call. If NSCD has cached the data required by the application, it returns it; otherwise, it calls the NSS module in the usual way.

Turn nscd on and put it to your chosen runlevel, after you have obtained the Kerberos ticket. The default configuration is ok, although for a large LDAP you may want to raise the passwd database size to a few megabytes.

Then edit sudoers as you see fit:

# visudo

# /etc/sudoers
# This file MUST be edited with the 'visudo' command as root.

Cmnd_Alias BASIC = /bin/echo, /bin/sh

# Defaults
Defaults        !lecture,tty_tickets,!fqdn,insults

# User privilege specification
root    ALL=(ALL) ALL

# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
%operator ALL=NOPASSWD: BASIC \
              PASSWD: ALL
%LinuxUsers ALL=NOPASSWD: BASIC

[edit] Joining the domain

This is quite simple, if you have configured Samba properly. You can use this example samba configuration /etc/samba/smb.conf as a base to work on:

[global]
        workgroup = OPENAD
        realm = OPENAD.LOCAL
        server string = Linux client
        interfaces = eth0, lo
        bind interfaces only = Yes
        wins server = openad.local
        password server = openad.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

Since Samba version 3.0.23, there is no need to enter the administrator password. The net command can do a whole lot of things, but this is sufficient to join the domain:

# net ads join

[edit] Network shares

[edit] Mounting network shares with Samba

In order to access any files on the Windows server, you need to configure Samba. Use the configuration presented in previous chapter to work on.

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: >

To virtually mount a windows share to a point on your samba server is not so simple. That's why this process is presented here in the form of a walkthrough, errors and all. By default, Windows servers (2003 at least) uses SMB signing, which is not resolved by the Samba folk in the 3.0 version. (4.0 is in the makes, preview was published a while ago - it could be in that version but it won't be out for the public before 2007 anyways).

# mkdir /mnt/win2003
# smbmount //win2003/c$ /mnt/win2003/
cli_negprot: SMB signing is mandatory and we have disabled it.
32453: protocol negotiation failed
SMB connection failed

CIFS as an alternative that works:

# user=Administrator; 
# mount -t cifs //win2003/share /mnt/win2003/ -o username=$user,uid=$user,dir_mode=0700

Without SMB signing

In case CIFS doesn't work and you control the server we'll disable SMB signing. This is a Group Policy in Windows Server and the instructions are given up there where the other Windows configuration tasks are mentioned. So let's turn those options off at the server (in case you don't control your server, try out CIFS). Then mounting should be possible:

# user=Administrator; 
# mount -t smbfs //win2003/share /mnt/win2003/ -o username=$user,uid=$user,gid=$user,dmask=0700
# ls /mnt/win2003

[edit] $HOME automounting

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 - -

Modify your login files.

[edit] Environment preconfiguration

[edit] $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 copied as the base for the user's $HOME. Set custom files here. You can pre-configure window managers, desktop environments, .bashrc, applications and so on this way.

[edit] Running scripts at logon

As users may login via the console or X, different files are evaluated during those processes. It is not convenient to put lengthy scripts, or scripts that should be only run once, in .bashrc. It could be that the user doesn't even open up a bash session. If you use GDM, you may consider putting the call for your scripts at /etc/gdm/Xsession. For console logins, you may use some minor logic to tell whether the script should be run. For instance,

# count how many sessions the user has
logins_atm="$(grep -Eo $(whoami) <<< $(users) | wc -l)"
login_tty="$(last -1 | grep -Eo 'tty')"


# if there is only one session, and this is a tty login, 
# and we're not starting up screen, run the script
if  [ $logins_atm -eq 1 ] && \
        [ "$login_tty" ] && \
        [ "$TERM" != "screen" ]; then

        login-script.sh 
fi

[edit] Evolution email client

As Evolution-2.6.0 doesn't have an LDAP backend, the user account have to be set with separate tools. Evolution uses the ~/.gconf/apps/evolution directory to store this data. I suggest using evolution-gconf-tools to do this job. The version 0.2.0 supports LDAP searches. The author of this article has made changes to this package, and the changes haven't been accepted upstream yet (the original author hasn't responded to my emails).

TODO: link for the package.

Simply edit /etc/gconf/evolution-gconf-tools/configure and run evolution-gconf-setup-user.

[edit] Troubleshooting

If you've gotten this far and everything works, your Linux client is now a fully-fledged member of your Active Directory domain, and can be managed like any other AD object. A nice bonus is you may have local Linux accounts on the Samba box that are not visible in Active Directory; which means your Linux admins can SSH directly into the client for admin chores, and not have to fuss with AD roadblocks.

This chapter tries to tackle with common problems that may appear during the configuration phase.

On a Red Hat system, PAM_LDAP is part of the NSS_LDAP RPM. PAM_LDAP by default uses the same configuration file (/etc/ldap.conf), so all of the nss_ldap changes work also for pam_ldap

Note that PAM_LDAP is only used for authentication, whereas NSS_LDAP is used for all user information. A user can still log on to a Linux system without NSS_LDAP working, although they will get frequent messages saying "I have no name!". If this is happening to you, then it is possible that you have PAM_LDAP working correctly but NSS_LDAP broken.

On some recent Debian systems, PAM_LDAP and NSS_LDAP have different configuration files. I am not entirely convinced of the wisdom of this, but it could be useful in certain situations, and for debugging purposes. If you are on such a system, it would be wise to locate all files containing the name "ldap.conf" on your system and work out which of these belong to PAM_LDAP and which belong to NSS_LDAP.

Note that to be able to change passwords on an Active Directory server from Linux, you need to have SSL and TLS enabled, both at the client end and at the server end. Enabling SSL and TLS on an LDAP client is covered in the SecurityFocus article, Linux Authentication Using OpenLDAP, Part One.

Read the info in here for more things you can do with other authentication with AD.

A good troubleshooting guide is chapter 9 of "Samba-3 by Example" (Adding UNIX/LINUX Servers and Clients). Also refer to chapter 12 (Identity Mapping) of "The Official Samba-3 HOWTO and Reference Guide" to learn about winbind in greater depth.

First of all, check that the Linux and Windows computers have the same clock time. They must be 5 minutes apart, at most. Run ntp-client and use the domain-server as the time server.

See [5] for a list of Kerberos error messages. Some errors you might encounter:

kinit(v5): Preauthentication failed while getting initial credentials

Solution: Might just fix after you wait for a few minutes. :)

Solution: Make sure that the Kerberos Ticket on the Windows Server was created with the correct mapping and service.

kinit(v5): Cannot resolve network address for KDC in requested realm while getting initial credentials

Solution: Check /etc/krb5.conf.

KDC has no support for encryption type

Solution: Try resetting the Administrator password in Active Directory as it's possible AD has not generated DES keys for the Administrator principal (reference: http://lists.samba.org/archive/samba-technical/2003-July/030726.html)

SMB signing

# mount -t smbfs -o username=Administrator //win2003/c\$ /mnt/samba/
cli_negprot: SMB signing is mandatory and we have disabled it.
17352: protocol negotiation failed
SMB connection failed

Solution: Like mentioned above, smbfs *is not* compatible with SMB signing, and therefore cannot be used with win2k3 DCs in their default mode. Use mount -t cifs.

samba/secrets

$ net ads join
Failed to open /var/lib/samba/secrets.tdb

Solution: sudo chmod 777 /var/lib/samba/secrets.tdb

READERS NOTE: The above solution seems like an unnecessary compromise in security. Try running "net ads join" as root. (A root prompt would end in a '#' and not a '$' as above!)

authtok errors from pam_mount

Solution: This is because you have a sufficient line in one of the PAM files within /etc/pam.d and pam_mount.so can not be used after a sufficient line. This error isn't fatal and is skipped. You'll probably notice it if you su and then su again (it's because of the pam_rootok.so line within /etc/pam.d/su)

id: cannot find name for user ID 1001

This is because your Active Directory cannot be searched anonymously. There are two solutions for this problem:

1. . Enable anonymous searches on your Active Directory
2. . Insert an administrator DN and password into /etc/ldap.conf

GSSAPI Error: No credentials cache found

This might occur after successful login, after ldappasswd. Solution: This means you are doing a SASL bind to the server, and you have no K5 ticket to authenticate you with for GSSAPI. Request a ticket.

GSSAPI Error: Cannot start kerberos signing/sealing when using TLS/SSL

SASL/GSSAPI already encrypts the LDAP traffic, this error is trying to say TLS/SSL is redundant.

[edit] TODO

Please finish this section if you find the HOWTO helpful.

[edit] Windows printers

See [6]

[edit] Mounting a Linux share

The /etc/smb.conf file in our case, sets up the home directory as a share. To mount my home directory from a Windows machine on the DC03 domain, I do this:

   * Log onto the Windows machine as user "fredrick".
   * Select Run from the start menu and enter "\\acdsmb-doctor\fredrick". 

Everything worked. I was not prompted for a password when connecting to the Samba share. This is because the initial authentication to the domain granted the Windows machine a ticket which is then used for subsequent share connections on the domain including those with Samba environments that have been joined to the domain.

[edit] Resources

[edit] Internal

• HOWTO Add a gentoo server to a windows network

[edit] Official Samba docs

• http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/domain-member.html#domain-member-server
• http://us1.samba.org/samba/docs/man/Samba-HOWTO-Collection/winbind.html
• - The samba/ADS HOWTO
• - Helpful info for winbind

[edit] Windows Server

• Windows Server 2003 Setup Guide
• Change the strong password policy
• Group policy management extension

[edit] Information on the www

• Active Directory authentication for Linux - an excellent tutorial to LDAP-based authentication
• Active Directory and nss_ldap for Linux - quite helpful
• elkabong's blog - Linspire Client Configuration Files
• Active Directory and Linux - AD4Unix + LDAP
• How to integrate Samba into Active Directory - forums.gentoo.org
• Configuring Unix to use Active Directory - from an MKS AD4Unix Schema extension point-of-view
• Setup Linux to authenticate against a Samba server - pam configuration
• Authorization with LDAP - a short article
• linux client/Active Directory server home directories A thread with people solving other people's problems
• Unite your Linux and Active Directory autfag.com/columns/article.asp?EditorialsID=858 Linux-Windows Single Sign-On - at Redmond, US
• http://www.intraperson.com/autodir.html
• Join Samba 3 to Your Active Directory Domain

[edit] Helpful software

• http://sadms.sourceforge.net/ - sadms doesn't work with Gentoo :(
• Samba4 release notes

[edit] Original article

The original author (winbind section), James Young

See the original HOWTO

New York’s Techguy

[7]