HP and OpenLDAP

Earlier this month the OpenLDAP Project had their 3rd annual Developer's Day. While I missed the conference myself (I don't travel, and even if I did my employer would have never paid for this one), I found the slide presentations archived on the project site very interesting. One that especially caught my eye was this:

www.openldap.org/conf/odd-sandiego-2004/Neil.pdf

The big news to me was that HP is moving off Sun's directory and onto OpenLDAP as their core enterprise directory in October. In fact, as the slides show, they've already made the switch for their extranet. The slides pretty much confirmed my own view of the readiness of OpenLDAP for the enterprise, with most of the same caveats I've raised to my management when we've discussed it. HP's approach was to work with OpenLDAP leader Symas Corporation to develop the enhancements they required. HP's team are the same guys whose homegrown LDAP sync tool, used during the HP and Compaq merger to sync their disparate directories, can be now purchased by outsiders for $20,000. Two of my remaining reservations, internal application reliance on proprietary features of the Netscape/Sun Directory series (mainly, Server Side Sort) and write performance (OpenLDAP used to be abyssmal, while Sun was always on top), are not addressed in the Developer Day presentation. The former is really a matter for internal standards enforcement, the latter may not be the issue it once was, now that OpenLDAP 2.2 has gone stable with its new Berkeley DB backend.

Samba and LDAP

Someone with an eye for detail might have noticed that the smb.conf I had in an earlier post was configured to use the tdbsam instead of the ldapsam backend. While tdbsam is a good alternative to the older smbpasswd backend that mimics a Windows LSA (Local Security Authority) database, it is understandable that one would assume that eldapo would opt for the LDAP backend. Although I've tried this in previous installations of both Samba 2 and Samba 3 (while the latter was still in development), my goal this time around was to get the service up and running as quickly and cleanly as possible.

With a little time on my hands today, I in fact did take the next step and convert over to the ldapsam backend. After pouring over the doc for awhile I thought I understood what to do, which I did -- pretty much.

First, I added the samba 3 schema file to my OpenLDAP instance's schema subdirectory and made the necessary changes to my slapd.conf (including adding an access control and indexes to support the new objectclass and attributes needed by Samba). Then I edited my smb.conf to add the LDAP related directives. Finally, I moved the Samba account information for my existing users over from tdbsam to LDAP.

For slapd.conf, the following lines got added:

At the top of the file:

include /usr/local/etc/openldap/schema/samba.schema

Above the database settings section:

# Limited access to Samba account attributes
access to attr=sambalmpassword,sambantpassword,sambapwdlastset,sambaacctflags,
sambalogontime,sambalogofftime,sambakickofftime,sambapwdcanchange,
sambapwdmustchange,sambahomepath,sambahomedrive,sambaprofilepath,
sambauserworkstations,sambaprimarygroupsid,sambadomainname,sambasid
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=lembo,dc=ny,dc=us" write
by self write

At the end of the database settings section:

# Samba v3 schema attributes
index sambasid eq
index sambaprimarygroupsid eq
index sambadomainname eq

I ran the command slapindex -f /usr/local/etc/openldap/slapd.conf to create the new indexes on the directory.

Here are the additional lines in the global section of smb.conf:

passdb backend = ldapsam
ldap admin dn = "cn=manager,dc=lembo,dc=ny,dc=us"
ldap ssl = start tls
ldap delete dn = no
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Domains
ldap suffix = dc=lembo,dc=ny,dc=us
ldap filter = (uid=%u)

Pretty standard stuff. I did have to use smbpasswd as root to add the "cn=manager" root directory account's password to the database before switching over. To migrate the existing tdbsam data to ldapsam I used the Samba pdbedit tool thusly:

pdbedit -i tdbsam -e ldapsam

For those users who did not have a previous account on tdbsam I used the smbpasswd utility to add them, which then wrote the requisite information into the user's corresponding LDAP entry.

Note that for now at least I have not enabled "ldap sync" to maintain both Samba and LDAP passwords automatically. This is mostly due to initial caution on my part. I know this feature does in fact work. What I'm really interested in in synching the Samba and UNIX passwords. Previously I was running FreeBSD 4.x, which does not support PAM (Pluggable Authentication Modules), a critical part of that feature. Now that I've moved everything to FreeBSD 5.2, I'm going to be researching how to configure PAM for this purpose. For now, I'll continue to maintain the 3 different passwords independantly, using native tools (passwd for UNIX, ldappasswd for LDAP and smbpasswd).




A sample slapd.conf

