Easy Samba/LDAP Installer

SambaLdapInstaller has more information about this script

LDAP on LTSP

NOTICE

This document is a work-in-progress, and it's not meant to be a complete guide for configuring LDAP for LTSP. At this point, LDAP is not officially supported by LTSP and this guide is more of a collection of notes about LDAP and the utilities available. As we work through the LDAP support in LTSP, our hope is that this document will get closer to becoming an official LDAP on LTSP guide.

A step forward from LDAP is using Kerberos such as used by Microsoft Active Directory, integration can be found on KerberosLTSP.

Purpose of LDAP on LTSP

For LTSP, we are interested in using LDAP for the following:

1. Authentication
2. LTSP Configuration info (lts.conf)

Authentication

Normally, an LTSP workstation doesn't have a clue about user accounts. Everything running on the client is running as root (uid=0). In most cases, it really doesn't matter. The Xserver runs as root, and runs an XDMCP query to the server, and the user logs into the server with a username and password. The session running on the server is running as that user.

As we try to run processes on the workstation, it would be good to run those processes as a specific user. For instance, if we run firefox locally, we'd really like firefox to run as a specific user, not as root. This way, firefox will use that users home directory, and profile. There's no easy way to run firefox as root and have it use individual users profiles.

So, to run a process as a specific user on the workstation, we need to give the workstation some idea of users. Currently, we've been using NIS (Network Information Service) to provide that capability to the workstations. If you enable LOCAL_APPS, that turns on NIS on the client. NIS seems to work ok, but it lacks any kind of security, and it's being replaced in the corporate world by LDAP.

Fortunately, Linux does a fine job of supporting LDAP by using OpenLDAP.

LTSP Configuration info (lts.conf)

The /opt/ltsp/i386/etc/lts.conf file contains all of the configuration information for the workstations. It's a flat file structure and it's pretty simple to manage. But, if you were to deploy LTSP in a large environment with hundreds or even thousands of workstations, the flat file would become un-manageable. So for this, we've been working on the ability to store the client configuration in an LDAP database.

Installing and configuring the LDAP server

My test server is running Debian Sarge (testing). Installing LDAP is fairly easy. Just a couple of packages to install. the slapd and the ldap-utils packages should be enough to get you going.

Installing the slapd package

Start with the slapd package:

    apt-get install slapd

The installation process will pop up several screens, asking some questions about how you want LDAP configured.

The first question is about the DNS domain name. This DOES NOT have to match your current domain name of your network. On my test server, I set this value to ltsp.org. You can do the same, and it shouldn't conflict with anything.

The next question is the name of your organization. For this, I chose: LTSP.

The third screen will ask you to set an Admin password. Make sure you remember this password. This is your key to the LDAP system.

The final question is whether you want to allow the older LDAPv2 protocol. Unless you are interacting with older LDAP clients, you can safely say NO to this question.

After you've answered the questions, the installation will continue, and slapd will be started.

Installing the ldap-utils package

Now, install the ldap-utils package and you'll have some tools to play with the database.

  apt-get install ldap-utils

Interacting with the LDAP database

There's not much in the database yet, but you can dump the current contents with the following command:

  ldapsearch -x -b 'dc=ltsp,dc=org' '(objectclass=*)'

At this point, we have an empty LDAP database. We need to start putting some users into it. I started out creating a user named 'guest'. Following the tradition of Linux, I also created a group called 'guest' and made the new user the only member. I also created a group called 'ltspusers', and I'll put all users in that group.

Creating the People and Group organizational units

Before I created the new user, I had to create a place to put the users and groups. For this, I created 2 new 'Organizational Units' or 'ou'. The first ou is People and the second ou is Group. the People ou is a collection of users, and the Group ou is a collection of groups.

It is common when manipulating an LDAP database to add commands to a file, and then process the file with either the ldapadd or ldapmodify commands.

For this example, I created a file called people_group.ldif, and here is what I put in it:

  #
  # Add an Organizational Unit called 'Group'
  #
  dn: ou=Group,dc=ltsp,dc=org
  objectClass: organizationalUnit
  objectClass: top
  ou: Group

  #
  # Add an Organizational Unit called 'People'
  #
  dn: ou=People,dc=ltsp,dc=org
  objectClass: organizationalUnit
  ou: People

Then, to feed this file to LDAP, run this command:

  ldapadd -x -D "cn=admin,dc=ltsp,dc=org" -f people_group.ldif -W

The -D "cn=admin,dc=ltsp,dc=org" binds to the LDAP server as the admin user. It will prompt for the admin password so that it can complete the task.

