LPI exam 301 prep, Topic 305: Integration and migration Use your LDAP server alongside an Active...

LPI exam 301 prep, Topic 305: Integration andmigrationSenior Level Linux Professional (LPIC-3)

Skill Level: Intermediate

Sean Walberg ([email protected])Network engineerFreelance

08 Apr 2008

In this tutorial, Sean Walberg helps you prepare to take the Linux® ProfessionalInstitute Senior Level Linux Professional (LPIC-3) exam. In this fifth in a series of sixtutorials, Sean walks you through integrating LDAP with your system's logins andapplications. He also details the procedure to integrate your server into a foreignMicrosoft® Active Directory.

Section 1. Before you start

Learn what these tutorials can teach you and how you can get the most from them.

About this series

The Linux Professional Institute (LPI) certifies Linux system administrators at threelevels: junior level (also called "certification level 1"), advanced level (also called"certification level 2"), and senior level (also called "certification level 3"). To attaincertification level 1, you must pass exams 101 and 102. To attain certification level2, you must pass exams 201 and 202. To attain certification level 3, you must havean active advanced-level certification and pass exam 301 ("core"). You may alsopass additional specialty exams at the senior level.

Integration and migration© Copyright IBM Corporation 1994, 2008. All rights reserved. of 47

mailto:[email protected]

http://www.ibm.com/developerworks/views/linux/libraryview.jsp?end_no=100&lcl_sort_order=asc&type_by=All+Types&sort_order=asc&show_all=false&sort_by=Title&search_by=lpi+301&topic_by=All+topics+and+related+products&search_flag=true&show_abstract=true


http://www.lpi.org

http://www.ibm.com/legal/copytrade.shtml

developerWorks offers tutorials to help you prepare for the five junior, advanced, andsenior certification exams. Each exam covers several topics, and each topic has acorresponding self-study tutorial on developerWorks. Table 1 lists the six topics andcorresponding developerWorks tutorials for LPI exam 301.

Table 1. LPI exam 301: Tutorials and topicsLPI exam 301 topic developerWorks tutorial Tutorial summary

Topic 301 LPI exam 301 prep:Concepts, architecture, anddesign

Learn about LDAP conceptsand architecture, how todesign and implement anLDAP directory, and aboutschemas.

Topic 302 LPI exam 301 prep:Installation and development

Learn how to install, configure,and use the OpenLDAPsoftware.

Topic 303 LPI exam 301 prep:Configuration

Learn how to configure theOpenLDAP software in detail.

Topic 304 LPI exam 301 prep:Usage

Learn how to search thedirectory and use theOpenLDAP tools.

Topic 305 LPI exam 301 prep:Integration and migration

(This tutorial) Learn how touse LDAP as the source ofdata for your systems andapplications. See the detailedobjectives.

Topic 306 LPI exam 301 prep:Capacity planning

Coming soon.

To pass exam 301 (and attain certification level 3), the following should be true:

• You should have several years of experience with installing andmaintaining Linux on a number of computers for various purposes.

• You should have integration experience with diverse technologies andoperating systems.

• You should have professional experience as, or training to be, anenterprise-level Linux professional (including having experience as a partof another role).

• You should know advanced and enterprise levels of Linux administrationincluding installation, management, security, troubleshooting, andmaintenance.

• You should be able to use open source tools to measure capacityplanning and troubleshoot resource problems.

developerWorks® ibm.com/developerWorks

Integration and migration of 47 © Copyright IBM Corporation 1994, 2008. All rights reserved.

http://www.ibm.com/developerworks/edu/l-dw-linux-lpic3301-i.html










• You should have professional experience using LDAP to integrate withUNIX® services and Microsoft® Windows® services, including Samba,Pluggable Authentication Modules (PAM), e-mail, and Active Directory.

• You should be able to plan, architect, design, build, and implement a fullenvironment using Samba and LDAP as well as measure the capacityplanning and security of the services

• You should be able create scripts in Bash or Perl or have knowledge of atleast one system programming language (such as C).

To continue preparing for certification level 3, see the series developerWorkstutorials for LPI exam 301, as well as the entire set of developerWorks LPI tutorials.

The Linux Professional Institute doesn't endorse any third-party exam preparationmaterial or techniques in particular.

About this tutorial

Welcome to "Integration and migration," the fifth of six tutorials designed to prepareyou for LPI exam 301. In this tutorial, you'll learn all about integration of LDAP withauthentication and other UNIX services.

This tutorial is organized according to the LPI objectives for this topic. Very roughly,expect more questions on the exam for objectives with higher weights.

Objectives

Table 2 provides the detailed objectives for this tutorial.

Table 2. Integration and migration: Exam objectives covered in this tutorialLPI exam objective Objective weight Objective summary

305.1LDAP integration with PAMand NSS

2 Integrate the core systemauthentication with LDAP.

305.2NIS to LDAP migration

1 Plan and implement a NISmigration strategy, includingthe deployment of a NIS toLDAP gateway.

305.3Integrating LDAP with UNIXservices

1 Use your LDAP server as thesource of data for SSH, FTP,HTTP, and other services.

305.4Integrating LDAP with Samba

1 Use your LDAP server as thesource of data for Samba.

ibm.com/developerWorks developerWorks®




http://www.ibm.com/developerworks/linux/lpi/index.html


305.5Integrating LDAP with ActiveDirectory

2 Use your LDAP serveralongside an Active Directoryservice.

305.6Integrating LDAP with e-mailservices

1 Integrate your e-mail serviceswith your LDAP directory.

Prerequisites

To get the most from this tutorial, you should have advanced knowledge of Linuxand a working Linux system on which to practice the commands covered.

If your fundamental Linux skills are a bit rusty, you may want to first review thetutorials for the LPIC-1 and LPIC-2 exams.

Different versions of a program may format output differently, so your results maynot look exactly like the listings and figures in this tutorial.

System requirements

To follow along with the examples in these tutorials, you'll need a Linux workstationwith the OpenLDAP package and support for PAM. Most modern distributions meetthese requirements.

Section 2. LDAP integration with PAM and NSS

This section covers material for topic 305.1 for the Senior Level Linux Professional(LPIC-3) exam 301. This topic has a weight of 2.

In this section, learn how to:

• Configure NSS to retrieve information from LDAP

• Configure PAM to use LDAP for authentication

• Configure PAM modules in various UNIX environments

In traditional UNIX fashion, PAM and the Name Service Switch (NSS) facilitiesabstract various components of authentication and lookup from their implementation,which allows the administrator to change backend data stores without recompiling



http://www.ibm.com/developerworks/linux/lpi/index.html


any applications. For instance, moving from traditional /etc/passwd-basedauthentication to the Network Information Service (NIS) is transparent because NSSis implemented as part of the C library. Applications make use of the standard librarycalls such as getpwent(3) to look up users, but through some configurationmagic, the data is redirected to another store like NIS.

PAM is a slightly different animal, because applications must be written specificallywith PAM in mind. Administrators can use a rich set of libraries to customize thebehavior of a PAM-aware application, such as requiring specific group membershipand a login time in order to successfully authenticate.

PAM and NSS can work in tandem for user authentication. PAM-aware applicationsinstruct PAM to check the user's credentials. The administrator can configure PAMto check the password through the NSS facility in addition to any other restrictions.PAM is used only for the password and shadow databases, not others like groupsand hosts.

LDAP support for both PAM and NSS is provided by an open source package fromPADL software.

Configure NSS to use LDAP

The NSS facility is implemented in the C library as a hook to traditional library callsto get information. The C library provides functions like getpwent to get userinformation and gethostbyname(3) for host information, which traditionally wereimplemented as lookups to /etc/passwd and /etc/hosts, respectively. Theadministrator can force hostname lookups to also use the Domain Name Service(DNS) by configuring NSS, meaning the application is unaware of the change.

Understand NSS

Table 3 outlines the databases that are handled by NSS. Most databases have acorresponding file in /etc, where the data is traditionally stored.

Table 3. NSS databasesDatabase name Description

aliases Mail aliases for sendmail, used to forward(alias) one local address to anotheraddress.

ethers Maps ethernet addresses to IPaddresses. Rarely seen anymorebecause of the availability of the AddressResolution Protocol (ARP).

group Contains a list of groups and the usersthat belong to them.




hosts Maps IP addresses to host names.

netgroup Used to group servers together. Mostoften used for NIS and Network FileSystem (NFS) security.

networks A map of network names to numbers. Notoften used because knowing the name ofthe network provides little value.

passwd Stores user account information such asname, Userid, description, primary group,home directory, and sometimes apassword.

protocols Maps IP protocols to their name.

publickey Used to distribute keys for NFS andNIS+.

rpc Maps Remote Procedure Call (RPC)function names to numbers.

services Maps TCP and UDP service names tothe port number.

shadow A protected, encrypted, password file.Usually the password field from/etc/passwd is stored in this file to keep itsafe.

NSS is configured in /etc/nsswitchconf and contains one line per database fromTable 3. Listing 1 shows a sample nsswitch.conf.

Listing 1. Sample nsswitch.conf

passwd: files nisshadow: files nisgroup: files nishosts: files nis dns

Listing 1 configures four maps: passwd, shadow, group, and hosts. The name of themap is followed by a colon (:) and then an ordered list of ways to access the data.The first three lines in Listing 1 are all the same: they first check the files for therequested information and then the NIS, sometimes known as the Yellow Pages.NIS is checked only if nothing is found in the files. The final line of the examplechecks the files (/etc/hosts), NIS, and then DNS for any hosts requests.

The methods available to be used in nsswitch.conf have a corresponding library in/lib that begins with libnss_. The functionality for files, for example, is found in/lib/libnss_files-2.5.so (the version number isn't important because it's resolved bythe dynamic linker, ld-linux.so).




Introducing LDAP to NSS

After the previous discussion about dynamic libraries and the format ofnsswitch.conf, it should come as no great surprise that LDAP integration with NSS ishandled through a shared library called libnss_ldap and is referenced through theldap keyword in /etc/nsswitch.conf. This shared library takes its configuration from/etc/ldap.conf (not to be confused with the OpenLDAP configuration file for thecommand-line clients, /etc/openldap/ldap.conf). Listing 2 shows a sample ldap.conf.

Listing 2. A sample ldap.conf to configure libnss_ldap

