Providing printing for a network is quite different to providing it for a single machine. On a single machine you simply attach a printer to the 'USB port' or 'parallel port'. However, for a network you have a dedicated machine (called a 'print server') that collects print jobs from any machine on the network, holds that job until a specified printer is ready (known as 'spooling'), and then feeds it to that printer. A good print server may also do a number of other useful things - like keeping track of usage statistics for departmental charging purposes, etc.

Printing in this way has a number of advantages. A major one is that it is far, far easier to administer - one or several central print servers are simpler for the IT team to look after than tens, hundreds or even thousands of different printers connected to and controlled by individual PCs all scattered around the building. Another advantage is that it increases the print options available - any user can send their print job to any selected printer (on the network), get back to work, then pick up the printed output later. They are no longer limited to the single printer directly attached to their PC.

What we're replacing:

Walk into any IT department in the country and ask them what their biggest user complaints are. I guarantee two of the TOP complaints will be "email's not working!" and "printing's slow/not working!".

Printing can be an IT support nightmare. Many businesses do it with one of the various flavours of Windows Server Edition, and very often this is at the root of the problem...

Firstly, there are all of the usual Windows issues. Instability, low uptimes, unexplainable crashes that need a reformat and reinstall to 'fix', virus susceptibility, poor security and, not least, the high cost of licences, CALs, support etc. But, more than this, using it to control printers brings loads more! Print jobs get lost or stuck, printers print out gibberish, scalability is dreadful forcing an unnaturally high ratio of servers to printers. And sometimes, perhaps just to keep us on our toes, it just stops printing and needs a reboot.

However, what I find even more worrying is that using Windows as a print server also drives you towards, or locks you further into, a Windows-only infrastructure. Try serving Macintosh or UNIX workstations from a Windows print server - it 'can' be done, but it's not easy, it's slow and it's even more unreliable! And if the business does require print services for Macs, there are no options, you have to purchase the even more expensive Windows Advanced Server (did you know, by the way, even though it's a Mac, once it's connected, you have to pay a Client Access Licence for the privilege! Money and trees spring to mind).

Here's how to change all that and get the fast, reliable, platform neutral print services your business needs plus save a great deal of money while you are at it.

Open Source, simply better software:

Once again, GNU/Linux and Open Source is simply the better business solution. As a print server, an Open Source solution is perfect. Since it is modular software, you only need to use the bits you require. This means you aren't forced to swamp the hardware with all that general purpose Windows code, you install made-for-the-job, fast, reliable, efficient modules that do precisely what you want. The end result? A lean, mean printing system that runs very, very happily on low spec hardware yet that delivers twice the speed of its Windows equivalent and is four times as scalable. And there are no licensing costs whatsoever. Now, won't the business like that!

Samba is the key to all this. After GNU/Linux, Samba is the 'crown jewels' of the Open Source world. You can think of it as an Open Source Windows Advanced Server on steroids. A network full of Windows desktops expects (in practice, demands) to see a Windows Server as its back-end. The genius of Samba is that it shows them one! Samba presents printers to your Windows desktops in exactly the same way as a Windows Server - so, from the user's perspective, it looks and feels like a Windows server. It is so seamless that all they see is that it is faster, it doesn't crash, and there are no viruses taking it out every few weeks.

Configuring Samba is simplicity itself edit a simple text file if you're an 'expert', fire up an easy-to-use GUI if you're not.

To complete the system you also need to install CUPS (the Common Unix Printing System) which handles the physical mechanics of printing. CUPS is a state-of-the-art printing system. Its many developers include HP's finest engineers, and they know a thing or two about printing so it ought to be good! Samba hands over the print jobs it receives from the Windows desktops to CUPS, which then handles the rest. Despite (or maybe because of...) the U for UNIX in the name, CUPS is a superior printing solution whether you're printing from UNIX, Windows or Apple Macintoshes. It is fully cross-platform and uses open protocols (IPP). It can handle any type, shape or breed of printer from lowly Deskjets to big lasers to esoteric poster printers, you name it, it handles it so no more problems with identifying, searching out and downloading drivers that work with the various versions of Windows you have in use. And once again, just like with Samba, configuring CUPS is a doddle text based or through a simple GUI.

So there you have it. A couple of day's work and you have all the printing system you'll ever need. And it really is as easy as that. You've now got a far more reliable, simpler and faster solution. You've eliminated one of the major causes of user complaints. You've reduced your exposure to, and dependency on, Windows technologies and the constant hardware/software upgrade treadmill they force you on. Even more, you've saved the business a great deal of money on hardware, support staff time, software licences and CALs.