Creating the user

File: user_guest.ldif:

  #
  # Create a User named 'guest'
  #
  dn: uid=guest,ou=People,dc=ltsp,dc=org
  objectClass: inetOrgPerson
  objectClass: posixAccount
  objectClass: top
  objectClass: shadowAccount
  objectClass: organizationalPerson
  uid: guest
  cn: LTSP User
  sn: Guest
  givenname: Guest LTSP User
  loginShell: /bin/bash
  uidNumber: 1001
  gidNumber: 1001
  homeDirectory: /home/guest
  gecos: Guest LTSP User

Feed the user_guest.ldif file to the database with this command:

  ldapadd -x -D "cn=admin,dc=ltsp,dc=org" -f user_guest.ldif -W

Setting the Password

You'll need to put a password on the account. This is done by doing the following:

  dev:~# slappasswd -h {CRYPT}                  <Type this command to generate an encrypted password>
  New password:                                 <enter your password here>
  Re-enter new password:                        <enter it again>
  {CRYPT}RJOWvUKarn7Ik                          <This is the encrypted password, using the crypt(3) library>

Once you have the encrypted string, you can feed that into ldapmodify, to set the password.

File: guest_password.ldif

  dn: uid=guest,ou=People,dc=ltsp,dc=org
  changetype: modify
  userPassword: {CRYPT}VjlhRTtKAfg0Y

Feed the guest_password.ldif file to the database with this command:

  ldapadd -x -D "cn=admin,dc=ltsp,dc=org" -f guest_password.ldif -W

Creating the Groups

File: groups.ldif:

  #
  # Create a Group named 'guest'
  #
  dn: cn=guest,ou=Group,dc=ltsp,dc=org
  objectClass: posixGroup
  objectClass: top
  cn: guest
  gidNumber: 1001
  memberUid: guest

  #
  # Create a Group named 'ltspusers', and put our user in it
  #
  dn: cn=ltspusers,ou=Group,dc=ltsp,dc=org
  objectClass: posixGroup
  objectClass: top
  cn: guest
  gidNumber: 9000
  memberUid: guest

Feed the groups.ldif file to the database with this command:

  ldapadd -x -D "cn=admin,dc=ltsp,dc=org" -f groups.ldif -W

Dumping the contents of the database

We've now collected a couple of entries in the LDAP database. We can dump them out, to see what we've got.

  ldapsearch -x -b 'dc=ltsp,dc=org' -LLL

The above example will dump out the entire contents of the database, in a format that is suitable to feed into ldapadd on another machine.

You can narrow the focus of the dump, by changing the search string:

  ldapsearch -x -b 'ou=People,dc=ltsp,dc=org' -LLL

The above example will only dump the 'ou=People,dc=ltsp,dc=org' branch of the tree.

In fact, you can take it even further by being more specific in the search base ('search string' for us english speaking people):

  server:~# ldapsearch -x -b 'uid=guest,ou=People,dc=ltsp,dc=org' -LLL

  dn: uid=guest,ou=People,dc=ltsp,dc=org
  objectClass: inetOrgPerson
  objectClass: posixAccount
  objectClass: top
  objectClass: shadowAccount
  objectClass: organizationalPerson
  uid: guest
  cn: LTSP User
  sn: Guest
  givenName: Guest LTSP User
  loginShell: /bin/bash
  uidNumber: 1001
  gidNumber: 1001
  homeDirectory: /home/guest
  gecos: Guest LTSP User

You can see in the example above, where we only dump the information about the guest user. If I had left the 'uid=guest,' from the search string, it would have shown all of that information for each user.

Configuring the LDAP client

So, now that the LDAP server is installed and configured, and you've got at least one user entered, you can setup a client machine to query the LDAP server at login time.

For my testing, I used a 2nd machine. Although, you could setup a single machine to be both an LDAP server and an LDAP client. Once I fully comprehend all this LDAP stuff I'll probably do that.

In my test environment, my server machine is called shuttle and my client machine is called dev.

On a Linux machine, there's several ways to log in:

• getty (console login)
• sshd (secure shell login from a remote machine)
• telnetd (not-so-secure shell login from a remote machine)
• ftpd (not-so-secure file transfer from a remote machine)
• xdm/gdm/kdm - Display manager for gui login either locally or remotely

Each of the above methods are configured separately. Although they all use PAM, so the place to make the changes is all in the same area /etc/pam.d on a Debian machine.

Installing the packages