This is a sample slapd.conf for those who might be interested in a bdb back-end, monitor, some basic access controls and indexes (Note: the stock stylesheet that I use on this site cuts off some of the line ends unless you maximize your browser):


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

# Define global ACLs to disable default read access.

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

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

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

# 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:
#
# if no access controls are present, the default policy is:
# Allow read by all
#
# rootdn can always write!

# Custom access controls - created 12/31/03 by P Lembo
# Read access to root dse by all
access to dn=""
by * read

# Access by all to schema
access to dn.base="cn=subschema"
by * read

# Access to monitor by all
access to dn.base="cn=monitor"
by * read

# Limited access to password
access to attr=userpassword
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users auth
by anonymous auth

# Limited access to Posix account attributes
access to attr=uidnumber,gidnumber,homedirectory,loginshell,gecos
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self read

# Limited access to Samba account attributes
access to attr=lmpassword,ntpassword,pwdlastset,acctflags,logontime,logofftime,kickofftime,
pwdcanchange,pwdmustchange,smbhome,homedrive,profilepath,userworkstations,
primarygroupid,rid
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self read

# User access to organizational attributes
access to attr=o,ou,c,description,uniquemember
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by users read

# Access to public attributes by all
access to attr=uid,c,title
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by users read
by anonymous read

# Self write access to public attributes
access to attr=cn,displayname,sn,givenname,mail,telephonenumber,facsimiletelephonenumber
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read
by anonymous read

# Self write and limited access to private attributes
access to attr=homephone
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read

# Self write and read access to all other attributes
access to *
by group/groupofuniquenames/uniquemember="cn=Administrators,dc=company,dc=com" write
by self write
by users read
by anonymous read

password-hash {SHA}

allow bind_v2
sizelimit 200
timelimit 120
# TLS/SSL directives
TLSCertificateFile /usr/local/etc/openldap/newcert.pem
TLSCertificateKeyFile /usr/local/etc/openldap/newkey.pem
TLSCACertificateFile /usr/local/etc/openldap/newca.pem

#######################################################################
# ldbm database definitions
#######################################################################
# Monitor backend
database monitor

# User database
database bdb
suffix "dc=company,dc=com"
rootdn "cn=Manager,dc=company,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw {SHA}xxxxxxxxxxxxxxxxxxxxxxxx
# 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/db/openldap-data

# Cache directives
cachesize 2000
idlcachesize 4000
# Indices to maintain
index objectclass eq
index cn eq,pres,sub
index sn eq,pres,sub
index givenname eq,pres,sub
index mail eq,pres,sub
index c eq,pres
index uid eq,pres
index displayname eq,pres,sub
index uidnumber eq
index gidnumber eq
index memberuid eq
# Samba v2 schema attribs
index rid eq

# Samba v3 schema attributes
# index sambasid eq
# index sambaprimarygroupsid eq
# index sambadomainname eq

FreeBSD-Windows Interoperability Using Samba

In the past I've set up Windows machines to talk lpd and NFS to UNIX boxes, but recently I decided to give Samba another try. Many years ago I used Samba 1.x with some success, and was at first frustrated by 3.0, until I stopped using SWAT and other GUI's and did everything from the command line. Here's my smb.conf:

# Global parameters
[global]
workgroup = WORKGROUP
server string = Samba Server
passdb backend = tdbsam
log file = /var/log/samba/log.%m
max log size = 50
os level = 33
preferred master = yes
domain master = yes
wins support = yes
printing = bsd
load printers = yes
show add printer wizard = yes
use client driver = no

[printers]
comment = All Printers
path = /var/spool/samba
printable = yes
browseable = yes
public = yes
guest ok = yes

[share]
path = /usr/local/share
read only = No

[lp]
comment = gimp/pcl-4;r=300x300;q=medium;c=gray;p=letter;m=auto
path = /var/spool/samba
read only = No
printable = Yes
printer name = lp
use client driver = Yes
oplocks = No
share modes = No

eldapo on vacation

... for the first time since Y2K. It's hard to believe, but it actually has been 5 years since I took a whole week off at a time. I was a desktop guy during Y2K, testing software and creating images to be deployed on 6,000+ PC's in my company. After a very brief respite, I volunteered to work on our new LDAP directory project. That turned into a full time job, involving way more dedication and hard work than any of us imagined. This summer, though, I thought I owed it to my family -- and myself -- to take some time off. There are a bunch of guys back at the shop who are covering for me this week. Hopefully the population, and the systems, won't be too hard on them. Especially because I'll be wanting them to do it all again at the end of August, when I take my next week off.