And it's not through some kind of magic, it's simply because it's better software.

1. Introduction
   What is LDAP?
   Why use LDAP?
   Credits
2. Setting Up An OpenLDAP Server
   Install Master Server
   Secure Master Server with SSL/TLS
   Populate Master Server
   Summary of User Object Classes and Attributes Table
   Install Slave Servers
3. Configure UNIX Hosts for LDAP Logins
   LDAP enable Samba PDC For NT Workstation Logins
   Configure NT Workstations for LDAP Logins
4. LDAP enable Samba PDC for NT Workstation Logins
5. Configure NT Workstations for LDAP Logins

---

Introduction

What is LDAP:

LDAP stands for Lightweight Directory Access Protocol. OpenLDAP is an Open Source project that uses LDAP to deliver a fast, free, distributed directory service to organisations without locking them into dependence upon a single software vendor.

For example, prior to the use of centralized directory services separate directories were required for the domain itself, mailboxes, remote access, databases, and other applications. OpenLDAP enables a systems administrator to make a single entry in a directory which them gives a user account access to the network, access their email, access to corporate CRM systems or other mission-critical applications. In short, by using OpenLDAP as a multi-purpose directory an organisation enables single sign-on for its users. Once a user is authenticated by the network using OpenLDAP they will automatically unlock all of the applications or services that they have been enabled for.

Why use LDAP?:

• Single source of authentication.
• Simplifies administration.
• Obviates need for baroque/homebrew user account replication.
• Replacement for NIS, /etc/passwd, /etc/groups, /etc/shadow, NT users/groups, etc.
• Platform agnostic.
• Can be back-end for authenticating most services (email, ftp, proxy services, etc).
• Can be used for much more than just authentication (HR, phone lists, address books, etc).

Basically, the process is:

• Set up OpenLDAP server
• Configure UNIX Hosts for LDAP Logins
• LDAP enable Samba PDC For NT/2000 Workstations

Credits:

The following people were involved in the production of this HOWTO:
Regan Burke

Setting Up An OpenLDAP Server

Install Master Server:

The latest stable version (currently 2.1.16) of OpenLDAP can be downloaded from here.

The Administrators Guide (essential reading) may be downloaded from here.

Source Install Under Solaris 8:

Solaris 8 is quite broken out of the box. We strongly suggest you immediately implement the sage advice found in fixsolaris8.txt before continuing.

Download the latest stable release
./configure
make depend
make
make install

Source Install Under Debian GNU/Linux 3.0:

You will need the following packages installed prior to building the OpenLDAP server (apt-get is your friend!):

• gcc
• automake
• autoconf
• autotools-dev
• m4
• autoconf2.13
• libtool
• libtdl3
• libtdl3-dev

You will also need to build the Berkeley DB software from source

• Download latest stable release (currently 4.1.25) from here and un-gzip it into wherever you build your local software (say /usr/local/src)
• cd to the 'build_unix' directory
• ../dist/configure
• make
• make install
• Download the latest stable release and un-gzip it into wherever you build your local software (say /usr/local/src)
  ./configure
  make depend
  make
  make install

Non-Source Install Under Linux:

Debian:

The required packages are:

• libldap2
• slapd
• libiodbc2
• ldap-utils

Install using apt-get or dselect.
Configure according to the debian-specific documentation.
The slapd.conf file may require some further editing.
Firstly you will need to decide which schemas to include.
The core.schema must always be included.
If you wish to support Solaris 8, you must include the cosine.schema, nis.schema, inetorgperson.schema and the solaris.schema.
The nis.schema supplied with the distribution is borked. Please please contact us for a replacement.
If you intend to support Solaris 8, please contact us.
If you intend to use Samba, please contact us for the correct schema.
They should be placed in /etc/ldap/schema along with the others.
The latest Debian unstable also has migrationtools.

Secure Master Server with SSL/TLS:

This section has not been completed. please contact us for further details.

Populate Master Server:

How the server is populated depends on which operating systems you wish to support authentication on.
Currently, this howto covers Linux, FreeBSD, Solaris 8 and the various incarntations of Microsoft Windows.
It is possible (and desirable) to keep non-authentication related information in your server, such as adresses, email details, and even staff photos(!) if you want to.
You will also have to make decisions on the structure of your LDAP server in terms of groupings of entries.