There are 2 packages that you'll need on the client machine (I'm talking about a full Linux client, not an LTSP client). The packages are:

• libpam-ldap
• libnss-ldap

On a Debian machine, you can install both of them with the following commands:

Installing libpam-ldap

  apt-get install libpam-ldap

The command shown above should run quickly, and it won't ask any configuration questions.

Installing libnss-ldap

  apt-get install libnss-ldap

The libnss-ldap package will ask several questions. The following questions will be asked:

1. 'LDAP server host address'. Enter the address of the LDAP server
2. 'The distinguished name of the search base'. This should be a string in the form of 'dc=XXXX,dc=YYY'. Use the same string that you used when you setup the LDAP database. In our example, that is dc=ltsp,dc=org.
3. 'LDAP version to use'. Choose the default of 3
4. 'Does the LDAP database require login?'. For this, you can answer No
5. 'Should the libnss-ldap configuration file be readable and writable only by the file owner?' You can answer No to this question.
6. It will then tell you that the nsswitch.conf file will need to be manually edited.

Edit configuration files

/etc/pam_ldap.conf

In the /etc/pam_ldap.conf file, you'll need make the following adjustments:

1. Set the host address. (line 21 in my system)

   host 192.168.0.254
         

2. Set the base entry. (line 24 in my system)

   base dc=ltsp,dc=org
         

3. Set the pam_member_attribute (line 101 in my system)

   pam_member_attribute memberUid
         

4. Comment out the pam_password crypt line (line 121) and Un-comment the pam_password exop line (line 142)

/etc/libnss-ldap.conf

The installation of the libnss-ldap package will configure the /etc/libnss-ldap.conf file for you, but if you need to make any changes, you can edit that file directly, and it is the same format as the /etc/pam_ldap.conf file above.

/etc/nsswitch.conf

The client needs some concept of the users. Without a local /etc/passwd file, we need to configure glibc to look elsewhere for the information, such as username, homedir, and other things. This is configured through the /etc/nsswitch.conf file.

Original nsswitch.conf:

  passwd:         compat
  group:          compat
  shadow:         compat

  hosts:          files dns
  networks:       files

  protocols:      db files
  services:       db files
  ethers:         db files
  rpc:            db files

  netgroup:       nis

Modified nsswitch.conf:

  passwd:         files ldap
  group:          files ldap
  shadow:         files ldap

  hosts:          files dns
  networks:       files

  protocols:      db files
  services:       db files
  ethers:         db files
  rpc:            db files

  netgroup:       nis

XDM as an LDAP client

My first login method that I want to play with is xdm, because my ultimate goal is to run the display manager locally on the thin client, and then use LDAP to do the authentication.

Edit the /etc/pam.d/xdm file

In the /etc/pam.d/xdm file, you'll need to make the following adjustments:

Original file:

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

  auth            requisite       pam_nologin.so
  auth            required        pam_env.so
  session         required        pam_limits.so

Modified file:

  auth            requisite       pam_nologin.so
  auth            required        pam_env.so
  auth            sufficient      pam_unix.so likeauth nullok shadow
  auth            sufficient      pam_ldap.so use_first_pass

  account         sufficient      pam_unix.so
  account         sufficient      pam_ldap.so
  account         required        pam_deny.so

  password        sufficient      pam_ldap.so use_authok

  session         required        pam_limits.so
  session         required        pam_mkhomedir.so skel=/etc/skel/ umask=0
  session         optional        pam_ldap.so

And for my next trick, I'm going to try to get XDM running on the client. The purpose of that is to have it use ssh to launch the window manager on the server. The big benefit there is all of the X traffic will be encrypted.

LDAP and Evolution

---

This short howto is based around the Setup Guide that resides here 

http://www.feldt.com/work/projects/openLDAP/

 
You should use this setup guide, and refer to the real world example 
below to help you with anything that is confusing you from the above guide.
these are our customisations using domain dc=ltsp,dc=org put your domain 
which doesn't have to be a real internet domain, just something that will 
allow you to expand if that possibility may arise.
This was done on a Fedora Core 4 box, the example above is using an rpm 
based distribution (not FC4 though) so it should work for most setups, 
switch rpm for apt etc if you're using a debian based system (or whatever 
packaging you are using)

---

[root@solar openldap]# pwd
/etc/openldap

---

[root@solar openldap]# ls
AddressBook.ldif  
cacerts  
DomainManagerEntries.ldif  
ldap.conf
matthew.ldif  schema  slapd.conf

---

