Storing Samba's User/Machine Account information in an LDAP Directory

Purpose

This document describes how to use an LDAP directory for storing Samba user +account information normally stored in the smbpasswd(5) file. It is +assumed that the reader already has a basic understanding of LDAP concepts +and has a working directory server already installed. For more information +on LDAP architectures and Directories, please refer to the following sites.

OpenLDAP - http://www.openldap.org/
iPlanet Directory Server - http://iplanet.netscape.com/directory

Note that O'Reilly Publishing is working on +a guide to LDAP for System Administrators which has a planned release date of +early summer, 2002.

It may also be helpful to suppplement the reading of the HOWTO with +the Samba-PDC-LDAP-HOWTO +maintained by Ignacio Coupeau.

Introduction

Traditionally, when configuring "encrypt +passwords = yes" in Samba's smb.conf file, user account +information such as username, LM/NT password hashes, password change times, and account +flags have been stored in the smbpasswd(5) file. There are several +disadvantages to this approach for sites with very large numbers of users (counted +in the thousands).

The first is that all lookups must be performed sequentially. Given that +there are approximately two lookups per domain logon (one for a normal +session connection such as when mapping a network drive or printer), this +is non-optimal. What is needed is an indexed approach such as is used in +databases.

The second problem is that administrators which desired to replicate an +smbpasswd file to more than one Samba server were left to use external +tools such as rsync(1) and ssh(1) +and write custom, in-house scripts.

And finally, the amount of information which is stored in an +smbpasswd entry leaves no room for additional attributes such as +a home directory, password expiration time, or even a Relative +Identified (RID).

As a result of these defeciencies, a more robust means of storing user attributes +used by smbd was developed. The API which defines access to user accounts +is referred to as the samdb interface (previously this was called the passdb +API, and is still so named in the CVS trees). In Samba 2.2.3, enabling support +for a samdb backend (e.g. --with-ldapsam or +--with-tdbsam) requires compile time support.

When compiling Samba to include the --with-ldapsam autoconf +option, smbd (and associated tools) will store and lookup user accounts in +an LDAP directory. In reality, this is very easy to understand. If you are +comfortable with using an smbpasswd file, simply replace "smbpasswd" with +"LDAP directory" in all the documentation.

There are a few points to stress about what the --with-ldapsam +does not provide. The LDAP support referred to in the this documentat does not +include:

A means of retrieving user account information from + an Windows 2000 Active Directory server.
A means of replacing /etc/passwd.