1. Set up base dn with appropriate object classes and attributes.
2. Set up organisational units (e.g. People, Groups, Machines, etc.) with appropriate object classes and attributes.
3. Add individual entries for People, Groups, Machines, etc.

Please contact us for an example setup file to create the top level plus our suggested organisational units.
Obviously, you will need to customise this file to match your own organisation.
When you are happy with it, it can be installed to the ldap server by issuing the command

"ldapadd -f setup.ldif -h yourserver -x -D cn=admin,dc=siriusit,dc=co,dc=uk -w p455w0rd" as root.

Where 'yourserver', the domain components (dc's), and p455w0rd are suitably adjusted for your site. yourserver may be a hostname or an ip address.

User Accounts:

The minimum object classes needed for UN*X clients to authenticate UN*X users against the LDAP server are top, posixAccount and shadowAccount.
The definitive guide to these (and other) object classes is RFC 2307.

Suggested object classes to include for a user:

top
person
organizationalPerson
inetOrgPerson
account
posixAccount
shadowAccount
sambaAccount

Change the value of the following parameters to 2147483647
logoffTime
kickoffTime
pwdMustChange

Summary of User Object Classes and Attributes:

Objectclass	Attributes	Required?	Description
top			default
	ObjectClass	required	Object Class
person			Basic person
	cn	required	Common Name
	sn	required	Surname
	userPassword	optional	User's UN*X Password
	telephoneNumber	optional	Phone Number
	seeAlso	optional	Reference related LDAP entry
	description	optional	Description/Special Interests
organizationalPerson			Extended Person
	title	optional	Organisational Title
	x121Address	optional	Naming Standard defined in CCITT Rec. X.121
	registeredAddress	optional	Address where recipient guarantees to accept delivery
	destinationIndicator	optional	Used for telegrams
	preferredDeliveryMethod	optional	Single value favourite delivery method
	telexNumber	optional
	teletexTerminalIdentifier	optional
	telephoneNumber	optional
	internationaliSDNNumber	optional
	facsmilieTelephoneNumber	optional
	street	optional
	postOfficeBox	optional
	postalCode	optional
	postalAddress	optional
	physicalDeliveryOfficeName	optional
	ou	optional
	st	optional
	l	optional
inetOrgPerson			Extended Internet Person
	audio	optional
	businessCategory	optional
	carLicence	optional
	departmentNumber	optional
	displayName	optional
	employeeNumber	optional
	employeeType	optional
	givenName	optional
	homePhone	optional
	homePostalAddress	optional
	initial	optional
	jpegPhoto	optional
	labeledURI	optional
	mail	optional
	manager	optional
	mobile	optional
	o	optional
	pager	optional
	photo	optional
	roomNumber	optional
	secretary	optional
	uid	optional
	userCertificate	optional
	x500uniqueIdentifier	optional
	preferredLanguage	optional
	userSMIMECertificate	optional
	userPKCS12	optional
account			Basic Account
	userid	required	see uid (below)
	description	optional
	seeAlso	optional
	localityName	optional
	organizationName	optional
	organizationalUnitName	optional
	host	optional
posixAccount			Unix Account
	cn	required	Common Name (if a person, their full name)
	uid	required	User's login
	uidNumber	required	Number that uniquely identifies user to system
	gidNumber	required	Number that uniquely identifies group to system
	homeDirectory	required	Path to user's home directory
	userPassword	optional	User's UN*X Password
	loginShell	optional	UN*X login shell
	gecos	optional
	description	optional
shadowAccount			Unix Shadow Account
	uid	required
	userPassword	optional
	shadowLastChangeshadowMin	optional
	shadowMin	optional
	shadowMax	optional
	shadowWarning	optional
	shadowInactive	optional
	shadowExpire	optional
	shadowFlag	optional
	description	optional
sambaAccount			Windows User Account
	uid	required
	rid	required	Windows relative identifier
	cn	optional
	ImPassword	optional
	ntPassword	optional
	pwdLastSet	optional
	logonTime	optional
	logoffTime	optional
	kickoffTime	optional
	pwdCanChange	optional
	pwdMustChange	optional
	acctFlags	optional
	displayName	optional
	smbHome	optional
	homeDrive	optional
	scriptPath	optional
	profilePath	optional
	description	optional
	userWorkStations	optional
	primaryGroupID	optional
	domain	optional

 

Workstations:
posixAccount
sambaAccount

cn
uid
uidNumber
gidNumber
homeDirectory
rid

clean profiles directory
home directory

Group Accounts:

The minimum object classes needed for clients to retrieve groups from the LDAP server are top and posixGroup.

Summary of Group Object Classes and Attributes:

Objectclass	Attributes	Required?	Description
top			default
	objectClass	required	Object Class
posixGroup			Unix Group
	cn	required
	gidNumber	required
	userPassword	optional	UN*X password
	memberUid	optional
	description	optional

Summary of Workstation Object Classes and Attributes

Objectclass	Attributes	Required?	Description
top			default
	objectClass	required	Object Class
posixAccount			Unix Account
	cn	required
	uid	required
	uidNumber	required	UN*X uid
	gidNumber	required	UN*X gid
	homeDirectory	required	UN*X home directory
	userPassword	optional	UN*X password
	loginShell	optional	UN*X login shell
	gecos	optional
	description	optional

Install Slave Servers:

This ain't done either ;)

Configure UNIX Hosts for LDAP Logins

This is achieved by using PADL Software's open source pam_ldap and nss_ldap modules.

The pam_ldap module enables the client operating system to authenticate against your LDAP server, whilst the nss_ldap module enables the client operating system to retrieve session information (GECOS field type information) from your LDAP server.
Configuration is different under each client operating system, and depends upon whether you compile from source or use precompiled modules if available.

A basic intro to PAM may be downloaded (pdf format) from here
Further detail on the Linux implementation of PAM may be found here
Sun (who started it all) have a web page here
The Linux-PAM System Administrators' Guide may be found here

Source Install Under Solaris 8:

Make sure that the following programs from Sunfreeware are installed:

• autoconf
• automake
• libtool
• libiconv
• m4

Download PADL Software's pam_ldap and nss_ldap modules source code. Put them in /usr/local/src, or wherever you keep stuff you compile locally.
Back up your existing /usr/lib/nss_ldap.so.1 and /usr/lib/security/pam_ldap.so.1 files.

cd into the pam_ldap-152 directory.
Run "./configure"
Run "aclocal"
Edit the Makefile to remove "-llber" on line 115
Run "make"
Run "make install"

cd into the nss_ldap-201 directory.
Run "./configure"
Edit the Makefile to remove "-llber" on line 157
Run "make"
Run "chmod +x install-sh"
Run "make install"

Edit /etc/ldap.conf to suit your site.
add ldap.secret
Edit /etc/nsswitch.conf.
Finally, the PAM configuration file must be modified.
Modify the configuration file /etc/pam.conf - for each service you wish to LDAP-enable.
The modifications are quite simple, generally involving adding lines of the form:
type sufficient pam_ldap.so
where type is one of account, auth, password, or session.
/etc/init.d/nscd restart
The name service caching daemon (nscd) caches LDAP lookups locally to speed up authentication. There is a problem with synchroniation though.

Non-Source Install Under Linux:

Debian:

The required packages are:

• libldap2
• libpam0g
• libpam-ldap
• libnss-ldap
• nscd

Install using apt-get or dselect.

Debconf will ask you a few questions:

• Configuring Libnss-ldap - LDAP Server host - enter the ip address of your ldap server.

Edit /etc/pam_ldap.conf to suit your site.
The admin passwords needs to be in the file /etc/ldap.secret. chmod this file to 0600.
Edit /etc/libnss-ldap.conf to suit your site.
Edit /etc/nsswitch.conf to suit your site.
Finally, the PAM configuration files must be modified.
cd to /etc/pam.d/ and modify the configuration file for each service you wish to LDAP-enable.
The modifications are quite simple, generally involving adding lines of the form:

This month's OPEN For Business! continues our LDAP mini-series. The series is about using directory services to make administration of your network easier, and potentially, how to replace every bit of proprietary software you may have in the network with better Open Source software, plus how to tie it all together. So far, we've covered setting up a Directory Service based on OpenLDAP, and everything you need to do to create a single user account base and single sign-on across all of your Operating Systems, including Windows. This month we're going to begin making your Directory even more useful by moving into the realm of applications. I'm going to show you how to LDAPify (pronounced el-dap-if-eye!) your Open Source email system. You can see where this is going, can't you?

Got your CV ready?

Email systems are great! They've gone from being an obscure plaything known only to geeks to being the business critical application. Your users are guaranteed to whine about two things: "printing's not working!" and "email's not working!". And if they're correct about email not working for any length of time you'll be looking for your next job!

Email systems range from 'fast, scalable and rock solid' to 'extremely expensive and fundamentally broken'. The great news I've got for you is that it is simple to exchange them! The best email systems are, of course, Open Source.

Having said that, Open Source email systems traditionally have perceived weaknesses when compared to certain 'integrated' proprietary email products. Chief amongst these is the need to configure user account information in multiple places and configure system functionality in multiple files (e.g. underlying UNIX accounts, aliases files, virtual user tables, mutter mutter, sed, grep, awk... - you get my point...). Just imagine if you could build the ultimate integrated email system from best-of-breed Open Source components, keep each individual component dumb, but pointing to a single source of configuration information (which is where all the intelligence is).

Then, if that single source of information was easy to manage too, maybe even with a simple GUI (shock! horror!), you may even find Windows email System Administrators eager to exchange what they currently use for a licence free, killer, Open Source email platform.

Guess what? It's simple:

Here's the deal (you should be getting used to this by now). Once again, it's not rocket science, it is easy, it's fun, and it gives you a one Hell of a kick-ass IT system...

We're going to make a few enhancements to our OpenLDAP server first, starting with extending the info we keep on our users. Do you remember a couple of issues back I asked you to come up with a list of stuff that defines a user in IT terms (careful! - I heard that thought! - let's keep this clean...). Let's dig in and think about this in terms of email.