cp /usr/share/evolution-data-server-1.2/evolutionperson.schema /etc/openldap/schema/evolutionperson.schema
(overwriting old outdated one that comes with openldap)

---

[root@solar openldap]# cat slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
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/evolutionperson.schema

# Allow LDAPv2 client connections.  This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# serltspe AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/slapd.pid
argsfile        /var/run/slapd.args

# Load dynamic backend modules:
# modulepath    /usr/sbin/openldap
# moduleload    back_bdb.la
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la
# moduleload    back_shell.la

# The next three lines allow use of TLS for encrypting connections using
a
# dummy test certificate which you can generate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions
on
# slapd.pem so that the ldap user or group can read it.  Your client
software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
        by self write
        by users write
        by anonymous read

#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

access to * by * write
access to * by anonymous read
access to dn="cn=subschema" by * read


#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database        bdb
suffix          "dc=ltsp,dc=org"
rootdn          "cn=Manager,dc=ltsp,dc=org"
# Cleartext passwords, especially for the rootdn, should
# be avoided.  See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
#rootpw         secret
#rootpw         {crypt}ijFYNcSNctBYg
rootpw          {SSHA}1cZIvTTCB5cpkygw6UuTIz5BCTG4pTq8

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory       /var/lib/ldap

# Indices to maintain for this database
index objectClass                       eq,pres
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
#     bindmethod=sasl saslmech=GSSAPI
#     authcId=host/ldap-master.example.com@EXAMPLE.COM

---

[root@solar openldap]# cat DomainManagerEntries.ldif
root:/etc/openldap# cat DomainManagerEntries
# Domain entry
dn: dc=ltsp,dc=org
objectclass: dcObject
objectclass: organization
o: ltsp
dc: ltsp

# Manager entry
dn: cn=Manager,dc=ltsp,dc=org
objectclass: organizationalRole
cn: Manager

---

[root@solar openldap]# cat AddressBook.ldif
dn:ou=AddressBook,dc=ltsp,dc=org
objectClass: top
objectClass: organizationalUnit
ou: AddressBook

---

[root@solar openldap]# cat matthew.ldif
dn: cn=Matthew Wright,ou=AddressBook,dc=ltsp,dc=org
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: evolutionPerson
cn: Matthew Wright
givenname: Matthew Wright
sn: Wright
userPassword: {SSHA}1cZIvTTCB5cpkygw6UuTIz5BCTG4pTq8
mail: matthew.wright@ltsp.org

---

/etc/rc.d/init.d/ldap restart

---

[root@solar openldap]# slappasswd

---

wget http://www.feldt.com/work/projects/openLDAP/code/DomainManagerEntries.ldif
wget http://www.feldt.com/work/projects/openLDAP/code/AddressBook.ldif

---

ldapadd -x -D "cn=Manager,dc=ltsp,dc=org" -W -f DomainManagerEntries.ldif

---

ldapadd -x -D "cn=Manager,dc=ltsp,dc=org" -W -f AddressBook.ldif

---

cp 'wget http://www.feldt.com/work/projects/openLDAP/code/Me.ldif' matthew.ldif

---

ldapadd -x -D "cn=Manager,dc=ltsp,dc=org" -W -f matthew.ldif

---

ldapsearch -x -b 'dc=ltsp,dc=org' -D "cn=Manager,dc=ltsp,dc=org" '(objectclass=*)' -W

---

-- JimMcQuillan - 30 Jan 2005

LDAPADMIN

cliebow@ltsp.org

Here are some ideas for managing smbldap in an ltsp environment.Be aware that my database is deep rather than flat. crude but effective.I am writing an oo-perl package for this..My variables are flying around like mosquitos waiting to bite.

ldapadmin.py

first is a trivial python script that produces a gui where scripts can be run from. ldapadmin.py and all other scripts live in /usr/lib/ldapadmin. http://www.grammacams.com/ldapadmin/ldapadmin.py

Bash Scripts

addgroup-- a template for adding groups http://www.grammacams.com/ldapadmin/addgroup

addstaff-- a template for adding a staff person http://www.grammacams.com/ldapadmin/addstaff

Web-Based CGI Scripts

An index page for users to change their pws--http://www.grammacams.com/ldapadmin/index.cgi

passwd.cgi referenced by index.html --http://www.grammacams.com/ldapadmin/passwd.cgi

cliebow.pm referenced by passwd.cgi --http://www.grammacams.com/ldapadmin/cliebow.pm

LDAPADMIN.pm To come

The code is "challenged" but the idea is sound.. cliebow@ltsp.org