# Server IP address (or space-separated addresses)host 192.168.1.138# Search basebase dc=ertw,dc=com# optional: bind credentialsbinddn: cn=nssldap,dc=ertw,dc=combindpw: letmein# If root is making the request, use this dn instead# The password is stored in /etc/ldap.secret and only readable by rootrootbinddn cn=root,dc=ertw,dc=com# Point the passwd, shadow, and group databases at a DN# the ?one defines the scopenss_base_passwd ou=People,dc=ertw,dc=com?onenss_base_shadow ou=People,dc=ertw,dc=com?onenss_base_group ou=Group,dc=ertw,dc=com?one# Don't look for secondary groups for any of these usersnss_initgroups_ignoreusersroot,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd

In addition to the content of /etc/ldap.conf shown in Listing 2, you also need to addthe keyword ldap to the passwd, shadow, and group lines in /etc/nsswitch.conf.Always make sure to have files as the first entry; otherwise, you may find yourselfwaiting for downed servers to time out—or you may even be locked out of yoursystem. (If you're locked out because of a problem with nsswitch.conf, boot tosingle-user mode, reset nsswitch.conf back to files, and then reboot.)

It's possible to use LDAP for all the databases, but the three listed here are the onesthat are useful. The other maps rarely change and should be managed separately.The exception is the hosts database, which can use LDAP, although DNS is amuch better choice.

Test it out

If you've got nsswitch.conf and ldap.conf configured properly, then you should beable to log in with an LDAP user, as long as the following attributes are available:

• uid: The login name

• uidNumber: The numeric userid

• gidNumber: The number primary groupid




• homeDirectory: The user's home directory

• userPassword: The user's password, encrypted with the {crypt}routine (use slappasswd to generate this)

These attributes and more are added through the posixAccount objectClass.

To test, try to log in as a user who is in your LDAP tree but not in the local passwordfiles. You can also use the getent passwd command to look at all the user entriesNSS knows about. If getent works but the login doesn't, your userPasswordattribute is likely incorrect.

If you've verified your configuration on the client, and NSS and LDAP still don't worktogether, enable stats-level logging on the OpenLDAP server and see if yourqueries are being seen by the server, and if they're being allowed.

Configure PAM to use LDAP

PAM is much like NSS in that it abstracts a set of library calls from the actualimplementation. Unlike NSS, PAM doesn't replace existing UNIX calls; instead, itprovides a set of new calls that applications can use.

Understand PAM

PAM is implemented as a library that applications use. Applications call this library touse the PAM management functions of checking authentication, accountmanagement, session management, and password management.

Checking authentication is the prime purpose of PAM. The application asks the PAMlibraries whether the user is authenticated. The PAM libraries, in turn, follow therules laid out by the systems administrator to prompt the user for a password orperform any number of other checks.

Account management is run after a user provides valid credentials and isresponsible for checking to see if the login is allowed. A login may not be allowed atcertain times or to certain applications.

Session management gives the application an opportunity to set up the environmentafter a successful login. It's often desirable to give the user logged into the consolesome extra permissions, such as the use of the local CDROM or other devices; thisis done at the session-management level.

Finally, password management provides a flexible way to change passwords. Asyou'll soon see, this functionality lets users change their LDAP passwords throughthe familiar passwd(1) program. PAM password management also allows you tospecify password-strength policies that operate independently of the password




backend.

To configure PAM for a service, you must create a file named after the service in/etc/pam.d, such as /etc/pam.d/sshd for the sshd service. This isn't a hard-and-fastrule, because the application specifies its own PAM service name. When in doubt,use the name of the binary, and check the logs for errors.

Each configuration file in /etc/pam.d specifies an ordered list of instructions for eachof the PAM management functions. Each line in the file is of the form functioncontrol module arguments. The function is the management function, usingkeywords auth, account, session, and password.

The control specifies how the return value of the instruction being evaluated is to beused, and is one of the following keywords:

• required -- This check must succeed if the function is to succeed. If thischeck fails, then PAM will continue to check the rest of the instructions forthe given function, but the results are meaningless.

• requisite -- This check must succeed if the function is to succeed. Ifthis check fails, then PAM will stop checking the rest of the instructionsand return a failure.

• sufficient -- If this check succeeds, processing stops and the functionreturns successfully, assuming no previous "required" elements havefailed. If this check fails, the failure is ignored and processing continues.

• optional -- The results of the check are ignored.

The module and the arguments implement the check itself. The same module canimplement one or more of the functions described, so you may see the same modulelisted several times. One module you'll see used often is pam_stack, which lets youcall instruction stacks from other files. Listing 3 shows a PAM file that usespam_stack.

Listing 3. Using pam_stack to call other instruction stacks

auth required pam_nologin.soauth required pam_stack.so service=system-authaccount required pam_stack.so service=system-authsession required pam_stack.so service=system-authpassword required pam_stack.so service=system-auth

Listing 3 shows the format of a PAM file. The auth function has two lines, both ofwhich are required and therefore must succeed in order for a successfulauthentication to happen. The first auth line calls pam_nologin, whose job is tofail if a non-root user tries to log in when the /etc/nologin file exists. The next authline calls the pam_stack module and passes it service=system-auth.




pam_stack.so then reads the contents of /etc/pam.d/system-auth and checks all theinstructions under the auth function. If that returns a success, pam_stack returns asuccessful result back to the file in Listing 3.

The other three functions— account, session, and password —make referenceonly to pam_stack and the system-auth service. If the respective functions fromsystem-auth return successfully, then the result is considered a success.

Many systems have a common set of routines for authentication, so pam_stack isused in most files, with the system-auth (or equivalent) containing all the interestingparts. For the rest of this section, the system-auth file will be the one used to injectLDAP into the PAM process.

Introducing LDAP to PAM

Both the NSS and PAM modules use /etc/ldap.conf for configuration, so if you'refollowing along, you're halfway to having a working PAM-LDAP system. It's possibleto use NSS and PAM together so that both PAM-aware and legacy applications canauthenticate to LDAP. PAM provides some new features on top of NSS, includingthe following:

• Password changes by users

• More granular configuration of authentication requirements

• Support for more password encryption types

• Centralized administration of user accounts

Ensure that pam_password md5 is in /etc/ldap.conf, and remove any otherpam_password lines if they exist. This tells the pam_ldap library to hash thepassword with Message Digest 5 (MD5) locally before sending it to the LDAP serverwhen changing passwords.

Edit your /etc/pam.d/system-auth (or equivalent) to add the references to pam_ldap,as shown in Listing 4. The line should go after any references to pam_unix (so thatlocal accounts take precedence over LDAP accounts) but before any references topam_allow and pam_deny (which provide a default allow or deny).

Listing 4. New system-auth that uses pam_ldap

auth sufficient pam_unix.so nullok try_first_passauth sufficient pam_ldap.so use_first_passauth required pam_deny.so

account required pam_unix.so broken_shadowaccount sufficient pam_ldap.so

account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3




password sufficient pam_unix.so md5 shadow nullok try_first_passuse_authtokpassword sufficient pam_ldap.so use_authtokpassword required pam_deny.so

session required pam_limits.sosession required pam_unix.sosession optional pam_ldap.so

The lines in bold show additions to the PAM configuration file. Note the addition ofbroken_shadow in the account function of pam_unix. This ensures thatpam_unix.so doesn't return a failure if the user doesn't have a shadow entry (which itdoesn't, because the account is in LDAP).

The use_first_pass option to the auth module of pam_ldap forcespam_ldap.so to use the password obtained from pam_unix.so rather than ask for anew password. use_authtok does a similar thing for the password function.

For authorization, the new configuration makes both UNIX passwords and LDAPpasswords sufficient to log in: that is, the first one to succeed allows the user to login. If neither returns success (either a failure, or "no such user"), then pam_denycauses a failure.

Test it out

Try to change a user's password through the passwd command, and then verify thatthe password was changed in the LDAP directory. Finally, ensure the user can stilllog in.

If you were able to get NSS working, PAM should also work. The biggest opportunityfor error is mistyping the entries in the PAM configuration, putting the entries in thewrong file, or putting them in the wrong place in the file.

Section 3. NIS to LDAP migration



• Analyze NIS structure prior to migration to LDAP

• Analyze NIS structure prior to integration with LDAP




• Automate NIS-to-LDAP migration

• Create a NIS-to-LDAP gateway

NIS is the traditional method of central authentication for UNIX machines. NIS issimple to set up and works well. Despite being more complex, LDAP authenticationis superior to NIS in several ways:

• LDAP is more secure than NIS because you can encrypt the traffic andlock down the database.

• LDAP can store more than just authentication data, whereas NIS islimited.

• LDAP is accessible by more clients than is NIS.

You can choose to replace NIS with LDAP or use both simultaneously. When youuse them together, LDAP is the canonical data source, and the NIS server uses datafrom LDAP instead of local files. This is a good approach for a longer-term migrationor for supporting legacy operating systems that won't work with LDAP.

Approach 1: Migrate to LDAP

The general approach to migrating from NIS to LDAP is as follows:

1. Determine which NIS databases need to be replaced.

2. Load the NIS data into LDAP.

3. Reconfigure the clients to use LDAP instead of NIS.

For the time between the start of step 2 and the end of step 3, you have two activedatabases with no connections. Any changes, such as adding a user or changing auser's password, must be done on both databases; otherwise, your data maybecome inconsistent. You may elect to put a freeze on all changes or go with anintegration strategy as shown in the next section.

Analyze your existing NIS structure

Before performing any migration, you must determine which databases are beinghosted by NIS. Log in to the NIS master server, and look in the database directory.On most systems, the files are stored in /var/yp/, in a directory named after thedomain name. Listing 5 shows the files in a typical NIS server's database directory.

Listing 5. Determining which databases are served by NIS




# ls /var/yp/`domainname`group.bygidgroup.bynamehosts.byaddrhosts.bynamemail.aliasesnetid.bynamepasswd.bynamepasswdbyuidprotocols.bynameprotocols.bynumberrpc.bynamerpc.bynumberservices.bynameservices.byservicenameypservers

Listing 5 uses the domainname command to display the domain name. Whenplaced inside backticks (`), the result of this command is inserted in the commandline. With the exception of the ypservers file, all the other files in this directoryrepresent a NIS database. Gather the list of unique database names to determinewhich databases need to be moved to LDAP. NIS stores the same data withdifferent lookup keys, such as by name and UID in the case of the password file; inthis case, they both represent the password database. Some aren't obvious: forexample, mail.aliases is the aliases table. If in doubt, look in /var/yp/Makefile todetermine the source of the database.

After looking at the server, you may wish to examine some of your NIS clients todetermine which maps they're using. To do so, look for the nis keyword in/etc/nsswitch.conf. You'll probably find that your server is storing more maps thanare being used.

Use the migration tools

The most popular tools to migrate NIS data to LDAP are provided by PADL software,the makers of pam_ldap, nss_ldap, and the NIS-LDAP gateway discussed later.Chances are, your distribution includes the files; otherwise, you can find links to thetools in the Resources section. The PADL migration tools can take data from localfiles, NIS, or NIS+ and dump them into your LDAP server.

Before using the PADL tools, you must have your LDAP server up and running withno data. The tools will generate all the entries necessary, and you want to avoidduplication.

The migration tools consist of a set of shell and perl scripts. On RedHat systems, thescripts are part of the openldap-servers package and are found in/usr/share/openldap/migration directory. Debian users will want themigrationtools package. Look for a file called migrate_base.pl, or download thelatest version from PADL.




These scripts take data from a variety of sources, convert it to LDIF, and then add itto your server. Data is added with the ldapadd command in online mode andthrough slapadd in offline mode, so you'll need administrative credentials for theformer, and you'll need to have your LDAP process stopped for the latter.

Before getting started, you'll find it helpful to set some environment variables to setup the base domain name (DN) of the tree and your root DN. Listing 6 shows thebash commands to prepare for migration of the ertw.com domain.

Listing 6. Setting environment variables in preparation for an LDAP migration

export LDAP_BASEDN="dc=ertw,dc=com"export LDAP_BINDDN="cn=root,dc=ertw,dc=com"export LDAP_DEFAULT_MAIL_DOMAIN=ertw.com

The first line in Listing 6 is the base DN of the LDAP tree, which will be used togenerate all the DNs later. The second line is your root DN. You need the passwordonly if you're using online mode. The final line of Listing 6 sets the default domainname for e-mail addresses. Some of the tools won't prompt you for this information,so setting it now will prevent aggravation later on.

The tools are split into two categories. The files in the first category have namesstarting with migrate_all_. The second category includes the remaining files,which have names beginning with migrate_ followed by the name of a file ordatabase. The scripts in the first category are used to gather the data together; thesecond category is used to convert the native format into LDIF.

You now have two options. You can use one of the migrate_all_ scripts, whichwill automatically grab all the common databases from your chosen location (NIS,files, NIS+m, and so on); or you can grab only the relevant data yourself and use theindividual migration scripts to convert the data into LDIF. The first approach, when itworks, is easier. Listing 7 shows the use of migrate_all_nis_online.sh to migrate allthe data from NIS into LDAP in online mode.

Listing 7. Migrating data from NIS to LDAP using the migrate_all_nis_online.shscript

[root@server1 migration]# ./migrate_all_nis_online.shEnter the NIS domain to import from (optional):No such map networks.byaddr. Reason: Internal NIS errorEnter the hostname of your LDAP server [ldap]: localhostEnter the credentials to bind with: mypasswordDo you wish to generate a DUAConfigProfile [yes|no]? no

Importing into dc=ertw,dc=com...

Creating naming context entries...Migrating groups...Migrating hosts...Migrating networks...




Migrating users...Migrating protocols...Migrating rpcs...Migrating services...Migrating netgroups...Migrating netgroups (by user)...sh: /etc/netgroup: No such file or directoryMigrating netgroups (by host)...sh: /etc/netgroup: No such file or directoryadding new entry "dc=ertw,dc=com"

Importing into LDAP...adding new entry "ou=Hosts,dc=ertw,dc=com"..... output omitted ...adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"

adding new entry "cn=rquotad,ou=Rpc,dc=ertw,dc=com"ldap_add: Already exists (68)

/usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to/tmp/nis.ldif.X17515

Listing 7 starts by running the migrate_all_nis_onlinesh script, which grabs data fromNIS, converts it to LDIF, and then uses ldapadd to import the data. The first queryfrom the script is the NIS domain; you can press Enter for the default NIS domain onthe system. The script then imports the NIS data (on this system, a nonfatal error isprinted because the networks map isn't used). The script prompts for information onthe LDAP server, such as the hostname and the password (the bind DN and baseDN were learned through the environment variables you entered in Listing 6). Youshould choose not to import a DUAConfigProfile unless you have a schema thatsupports it, which is unlikely.

If, at this point, you start getting errors about invalid DN syntax, be sure you'veimported the nis.schema file inside slapd.conf.

If your schema is correct, the script will import data into your LDAP tree. It's likelythat the script may die with an error such as the one seen at the end of Listing 7.Because of the way data is stored in NIS, you may have duplicate entries in somedatabases. This is fine in NIS but not in LDAP. There are a few solutions to thisproblem, depending on your needs:

• Edit the LDIF file (/tmp/nis.ldif.X17515 in this case) to remove theduplicates, and then delete your LDAP database and import the file.

• Tell ldapadd to ignore errors with the -c option. exportLDAPADD="/usr/bin/ldapadd -c" will do this. (Note that the scriptwill still report an error, but the data will have been imported.)

• Edit migrate_all_nis_online.sh to set the value of ETC_SERVICES,ETC_PROTOCOLS, and ETC_RPC to /dev/null instead of a temporary file.Doing so skips processing the database. (Note that some of themigrate_all_ scripts can be overridden by environment variables, but not




the NIS variant.)

• Skip migrate_all_nis_online.sh, and migrate by hand.

The first three options are self explanatory and effective as long as you'recomfortable with the results (such as not having protocols, RPC, and services inLDAP for the third option). The fourth option needs some explanation.

If all you want to do is move groups and users over to LDAP, you can just as easilycopy the files yourself and generate the LDIF using the other scripts provided, andusing ypcat to get the data out of NIS. Listing 8 shows the process.

Listing 8. Migrating groups and users by hand

[root@server1 migration]# ypcat passwd > /tmp/passwd.tmp[root@server1 migration]# ypcat group > /tmp/group.tmp[root@server1 migration]# ./migrate_base.pl > /tmp/ldif[root@server1 migration]# ./migrate_passwd.pl /tmp/passwd.tmp >> /tmp/ldif[root@server1 migration]# ./migrate_group.pl /tmp/group.tmp >> /tmp/ldif[root@server1 migration]# ldapadd -x -D "cn=root,dc=ertw,dc=com" \-w "mypassword" -f /tmp/ldif

adding new entry "dc=ertw,dc=com"adding new entry "ou=Hosts,dc=ertw,dc=com"..... output omitted ...

The first two lines of Listing 8 use ypcat to get the data from NIS into a file in /tmp.The next three lines generate LDIF. migrate_base generates some basic entriesin the tree, and the next two lines convert the password and group files to LDIF.Note the use of the append operator (>>), so the resulting file will contain the outputof all three migration scripts. Finally, you call ldapadd to import the data.

Whichever way you go, perform some basic searches to make sure you can see thedata. Be sure you can see the password hashes (use the root DN for this, becauseit's possible you have an access control list preventing passwords from being seen).

At this point, you have your NIS data in LDAP. Until all your NIS clients are movedover, all changes to NIS must be replicated to LDAP and vice versa.

Move the clients and verify results

Moving the clients is a simple matter of setting up NSS and PAM on the client. Theprevious section covered this in detail. In brief, you populate /etc/ldap.conf with yourserver information and edit /etc/nsswitch.conf to replace nis with ldap. If you'resetting up PAM, then you need to edit the relevant files in /etc/pam.d to addreferences to pam_ldap.so.

Test your clients by logging in to them as a regular user and running the getentcommands on the databases you moved to LDAP.




Approach 2: Integrate with LDAP

The second approach calls for the coexistence of NIS and LDAP. This can be helpfulif you have clients that don't speak LDAP (either by not having a native LDAPmodule or by not supporting PAM), or if you want to spread out your transition over alonger period of time. The approach for a NIS/LDAP coexistence is similar to the firststrategy:

1. Determine which NIS databases are in use.

2. Load the NIS data into LDAP.

3. Replace your NIS servers with ypldapd.

4. Reconfigure the clients that will be using LDAP.

The clients that will continue to use NIS need no changes because ypldapd is afully functional NIS server. The only difference between it and the standard ypservthat comes with your operating system is that ypldapd gets its data from LDAPinstead of local files.

The first two steps are the same as the first approach, so you begin at step 3.

Replace your NIS servers with ypldapd

ypldapd is a NIS server daemon that gets its information from LDAP instead of thedatabase files in /var/yp. It's commercial software from PADL, but you can get a30-day trial license by e-mailing PADL (see the Resources). Installation of ypldapdis a simple process:

1. Untar the software to /opt/ypldapd.

2. Copy the license to /opt/ypldapd/etc/padlock.ldif.

3. Edit the configuration file, /opt/ypldapd/etc/ypldapd.conf

4. Stop your existing NIS server.

5. Start up ypldapd.

First, run mkdir -p /opt/ypldapd as root to make the ypldapd directory (and/opt, if it doesn't already exist). Change into this directory (cd /opt/ypldapd), anduntar the ypldapd distribution with tar -xzf/tmp/ypldapd_linux-i386.tar.gz. This places the ypldapd files in the




proper directory.

You'll have been given a license file, which you'll place in/opt/ypldapd/etc/padlock.ldif. If you're copying it from an e-mail, then make sure youre-mail client didn't wrap long lines: the key should be four lines long with a series ofattribute:value pairs.

ypldapd's configuration file is in /opt/ypldapd/etc/ypldapd.conf. There is a file calledypldapd.conf.sample that you can copy to start with. As with the other utilities you'veseen so far, you need to provide information about your LDAP server. Listing 9shows a simple ypldapd.conf.

Listing 9. Sample ypldapd.conf

# The NIS domain nameypdomain ertw# The LDAP server and base DNldaphost localhostbasedn dc=ertw,dc=com# Credentials... The user must be able to read the userPassword attributebinddn cn=ypldapd,dc=ertw,dc=combindcred mypassword# The map of NIS databases to DNs (relative to basedn)# If you used the migration tools then you shouldn't have to change anythingnamingcontexts namingcontexts.conf# Should ypldapd cache data?caching on# Cache lifetime, in minutescache_dump_interval 15# Should passwords be hidden?hide_passwords off# How many ypldapd servers can be running at a given time?maxchildren 5

With ypldapd.conf in place, you can shut down all instances of ypserv and then runsbin/ypldapd, which starts ypldapd in the background.

Move the clients and verify results

To test your new NIS server, run ypwhich, which tells you which NIS server you'rebound to. If you get an error, make sure that no other instances of ypserv arerunning and that only one ypldapd is running. Then, try to fetch a map by typingypcat passwd (this assumes your server was also running a client).

Clients that will be staying with NIS should also be able to run ypwhich and ypcatagainst the new server. For clients that will be moving to LDAP, see the previous setof instructions for the migration.




Section 4. Integrate LDAP with UNIX services



• Integrate SSH with LDAP

• Integrate FTP with LDAP

• Integrate HTTP with LDAP

• Integrate FreeRADIUS with LDAP

• Integrate print services with LDAP

Most applications will work correctly with LDAP if you've configured NSS and PAM.Some applications need to be told to use PAM, or provide additional functionality byaccessing LDAP correctly. This section focuses on the common UNIX daemons andhow they support LDAP integration.

Integrate SSH with LDAP

The OpenSSH distribution integrates with LDAP through PAM, as long as thefunctionality was compiled in. To check, run ldd /usr/sbin/sshd | grep pamto see if the PAM shared libraries are linked. If not, you must recompile sshd with--with-pam.

To use PAM, be sure you have a PAM configuration file named /etc/pam.d/sshd ifone doesn't exist already. Listing 10 shows a sample PAM file that makes use of thesystem-auth stack.

Listing 10. A sample /etc/pam.d/system-auth

auth required pam_stack.so service=system-authaccount required pam_stack.so service=system-authpassword required pam_stack.so service=system-authsession required pam_stack.so service=system-auth

With the PAM configuration file in place, you can configure sshd to work with PAM.In /etc/ssh/sshd_config, add UsePAM yes, and restart sshd.




Integrate FTP with LDAP

Many FTP daemons are available, and it isn't clear which ones apply to the LPIC 3exam.

The easiest integration method is to rely on NSS integration. When the FTP serverperforms a password lookup, the NSS facility uses LDAP.

In modern times, though, FTP servers are likely to be built with PAM support. Inthese cases, you create your PAM configuration file in /etc/pam.d. This file is usuallycalled ftp, but it can be overridden depending on the software and distribution. Forexample, RedHat packages the vsftpd daemon to use /etc/pam.d/vsftpd instead ofthe default /etc/pam.d/ftp.

Once the ftp daemon has found its PAM configuration file, it processes it just likeany other PAM client. The configuration in Listing 10 is enough to get started. Youmay also consider using pam_listfile.so item=user sense=denyfile=/etc/ftpusers onerr=succeed and pam_shells in the auth phase tolimit the users who can log in and the valid shells, like the legacy FTP servers did.

Integrate HTTP with LDAP

The Apache Web server has modules that handle basic HTTP authentication with anLDAP backend instead of the traditional htpasswd file-based backend. This isprovided through the mod_authnz_ldap and mod_ldap modules. The first moduleprovides the mechanisms to use LDAP information to authenticate a Web user,whereas mod_ldap provides an interface for mod_authnz_ldap (or any futureLDAP-based module) to access LDAP, including connection pooling and caching.

The instructions in this section refer to Apache 2.2. If you're using Apache 2.0, themod_auth_ldap module is used instead of mod_authnz_ldap. Configuration ofthese two modules is similar.

Both mod_ldap and mod_authnz_ldap are part of the Apache distribution. If youcompile your Web server by hand, you need to add --enable-authnz-ldap--enable-ldap to your configure command. If you use your distribution'sversion of Apache, then install the appropriate module (for Red Hat distributions, themodules are part of the core httpd package).

When a user makes a request to a protected resource, Apache returns an error code401 (unauthorized). At this point, the Web browser should prompt the user for ausername and password. The Web browser then reissues the request with thisinformation encoded in an Authorization header. If the username and passwordare accepted by the Web server, the page is served to the client; otherwise, the




server returns another 401.

Apache, when configured to check passwords against LDAP, first binds to the serveras a predefined user and performs a lookup on the user to find the DN. The serverthen rebinds as the user with the provided password. If the server can successfullybind as this user, the authentication is considered successful.

After a successful authentication, the server can be configured to perform additionalauthorization tasks, such as checking against the DN or attribute, or testing to see ifthe user passes a search filter. If any of these tests are configured, then the testmust pass for the authorization to pass.

Configuration of mod_authnz_ldap is similar to the standard authenticationmethod using text files. Listing 11 shows the simplest case of LDAP authenticationwith no authorization.

Listing 11. Apache configuration for LDAP authentication

LoadModule ldap_module modules/mod_ldap.soLoadModule authnz_ldap_module modules/mod_authnz_ldap.so

<Location /protected>AuthType basicAuthName ProtectedByLDAPAuthBasicProvider ldap

AuthLDAPUrl ldap://192.168.1138/ou=People,dc=ertw,dc=com?uid# Anon bind for first phase#AuthLDAPBindDN#AuthLDAPBindPassword

AuthzLDAPAuthoritative offrequire valid-user

</Location>

The first two lines of Listing 11 load the required modules into the Web server. Therest of the configuration is enclosed in a Location container, meaning it appliesonly to requests beginning with /protected. The configuration first declares Basicauthentication and a name of ProtectedByLDAP. The Web browser shows thename to the user. The AuthBasicProvider line tells Apache that authentication isprovided through LDAP.

Listing 11 continues with AuthLDAPUrl, which points Apache to the LDAP server.The form of the parameter isldap://host:port/basedn?attribute?scope?filter. host and portdefine the LDAP server, and basedn is the base DN from which the initial search isperformed. attribute refers to the attribute that will be searched along with theusername during the initial search (the default is uid). scope is either one or sub tocorrespond with one level or all children. filter is an optional filter that will belogically ANDed with the search for the given user/attribute combination.




The example in Listing 11 has AuthLDAPBindDN and AuthLDAPBindPasswordcommented out, which results in an anonymous bind. If you want to specify a userhere, you may. Either way, the user performing the initial bind must be able tosearch on the attribute provided in the AuthLDAPUrl command.

The final two lines disable authorization by allowing any validated user.AuthzLDAPAuthoritative off means that a later module can allow the accesseven if LDAP denies authorization (but not authentication). require valid-usercomes from another module, so this deferral is required. Instead of these two lines,you can use LDAP-related ones, such as checking for group membership or anLDAP attribute. Listing 12 shows part of the configuration from Listing 11, but itrestricts access to people with the ou=Engineering attribute and value.

Listing 12. Restricting access to a particular OU

AuthzLDAPAuthoritative onrequire ldap-filter ou=engineering

Two things are notable in Listing 12. First, AuthzLDAPAuthoritative is now on(this is the default) because your requirement can be handled by the LDAP module.Second, the ldap-filter doesn't include parentheses. Apache uses the givenLDAP filter and also performs a logical AND with the uid (or whichever attribute youspecified in the AuthLDAPUrl command) and builds the search filter with a simplestring insertion. If you have extra quotes or parentheses in your filter, the resultingquery becomes invalid. The authentication fails, and a log message is printed to theserver's error_log.

Integrate FreeRADIUS with LDAP

FreeRADIUS is an open source Remote Authentication Dial In User Service(RADIUS) server that is often used for authentication of dial-up or other networkdevices. Clients use RADIUS to authenticate users, and the RADIUS server in turnuses LDAP to find its information.

You can integrate PAM and FreeRADIUS two ways: by using PAM, or by enablingnative LDAP support through the rlm_ldap module. The choice depends on howyou plan to use RADIUS. If all you need is authentication, or you don't wish to modifyyour LDAP schema, then use PAM. If you need to use RADIUS attributes, then it'seasier to configure the LDAP module and store the attributes in LDAP (RADIUSallows the server to send configuration details to the device asking forauthentication, which lets you provide different services to different users).

For PAM mode, ensure that you have PAM set up for LDAP like the other systems.The PAM configuration file for FreeRADIUS is /etc/pam.d/radiusd. Starting from thedefault configuration files that come with FreeRADIUS, uncomment the pam keyword




in the authenticate section of radiusd.conf. Next, edit the users file and look forDEFAULT Auth-Type = System. Change the System keyword to PAM. Restartradiusd, and you're done.

The native LDAP module, rlm_ldap, is more complex. First, you must haveFreeRADIUS installed on your system, built with the rlm_ldap module(--enable-ldap). FreeRADIUS is built like most other packages and so won't becovered here. Your Linux distribution, if it includes FreeRADIUS, likely includes theLDAP module.

FreeRADIUS includes an LDAP schema in a file called openldap.schema. Copy thisto /etc/openldap/schema/freeradius.schema, and import it into OpenLDAP throughthe include directive in slapd.conf. The schema provides several attributes andtwo objectClasses. One of the objectClasses is radiusprofile; it's used for anyusers who will be authenticated with RADIUS. radiusprofile is an auxiliaryobjectClass and therefore can go on any entry. radiusObjectProfile is astructural objectClass used to create containers of radius profiles; it isn't necessaryfor operation.

Next, edit the default users file as in the PAM example, but instead of changing thedefault method to PAM, comment out that entire section. This file controls how usersare authenticated and authorized. Removing the default method is enough to allowthe LDAP module to take over and handle user authentication and authorization.

radiusd.conf needs more work. In both the authenticate and authorizesections, uncomment the ldap keyword that enables LDAP authentication andauthorization. You must also find a section that looks like Auth-Type LDAP {ldap } and uncomment that. Finally, uncomment the ldap { ... } section, andenter your server's address, base DN, and optional authentication information. Likeother software you've seen, the initial bind performs the lookup of the user's DN;then, a second bind is made as that user to confirm the password and retrieve theattributes. Therefore, the user you initially bind as (or anonymous if you have noconfigured user) must be able to perform searches on the uid attribute, and usersmust be able to read their own attributes.

Users who need to be authenticated by LDAP must use the radiusProfileobjectClass and have a dialupAccess attribute with some value in it, such as"yes". With more advanced configurations, you can use the value to apply differentsettings, but for basic purposes, the attribute can take any value.

FreeRADIUS is an extremely robust RADIUS server, and a great deal ofconfiguration can be required to get it to do what you need. The two configurationsshown here focus only on what is needed to get LDAP working.

Integrate CUPS with LDAP




The Common UNIX Printing System (CUPS) is the currently favored printingdaemon because of its ease of configuration, support for the Internet PrintingProtocol (IPP), and backward compatibility with the traditional lpr tools. CUPSsupports PAM, but it must be told how and when to authenticate.

First edit /etc/pam.d/cups so that it supports LDAP. Next, in /etc/cups/cupsd.conf,create for your printers a container that requires authentication, such as in Listing13.

Listing 13. A printers container that requires authentication

<Location /printers>AuthType Basic

</Location>

Listing 13 shows a configuration that requires Basic authentication for any URLbeginning with /printers. The CUPS configuration is almost identical to that ofApache, so this configuration should remind you of Listing 11. However, CUPS isusing PAM instead of a native LDAP module, so no LDAP configuration isnecessary. CUPS uses PAM for authentication because that is how it's configured.Now, when you try to browse a URL under /printers, which includes printing to aprinter, you're prompted for a password. Listing 14 shows such a prompt.

Listing 14. Verifying that CUPS is working with LDAP

[sean@bob LPIC-III_5]$ lpr index.xmlPassword for sean on localhost? mypassword[sean@bob LPIC-III_5]$

If the password were incorrect or PAM wasn't working, then Listing 14 would havereprompted for a password. PAM was successful, though, so the document wasprinted and the user was returned to the shell prompt.

Section 5. Integrate LDAP with Samba



• Migrate from smbpasswd to LDAP




• Understand the OpenLDAP Samba schema

• Understand LDAP as a Samba password backend

Samba is the UNIX community's way of integrating with Microsoft Windowsnetworks. With this software, you can share files with Microsoft networks (both clientand server) and make your UNIX computer appear as a Windows computer to theother Windows clients.

Understand Samba authentication

Samba's goal is integration with Windows networks, so it must use theauthentication mechanisms that Windows uses. If you're authenticating against aWindows server, this is fine, but often the Samba server is the repository for thecredentials. Thus, two copies of password hashes are needed—one for thetraditional UNIX passwords and another for the Microsoft hashes.

Microsoft passwords are similar to UNIX passwords in that they're hashes of the realpassword. A hash function is a one-way function that accepts a variable-length input(such as a password) and outputs a fixed-length hash (string). It's impossible to takethe hash and recover the original password, although you could try billions ofdifferent inputs in hopes that the resulting hash will match.

Two different password hashes are stored for Microsoft passwords: theLANManager hash and the Windows NT hash. The first isn't as secure as thesecond because several things are done to the password before hashing that reducethe number of possible outputs. The Windows NT hash was designed to overcomethese limitations. Even though both hashes are stored, you can choose to disablethe LANManager support if all your clients support NT hashes (available onWindows NT SP 3 and above).

Samba has traditionally stored the password hashes in the smbpasswd file and usestools like smbpasswd to manage the password file by the same name. This caneasily be moved to LDAP so that multiple Samba servers can authenticate withoutneeding to use Primary Domain Controllers or other Microsoft infrastructure. Storingthe data in LDAP also reduces duplication of information across your network.

Understand the Samba schema

NT passwords are different from UNIX passwords and can't be stored in theuserPassword attribute. Therefore, the LDAP schema must be extended to storethe password hashes and other pieces of information that a Microsoft device expectsto be available.




The schema file is distributed with the Samba suite as samba.schema. Copy this fileto /etc/openldap/schema, and use the include directive in slapd.conf to make it apart of your server's schema.

samba.schema introduces several new objectClasses, which are explained in Table4.

Table 4. objectClasses in samba.schemaobjectClass Description

sambaSamAccount Provides the information needed for anaccount (computer, user, and so on) in anNT environment.

sambaGroupMapping Maps a UNIX group to a Windows group.

sambaTrustPassword Provides authentication information abouttrust relationships between domains.

sambaDomain Stores information about the domain inthe LDAP tree. You'll find one of theseadded automatically to your LDAP treeafter you set up Samba/LDAP.

Configure Samba for LDAP

Configuring Samba for LDAP involves editing smb.conf to set up the LDAP datasource and then manipulating your users' LDAP entries to make them aware of thenew Samba attributes.

In your smb.conf, you'll find a line like passdb backend = tdbsam, whichrepresents the smbpasswd file storage mechanism. Replace this with the code inListing 15, modified for your environment.

Listing 15. Using the ldapsam password storage

# ldapsam requires the uri to the LDAP serverpassdb backend = ldapsam:ldap://192.168.1.138/# A user in your LDAP server that can read and write the new attributes# The password will be entered laterldap admin dn = cn=root,dc=ertw,dc=com# Same as search baseldap suffix = dc=ertw,dc=com# OUs for users/computers/groupsldap user suffix = ou=Peopleldap machine suffix = ou=Computersldap group suffix = ou=Group

Once you've set up smb.conf, restart Samba and execute smbpasswd -W. You'reprompted for the password for the LDAP admin DN you entered in smb.conf. At this




point, Samba will use LDAP data to authenticate users.

Manage Samba users in LDAP

Users must be set up with the sambaSamAccount objectClass before they can useSamba, which includes setting the password hashes and assigning a securityidentifier (SID) to the user. This is easily handled by the smbpasswd utility, whichtraditionally added users to the smbpasswd file. smbpasswd will manage an LDAPuser if smb.conf is configured to use LDAP, such as in Listing 15.

To set up a new user, first be sure the user's account is set up with theposixAccount objectClass and a uid attribute, which should already be there ifthe user logs in through LDAP and PAM or NSS. Next, run smbpasswd -ausername to modify the user's LDAP entry, which includes setting the Sambapassword. Listing 16 shows a typical user's entry after being set up for Samba.

Listing 16. A Samba user's entry

dn: cn=Jim Joe,ou=people,dc=ertw,dc=comgivenName: Jimsn: Joecn: Jim Joeuid: jjoeuidNumber: 1000sambaSID: S-1-5-21-2287037134-1443008385-640796334-userPassword:: e01ENX1yTDBZMjB6QytGenQ3MlZQek1TazJBPT0=sambaLMPassword: 5BFAFBEBFB6A0942AAD3B435B51404EE

sambaNTPassword: AC8E657F83DF82BEEA5D43BDAF7800CCloginShell: /bin/bashgidNumber: 4homeDirectory: /home/asambaAcctFlags: [U]objectClass: inetOrgPersonobjectClass: sambaSamAccountobjectClass: posixAccountobjectClass: top

The bold lines from Listing 16 were added by smbpasswd. Starting from the top, aSID is added to the account. Using smbpasswd frees you from needing to calculatethis, because smbpasswd figures out what SID to use. Next, the LanManager andNT password hashes are stored. The sambaAcctFlags is used to store someattributes of the entry. Possible values of this flag are as follows:

• N: No password required

• D: Account disabled

• H: Home directory required

• T: Temporary duplicate of other account




• U: Regular user account

• M: MNS (Majority Node Set cluster) logon user account

• W: Workstation Trust Account

• S: Server Trust Account

• L: Automatic locking

• X: Password doesn't expire

• I: Domain Trust Account

Finally, the sambaSamAccount objectClass enables all these attributes.

In addition to those described here, you can set many other options to carry moreWindows-specific information. Consult the pdbedit manpage to learn about readingand modifying Samba user information from the command line. Samba can act as aWindows Primary Domain Controller (PDC), and the extra information is necessaryfor Windows clients to function correctly.

Password synchronization

Now that two sets of passwords exist (userPassword and the two Samba hashes),you must find a way to keep the passwords in sync with each other. If a userchanges his or her Samba password, either from the command line or from aWindows client, the UNIX password should change. Likewise, if a user changes theUNIX password, the Samba password should change.

The first case is the easiest. Add ldap password sync = yes to the [global]section of smb.conf, and restart Samba. Any further password changes will changeboth the Samba and userPassword hashes.

Getting the Samba passwords changed when a user changes his or her passwordthrough the UNIX passwd command requires PAM. Samba comes withmod_smbpasswd, which is used to authenticate and change passwords through theSamba system. For now, there is no need to authenticate passwords, so only thepassword function will be used. Listing 17 shows part of a PAM configuration filethat, when used, changes both UNIX and Samba passwords in LDAP.

Listing 17. A PAM password stack to change both UNIX and Samba passwords

password requisite pam_cracklib.so try_first_pass retry=3password optional pam_smbpass.so use_authtok use_first_passpassword sufficient pam_unix.so md5 shadow nullok try_first_passuse_authtokpassword sufficient pam_ldap.so use_authtok




password required pam_deny.so

In Listing 17, the added line is shown in bold. The pam_smbpass module is listed asoptional so that if a user isn't configured as a Samba user, that step will fall through.The Samba password change is before the UNIX and LDAP password changes,because these two are marked as sufficient, meaning the first one to succeedstops processing.

With Listing 17 in place, a user changing his or her password from the command linewill also change the Samba password.

Migrate existing users to LDAP

When you move to an LDAP backend, you're likely to have existing users in afile-based password mechanism that you need to migrate. The pdbedit utility cancopy accounts from one place to another to make this job easy.

Listing 18 shows the use of pdbedit to migrate users. The -i parameter sets thesource of the data, and the -e parameter sets the destination. Before running thepdbedit command, you should have the ldapsam database set up in smb.conf.

Listing 18. Migrating users from tdbsam to ldapsam

[root@server1 ~]# pdbedit -e ldapsam -i tdbsamImporting account for fred...okImporting account for jsmith...ok

If you're using the older smbpasswd password backend, use smbpasswd instead oftdbsam.

Section 6. Integrate LDAP with Active Directory


In this section, learn about:

• Kerberos integration with LDAP

• Cross-platform authentication




• Single sign-on concepts

• Integration and compatibility limitations between OpenLDAP and ActiveDirectory

Microsoft Windows can be found in almost every company; there's a good chancethat your environment already makes use of Active Directory, Microsoft's enterprisedirectory service. Active Directory is based on two open protocols: LDAP andKerberos. By understanding these protocols and configuring the Linux systemappropriately, your Linux box can authenticate against the enterprise directory andfacilitate single sign on (SSO). This means you log in to your machine once, andyour credentials are good throughout the network.

Understand Kerberos

Kerberos, named after the three-headed dog from Hades in Greek mythology, is aprotocol that allows users and servers to prove their identity to each other over anuntrusted network. It was developed at the Massachusetts Institute of Technology(MIT) for use on their network and has since found its place in many other networks.Microsoft chose to use Kerberos as part of Windows 2000's Active Directory.

Kerberos V is the currently developed stream, although you may run into KerberosIV at times. Kerberos V provides backward compatibility for systems still usingKerberos IV.

The Kerberos protocol

Kerberos is a protocol that allows a service to authenticate the identity of a userwithout needing to see a password. This is achieved by having a mutually trustedserver, called the Authentication Service (AS). The AS shares a secret with eachuser and service. The secret is used to protect information between the AS and theother end of the conversation; it even lets the AS give the user a message (called aticket) destined for someone else. In this latter case, users can't read the ticketbecause they don't have the shared secret.

All clients and servers form a Kerberos realm, which is much like an NIS domain or,in some respects, the base DN of an LDAP tree. The realm defines all the devicesand people that authenticate to a common set of Kerberos servers. Generally, therealm is the DNS zone of the organization written in uppercase, such asERTW.COM. For the purposes of Kerberos, the clients are the computers that gettickets from a Kerberos server. The servers are the devices that provide theKerberos services of granting tickets.

Everything that is authenticated in the Kerberos realm has a corresponding Kerberosprincipal that identifies it and is associated with the password or shared secret.




When a user connects to a server, they're really connecting to a service running onthe server. Each service is treated separately and must be registered as a principalwith the Kerberos server. A service's principal is of the formservicename/servername@REALM, whereas a user's principal is of the formuser@REALM.

The Kerberos protocol is shown in Figure 1.

Figure 1. The Kerberos protocolThe Kerberos protocol can be viewed as having two distinct phases: the initial loginof the user to the realm, and the authenticating of the user to the service. The magicof Kerberos is that the initial login happens only once; the subsequent serviceauthentication can happen many times to many servers.

The first phase of Kerberos starts with the user asking the Kerberos server(specifically, a component called the Key Distribution Center [KDC]) for a TicketGranting Ticket (TGT), which will be used later to request service. The KDCgenerates a TGT, encrypts it with the user's password, and sends it back to the user.

The TGT has been likened to a visitor pass in a company. You show youridentification to the security guard (KDC) and are granted a visitor pass that's validfor one day. This process allows you to keep your own ID secure and also limits thecompany's exposure to a stolen visitor pass. The TGT expires in a short period oftime, usually around 8 hours.

In the second phase, the user decides he or she needs access to a service. Theuser sends a request to the Kerberos server's Ticket Granting Service (TGS)component, which includes the TGT and the name of the service (the principal). TheTGS checks to see if the TGT is still valid and then issues a ticket that has beenencrypted with the shared secret of the service. Finally, the user presents this ticketto the service. If the service can successfully decrypt the ticket, then the serviceknows the Kerberos system approved the request. No passwords ever crossed thenetwork.

Kerberos thwarts replay attacks, where an attacker captures a ticket and uses itagain, by imposing limited lifetimes on tickets and including timestamps in theencrypted ticket. A ticket for a service may be valid for 5 minutes, so the service hasto remember just 5 minutes' worth of tickets to know if a ticket was replayed. Allclocks must be synchronized for this to succeed.

Where does LDAP fit in?

Kerberos provides only an authentication framework, much like the PAM systemdoes. User information isn't stored in the Kerberos database.

Kerberos secrets can be stored in the LDAP database or they can be left separate.The choice is up to the implementation of Kerberos. In either case, LDAP is used to




store the user information such as home directory and personal information.

You must keep your Kerberos database secure regardless of where it's stored. TheKerberos keys are like passwords: they can be stolen and used to generate TGTsand tickets. Most guides strongly recommend keeping your Kerberos server on itsown device and protecting it as much as possible.

Configure Microsoft Active Directory for your Linux guests

Active Directory uses implementations of Kerberos and LDAP that are compatiblewith those shipped with Linux. Microsoft has extended Kerberos to supportWindows-specific attributes, but this doesn't prevent UNIX users from using it (seethe Resources for Microsoft's documentation on the subject).

The Active Directory schema must be extended to support some of the UNIXattributes, which is easily done in Windows 2003 Server. Go to the Control Panel ofyour Domain Controller, and choose Add or Remove Programs > Add/RemoveWindows Components. From the Active Directory Services component, choose theIdentity Management for UNIX subcomponent. (If you have an earlier version ofWindows, this component is sometimes called the Server for NIS.) Install thissoftware, and the LDAP schema will be extended; your user dialogs will also includea UNIX Attributes tab, which will be used soon.

From the Active Directory Users and Computers application, edit the Domain Userssecurity group. Note the new tab, UNIX Attributes. Assign a group and NIS domainto your Domain Users group, as shown in Figure 2. Doing so allows the group to beseen by the UNIX systems. This group will be the user's primary group.

Figure 2. Assigning UNIX attributes to a group




Still in the Users container, find a user whom you want to use on your UNIX servers.Find the UNIX Attributes tab for this user, and assign the standard UNIX attributesto them. Figure 3 shows a sample user.

Figure 3. The UNIX attributes of a user




The user in Figure 3 has been assigned a primary group, a home directory, a shell,and a userid.

Next, you must create a service account that allows access to your LDAP tree,because anonymous access is disabled by default. Use the following configurationfor this user:

• Name: LDAP service account (or your choice)

• User logon name: ldap (or your choice)




• Password: Your choice

• User can't change password: Selected

• Password never expires: Selected

• Primary group: Domain Guests

The service account should only be a member of Domain Guests. From the MemberOf tab, add the Domain Guests group to the account, highlight it in the list of groups,then click the Set Primary Group button. With the group changed, you can removethe Domain Users group from the profile.

If your security policy prohibits the password options, you'll have to adjust your Linuxconfiguration (described next) each time the password changes. Note that LDAP isused here only for directory information and not passwords, so the requirement tochange passwords is lessened.

Configure Linux

The Linux side of the equation involves three steps. First, you set up directoryaccess through /etc/ldap.conf. Next, you configure PAM for Kerberos authentication.Finally, configure Samba to use Active Directory information for authentication, andjoin it to the domain.

Before you start, you must ensure that your Linux machine is using your Microsoftserver for both DNS and network time. Your Linux server must also have a hostrecord in the Microsoft DNS zone for your domain.

Configure LDAP

LDAP is configured as it was earlier, except that some mapping is required fromUNIX attributes to Microsoft attributes. Listing 19 shows /etc/ldap.conf configured toaccess a Microsoft LDAP directory using the user account set up previously.

Listing 19. Configuring ldap.conf to use a Microsoft directory

# Information about the directoryuri ldap://192.168.1.151binddn [email protected] ldapssl nobase dc=ertw,dc=com

# Map attributesnss_map_objectclass posixAccount usernss_map_objectclass shadowAccount usernss_map_attribute uid sAMAccountNamenss_map_attribute homeDirectory unixHomeDirectorynss_map_attribute shadowLastChange pwdLastSet




nss_map_objectclass posixGroup groupnss_map_attribute uniqueMember memberpam_login_attribute sAMAccountNamepam_filter objectclass=Userpam_password ad

The configuration shown in Listing 19 first points the module to the Microsoft LDAPserver using the credentials set up earlier. The attributes are mapped from the UNIXname to the Microsoft name, such as using sAMAccountName for the userid.

Finally, add ldap winbind to the passwd, group, and shadow sections of/etc/nsswitchconf (leave files in there). This lets your system pull directoryinformation from LDAP and Samba (the latter to be configured later).

After this step, you can run getent passwd to see the LDAP users. Note that youmust set the UNIX attributes for the user in Active Directory for the user to show upin the list.

Configure Kerberos

Kerberos is configured through PAM and the /etc/krb5.conf file. If you're using yourMicrosoft DNS server for your DNS, then you only need to specify your realm,because the server will be learned automatically from DNS. Listing 20 shows thecontents of /etc/krb5.conf

Listing 20. /etc/krb5.conf for the ERTW.COM realm

[logging]default = FILE:/var/log/krb5libs.logkdc = FILE:/var/log/krb5kdc.logadmin_server = FILE:/var/log/kadmind.log

[libdefaults]default_realm = ERTW.COMdns_lookup_realm = falsedns_lookup_kdc = trueticket_lifetime = 24hforwardable = yes

[realms]ERTW.COM = {default_domain = ertw.com

}

[domain_realm].ertw.com = ERTW.COMertw.com = ERTW.COM

[appdefaults]pam = {

debug = falseticket_lifetime = 36000renew_lifetime = 36000forwardable = truekrb4_convert = false

}




krb5.conf is divided into sections, with the name of the section enclosed in squarebrackets. The logging section specifies the paths of various logfiles. The libdefaultssections configure the Kerberos libraries: in particular, the dns_lookup_kdc tellsthe library to look for server records (SRV) in DNS to find the KDC. The record lookslike _kerberos._tcp.ERTWCOM., and the response is the name of a server andthe port to contact.

The realms section defines the realms and the associated DNS zones. Thedomain_realm section does the reverse: it allows a host to determine its realmbased on its fully qualified domain name (FQDN). Finally, the appdefaults section isfor the applications using Kerberos; in this case, PAM has been configured withsome default options.

In practice, there is little to configure in krb5.conf because the default configurationfile has all the required elements. All you have to do is substitute your realm anddomain name where appropriate. You can also use your system's Kerberosconfiguration utility, such as authconfig.

The configuration of PAM is just like the previous configurations of LDAP andsmbpasswd. You insert a call to the Kerberos PAM library where appropriate. Listing21 shows part of the Fedora system-auth file after Kerberos has been configured.

Listing 21. system-auth file after configuring Kerberos

auth sufficient pam_unix.so nullok try_first_passauth sufficient pam_krb5.so use_first_passauth required pam_deny.so

account required pam_unixso broken_shadowaccount [default=bad success=ok user_unknown=ignore] pam_krb5.soaccount required pam_permit.so

password sufficient pam_unix.so md5 shadow nullok try_first_passuse_authtokpassword sufficient pam_krb5.so use_authtokpassword required pam_deny.so

session required pam_unix.sosession optional pam_krb5.so

Kerberos has been added directly after the UNIX password check in theauthorization phase as a sufficient item. This means that if a UNIX password isfound, Kerberos isn't consulted. If no UNIX password is found, then Kerberos isconsulted. If Kerberos fails, the stack fails. If no user is found, then control passes tothe pam_deny module, which causes a failure.

The account phase uses an alternative syntax to the one you've seen so far. EachPAM module can return different options, such as "success" or "no such user". Thesquare brackets allow the administrator to take a different action based on eachpossible return code. Listing 21 implements a policy that says if pam_krb5 returns a




successful result, then continue processing. If the user is unknown, then ignore themodule completely. Anything else is considered a failure. This behavior is close tothe required keyword, with the exception that an unknown user doesn't cause afailure. Consult the pam.conf(5) manpage for more details on this syntax,including the options.

The password and session phases include the module in the stack with no specialoptions.

At this point, you should be able to log in to your Linux server using Active Directorycredentials. The next step configures Samba and further secures the connection bycreating a computer account for the server.

Configure Samba and join the domain

For Samba's configuration, you must first remove your existing password backendfrom smb.conf, and any of the tdb files in /etc/samba and /var/cache/samba. Listing22 shows the directives you must add to the [global] section of smb.conf to allowSamba to use AD.

Listing 22. Samba configuration for AD integration

# Active directory securitysecurity = adsrealm = ERTW.COMuse kerberos keytab = yes

# Identity mappingidmap backend = adldap idmap suffix = dc=ertw,dc=com

# LDAP configurationldap admindn = cn=ldap,cn=users,dc=ertw,dc=comldap suffix = dc=ertw,dc=com

# Winbindwinbind use default domain = yeswinbind nested groups = yes

Listing 22 starts by specifying that ADS security mode is used (remote ActiveDirectory server), along with the Kerberos realm. The second section configuresidmapping, which is a feature that maps remote Microsoft SIDs to local UNIX ids.This configuration specifies that Active Directory is the source of the information.The mapping is taken care of on the Microsoft side, because you've already enteredthe IDs in the UNIX Attributes tab of the users and groups. Your server just has topull this information from LDAP.

The LDAP configuration is familiar; it sets the DN for the LDAP connection to theldap user created earlier. Note that the container is cn=users instead of theou=people that has been used so far. The password is entered through




smbpasswd.

The last two lines enable Winbind, which is an implementation of some of theMicrosoft Remote Procedure Calls (see Resources for more information onWinbind). It lets you get more information out of your Active Directory server, ratherthan only the groups and users for which you've added UNIX attributes.

After smb.conf is configured, start the Samba and winbind services.

The final steps in the Samba configuration are to set the admindn password and tojoin your domain. Listing 23 shows the computer joining the domain.

Listing 23. Setting the admindn password and joining the domain

[root@server1 ~]# smbpasswd -WSetting stored password for "cn=ldap,cn=users,dc=ertw,dc=com" in secrets.tdbNew SMB password: ldapRetype new SMB password: ldap

[root@server1 ~]# net ads join -U administratoradministrator's password: mypasswordUsing short domain name -- ERTW0Joined 'SERVER1' to realm 'ERTW.COM'

Test it out

You should be able to log in to your server with Active Directory credentials andbrowse file shares from a remote computer without having to log in. Some helpfulcommands to test are:

• net ads testjoin: Tests the computer account

• wbinfo -u: Shows a list of Active Directory users and tests winbind

• klist: After you log in through Kerberos, shows your TGT and anyservice tickets that have been issued

• smbclient -k -L '\\SERVERNAME': Shows a list of shares fromSERVERNAME, using a Kerberos login

Section 7. Integrate LDAP with e-mail services






• Plan LDAP schema structure for e-mail services

• Create e-mail attributes in LDAP

• Integrate Postfix with LDAP

• Integrate sendmail with LDAP

sendmail and Postfix are two of the more popular mail transport agents (MTAs) inuse. The job of the MTA is to receive messages from the systems and send them tobe delivered to the end user or to the next hop MTA. MTAs also take messages fromusers and find the remote MTA that is capable of delivering the message.

Both sendmail and Postfix rely on various maps—key/value pairs that are normallyheld in flat files or hash databases like BDB. This type of lookup is also a good fit forLDAP. The advantages of LDAP are that many hosts can share the sameconfiguration, and that it's easier to develop tools to manage the data in LDAP ratherthan in flat files that must then be rebuilt into hash tables. The overhead of LDAPversus disk reads should not be that onerous, especially if the LDAP tree is properlyindexed.

Configure sendmail

The sendmail MTA is a complex creature, and adding LDAP to the mix onlyincreases the complexity. You can do just about anything with sendmail because it'salmost infinitely configurable. The downside is that things that should be simple tendto be more complicated than necessary.

Understand that sendmail is a program that interprets a language often called cf inorder to process mail. Cf is a language made for easy parsing by sendmail, nothumans. Fortunately, humans can use a language called M4, which has a muchsimpler syntax, to generate the resulting cf code.

sendmail maps

Many cf operations involve looking up information in maps, which are series ofkey-value pairs. Each map has a particular purpose, such as the aliases map formail aliases and the mailertable map for static routing of e-mail. The map is atwo-column entity; lookups are performed on the left-hand side (LHS), and thecorresponding value from the right-hand side (RHS) is returned.

The concept of a map doesn't translate directly into LDAP. A single-key lookup in asendmail map may return only one RHS entry (the RHS can have multiple values,but only one instance of the key may exist). sendmail works with this by defining a




schema that allows key-value pairs to be stored in LDAP. Furthermore, sendmailtranslates each map request into an LDAP query filter that is designed to return a setof attributes from a single entry. You can choose to use the sendmail schema, oryou can modify the filters to work with the data in your tree.

To get started, add the misc.schema schema (it comes with OpenLDAP) to yourserver's schema. This implements LDAP-based mail routing. Then, addsendmail.schema from the sendmail distribution, which lets you store maps in LDAP.

Configure LDAP mail routing

Some organizations have multiple mail servers to handle all their users, eitherbecause of geographical constraints or for managing capacity on the servers. In thiscase, a user's mailbox might be on a server called wpgertw.com but the user'se-mail address might be [email protected]. LDAP mail routing allows any sendmailserver to receive the message, perform an LDAP lookup, and rewrite the address tothe internal version. It's then a simple matter to change the destination server bychanging LDAP. In any case, the user's e-mail address stays the same.

The misc.schema implements an Internet draft for LDAP routing. This schemaprovides the inetLocalMailRecipient objectClass with the following attributes:

• mailLocalAddress: An attribute that defines someone's e-mail addressas it's seen by someone outside the organization

• mailRoutingAddress: An attribute that defines the internal address ofa user, which usually includes the server that holds the user's mailbox

• mailHost: An attribute that defines the server that handles this user'se-mail

The host information for the user can be held in either mailRoutingAddress ormailHost. For example, a mailRoutingAddress of [email protected] with amailHost of mx.ertw.com seems like a contradiction. If the host is set, the mail willbe delivered there regardless of the routing address. The address will still berewritten to the routing address if that attribute exists. In the example [email protected], the address in the envelope will be rewritten [email protected], but the message will be delivered to mx.ertw.com.

Listing 24 shows the M4 code that enables LDAP routing. This should go in/etc/mail/sendmail.mc; then, you must rebuild your sendmail.cf. Usually this meansgoing into /etc/mail/ and running make; or it may mean running m4 sendmail.mc> sendmail.cf.

Listing 24. Enabling LDAP routing in sendmail.mc




define(`confLDAP_DEFAULT_SPEC', `-h localhost -b dc=ertw,dc=com')FEATURE(`ldap_routing')LDAPROUTE_DOMAIN(`ertw.com')

The first line sets the default arguments for the internal LDAP client: the host and thesearch base. The second line enables the LDAP routing feature, and the thirdenables the ertw.com domain for LDAP routing.

The duplication of the mailLocalAddress attribute frominetLocalMailRecipient and the mail attribute from inetOrgPerson is worthlooking at. sendmail lets you override the searches it uses internally by passing extraarguments to the ldap_routing feature. The first argument is the filter used to findthe mailHost attribute, and the second is used to find mailRoutingAddress.Therefore, FEATURE(`ldap_routing', `ldap -1 -T<TMPF> -v mailHost-k (&(objectClass=inetLocalMailRecipient)(mail=%0))', `ldap -1-T<TMPF> -v mailRoutingAddress -k(&(objectClass=inetLocalMailRecipient)(mail=%0))') enablessendmail to use the mail attribute instead of mailLocalAddress. The search filteris specified with the -k switch, and the attribute to return with -v. The rest of thearguments are standard for sendmail.

Configure aliases

sendmail implements LDAP aliases as a series of entries in the LDAP tree, keyed onan attribute called sendmailMTAKey using an objectClass ofsendmailMTAAliasObject. You may wish to keep the aliases in their owncontainer. Listing 25 shows the LDIF for a sendmail alias that takes mail [email protected] and sends it to hair@ertwcom and [email protected].

Listing 25. Alias for [email protected]

dn: sendmailMTAKey=execs,ou=aliases,dc=ertw,dc=comobjectClass: sendmailMTAAliasObjectsendmailMTACluster: externalsendmailMTAAliasGrouping: aliasessendmailMTAKey: execssendmailMTAAliasValue: hair@ertwcomsendmailMTAAliasValue: [email protected]

The first attribute, sendmailMTACluster, defines the servers that can use thisalias. You must also define the cluster name in the sendmail.mc file, such asdefine(`confLDAP_CLUSTER', `external'). This cluster is used as part ofthe search filter, so if you forget to define it, your aliases will never be used. Thealternative to defining a cluster is to set sendmailMTAHost, which makes the entryapply only to a particular host.

sendmailMTAAliasGrouping must be aliases; this is part of the search filter.The key refers to the name of the alias; finally, you have one or more values that are




the targets.

The final step is to configure sendmail to use LDAP for the aliases file with thedefine(`ALIAS_FILE', `ldap:') M4 directive. In general, anywhere you'reasked for a file in sendmail.mc, you can put ldap:, and the map will be referencedin LDAP. The sendmailMTAAliasGrouping then becomes the name of the map.

Configure Postfix

Postfix is designed to be simpler than sendmail but to remain compatible withsendmail. The concept of maps is still around, but instead of fitting the maps into aschema, you must define your own query filters that use your own attributes.

For most maps, you specify the target as ldap:/path/to/config.cf, withconfig.cf being a configuration file that defines the LDAP server, the query, and theattributes that form the response. For example, the local_recipient_mapsdirective specifies how Postfix will map e-mail addresses to local accounts. Specifylocal_recipient_maps = $aliases,ldap:/etc/postfix/localrecipients.cf to first check the aliases database(to come later) and then the regular address attached to a user's entry. Listing 26shows the contents of localrecipients.cf.

Listing 26. The local recipients LDAP lookup

# LDAP server infoserver_host = ldap://localhostsearch_base = ou=people,dc=ertw,dc=com

# %s is the e-mail address...query_filter = mail=%s

# the uid tells the account that gets the deliveryresult_attribute = uid

Listing 26 specifies the local LDAP server and the People OU. Postfix consults thesearch filter and replaces the %s with the e-mail address. Thus, an e-mail [email protected] will result in a search for ([email protected]) in the PeopleOU. The uid attribute is used to determine the mailbox. To test, you can runpostmap -q [email protected] ldap:/etc/postfix/localrecipients.cf,which runs the given e-mail address through the localrecipients.cf configuration file(note that NSS must be configured to return details about the fred account).

Section 8. Summary




In this tutorial, you learned how to integrate LDAP with your current systems. NSSprovides an easy way for core UNIX tools to make use of LDAP by redirecting thestandard C library calls to the backend of your choice. PAM is yet anotherabstraction; it allows you to change the way applications authenticate in a granularfashion as long as the application is PAM aware. PAM also has hooks for accountrestrictions and password changes. The PAM files live in /etc/pam.d.

Migrating from NIS to LDAP involves planning which databases need to be movedand then running some utilities to extract the data and convert it to LDIF. If you stillmust support NIS in your environment, PADL has written a NIS server calledypldapd that translates between NIS and LDAP by presenting a NIS interface toapplications, and that reads the data from LDAP.

Many applications are PAM aware, which means your migration to LDAP is assimple as changing a few files in /etc/pam.d. Some applications, like Apache, speakLDAP directly. Configuring Apache for LDAP involves using the mod_authnz_ldapmodule and specifying search filters that help Apache find the users in the tree.

Samba provides Windows services on a UNIX platform. You can configure Samba touse LDAP data or even to use Kerberos data to talk directly to Windows. In the lattercase, LDAP is still used for directory information, and Kerberos is used forauthentication.

E-mail is a natural fit for LDAP because of its similarity to a phone book. Bothsendmail and Postfix allow maps to be served from LDAP.

This concludes the look at directory services for the LPIC 3 exam. The next and finaltutorial in the series will focus on monitoring and predicting the performance of yourLinux servers.




Resources

Learn

• Review the previous tutorial in this 301 series, "LPI exam 301 prep, Topic 304:Usage" (developerWorks, March 2008), or all tutorials in the 301 series.

• Review the entire LPI exam prep tutorial series on developerWorks to learnLinux fundamentals and prepare for system administrator certification.

• At the LPIC Program, find task lists, sample questions, and detailed objectivesfor the three levels of the Linux Professional Institute's Linux systemadministration certification.

• New to Kerberos? Start with this explanation in the form of a play, read theMoron's Guide to Kerberos, and then read the Kerberos FAQ.

• Read Microsoft's documentation on Kerberos operation and Kerberostroubleshooting.

• This PowerPoint presentation on how Kerberos works (ppt) includesplay-by-play animations of the packets and messages. It's geared towardWindows administrators, but if you ignore the Windows-specific details, you'llget an excellent description of the protocol.

• These guides on Using Samba and Kerberos and Native LDAP, nativeKerberos, and Windows Server AD Services and schema for cross-platformidentity management provide a step-by-step method for integrating Linuxservices into Active Directory.

• The Samba documentation on IDMAP shows you how Samba maps betweenMicrosoft SIDs and UNIX userids.

• This article on Winbind shows you an alternative way to integrate Samba andAD without using Kerberos.

• mod_authnz_ldap gives you all the details on Apache and LDAP configuration.

• How HTTP authentication works is covered in Wikipedia.

• Read the FreeRADIUS documentation on the LDAP module. If you're having ahard time finding the schema, try RADIUS-LDAPv3.schema.gz.

• Read the Postfix LDAP Howto and the man page for ldap_table(5) beforeyou start with Postfix and LDAP.

• The sendmail configuration guide describes all the ways LDAP can be used,including the way the search filters are generated from the configuration file.This post about an alternative way to build sendmail aliases is enlightening, notonly because it's simpler than the normal way, but also because it gives you apeek behind the scenes.



http://www.ibm.com/developerworks/linux/edu/l-dw-linux-lpic3304-i.html

http://www.ibm.com/developerworks/linux/edu/l-dw-linux-lpic3304-i.html


http://www.ibm.com/developerworks/views/linux/libraryview.jsp?end_no=100&lcl_sort_order=asc&type_by=All+Types&sort_order=asc&show_all=false&sort_by=Title&search_by=lpi+exam&topic_by=All+topics+and+related+products&search_flag=true&show_abstract=true

http://www.lpi.org/en/lpi/english/certification/the_lpic_program

http://web.mit.edu/kerberos/www/dialogue.html

http://www.isi.edu/~brian/security/kerberos.html

http://www.cmf.nrl.navy.mil/CCS/people/kenh/kerberos-faq.html

http://technet.microsoft.com/en-us/library/bb742516.aspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

http://support.microsoft.com/servicedesks/webcasts/so_projects/so7/so7.ppt

http://www.interopsystems.com/LearningCenter/Using_Samba_and_Kerberos.htm

http://www.interopsystems.com/LearningCenter/Native_LDAP_native_Kerberos_and_AD_services.htm



http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/idmapper.html

http://www.justlinux.com/forum/archive/index.php/t-118512.html

http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

http://en.wikipedia.org/wiki/Basic_access_authentication

http://wiki.freeradius.org/Rlm_ldap

http://www.ibr.cs.tu-bs.de/cgi-bin/dwww?type=file&location=/usr/share/doc/freeradius/RADIUS-LDAPv3.schema.gz

http://www.postfix.org/LDAP_README.html

http://www.postfix.org/ldap_table.5.html

http://www.sendmail.org/doc/sendmail-current/cf/README

http://www.madboa.com/geek/ldap-aliases/


• This online LDAP book is an excellent work in progress.

• In the developerWorks Linux zone, find more resources for Linux developers,and scan our most popular articles and tutorials.

• See all Linux tips and Linux tutorials on developerWorks.

• Stay current with developerWorks technical events and Webcasts.

Get products and technologies

• Firewall Builder simplifies the task of typing in iptables rules with a nice GUI andsuite of tools to roll out updates to your firewalls.

• Download pam_ldap and nss_ldap if your distribution does not include thePADL PAM and NSS LDAP libraries.

• Download ypldapd if you're going to follow along with the NIS-LDAP gatewaydemonstration. The license is good for 30 days.

• Download the LDAP migration tools from PADL's site.

• Microsoft has developed gssMonger for verifying Kerberos authenticationinteroperability between Windows and other platforms.

• OpenLDAP is a great choice for an LDAP server.

• phpLDAPadmin is a Web-based LDAP administration tool. If the GUI is moreyour style, Luma is a good one to look at.

• Order the SEK for Linux, a two-DVD set containing the latest IBM trial softwarefor Linux from DB2®, Lotus®, Rational®, Tivoli®, and WebSphere®.

• With IBM trial software, available for download directly from developerWorks,build your next development project on Linux.

Discuss

• Participate in the discussion forum for this content.

• Get involved in the developerWorks community through blogs, forums,podcasts, and community topics in our new developerWorks spaces.

About the author

Sean WalbergSean Walberg has been working with Linux and UNIX since 1994 in academic,corporate, and Internet service provider environments. He has written extensivelyabout systems administration over the past several years.



http://www.zytrax.com/books/ldap/

http://www.ibm.com/developerworks/linux/

http://www.ibm.com/developerworks/linux/library/l-top-10.html

http://www.ibm.com/developerworks/views/linux/libraryview.jsp?topic_by=All+topics+and+related+products&sort_order=desc&lcl_sort_order=desc&search_by=linux+tip%3A&search_flag=true&type_by=All+Types&show_abstract=true&start_no=1&sort_by=Date&end_no=100&show_all=false

http://www.ibm.com/developerworks/views/linux/libraryview.jsp?topic_by=All+topics+and+related+products&sort_order=desc&lcl_sort_order=desc&search_by=&search_flag=&type_by=Tutorials&show_abstract=true&sort_by=Date&end_no=100&show_all=false

http://www.ibm.com/developerworks/offers/techbriefings/

http://www.fwbuilder.org/

http://www.padl.com/OSS/pam_ldap.html

http://www.padl.com/OSS/nss_ldap.html

http://www.padl.com/Products/NISLDAPGatewayEvaluation.html

http://www.padl.com/OSS/MigrationTools.html

http://www.microsoft.com/Downloads/details.aspx?familyid=986A0A97-CFA9-4A45-B738-535791F02460&displaylang=en

http://www.openldap.org/software/download/

http://phpldapadmin.sourceforge.net/

http://luma.sourceforge.net/

http://www.ibm.com/developerworks/offers/sek/

http://www.ibm.com/developerworks/downloads/

http://www.ibm.com/developerworks/forums/dw_forum.jsp?forum=160&cat=5

http://www.ibm.com/developerworks/community

http://www.ibm.com/developerworks/spaces/


Trademarks

DB2, Lotus, Rational, Tivoli, and WebSphere are trademarks of IBM Corporation inthe United States, other countries, or both.Linux is a trademark of Linus Torvalds in the United States, other countries, or both.UNIX is a registered trademark of The Open Group in the United States and othercountries.Microsoft and Windows are trademarks of Microsoft Corporation in the United States,other countries, or both.




LPI exam 301 prep, Topic 305: Integration and migration Use your LDAP server alongside an Active...

Documents

Transcript of LPI exam 301 prep, Topic 305: Integration and migration Use your LDAP server alongside an Active...