If email on your network works anything like it does on the ones I've set up, we end up with a simple list that looks something like:

• 'Home' email server
• Username ' i.e. Account on that email server
• Password
• One or more email addresses (occasionally with different domain names, but all ending up in the same inbox)
• A few 'housekeeping' rules (like quotas, etc.)

All these bits of information can be held in your LDAP Directory. And by now I reckon you know how we make the attributes available - that's right, we register some appropriate schemas.

Some of the attributes are available from schemas we've already got (things like email addresses and usernames). The others depend on the Open Source software you're going to be using for your email system. If you use Sendmail, for example, you'll probably want to use the 'sendmail.schema' file that comes with it.

Doing it - step by step:

Ok, time to make it real. Let's build an email server from scratch and integrate it with our newly email-enabled LDAP directory. I said earlier you can use any Open Source components - we're going to use Sendmail as our MTA. Sendmail is very easy to LDAPify, you simply add some lines to the Sendmail.cf telling it to do its lookups from your directory server. Once you've done this, Sendmail can get its aliases, routing information, authentication information, simply everything from the OpenLDAP directory. The beauty of this is that you don't ever have to touch this machine again - from now on you manage Sendmail from the LDAP directory, which is pretty great in itself.

Again, in the Open Source world, there's a wealth of 'user-facing' mail delivery software. We're going to choose the fantastic project Cyrus for LDAPification.