The second item can be accomplished by using LDAP NSS and PAM modules. LGPL +versions of these libraries can be obtained from PADL Software +(http://www.padl.com/). However, +the details of configuring these packages i beyond the scope of this document.

Supported LDAP Servers

The LDAP samdb code in 2.2.3 has been developed and tested using the OpenLDAP +2.0 server and client libraries. The same code should be able to work with +Netscape's Directory Server and client SDK. However, due to lack of testing +so far, there are bounds to be compile errors and bugs. These should not be +hard to fix. If you are so inclined, please be sure to forward all pacthes to +samba-patches@samba.org and +jerry@samba.org.

Schema and Relationship to the RFC 2307 posixAccount

Samba 2.2.3 includes the necessary schema file for OpenLDAP 2.0 in +examples/LDAP/samba.schema. (Note that this schema +file has been modified since the experimental support initially included +in 2.2.2). The sambaAccount objectclass is given here:

objectclass ( 1.3.1.5.1.4.1.7165.2.2.2 NAME 'sambaAccount' SUP top STRUCTURAL
+     DESC 'Samba Account'
+     MUST ( uid $ rid )
+     MAY  ( cn $ lmPassword $ ntPassword $ pwdLastSet $ logonTime $
+            logoffTime $ kickoffTime $ pwdCanChange $ pwdMustChange $ acctFlags $
+            displayName $ smbHome $ homeDrive $ scriptPath $ profilePath $
+            description $ userWorkstations $ primaryGroupID ))

The samba.schema file has been formatted for OpenLDAP 2.0. The OID's are +owned by the Samba Team and as such as legal to be openly published. +If you translate the schema to be used with Netscape DS, please +submit the modified schema file as a patch to jerry@samba.org

Just as the smbpasswd file is mean to store information which supplements a +user's /etc/passwd entry, so is the sambaAccount object +meant to supplement the UNIX user account information. A sambaAccount is a +STRUCTURAL objectclass so it can be stored individually +in the directory. However, there are several fields (e.g. uid) which overlap +with the posixAccount objectclass outlined in RFC2307. This is by design.

In order to store all user account information (UNIX and Samba) in the directory, +it is necessary to use the sambaAccount and posixAccount objectclasses in +combination. However, smbd will still obtain the user's UNIX account +information via the standard C library calls (e.g. getpwnam(), et. al.). +This means that the Samba server must also have the LDAP NSS library installed +and functioning correctly. This division of information mkes it posible to +store all Samba account information in LDAP, but still maintain UNIX account +information in NIS while the network is transitioning to a full LDAP infratrsucture.

To include support for the sambaAccount object in an OpenLDAP directory +server, first copy the samba.schema file to slapd's configuration directory.

root# cp samba.schema /etc/openldap/schema/

Next, include the samba.schema file in slapd.conf. +The sambaAccount object contains two attributes which depend upon other schema +files. The 'uid' attribute is defined in cosine.schema and +the 'displayName' attribute is defined in the inetorgperson.schema +file. Bother of these must be included before the samba.schema file.

## /etc/openldap/slapd.conf
+
+## schema files (core.schema is required by default)
+include	           /etc/openldap/schema/core.schema
+
+## needed for sambaAccount
+include            /etc/openldap/schema/cosine.schema
+include            /etc/openldap/schema/inetorgperson.schema
+include            /etc/openldap/schema/samba.schema
+
+## uncomment this line if you want to support the RFC2307 (NIS) schema
+## include         /etc/openldap/schema/nis.schema
+
+....

smb.conf LDAP parameters

The following parameters are available in smb.conf only with --with-ldapsam +was included with compiling Samba.

ldap ssl
ldap server
ldap admin dn
ldap suffix
ldap filter
ldap port

These are described in the smb.conf(5) man +page and so will not be repeated here. However, a sample smb.conf file for +use with an LDAP directory could appear as

## /usr/local/samba/lib/smb.conf
+[global]
+     security = user
+     encrypt passwords = yes
+
+     netbios name = TASHTEGO
+     workgroup = NARNIA
+
+     # ldap related parameters
+
+     # define the DN to use when binding to the directory servers
+     # The password for this DN is not stored in smb.conf.  Rather it
+     # must be set by using 'smbpasswd -w secretpw' to store the
+     # passphrase in the secrets.tdb file.  If the "ldap admin dn" values
+     # changes, this password will need to be reset.
+     ldap admin dn = "cn=Manager,dc=samba,dc=org"
+
+     #  specify the LDAP server's hostname (defaults to locahost)
+     ldap server = ahab.samba.org
+
+     # Define the SSL option when connecting to the directory
+     # ('off', 'start tls', or 'on' (default))
+     ldap ssl = start tls
+
+     # define the port to use in the LDAP session (defaults to 636 when
+     # "ldap ssl = on")
+     ldap port = 389
+
+     # specify the base DN to use when searching the directory
+     ldap suffix = "ou=people,dc=samba,dc=org"
+
+     # generally the default ldap search filter is ok
+     # ldap filter = "(&(uid=%u)(objectclass=sambaAccount))"

Security and sambaAccount

There are two important points to remember when discussing the security +of sambaAccount entries in the directory.

Never retrieve the lmPassword or + ntPassword attribute values over and unencrypted LDAP session.
Never allow non-admin users to + view the lmPassword or ntPassword attribute values.

These password hashes are clear text equivalents and can be used to impersonate +the user without deriving the original clear text strings.

To remedy the first security issue, the "ldap ssl" smb.conf parameter defaults +to require an encrypted session (ldap ssl = on) using +the default port of 636 +when contacting the directory server. When using an OpenLDAP 2.0 server, it +is possible to use the use the StartTLS LDAP extended operation in the place of +LDAPS. In either case, you are strongly discouraged to disable this security +(ldap ssl = off).

The second security precaution is to prevent non-administrative users from +harvesting password hashes from the directory. This can be done using the +following ACL in slapd.conf:

## allow users to update their own password, but not to browse others
+access to attrs=userPassword,lmPassword,ntPassword
+     by self write
+     by * auth

You may of course, add in write access to administrative DN's as necessary.

There are currently four sambaAccount attributes which map directly onto +smb.conf parameters.

smbHome -> "logon home"
profilePath -> "logon path"
homeDrive -> "logon drive"
scriptPath -> "logon script"

First of all, these parameters are only used when Samba is acting as a +PDC or a domain (refer to the Samba-PDC-HOWTO +for details on how to configure Samba as a Primary Domain Controller). +Furthermore, these attributes are only stored with the sambaAccount entry if +the values are non-default values. For example, assume TASHTEGO has now been +configured as a PDC and that logon home = \\%L\%u was defined in +its smb.conf file. Assuming smb.conf +also contains , when a user named "becky" logons to the domain, the logon +home string is expanded to \\TASHTEGO\becky.

If the smbHome attribute exists in the entry "uid=becky,ou=people,dc=samba,dc=org", +this value is used. However, if this attribute does not exist, then the value +of the logon home parameter is used in its place. Samba +will only write the attribute value to the directory entry is the value is +something other than the default (e.g. \\MOBY\becky).

Example LDIF Entries for a sambaAccount

The following is a working LDIF with the inclusion of the posixAccount objectclass:

dn: uid=guest2, ou=people,dc=plainjoe,dc=org
+ntPassword: 878D8014606CDA29677A44EFA1353FC7
+pwdMustChange: 2147483647
+primaryGroupID: 1201
+lmPassword: 552902031BEDE9EFAAD3B435B51404EE
+pwdLastSet: 1010179124
+logonTime: 0
+objectClass: sambaAccount
+uid: guest2
+kickoffTime: 2147483647
+acctFlags: [UX         ]
+logoffTime: 2147483647
+rid: 19006
+pwdCanChange: 0

The following is an LDIF entry for using both the sambaAccount and +posixAccount objectclasses:

dn: uid=gcarter, ou=people,dc=plainjoe,dc=org
+logonTime: 0
+displayName: Gerald Carter
+lmPassword: 552902031BEDE9EFAAD3B435B51404EE
+primaryGroupID: 1201
+objectClass: posixAccount
+objectClass: sambaAccount
+acctFlags: [UX         ]
+userPassword: {crypt}BpM2ej8Rkzogo
+uid: gcarter
+uidNumber: 9000
+cn: Gerald Carter
+loginShell: /bin/bash
+logoffTime: 2147483647
+gidNumber: 100
+kickoffTime: 2147483647
+pwdLastSet: 1010179230
+rid: 19000
+homeDirectory: /home/tashtego/gcarter
+pwdCanChange: 0
+pwdMustChange: 2147483647
+ntPassword: 878D8014606CDA29677A44EFA1353FC7

Comments

Please mail all comments regarding this HOWTO to jerry@samba.org. This documents was +last updated to reflect the Samba 2.2.3 release.