HOWTO Setup Samba as PDC with LDAP Backend

From RADION OpenLab

This Howto explains how to set up and use an Linux Departemental Server with Samba an OpenLDAP to replace an existing Microsoft Windows Domain Controler servers and provide central authentication services, file and print sharing for Microsoft Windows and Unix clients.

Contents

[edit]

1 Daily Admin stuff

Overview of Samba Policy Controls

NT4 policy Name

Samba Policy Name

NT4 Range

Samba Range

Samba Default

Maximum Password Age

maximum password age

0 - 999 (days)

0 - 4294967295 (sec)

4294967295

Minimum Password Age

minimum password age

0 - 999 (days)

0 - 4294967295 (sec)

0

Mimimum Password Length

min password length

1 - 14 (Chars)

0 - 4294967295 (Chars)

5

Password Uniqueness

password history

0 - 23 (#)

0 - 4294967295 (#)

0

Account Lockout - Reset count after

reset count minutes

1 - 99998 (min)

0 - 4294967295 (min)

30

Lockout after bad logon attempts

bad lockout attempt

0 - 998 (#)

0 - 4294967295 (#)

0

*** Not Known ***

disconnect time

TBA

0 - 4294967295

0

Lockout Duration

lockout duration

1 - 99998 (min)

0 - 4294967295 (min)

30

Users must log on in order to change password

user must logon to change password

0/1

0 - 4294967295

0

*** Registry Setting ***

refuse machine password change

0/1

0 - 4294967295

0


Overview of SAMBA account control flags:

FlagDescription
DAccount is disabled.
HA home directory is required.
IAn inter-domain trust account.
LAccount has been auto-locked.
MAn MNS (Microsoft network service) logon account.
NPassword not required.
SA server trust account.
TTemporary duplicate account entry.
UA normal user account.
WA workstation trust account.
XPassword does not expire.


get current user status:

$ pdbedit -r -u username


unlock autolocked account:

$ pdbedit -c [-L] -u testuser


set numbber of failod login attempts to lockout user:

$ pdbedit -P 'bad lockout attempt' -C 5

Never expire a password for a certain user:

$ pdbedit -c [X] -u testuser


An example of use of the pdbedit utility to set the account control flag is shown here: 

$ pdbedit -r -c "[DLX]" username
Unix username:        jht
NT username:          jht
Account Flags:        [DHULX      ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Rhe flags can be reset to the default settings by executing: 

$ pdbedit -r -c "[]" jht
Unix username:        jht
NT username:          jht
Account Flags:        [U          ]
User SID:             S-1-5-21-729263-4123605-1186429-3000
Primary Group SID:    S-1-5-21-729263-4123605-1186429-513
Full Name:            John H Terpstra,Utah Office
Home Directory:       \\aurora\jht
HomeDir Drive:        H:
Logon Script:         scripts\logon.bat
Profile Path:         \\aurora\profiles\jht
Domain:               MIDEARTH
Account desc:         BluntObject
Workstations:
Logon time:           0
Logoff time:          Mon, 18 Jan 2038 20:14:07 GMT
Kickoff time:         0
Password last set:    Sun, 03 Jul 2005 23:19:18 GMT
Password can change:  Sun, 03 Jul 2005 23:19:18 GMT
Password must change: Mon, 18 Jan 2038 20:14:07 GMT
Last bad password   : 0
Bad password count  : 0
Logon hours         : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

Domain Account Policy Managment

To view the domain account access policies that may be configured execute: 

$ pdbedit -P ?
No account policy by that name
Account policy names are :
min password length
password history
user must logon to change password
maximum password age
minimum password age
lockout duration
reset count minutes
bad lockout attempt
disconnect time
refuse machine password change

Commands will be executed to establish controls for our domain as follows:

  1. min password length = 8 characters.

  2. password history = last 4 passwords.

  3. maximum password age = 90 days.

  4. minimum password age = 7 days.

  5. bad lockout attempt = 8 bad logon attempts.

  6. lockout duration = forever, account must be manually reenabled.

The following command execution will achieve these settings: 

$ pdbedit -P "min password length" -C 8
account policy value for min password length was 5
account policy value for min password length is now 8
$ pdbedit -P "password history" -C 4
account policy value for password history was 0
account policy value for password history is now 4
$ pdbedit -P "maximum password age" -C 7776000
account policy value for maximum password age was 4294967295
account policy value for maximum password age is now 7776000
$ pdbedit -P "minimum password age" -C 7
account policy value for minimum password age was 0
account policy value for minimum password age is now 7
$ pdbedit -P "bad lockout attempt" -C 8
account policy value for bad lockout attempt was 0
account policy value for bad lockout attempt is now 8
$ pdbedit -P "lockout duration" -C -1
account policy value for lockout duration was 30
account policy value for lockout duration is now 4294967295

Note:

To set the maximum (infinite) lockout time use the value of -1.

[edit]

2 Introduction


This smbldap-tools aims on helping to use Open Source softwares Linux, Samba and OpenLDAP to replace existing Microsoft Windows Domain Controler servers. It explains how to set up and use a Linux Departemental Server with Samba and OpenLDAP to offer central authentication (Domain Controler), file and print sharing for Microsoft Windows and Unix clients.


[edit]

2.1 Softwares used

This howto currently runs for:

  • release 3.0.11rc1 of Samba,
  • Microsoft Windows, Microsoft Windows NT 4.0, Windows 2000 and Windows XP Workstations and Servers,
  • Linux RedHat 9 (should work on any Linux distribution anyway <A NAME="text1" HREF="#note1">1</A>),
  • release 2.1.22 of OpenLDAP (should work anyway on any other releases of OpenLDAP, and any implementation of LDAP servers like iPlanet Directory for example).


[edit]

2.2 Updates of this document

The most up to date release of this document may be found on the smbldap-tools project page available at <A HREF="http://samba.IDEALX.org/">http://samba.IDEALX.org/</A>.

If you find any bugs in this document, of if you want this document to integrate some additional infos, please drop us a mail with your bug report and/or change request at samba@IDEALX.org.


[edit]

2.3 Availability of this document

This document is the property of IDEALX (<A HREF="http://www.IDEALX.com/">http://www.IDEALX.com/</A>).

Permission is granted to distribute this document under the terms of the GNU Free Documentation License (See <A HREF="http://www.gnu.org/copyleft/fdl.html">http://www.gnu.org/copyleft/fdl.html</A>).



[edit]

3 Context of this Howto

This Howto aims at helping to configure an Samba + OpenLDAP Primary Domain Controler for Microsoft Windows Workstations (and, using nss_ldap and pam_ldap, a unique source of authentification for all workstations, including Linux and other Unix systems).

For the need of this howto, we took some snakeoils global parameters and default guidelines which are explained hereafter.


[edit]

3.1 Global parameters

For the need of our example, we settled the following context:

  • All workstations and servers are in the same LAN 192.168.1.0/24,
  • DNS resolution is okay (using Bind or Djbdns for example), and out of the scope of this Howto <A NAME="text2" HREF="#note2">2</A>,
  • We want to configure the Microsoft Windows NT Domain named IDEALX-NT,
  • We will have a central Primary Domain Controler named PDC-SRV (netbios name) on the host 192.168.1.1/32 ,
  • We want this Primary Domain Controller to be the WINS server and the Master Browser Server of the IDEALX-NT domain,
  • All authentifications objects (users and groups) will be stored on an OpenLDAP server, using the base DN: dc=idealx,dc=org,
  • Users accounts will be stored in ou=Users,dc=idealx,dc=org,
  • Computers accounts will be stored in ou=Computers,dc=idealx,dc=org,
  • Groups accounts will be stored in ou=Groups,dc=idealx,dc=org.


[edit]

3.2 RedHat base

In this Howto, we took the RedHat/Linux 9 as a base, and made RPM packages for software component involved in this Howto (Samba, OpenLDAP, smbldap-tools, ...) to ease you installing this configuration.

Of course, this do not mean Samba only run on RedHat/Linux nor RedHat/Linux is a better Linux distribution than Debian GNU/Linux. The choice of RedHat/Linux present the advantage to be quickly reproductible by anybody (RedHat Linux is very common on the server market nowadays, and supported by many vendors). However, we presented in section <A HREF="#sec:anx">17</A> all .spec files used by our packages to help you install and compile the used softwares on your favorite Linux (or any other Operating System in fact).

All available RPM (and SRPM) packages are available on the smbldap-tools project home page at <A HREF="http://samba.IDEALX.org/">http://samba.IDEALX.org/</A>.


[edit]

3.3 FHS, LSB and High Availability

Installing and compiling the key softwares (Samba and OpenLDAP), we tried to keep in mind two key principles:

  1. we must enforce File Hierarchy Standard (FHS<A NAME="text3" HREF="#note3">3</A>) recommandations,
  2. we should follow the Linux Standard Base (LSB<A NAME="text4" HREF="#note4">4</A>) recommandations
  3. we must think our Primary Domain Controler may be used in a High Available configuration (in a futur revision of this Howto).
Let us know if you think one of these key principles were not correctly enforced: drop a mail to samba@IDEALX.com.



[edit]

4 Installation


To stick to this Howto<A NAME="text5" HREF="#note5">5</A>, you must have the following requirements prior to download anything:

  • Fedora Core release 2 installed and operational (network included) <A NAME="text6" HREF="#note6">6</A>,
  • you must be prepared (if not already done) to use pam_ldap and nss_ldap (we'll see later how to configure them correctly).

Additionnaly, you must download and install packages :

  • OpenLDAP,
  • Samba,
  • nss_ldap and pam_ldap,
  • smbldap-tools.

The smbldap-tools are available on the project page (<A HREF="http://samba.IDEALX.org/dist/">http://samba.IDEALX.org/dist/</A>); others are part of the Fedora Core release 2 distribution. Only OpenLDAP was downloaded separatly because of the old version available in the distribution.


[edit]

4.1 OpenLDAP

At the date we wrote this document, release 2.1.29of OpenLDAP was considered stable enough to be used in production environment. We use the release of OpenLDAP provided with Fedora Core release 2. Packages that need to be downloaded are :

  • core components: openldap-2.1.29-1
  • server components: openldap-servers-2.1.29-1,
  • clients components: openldap-clients-2.1.29-1

Once downloaded, install the following packages on your system: 

rpm -Uvh openldap-2.1.29-1.i386.rpm
rpm -Uvh openldap-servers-2.1.29-1.i386.rpm
rpm -Uvh openldap-clients-2.1.29-1.i386.rpm
[edit]

4.2 Samba 3.0.28

Samba 3.0.11 is the latest release of Samba 3 branch (at the date of this Howto redaction, and used by this Howto). To use Samba with LDAP, ther's no need of compilation options to Samba as LDAP is the default backend used with classic RedHat's Samba packages.

Samba package can be dowloaded on the samba project <A NAME="text7" HREF="#note7">7</A>.

Just download the samba packages and install them on your system: 

rpm -Uvh samba-3.0.10-2.i386.rpm
rpm -Uvh samba-client-3.0.10-2.i386.rpm
rpm -Uvh samba-common-3.0.10-2.i386.rpm

Of course, you can also use the default RedHat package.

[edit]

4.3 smbldap-tools 0.8.8

smbldap-tools is a package containing some useful scripts to manage users/groups when you're using LDAP as source of users/groups datas (for Unix and for Samba). We used those scripts in this Howto to add/delete/modify users and groups.

smbldap-tools are included in the Samba source tree scince release 2.2.5 <A NAME="text8" HREF="#note8">8</A>, but you will find RPM and SRPMS packages on the smbldap-tools project page.

For this Howto, just download smbldap-tools release 0.8.8 RPM and install it: 

rpm -Uvh smbldap-tools-0.8.8-1.i386.rpm

smbldap-tools will continue to evoluate. Consult the ChangeLog in the CVS source tree to see if changes are interesting for your context. For this Howto setup however, we encourage you to use release 0.8.8 as they are sufficient for the limited use they cover


[edit]

5 Configuration

[edit]

5.1 OpenLDAP

You'll need to configure your OpenLDAP server for it to act as a SAM database. Following our context example, we must configure it to :

  • accept the Samba 3.0.11rc1 LDAP v3 schema<A NAME="text9" HREF="#note9">9</A>,
  • run on the base DN dc=idealx,dc=org,
  • contain the minimal entries needed to start using it.

For the needs of this Howto example, we have used the following LDAP DIT: 

(using Relative DN notation)

dc=IDEALX,dc=ORG
 |
 `--- ou=Users     : to store user accounts for Unix and Windows systems
 |
 `--- ou=Computers : to store computer accounts for Windows systems
 |
 `--- ou=Groups    : to store system groups for Unix and Windows 
 |                   systems (or for any other LDAP-aware systems)
 |
 `--- ou=DSA       : to store special accounts (simpleSecurityObject)
                     systems (or for any other LDAP-aware systems)
This DIT is compliant with recommandations from RFC 2307bis. We did not use

ou=Host to store computer accounts as there is a difference between TCP/IP hosts and Microsoft Windows computer accounts. We used ou=DSA to store specific security accounts for LDAP Clients, in the context of the smbldap-tools (look at the <A HREF="#sec::security::considerations">5</A> section for more details and example).

You may choose to use another LDAP tree to store objects: for example, all accounts (shadowAccounts and sambaSAMAccounts) "under" the same DN. We choosed this DIT because of the compliance with RFC 2307bis recommandations, and because we think it's clearer for human comprehension this way.

Using Samba 3.0.11rc1 and OpenLDAP, we will store :

  • Microsoft Windows user accounts using sambaSAMAccount object class (samba.schema),
  • Microsoft Windows computer accounts (ie. workstations) using sambaSAMAccount object class,
  • Unix user accounts using posixAccount objectclass and shadowAccount objectclass for the shadow suite password (nis.schema)
  • Users groups using posixGroup and sambaGroupMapping object classes <A NAME="text10" HREF="#note10">10</A>.
  • security accounts used by software clients (Samba and Linux) using simpleSecurityObject (core.schema) object class.
[edit]

5.1.1 Schemas

The Samba schema must be supported by the OpenLDAP server. To do so, and using the smbldap-tools OpenLDAP RedHat packages, just verify that your /etc/openldap/slapd.conf include the lines like the example hereafter: 

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/samba.schema

As you can see, we use the inetOrgPerson objectclass because we want to merge organizational with technical data. Doing so will ease administration as a user account will be used to define:

  1. a human user in your company,
  2. a user account for Microsoft Windows and Unix systems,
  3. a user account for any LDAP-aware application.
Doing so is not mandatory: feel free to use a context who feet your needs better if this way is not the one you want to follow.

Note that we use the samba.schema shipped with Samba release 3.0.11rc1 sources.

[edit]

5.1.2 Server configuration

Configure the slapd server to be a master server on the following suffix: dc=idealx,dc=org. This will result in the following lines in slapd.conf configuration files: 

database   bdb
directory  /var/lib/ldap

suffix     "dc=IDEALX,dc=ORG"
rootdn     "cn=Manager,dc=IDEALX,dc=ORG"

index      objectClass,uidNumber,gidNumber                  eq
index      cn,sn,uid,displayName                            pres,sub,eq
index      memberUid,mail,givenname                 eq,subinitial
index      sambaSID,sambaPrimaryGroupSID,sambaDomainName    eq

Then, position Access Control Lists to protect your datas. This will result in the following lines in the configuration file: 

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
      by self write
      by anonymous auth
      by * none
access to *
      by * read

Finally, define the Root DN password for your server. This will result in the following lines : 

rootpw          mysecretpwd

Don't forget to place mode 600 on file/etc/openldap/slapd.conf to protect your Root DN password, if not already set. You can also set a hashed password in that file: use the slappasswd command. For example, to have the word mysecretpwd hashed with the SSHA algorithm, use the command 

[root@etoile]$ slappasswd -h {SSHA} -s mysecretpwd
{SSHA}X+Qv3lKnVB/oov2uvC6Id1nfEkgYaPrd
Available algorithm are CRYPT, MD5, SMD5, SSHA, and SHA.

The default is SSHA. The resulting lines in the file/etc/openldap/slapd.conf will then be 

rootpw      {SSHA}X+Qv3lKnVB/oov2uvC6Id1nfEkgYaPrd

[edit]

5.1.3 Clients configuration

Configure default settings for LDAP clients by editing /etc/openldap/ldap.conf like in the following example: 

HOST 127.0.0.1
BASE dc=IDEALX,dc=ORG
[edit]

5.1.4 Start the server

Finally, start your OpenLDAP server using the following 

$ /etc/init.d/ldap start

Everything should work fine. If not:

  • verify your configuration files,
  • verify that the configuration file /etc/openldap/slapd.conf and the directory /var/lib/ldap exist and are owned by the user who run slapd (ldap user for RedHat OpenLDAP packages),
  • consult the OpenLDAP documentation.
[edit]

5.2 Linux Operating System

You need to tell you Linux box to use LDAP using pam_ldap and nss_ldap. Then, you should run nscd and finish your system LDAP configuration.

[edit]

5.2.1 pam_ldap, nss_ldap and nscd

Use authconfig <A NAME="text11" HREF="#note11">11</A> to activate pam_ldap :

  • Cache Information
  • Use LDAP
  • dont select 'Use TSL'
  • Server: 127.0.0.1
  • Base DN: dc=idealx,dc=org
  • Use Shadow Passwords
  • Use MD5 Passwords
  • Use LDAP Authentification
  • Server : 127.0.0.1
  • Base DN: dc=idealx,dc=org

Cache Information mean you're using nscd (man nscd for more info) : if you're going to use pam_ldap and nss_ldap, you should really use it for optimization.

If you don't rely on 'authconfig', you can edit your /etc/pam.d/system-auth by hand, to have something like the following: 

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/pam_ldap.so use_first_pass
auth        required      /lib/security/pam_deny.so

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

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/pam_ldap.so use_authtok
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_ldap.so

Warning: a special attention must be taken about the account sufficient parameters as it seems RedHat authconfig tools place it as 'required' in any case (which is not the way you'll need).

[edit]

5.2.2 /etc/ldap.conf

Edit your /etc/ldap.conf to configure your LDAP parameters:

  • host: LDAP server host,
  • base: distinguished name of the default search base,
  • nss_base_passwd: naming context for accounts,
  • nss_base_group: naming context for groups,
  • rootbinddn and associated password: the distinguished name used to bind if effective ID is root (to allow root to change any user's password for example).

Which should be like the following: 

# Your LDAP server. Must be resolvable without using LDAP.
host 127.0.0.1

# The distinguished name of the search base.
base dc=IDEALX,dc=ORG

# The distinguished name to bind to the server with if the effective user ID 
# is root. Password must be stored in /etc/ldap.secret (mode 600)
rootbinddn cn=nssldap,ou=DSA,dc=IDEALX,dc=ORG

# RFC2307bis naming contexts
nss_base_passwd         ou=Users,dc=IDEALX,dc=ORG?one
nss_base_passwd         ou=Computers,dc=IDEALX,dc=ORG?one
nss_base_shadow         ou=Users,dc=IDEALX,dc=ORG?one
nss_base_group          ou=Groups,dc=IDEALX,dc=ORG?one

# Security options
ssl no
pam_password md5

# - The End
[edit]

5.2.3 /etc/ldap.secret

You must place in this file, protected by mode 600, the bind password associated with the distinguished name used by nss_ldap to bind to the OpenLDAP directory when the local user is root. In our example, this file must contain the following password: 

nssldapsecretpwd
[edit]

5.2.4 /etc/nsswitch.conf

Edit your /etc/nswitch.conf to configure your Name Service Switch to use LDAP for users and groups: 

# significative entries for /etc/nsswitch.conf using 
# Samba and OpenLDAP
passwd:     files ldap   
shadow:     files ldap
group:      files ldap

A complete sample /etc/nsswitch.conf is presented in section <A HREF="#sec:anx:nsswitch-conf">17.1.4</A>.

[edit]

5.3 Samba

Here, we'll configure Samba as a Primary Domain Controler for the Microsoft Windows NT Domain named IDEALX-NT with the SAM database stored in our OpenLDAP server.

[edit]

5.3.1 Configuration

We need to configure /etc/samba/smb.conf like in the example of <A HREF="#sec:anx:smb-conf">17.1.3</A>, assuming that :

  • Our Microsoft Windows NT Domain Name will be : IDEALX-NT
  • Our server Netbios Name will be : PDC-SRV
  • Our server will allow roving/roaming profiles
  • All samba share will rely on /home/samba/* excepted for home directories (always on /home/USERNAME).
  • We really want our Samba-LDAP PDC server to be the domain browser on the LAN.

Edit your /etc/samba/smb.conf like in the example of <A HREF="#sec:anx:smb-conf">17.1.3</A> to configure your Samba server. Let make some remarques about this file:

[edit]
5.3.1.1 The global section

This section allow you to configure the global parameter of the server. Here takes places all the parameters we defined in the previous paragraph. We also have defined the program used for a user to change his password (passwd program) and the dialog used between the server and the user during the change.

The option "add machine script" allow smbd to add, as root, a new machine account in the doamin. When a machine contact the domain, this script is called and the new machine's account is created in the domain. This makes easily the administration of machine's account. For security reason, the only account allowed to join computer in the domain is the "Administrator" which is a privilege account.

For french users, we added a line that allow smbd to map incoming filenames from a DOS code page. This option is very useful if you want that files and directories in your profiles are saved with all the accents they have. Don't forget to read the man page for more detail: this option is a Western European UNIX character set. The parameter client code page MUST be set to code page 850 in order for the conversion to the UNIX character set to be done correctly.

  workgroup = IDEALX-NT
  netbios name = PDC-SRV
  enable privileges = yes
  server string = SAMBA-LDAP PDC Server
  ...
  #unix password sync = Yes
  #passwd program = /usr/local/sbin/smbldap-passwd -u %u
  #passwd chat = "Changing password for*\nNew password*" %n\n "*Retype new password*" %n\n"
  ldap passwd sync = Yes
  ...
  ; SAMBA-LDAP declarations
  passdb backend = ldapsam:ldap://127.0.0.1/
  # ldap filter = (&(objectclass=sambaSamAccount)(uid=%u))
  ldap admin dn = cn=Manager,dc=IDEALX,dc=ORG
  ldap suffix = dc=IDEALX,dc=ORG
  ldap group suffix = ou=Groups
  ldap user suffix = ou=Users
  ldap machine suffix = ou=Computers
  ldap ssl = start_tls

  add machine script = /usr/local/sbin/smbldap-useradd -w "%u"
  add user script = /usr/local/sbin/smbldap-useradd -m "%u"
  ldap delete dn = Yes
  #delete user script = /usr/local/sbin/smbldap-userdel "%u"
  add group script = /usr/local/sbin/smbldap-groupadd -p "%g"
  #delete group script = /usr/local/sbin/smbldap-groupdel "%g"
  add user to group script = /usr/local/sbin/smbldap-groupmod -m "%u" "%g"
  delete user from group script = /usr/local/sbin/smbldap-groupmod -x "%u" "%g"
  set primary group script = /usr/local/sbin/smbldap-usermod -g "%g" "%u"

  ...
  Dos charset = 850
  Unix charset = ISO8859-1
[edit]
5.3.1.2 The shares sections

Here takes place all the share sections. In particular, we can define all the user's home directories which are defined by the [homes] section: 

  comment = Home Directories
  valid users = %U
  read only = No
  create mask = 0664
  directory mask = 0775
  browseable = No

  path = /home/samba/profiles
  read only = No
  create mask = 0600
  directory mask = 0700
  browseable = No
  guest ok = Yes
  profile acls = Yes
  csc policy = disable
  # next line is a great way to secure the profiles 
  force user = %U
  # next line allows administrator to access all profiles 
  valid users = %U @"Domain Admins"

If you want command's file to be downloaded and ran when a user successfully logged in the windows workstation, you have to define a netlogon section and a netlogon script. The netlogon script must take place in the global section and the script must be a relative path to the [netlogon] service. For example, if the [netlogon] service specifies a path of /home/samba/netlogon (like in our example), then if the script is defined as logon script = STARTUP.BAT, the file that will be downloaded is /home/samba/netlogon/STARTUP.BAT. Finally, we defined a doc section that authorized everybody to browse the /usr/share/doc documentation directory.

  ...
  logon script = STARTUP.BAT
  ...

[netlogon]
  path = /home/samba/netlogon/
  browseable = No
  read only = yes

[doc]
  path=/usr/share/doc
  public=yes
  writable=no
  read only=no
  create mask = 0750
  guest ok = Yes

For example, we could have the STARTUP.BAT script that set the documentation directory mounted on the "J" volume on windows clients. Another useful command set windows time synchronized to the server's one: 

NET USE J: \\PDC-SRV\doc
NET TIME \\PDC-SRV /SET /YES
[edit]

5.3.2 Preparation

You must create some directories, according to your /etc/samba/smb.conf : 

mkdir /home/samba
mkdir /home/samba/netlogon
mkdir /home/samba/profiles
chmod 1777 /home/samba/profiles
[edit]

5.3.3 Initial entries

Samba must know the passwd of the ldap admin dn (cn=Manager,dc=IDEALX,dc=ORG) user you've specified in smb.conf. This user is used by samba to bind to the directory and must have enough permissions to add/modify accounts stored in the ldap directory.

To do so, use the following command (assuming 'mysecretpwd' is the ldap admin dn password, see your /etc/openldap/slapd.conf configuration file to be sure) : 

[root@pdc-srv samba]# smbpasswd -w mysecretpwd
Setting stored password for "cn=Manager,dc=IDEALX,dc=ORG" in secrets.tdb
Samba will store this datas in /etc/samba/secrets.tbd.


Note that this "ldap admin dn" can be another account than the Root DN : you should use another ldap account who should have permissions to write any sambaSAMAccount and some posixAccount attrs (see section <A HREF="#sec::security::considerations">5</A> for security considerations).

[edit]

5.3.4 Testing

To validate your Samba configuration, use testparm who should return 'Loaded services file OK.' without any warnings nor unknow parameter. See man testparm for more info.

[edit]

5.4 smbldap-tools

Finally, you must configure your smbldap-tools to match your system and LDAP configuration. This can be done in the two files /etc/opt/IDEALX/smbldap-tools/smbldap.conf and /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf.

[edit]

5.4.1 Configuration

  • the /etc/opt/IDEALX/smbldap-tools/smbldap.conf file You'll find some other configuration options in this configuration file: those are the default values used by smbldap-tools when creating an account (user or computer). Feel free to change those values if desired. Consult the smbldap-tools documentation for more information about configuration parameters. The main option that you need to defined now is the domain secure ID (SID). You can obtain its value using the following command 
     net getlocalsid
    Note that you need to start samba for several

    minutes for this command to successfull finished)

  • the /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf file and configure them according to your LDAP configuration (RootDN password and LDAP server @IP address). You'll find two confusing entries: slaveLDAP and masterLDAP. For our first example, those two LDAP servers will be the same one, but in a real life configuration, you may want to have a slave server to serve all your read request, and one dedicated to write request. Anyway, in the current example, as we build the PDC using Samba and OpenLDAP on the same host, you should specify 127.0.0.1 for the two LDAP servers.
    Note that you can't put hashed password here ! This configuration file must then be readable only for root.
[edit]

5.4.2 Initial entries

We need to add some initial entries on the new configured OpenLDAP server:

  1. base entries:
    • base DN: dc=idealx,dc=org
    • base organizational categories (ou=Users,dc=idealx,dc=org, ou=Groups,dc=idealx,dc=org and, ou=Computers,dc=idealx,dc=org)
  2. security accounts later used by software clients (Samba and Linux):
    • Samba server DN: cn=samba,ou=DSA,dc=idealx,dc=org
    • Linux DN: cn=nssldap,ou=DSA,dc=idealx,dc=org
    • smbldap-tools DN: cn=smbldap-tools,ou=DSA,dc=idealx,dc=org

The easiest way to set up your directory and add the default base entries can be done using the smbldap-populate script <A NAME="text12" HREF="#note12">12</A>: 

[root@etoile root]$ smbldap-populate 
Populating LDAP directory for domain IDEALX-NT (S-1-5-21-4205727931-4131263253-1851132061)
(using builtin directory structure)
 
adding new entry: dc=idealx,dc=org
adding new entry: ou=Users,dc=idealx,dc=org
adding new entry: ou=Groups,dc=idealx,dc=org
adding new entry: ou=Computers,dc=idealx,dc=org
adding new entry: uid=root,ou=Users,dc=idealx,dc=org
adding new entry: uid=nobody,ou=Users,dc=idealx,dc=org
adding new entry: cn=Domain Admins,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Users,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Guests,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Domain Computers,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Administrators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Account Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Print Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Backup Operators,ou=Groups,dc=idealx,dc=org
adding new entry: cn=Replicators,ou=Groups,dc=idealx,dc=org
adding new entry: sambaDomainName=IDEALX-NT,dc=idealx,dc=org
 
Please provide a password for the domain root: 
Changing password for root
New password : 
Retype new password :

The sambaDomainName=IDEALX-NT,dc=idealx,dc=org entry define the samba domain and specially it's domain SID. We also use it to defined the next uidNumber and gidNumber available for creating new users and groups. The default values for those numbers are 1000. You can change it with the -u and -g option. For example, if you want the first available value for uidNumber and gidNumber to be set to 1500, you can use the following command : 

smbldap-populate -u 1550 -g 1500

The 'Administrator' user's password, ie the root account password is immediatly defined. In fact, any user placed in the "Domain Admins" group will be granted Windows admin rights for the domain, but only the Administrator account is allowed to join computers to the domain.

Once added, you should add the security accounts for Samba and Linux. To proceed, copy/paste the accounts defined in section <A HREF="#sec:anx:smbldap-dsa-ldif">17.3</A> and add them in the directory with the following command: 

ldapadd -x -h localhost -D "cn=Manager,dc=IDEALX,dc=ORG" -f smbldap-dsa.ldif -W
Finally, set the default password to those accounts:
  • the Samba security account, using 'sambasecretpwd' password: 
     ldappasswd -x -h localhost -D "cn=Manager,dc=IDEALX,dc=ORG" -s sambasecretpwd \
-W cn=samba,ou=DSA,dc=IDEALX,dc=ORG
  • the Linux (nss_ldap) security account, using

    'nssldapsecretpwd' password: 

     ldappasswd -x -h localhost -D "cn=Manager,dc=IDEALX,dc=ORG" -s nssldapsecretpwd \
 -W cn=nssldap,ou=DSA,dc=IDEALX,dc=ORG
  • the smbldap-tools security account, using 'smbldapsecretpwd'

    password: 

     ldappasswd -x -h localhost -D "cn=Manager,dc=IDEALX,dc=ORG" -s smbldapsecretpwd \
-W cn=smbldap-tools,ou=DSA,dc=IDEALX,dc=ORG

(type your admin DN password, 'mysecretpwd' to complete the command when prompted).

[edit]

5.5 Test your system

To test your system, we'll create a system account in LDAP (say 'testuser'), and will try login as this new user.

To create a system account in LDAP, use the smbldap-useradd<A NAME="text13" HREF="#note13">13</A> script (assuming you have already configured your smbldap-tools): 

[root@pdc-srv tmp]# smbldap-useradd -m testuser1
[root@pdc-srv tmp]# smbldap-passwd testuser1
Changing password for testuser1
New password : 
Retype new password :
Then, try to login on your system (Unix login) as testuser1 (using another

console, or using ssh). Everything should work fine : 

[user@host-one:~]$ ssh testuser1@pdc-srv
testuser1@pdc-srv's password:
Last login: Sun Dec 23 15:49:40 2004 from host-one

[testuser1@pdc-srv testuser1]$ id
uid=1000(testuser1) gid=100(users) groupes=100(users)
Dont forget to delete this testuser1 after having completed your tests : 
[root@pdc-srv]# smbldap-userdel -r testuser1
[edit]

6 Security considerations

[edit]

6.1 Use an account which is not Root DN

In this HOWTO, we're using the Root DN : the ldap admin dn should be another account than Root DN : you should use another ldap account who should have permissions to write any sambaSAMAccount and some posixAccount attributes.

So if you don't want to use the cn=Manager,dc=idealx,dc=org account anymore, you can use a dedicated account for Samba and another one for the smbldap-tools scripts. The two users were created in section <A HREF="#sec::initial::entries">4.4.2</A> in the DSA branch : cn=samba,ou=DSA,dc=idealx,dc=org and cn=smbldap-tools,ou=DSA,dc=idealx,dc=org. If the password set for thoses account were respectivly samba and smbldap-tools, you can modify the configuration files as follow (of course, you can use the same account for both samba and smbldap-tools) :

  • file /etc/opt/IDEALX/smbldap-tools/smbldap_bind.conf 
        slaveDN="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org"
    slavePw="smbldapsecretpwd"
    masterDN="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org"
    masterPw="smbldapsecretpwd"

        ldap admin dn = cn=samba,ou=DSA,dc=idealx,dc=org

    don't forget to also set the samba account password in secrets.tdb file : 

    smbpasswd -w sambasecretpwd
  • file /etc/openldap/slapd.conf: many access control list must be set :
    • samba user need write access to all samba attributes and some others (uidNumber, gidNumber ...).
    • smbldap-tools must have write access to add or delete new users, groups or computers account
    • nssldap also need write access to unix password attribute (for example if a user want to change his password with the passwd command). 
    # users can authenticate and change their password
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdLastSet,sambaPwdMustChange
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=nssldap,ou=DSA,dc=idealx,dc=org" write
      by self write
      by anonymous auth
      by * none
# some attributes need to be readable anonymously so that 'id user' can answer correctly
access to attrs=objectClass,entry,homeDirectory,uid,uidNumber,gidNumber,memberUid
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by * read
# somme attributes can be writable by users themselves
access to attrs=description,telephoneNumber,roomNumber,homePhone,loginShell,gecos,cn,sn,givenname
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by self write
      by * read
# some attributes need to be writable for samba
access to attrs=cn,sambaLMPassword,sambaNTPassword,sambaPwdLastSet,sambaLogonTime,sambaLogoffTime,sambaKickoffTime,sambaPwdCanChange,sambaPwdMustChange,sambaAcctFlags,displayName,sambaHomePath,sambaHomeDrive,sambaLogonScript,sambaProfilePath,description,sambaUserWorkstations,sambaPrimaryGroupSID,sambaDomainName,sambaMungedDial,sambaBadPasswordCount,sambaBadPasswordTime,sambaPasswordHistory,sambaLogonHours,sambaSID,sambaSIDList,sambaTrustFlags,sambaGroupType,sambaNextRid,sambaNextGroupRid,sambaNextUserRid,sambaAlgorithmicRidBase,sambaShareName,sambaOptionName,sambaBoolOption,sambaIntegerOption,sambaStringOption,sambaStringListoption,sambaPrivilegeList
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by self read
      by * none
# samba need to be able to create the samba domain account
access to dn.base="dc=idealx,dc=org"
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by * none
# samba need to be able to create new users account
access to dn="ou=Users,dc=idealx,dc=org"
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by * none
# samba need to be able to create new groups account
access to dn="ou=Groups,dc=idealx,dc=org"
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by * none
# samba need to be able to create new computers account
access to dn="ou=Computers,dc=idealx,dc=org"
      by dn="cn=samba,ou=DSA,dc=idealx,dc=org" write
      by dn="cn=smbldap-tools,ou=DSA,dc=idealx,dc=org" write
      by * none
# this can be omitted but we leave it: there could be other branch
# in the directory
access to *
      by self read
      by * none
    [edit]

    6.2 Secure connections: use TLS

    In this HOWTO, whe are using clear LDAP transport between Samba and OpenLDAP. As both servers implement SSL, you should use TLS transport instead.

    If you want to use TLS, you have to create a certificate for each servers. Certificates can be self-signed but it is preferable to have certificates signed by the same authority (CA) if OpenLDAP is configured so that client are requested (TLSVerifyClient demand in slapd.conf file).

    The next paragraphs illustrate the few steps needed to set up an example CA and how to create a server's certificate signed by the CA. Refer to the appropriate documentations for more informations (for example <A HREF="http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html">http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html</A>).

    You may also want to take a look at IDX-PKI for installing the real thing. See <A HREF="http://www.idealx.com/solutions/idxpki/">http://www.idealx.com/solutions/idxpki/</A> for more informations.

    Remember one important thing: certificates are created with their common name hardcoded in the certificate. Each time you want to connect to the server in secure mode, you must contact it using this name (and not it's IP address, unless you set it's common name to the IP address)!

    [edit]

    6.2.1 Certificates creation

    For this example, we'll create a CA authority. Next, we'll create a certificate for the server ldap.idealx.com wich will be signed by the CA.

    1. create the CA key and certificate
      • create directory structure 
        mkdir certs  csr  datas  keys  private datas/ca.db.certs
touch private/ca.key datas/ca.db.serial
cp /dev/null datas/ca.db.index
      • Generate pseudo-random bytes 
        openssl rand 1024 > datas/random-bits
      • create the key for the CA: a pass phrase will be asked to 
        you. Don't forget it: it will be asked to you each time
you want to create a new certificate's server.

        openssl genrsa -des3 -out private/ca.key 1024 -rand datas/random-bits
chmod 600 private/ca.key
        Warning: key the ca.key private !
      • Self-sign the root CA 
        openssl req -new -x509 -days 3650 -key private/ca.key -out certs/ca.pem
      • create a configuration ca.conf file for the CA 
              default_ca              = default_CA
      [ default_CA ]
      dir                     = .                       # Where everything is kept
      certs                   = ./certs                 # Where the issued certs are kept
      new_certs_dir           = ./datas/ca.db.certs     # Where the issued crl are kept
      database                = ./datas/ca.db.index     # database index file
      serial                  = ./datas/ca.db.serial    # The current serial number
      RANDFILE                = ./datas/random-bits     # private random number file
      certificate             = ./certs/ca.pem          # The CA certificate
      private_key             = ./private/ca.key        # The private key
      default_days            = 730
      default_crl_days        = 30
      default_md              = md5
      preserve                = no
      x509_extensions         = server_cert
      policy                  = policy_anything
      [ policy_anything ]
      countryName             = optional
      stateOrProvinceName     = optional
      localityName            = optional
      organizationName        = optional
      organizationalUnitName  = optional
      commonName              = supplied
      emailAddress            = optional
      [ server_cert ]
      #subjectKeyIdentifier   = hash
      authorityKeyIdentifier  = keyid:always
      extendedKeyUsage        = serverAuth,clientAuth,msSGC,nsSGC
      basicConstraints        = critical,CA:false
      • initialize the serial database 
        echo '01' > datas/ca.db.serial
    2. create the server key and certificate for ldap.idealx.com server
      • create the key for the server ldap.idealx.com 
        openssl genrsa -out keys/ldap.idealx.com.key 1024
      • create certificate data for ldap.idealx.com: when asking you for 
        the Common Name, you must set the full qualified
name of the server, ie ldap.idealx.com

        openssl req -new -key keys/ldap.idealx.com.key -out csr/ldap.idealx.com.csr
      • sign the ldap.idealx.com certificate with the CA one 
        openssl ca -config ca.conf -out certs/ldap.idealx.com.txt -infiles csr/ldap.idealx.com.csr
      • extract the ldap.idealx.com certificate 
        perl -n -e 'm/BEGIN CERTIFICATE/ && do {$$seen=1}; $$seen && print;' < certs/ldap.idealx.com.txt > certs/ldap.idealx.com.pem
      • you can also verify the certificate 
        openssl verify -CAfile certs/ca.pem certs/ldap.idealx.com.pem
    3. you then have the three files you need for setting up properly the configuration's server :
      • ./certs/ca.pem : the CA certificate
      • ./certs/ldap.idealx.com.pem : the ldap server certificate
      • ./keys/ldap.idealx.com.key : and it's associated key

    [edit]

    6.2.2 Configure the smbldap-tools scripts

    The smbldap-tools scripts will connect to the secure directory. We'll then need to create a certificate for this client : use smbldap-tools as common name.
    Update the configuration file /etc/opt/IDEALX/smbldap-tools/smbldap.conf :

    • activate the TLS support
      ldapTLS="1"
    • the file that contains the client certificate
      clientcert="/etc/opt/IDEALX/smbldap-tools/smbldap-tools.pem"
    • the file that contains the private key that matches the certificate stored in the clientcert file
      clientkey="/etc/opt/IDEALX/smbldap-tools/smbldap-tools.key"
    • the PEM-format file containing certificates for the CA's that slapd will trust.
      cafile="/etc/opt/IDEALX/smbldap-tools/ca.pem"
    [edit]

    6.2.3 Configure OpenLDAP

    Create a certificate for the OpenLDAP server with common name ldap.idealx.com.
    Update the configuration file /etc/openldap/slapd.conf and set :

    • the file that contains the server certificate
      TLSCertificateFile ldap.idealx.com.pem
    • the file that contains the private key that matches the certificate stored in the TLSCertificateFile file
      TLSCertificateKeyFile ldap.idealx.com.key
    • the PEM-format file containing certificates for the CA's that slapd will trust
      TLSCACertificateFile ca.idealx.com.pem

    You can also request a valid certificate to all incoming TLS session :

    • TLSVerifyClient demand
    [edit]

    6.2.4 Configure Samba

    Simply add one line in the configuration file /etc/samba/smb.conf :

    • ldap ssl = start tls
    [edit]

    6.2.5 Configure the linux operating system

    Check that the /etc/ldap.conf contains the following informations :

    • the OpenLDAP server
      host ldap.idealx.com
    • the distinguished name of the search base
      base dc=idealx,dc=org
    • require and verify server certificate
      tls_checkpeer yes
    • the PEM-format file containing certificates for the CA's that slapd will trust.
      tls_cacertfile /etc/opt/IDEALX/smbldap-tools/ca.pem
    • OpenLDAP SSL mechanism
      ssl start_tls
    • if you also configured OpenLDAP to request a valid certificate to all incoming TLS session (with the "TLSVerifyClient demand" directive), you have to create a certificate for nss. Then you can add the two following lines :
      tls_cert /etc/nss/nss.idealx.org.pem
      tls_key /etc/nss/nss.idealx.org.key

    Be careful to set a proper name for the host directive: it must match the exact name that what given to the OpenLDAP server certificate. It must also be a resolvable name.

    [edit]

    6.3 Backup your data

    TODO: how to backup and restore your PDC !

    Crucial ! Some scripts may help do the job (even if not used, the will explain what to backup exactly, and how to restore). In fact, those scripts just have to backup: config files (ldap, nss, ldap, samba and tbds..) and the 'SAM' (so a LDIF may do the job). An smbldap-backup and smbldap-restore?


    [edit]

    7 Start-Stop servers

    To :

    • start/stop the OpenLDAP server : /etc/init.d/ldap start/stop
    • start/stop the Samba server : /etc/init.d/smb start/stop
    [edit]

    8 Migrating posix accounts and groups

    Pawel Wielaba has written two scripts smbldap-migrate-unix-accounts and smbldap-migrate-unix-groups to help you migrating users and groups defined in /etc/passwd (and/or /etc/shadow) and /etc/group.

    You can find his scripts with the smbldap-tools package (in documentation directory for rpm package). They can also be found on his site : <A HREF="http://www.iem.pw.edu.pl/~wielebap/ldap/smbldap-tools/2/">http://www.iem.pw.edu.pl/~wielebap/ldap/smbldap-tools/2/</A>

    [edit]

    8.1 users migration (from /etc/shadow)

    We suppose that you use the shadow password. We'll then also use the shadow file to migrate password's account. Users migration should be done as follow :

    1. copy /etc/passwd and /etc/shadow in a temporary directory : 
      cp /etc/passwd /etc/shadow /tmp/
    2. remove all accounts on both file that you not want to be in the directory : 
      for user in root nobody bin daemon
do
 export user
 perl -i -pe's@^$ENV{user}:(.*)\n@@' /tmp/passwd
 perl -i -pe's@^$ENV{user}:(.*)\n@@' /tmp/shadow
done
      don't forget to remove the user nobody as it is created when initializing the directory

      with smbldap-populate.

    3. migrate accounts : 
      /usr/share/doc/smbldap-tools-*/smbldap-migrate-unix-accounts -a -P /tmp/passwd -S /tmp/shadow
    4. remove migrated users from /etc/passwd and /etc/shadow

    Note : with the -a option on smbldap-migrate-unix-accounts, the sambaSAMAccount will be added to users. All users having previously a shell defined in /etc/passwd will then be able to connect to the server and update their "windows" password using /opt/IDEALX/sbin/smbldap-passwd script.

    [edit]

    8.2 groups migration (from /etc/group)

    We'll now migrate all groups defined in /etc/group file. Migration process should be done as follow :

    1. copy /etc/group in a temporary directory : 
      cp /etc/group /tmp/
    2. remove all groups that you not want to be in the directory : 
      for group in root bin daemon
do
        export group
        perl -i -pe's@^$ENV{group}:(.*)\n@@' /tmp/group
done
    3. migrate groups : 
      /usr/share/doc/smbldap-tools-*/smbldap-migrate-unix-groups -a -G /tmp/group
    4. remove migrated groups from /etc/group

    Note : with the -a option on smbldap-migrate-unix-groups, the sambaGroupMapping will be added to groups so that they can be used as "windows" groups (samba will than mapped unix groups to windows groups). You should remove this option if you don't want this.


    [edit]

    9 Exploitation

    [edit]

    9.1 User management

    To manager user accounts, you can use:

    1. smbldap-tools, using the following scripts:
      • smbldap-useradd : to add a new user
      • smbldap-userdel : to delete an existing user
      • smbldap-usermod : to modify an existing user data
    2. idxldapaccounts (webmin module) if you are looking for a nice Graphical User Interface.
    3. Microsoft Windows NT Domain management tools
    The first method will be presented hereafter.

    [edit]

    9.1.1 A LDAP view

    First, let's have a look on what is really a user accounts for LDAP. In fact, there is two kinds of user accounts :

    • Posix Accounts, for use with LDAP-aware systems like Unix (Linux using pam_ldap and nss_ldap, in this HOWTO). Those kind of accounts use the posixAccount, or shadowAccount if you are using shadow passwords.
    • Samba Accounts, for the use of Samba Windows user accounts (and computer accounts too). Those kind of accounts use the sambaSAMAccount LDAP object class (according to the Samba samba.schema).

    Here's a LDAP view of an Unix Account (posixAccount in fact, for this HOWTO) : 

    dn: uid=testuser1,ou=Users,dc=IDEALX,dc=ORG
objectClass: top
objectClass: account
objectClass: posixAccount
cn: testuser1
uid: testuser1
uidNumber: 1000
gidNumber: 100
homeDirectory: /home/testuser1
loginShell: /bin/bash
gecos: User
description: User
userPassword: {SSHA}ZSPozTWYsy3addr9yRbqx8q5K+J24pKz

    Here's a LDAP view of a Samba user account (sambaSAMAccount) : 

    dn: uid=testsmbusers2,ou=Users,dc=idealx,dc=org
objectClass: top,inetOrgPerson,posixAccount,shadowAccount,sambaSAMAccount
cn: testsmbusers2
sn: testsmbusers2
uid: testsmbusers2
uidNumber: 1000
gidNumber: 513
homeDirectory: /home/testsmbusers2
loginShell: /bin/bash
gecos: System User
description: System User
sambaLogonTime: 0
sambaLogoffTime: 2147483647
sambaKickoffTime: 2147483647
sambaPwdCanChange: 0
displayName: System User
sambaSID: S-1-5-21-4231626423-2410014848-2360679739-3000
sambaPrimaryGroupSID: S-1-5-21-4231626423-2410014848-2360679739-513
sambaLogonScript: testsmbusers2.cmd
sambaProfilePath: \\PDC-SRV\profiles\testsmbusers2
sambaHomePath: \\PDC-SRV\home\testsmbusers2
sambaHomeDrive: H:
sambaLMPassword: 7584248B8D2C9F9EAAD3B435B51404EE
sambaAcctFlags: [U]
sambaNTPassword: 186CB09181E2C2ECAAC768C47C729904
sambaPwdLastSet: 1081281346
sambaPwdMustChange: 1085169346
userPassword: {SSHA}jg1v0WaeBkymhWasjeiprxzHxdmTAHd+


    Here follow a quick explanation about the attributes used:

    Attribute from schema Usage
    cn core usually, the username
    uid core username
    description core TODO
    userPassword core password for Unix systems using NSS/PAM LDAP
    displayName inetorgperson TODO
    uidNumber nis the numeric user number (Unix and Samba)
    gidNumber nis the primary group number of the user (Unix)
    loginShell nis the logon shell used on Unix systems
    gecos nis the long form of the username
    homeDirectory nis home directory path for Unix systems
    sambaPwdLastSet samba The integer time in seconds since 1970 when
        the lm and ntpasswd were last set.
    sambaLogonTime samba timestamp of last logon
    sambaLogoffTime samba timestamp of last logoff
    sambaKickoffTime samba timestamp of when the user will be logged off automatically
    sambaPwdCanChange samba timestamp of when the user is allowed to update the password
    sambaPwdMustChange samba timestamp of when the password will expire
    sambaPwdLastSet samba timestamp of the last password update
    sambaAcctFlags samba specify the type of the samba account
    sambaBadPasswordCount samba Bad password attempt count
    sambaBadPasswordTime samba Time of the last bad password attempt
        (W=workstation, U=user, D=disabled,
        X=no password expiration,...)
    sambaSID samba the secure identifier (SID) of the user
    sambaPrimaryGroupID samba the relative identifier (SID) of the primary group
        of the user
    sambaHomePath samba specifies the path of the home directory for the
        user. The string can be null. If homeDrive is set and
        specifies a drive letter, homeDirectory should be a
        UNC path. The path must be a network UNC path.
        This value can be a null string
    sambaLogonScript samba The scriptPath property specifies the path of
        the user's logon script, .CMD, .EXE, or .BAT file.
        The string can be null. The path is relative to the
        netlogon share
    sambaLMmPassword samba the LANMAN password
    sambaNTPassword samba the NT password (md4 hash)
    sambaHomeDrive samba specifies the drive letter to which to map the UNC
        path specified by homeDirectory. The drive letter
        must be specified in the form "driveletter:" where
        driveletter is the letter of the drive to map.
        For example: "Z:"
    sambaProfilePath samba specifies a path to the user's profile. This value
        can be a null string, a local absolute path, or
        a UNC path
    [edit]

    9.1.2 Using the smbldap-tools scripts

    To manipulate user accounts, we've developped a collection of PERL scripts named smbldap-tools : they provide all the tools you need to manage user and groups accounts, in a LDAP directory.

    Because we've merged posixAccount, shadowAccount and sambaAccount, those scripts may be used to manage Unix and Windows (Samba) accounts. As most of existing software are LDAP aware, you can use your SAMBA-LDAP PDC to be an unique source of authentification, and the smbldap-tools may offer you a good base to manage user accounts datas.

    In this Howto, we have used the following tools to manage user accounts :

    • smbldap-useradd : to add an user account (by default a posixAccount. Using '-a' option for a sambaSAMAccount, '-w' option for a machine sambaAccount),
    • smbldap-userdel : to delete an existing user accou