Cyrus is simply a superb, Enterprise Class Open Source mail storage system. It handles IMAP and POP, implements single instance storage, integrates beautifully with web-email front ends like Squirrelmail, has a delicious abstracted authentication subsystem called Cyrus SASL, and integrates with LDAP (through SASL) like nothing else I've ever seen. And here's a hot tip! Use the Cyrus patches the team at the University of Athens have created – they add invaluable functionality to Cyrus (like automatic account creation the first time a user in your LDAP directory connects to the Cyrus server or the first time an email is received for that user). Trust me, this kind of functionality makes administration of your system absolutely trivial.

LDAPifying Cyrus is simply a case of compiling it against your OpenLDAP libraries (or getting the LDAPified package for your favourite Linux distribution) plus adding a couple of lines to your config files to tell Cyrus SASL to get its account and authentication information from your LDAP Directory.

And, that's it. You're done!

Bells and whistles:

You can add as many bells and whistles as you like (say spam filtering and anti-virus, maybe even calendaring, voice messaging and email to fax gateway if you really want to get fancy). But what you've now got is an Enterprise Ready email system that's fully integrated with, and managed from, your Open Source Directory Server. Now, how cool is that?

So there we are. We've made our start with applications. We've taken over the most user-critical network service and we've exchanged it for a far, far better one!

Next month I'm going to round up our LDAP mini-series by showing you how to integrate a batch of other services, plus build a company wide address book. By the time we've finished you'll be in no doubt that you can do everything the proprietary Directory Servers do for you, and do it far, far better, using superior Open Source software. It will be far faster and far more reliable. You won't be locked in to the continual upgrade cycle, and you won't have to pay those extortionate licence fees.