RH423 RedHat Enterprise Directory Services and Authentication-Lab Guide(1)

RH423Red Hat Enterprise Directory Services andAuthentication

RH423-RHEL5-en-2-20081020

Copyright © 2008 Red Hat, Inc.All rights reserved

RH423-RHEL5-en-2-20081020, Table of Contentsi

Table of Contents

RH423 - Red Hat Enterprise DirectoryServices and Authentication

Unit 1 - Introduction to Directory Services

Unit 2 - The LDAP Naming Model

Unit 3 - Red Hat Directory Server: Basic Configuration

Unit 4 - Searching and Modifying the LDAP Directory

Unit 5 - Red Hat Directory Server: Authentication and Security

Unit 6 - Linux User Authentication with NSS and PAM

Unit 7 - Centralized User Authentication with LDAP

Unit 8 - Kerberos and LDAP

Unit 9 - Directory Referrals and Replication

Unit 10 - Cross-Platform Centralized Identity Management

Unit 11 - Red Hat Enterprise IPA

Appendix A - Authenticating Windows Clients


RH423-RHEL5-en-2-20081020, Table of Contentsii


RH423-RHEL5-en-2-20081020, Unit 11

Unit 1

Introduction to Directory Services

1-1

For use only by a student enrolled in a Red Hat training course taught by Red Hat, Inc. or a Red Hat Certified Training Partner. No part of this publication may bephotocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materialsare being improperly used, copied, or distributed please email <[email protected]> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.


RH423-RHEL5-en-2-20081020, Lab 12

Lab 1Directory Schema and LDIF

Goal: To gain a better understanding of the directory information model. Be ableto read and interpret schema files. Be able to check entries in LDIF form forcorrectness.


RH423-RHEL5-en-2-20081020, Lab 1 Sequence 13

Sequence 1: Reading SchemaScenario: The ability to read LDAP schema files is important in order to make sure

that your data is easy to maintain. Schema files are usually standardized, andschema violations tend to cause later interoperability, migration, data integrity,or even security problems depending on the nature of the directory data.

Instructions:

1. Given the following schema fragment:

objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST objectclass )

objectClasses: ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL MUST c MAY ( searchGuide $ description ))

objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ l $ description ))

objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject' SUP top AUXILIARY MAY ( labeledURI ))

which attributes are mandatory and which are optional for object class country?

2. Given the same schema, which attributes are mandatory for object class locality?

3. Can an entry be of object class country and locality at the same time?

4. Can an entry be of object class country and labeledURIObject at the same time?

5. Can an entry be of object class top and locality at the same time? (Or can an entry beof object class locality without being of object class top?)



6. Given the following schema fragment:

attributeTypes: ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32767} )

attributeTypes: ( 2.5.4.3 NAME ( 'cn' 'commonName' ) SUP name )

attributeTypes: ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )

attributeTypes: ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributeTypes: ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )

attributeTypes: ( 1.3.6.1.1.1.1.2 NAME 'gecos' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

objectClasses: ( 0.9.2342.19200300.100.4.5 NAME 'account' SUP top STRUCTURAL MUST userid MAY ( description $ seeAlso $ l $ o $ ou $ host ))

objectClasses: ( 1.3.6.1.1.1.2.0 NAME 'posixAccount' SUP top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) )

can posixAccount be used as the only object class for an entry? Can it be used if top isincluded? Can it be used with object class country from the previous page?



7. Given the same schema, does a posixAccount entry require a loginShell attribute?

8. Can an entry have multiple uid attributes? Multiple gecos attributes? Multiple cnattributes?

9. The uid attribute is a mandatory attribute of posixAccount. Is it also a mandatoryattribute of account?

10. If an entry has object classes top and account only, may it include the cn attribute?



Sequence 2: Reading LDIF files

Scenario:

Instructions:

1. Given the schema on the previous pages, is this a valid entry?

dn: c=USobjectclass: countryobjectclass: topc: US

2. Is this entry valid? Why or why not?

dn: uid=john,dc=example,dc=comobjectclass: labeledURIObjectobjectclass: accountobjectclass: topuid: john


dn: uid=philip,dc=example,dc=comobjectclass: posixAccountobjectclass: topuid: philipuidNumber: 500gidNumber: 500homeDirectory: /home/philip




dn: userid=marta,dc=example,dc=comobjectclass: accountobjectclass: topo: MPVK Enterprises, Inc.l: Hassadaruserid: martya


dn: objectclass=top,dc=redhat,dc=comobjectclass: top


dn: userid=avi,o=Epiphyte Inc.,l=Mountain View,st=California,c=USobjectclass: topobjectclass: accountuserid: avi


RH423-RHEL5-en-2-20081020, Lab 1 Sequence 1 Solutions8

Sequence 1 Solutions

1. Object class country has two mandatory attributes; c, and objectclass, which itinherits from top. (Not fair of us, starting with a tricky one!)

2. Only objectclass is mandatory for locality.

3. No, country and locality are both structural object classes. An entry must haveexactly one structural object class. If either locality or country were a superior classof the other (and therefore inherited attributes from the other), then both could be in theentry.

4. Yes. country is structural and labeledURIObject is auxiliary.

5. Since top is an ancestor class of locality, if locality is in the entry, then top mustbe as well. Another way to put this is to say that an entry of object class locality is alsoalways of object class top.

6. No. Since posixAccount is an auxiliary class, it may not be the only object class inan entry, even including top. (Adding top does not help because it is an abstract objectclass, a special kind of class that is only used as a parent for defining structural and auxiliaryclasses.)

Since country is a structural class, posixAccount may be used with it in a validentry. (In practice, this would be a strange combination of classes, since normallyposixAccount represents objects that are people, not entire nations.)

7. No. posixAccount does not require loginShell, since loginShell is an optionalattribute.

8. An entry may have multiple cn or uid attributes, but only one gecos attribute, becausegecos is marked SINGLE-VALUE and the other attributes are not.

9. Yes. uid is a mandatory attribute of account -- userid is listed as a synonym for uid.

10. No, because it is not mandatory or optional for either object class.




1. Yes. Optional attributes need not appear.

2. Yes. The labeledURIObject class has no mandatory attributes! The object classaccount does, userid, but uid is an alternative name for the userid attribute.

3. No. The mandatory cn attribute is missing and the entry has no structural class.

4. No. The attribute used for the DN does not appear in the entry. This looks like amisspelling.

5. No. The entry has no structural class.

6. Yes. The mandatory attribute for structural object class account is present, and it is usedas the entry's relative distinguished name. (The rest of this entry's distinguished name looksstrange compared to the other entries, because it uses X.500-like naming. This will bediscussed further in the next unit.)


RH423-RHEL5-en-2-20081020, Unit 210

Unit 2

The LDAP Naming Model

2-1



RH423-RHEL5-en-2-20081020, Lab 211

Lab 2Preparing Directory Data

Goal: To prepare contact information for upload to a LDAP directory.

System Setup: Workstation installed with Red Hat Enterprise Linux.



Sequence 1: Selecting a schema and naming planInstructions:

1. The first thing which must be determined is the suffix to use for the directory partition. Theusual choice is between a X.500-based naming plan or a modern “Internet” naming plan. Inpractice, the latter has many advantages, so we will use the “Internet”-style of suffix.

You have two virtual machines, serverX+100.example.com and serverX+200.example.com, where X varies from machine to machine in the classroom. Youwill use serverX+100 as your first LDAP server for these labs. Use the fully-qualifiedhost name to construct a suffix:

dc=serverX+100,dc=example,dc=com

2. Next, you need to decide how you will divide up your part of the directory hierarchy.Since you are a small organization with one location, there is no reason to be elaborate.You also know that you currently want to store contact information about some users,but that someday you may want to store other information in the directory as well.Therefore, plan to create a single entry with the DN ou=People,dc=serverX+100,dc=example,dc=com to store the addresses. Later you may add more containersfor other sorts of objects.

You need to create LDIF to specify the initial naming structure and containerentries. Create a new file, /tmp/addressbook.ldif. Since dc=serverX+100,dc=example,dc=com is the suffix of this directory partition, there should beno entries for dc=example,dc=com or other suffixes present. Your entries could bestructured in a number of ways, but the following will work:

dn: dc=serverX+100,dc=example,dc=comobjectclass: organizationalUnitobjectclass: dcObject objectclass: topou: stationX.example.comdc: serverX+100

dn: ou=People,dc=serverX+100,dc=example,dc=comobjectclass: organizationalUnitobjectclass: topou: People

3. You know that you currently want to store names, e-mail addresses, postal addresses, andphone numbers for your contacts. Later on, you may also store other information about yourusers as well.

There are many different object classes that might be applied to people. Some of the moreinteresting ones are listed on the next page. Look over them for a moment. Each of them hasadvantages and disadvantages.



organization is great for representing a company, not so good for a single person, sinceit does not include cn or sn attributes for the person's full name or last name. person isvery limited by itself; only name and phone number, with name attributes mandatory. Theremaining three classes inherit from person. The problem with pilotPerson is that itsmix of attributes is somewhat strange, since it was originally defined for one of the X.500pilot projects. Between the last two, inetOrgPerson has two advantages; it includesall of the organizationalPerson attributes as well as some useful ones of its own,and it turns out that it is widely supported by software on the Internet, including Red HatDirectory Server.

For your users in this class, you will use inetOrgPerson.

Fig. 1: Example object classes for representing organizations

objectClasses: ( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

objectClasses: ( 2.5.6.5 NAME 'organizationalUnit' SUP top STRUCTURAL MUST ou MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ l $ description ) )

Fig. 2: Example object classes for representing people

objectClasses: ( 2.5.6.6 NAME 'person'



SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

objectClasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )

objectClasses: ( 0.9.2342.19200300.100.4.4 NAME 'pilotPerson' SUP person STRUCTURAL MAY ( uid $ textEncodedORAddress $ mail $ favouriteDrink $ roomNumber $ userClass $ homePhone $ homePostalAddress $ secretary $ personalTitle $ preferredDeliveryMethod $ businessCategory $ janetMailbox $ otherMailbox $ mobile $ pager $ organizationalStatus $ mailPreferenceOption $ personalSignature ) )

objectClasses: ( 2.16.840.1.113730.3.2.2 NAME 'inetOrgPerson' SUP organizationalPerson STRUCTURAL MAY ( audio $ businessCategory $ carLicense $ departmentNumber $ displayName $ employeeNumber $ employeeType $ givenName $ homePhone $ homePostalAddress $ initials $ jpegPhoto $ labeledURI $ mail $ manager $ mobile $ o $ pager $ photo $ roomNumber $ secretary $ uid $ userCertificate $ x500uniqueIdentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) )

4. Next, it is time to code some data. Here is an address from your rolodex:

George W. Bush1600 Pennsylvania Avenue NWWashington, DC 20500



202-456-1111 (work)[email protected] (e-mail)gwbush (local login name)

Look over inetOrgPerson, its parent organizationalPerson , and its parentperson, for applicable attributes to use. For practice, you might try to work out a planyourself first, before we walk through one. You may use the following references on yoursystem to help:

/usr/share/doc/openldap-devel-2*/rfc/

Contains a number of LDAP-specific RFC documents, if openldap-devel is installed. Inparticular, RFC 2252 discusses attribute syntaxes, RFC 2256 has discussion on the coreLDAP schema, and RFC 2798 is for inetOrgPerson. These can be dry; try to get thegist of what they are saying.

/etc/openldap/schema/

Has sample schema files, if openldap-servers is installed. Look at core.schema andinetorgperson.schema in particular.

5. Here is one possible plan:

George W. Bush cn1600 Pennsylvania Avenue NW streetWashington lDC st20500 postalCode202-456-1111 (work) [email protected] (e-mail) mailgwbush (local login name) uid

We also must store sn=Bush , since person requires a sn attribute. For good measure, addgivenName=George .

An alternative to spelling out all the components of his postal address would be to use thespecial postalAddress attribute. It expects six lines, separated by dollar signs, of nomore than 30 characters each: 1600 Pennsylvania Avenue NW$Washington,DC$20500$USA. The disadvantage of the postalAddress attribute is that it is unclearto client applications what the meaning of each line should be. The advantage of thepostalAddress attribute is that, since postalAddress can take multiple values, it isclear how to represent multiple postal addresses for an entry without confusing things likewhich street address goes with which postal code.



6. The final decision that needs to be made is what attribute to use for the DN of our addressbook entries. You may choose any attribute, as long as it will be unique to an entry. Themost obvious choice is cn, the person's full name. The problem with cn is that full namescollide. George W. Bush and George H. W. Bush would be hard to distinguish without theinitials. How many people might all be named David Jones?

It is better if we can use something that we can guarantee will be unique. If this were acompany directory, employeeNumber might be attractive. We will use uid, the uniquelyassigned login names for our users, which is a common choice. So the full DN for GeorgeW. Bush's entry is:

dn: uid=gwbush,ou=People,dc=serverX+100,dc=example,dc=com

7. To finish up, here is a conversion of the entire address into LDIF:

dn: uid=gwbush,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: gwbushcn: George W. Bushsn: BushgivenName: Georgestreet: 1600 Pennsylvania Avenue NWl: Washingtonst: DCpostalCode: 20500telephoneNumber: +1 202 456 1111mail: [email protected]

The distinguished name is first, followed by object classes. Order after that is not important.

Notice that the structural object class and all its parents are listed. The telephone numberhas been placed in a standard international format. If you want to add other attributes frominetOrgPerson, you may. In an LDIF file, a blank line separates entries.

8. Add this entry to the bottom of the /tmp/addressbook.ldif file.



Sequence 2: Converting Data

Instructions:

1. Listed on the next page is a collection of sample data. Open /tmp/addressbook.ldifin a text editor and create the LDIF equivalents for these users. Some of them may be ableto take advantage of or need to use additional attributes from those available. Save yourwork for use in a later lab.

Homer Simpson742 Evergreen TerraceSpringfield, NT 60066248-555-6754 (home)donuts (local user)

Fred G. SanfordSanford and Son Salvage9114 South CentralLos Angeles, CA 90002650-555-1079 (work)fsanford (local user)

Dr. Dana ScullyFederal Bureau of Investigations3170 W. 53rd Street Annapolis, MD 21402202-555-7117 (fax)202-555-6431 (mobile)[email protected] (e-mail)dscully (local user)

Jed ClampettRural Route 1Bugtussle, TN 65616jclampett (local user)

Mary Richards119 N. Weatherly Ave.Minneapolis, MN [email protected] (e-mail)mrichards (local user)612-555-7862 (home)

Buffy Summers1630 Revello DriveSunnydale, CA 94086408-555-4291 (pager)



slayer (local user)

Some hints about appropriate attributes to use for encoding:

The personalTitle attribute holds a title that is part of a person's name: Mr., Ms., Dr.,Prof., Mlle., and so on. title normally represents a person's job title: “Chief of ThoracicSurgery”.

It is generally assumed that attributes like postalAddress and telephoneNumberare for addresses and phone numbers at work unless otherwise specified, which is why someof the object classes have special attributes for personal addresses and telephone numbers athome.

Some attributes have short names that make them easy to miss. The o attribute (alsoknown as organizationName) is normally the name of an organization; a company,a club, a governmental department, and the like. The ou attribute (also known asorganizationalUnitName) is a subcomponent, division, or department of anorganization. The st attribute (also stateOrProvinceName) represents a majorpolitical or geographical subdivision of a country. The l attribute (also localityName)specifies a “locality”, typically a city but possibly a county, township, parish, or other minorpolitical or geographical subdivision.

Not all of these attributes may be available in the particular object classes you will use forencoding your users.



Sequence 2 Solutions1. dn: uid=donuts,ou=People,dc=serverX+100,dc=example,dc=com

objectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: donutscn: Homer Simpsonsn: Simpsongivenname: Homerstreet: 742 Evergreen Terracel: Springfieldst: NTpostalCode: 60066homePhone: +1 248 555 6754

dn: uid=fsanford,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: fsanfordcn: Fred G. Sanfordsn: Sanfordgivenname: Fredstreet: 9114 South Centrall: Los Angelesst: CApostalCode: 90002o: Sanford and Son SalvagetelephoneNumber: +1 650 555 1079

dn: uid=dscully,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: dscullycn: Dr. Dana Scullysn: Scullygivenname: Danastreet: 3170 West 53rd Streetl: Annapolisst: MDpostalCode: 21402facsimileTelephoneNumber: +1 202 555 7117mobile: +1 202 555 6431



mail: [email protected]: Federal Bureau of Investigations

dn: uid=jclampett,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: jclampettcn: Jed Clampettsn: Clampettgivenname: Jedstreet: Rural Route 1l: Bugtusslest: TNpostalCode: 65616

dn: uid=mrichards,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: mrichardscn: Mary Richardssn: Richardsgivenname: Marystreet: 119 N. Weatherly Avenuel: Minneapolisst: MNpostalCode: 55403homePhone: +1 612 555 7862mail: [email protected]

dn: uid=slayer,ou=People,dc=serverX+100,dc=example,dc=comobjectclass: inetOrgPersonobjectclass: organizationalPersonobjectclass: personobjectclass: topuid: slayercn: Buffy Summerssn: Summersgivenname: Buffystreet: 1630 Revello Drivel: Sunnydalest: CA



postalCode: 94086pager: +1 408 555 4291


RH423-RHEL5-en-2-20081020, Unit 322

Unit 3

Red Hat Directory Server: Basic Configuration

3-1



RH423-RHEL5-en-2-20081020, Lab 323

Lab 3Installing Red Hat Directory Server

Goal: To prepare a basic Red Hat Directory Server service containing address bookinformation.

System Setup: One workstation installed with Red Hat Enterprise Linux called stationX.There should be two virtual machines installed and running on stationX calledserverX+100 and serverX+200. All of these machines are in the example.comDNS domain.

Configure all three of your hosts to refer to yum repositories onserver1.example.com for additional software:

# wget ftp://server1/pub/gls/server1.repo -O /etc/yum.repos.d/server1.repo# wget ftp://server1/pub/gls/rh423/rh423.repo -O /etc/yum.repos.d/rh423.repo

The completed addresses.ldif file from an earlier lab will also be used.



Sequence 1: Controlling the default host-based firewall

Scenario: By default, the installer sets up some basic connection-based packet filteringrules on inbound network traffic. The intention of this is to block access tonetwork services which a system administrator may turn on inadvertently. Inthis sequence, we will ensure that the firewall is enabled. Over the course ofsubsequent labs, we will open access to your local services only as needed.

As a quick review, remember that you can delete rules with iptables -DCHAIN rule-number if you make a mistake. The iptables -L --line-numbers command can help you determine the correct line number of yourbroken rule. Do not forget to use service iptables save to save your work, oryou will lose your changes on the next reboot!

Instructions:

1. On your serverX+100 machine, log in as root and run system-config-securitylevel.

2. In that interface, set Firewall to Enabled. Mark SSH as a trusted service and click OK

3. Run the iptables -L -v -n command and examine your firewall rules. You should seethree standard chains and a custom chain, RH-Firewall-1-INPUT, on the filtertable. Rules are set in the INPUT and FORWARD chains directing all traffic to the customchain. The custom chain permits any traffic from the lo network interface (localhost),any ICMP traffic, traffic using the AH/ESP IPSec protocols, and traffic part of or relatedto communications initiated by your host. It should also accept inbound traffic to port22/tcp, for sshd. Any other traffic will be rejected by the firewall with an ICMP HostProhibited message.

4. Set up a new custom chain for our rules in this class, CLASS-RULES.

5. Now make sure that all incoming traffic is processed by the CLASS-RULES chain before itis processed by RH-Firewall-1-INPUT.

We want the CLASS-RULES chain to match first on the INPUT chain. If there are nomatches on the CLASS-RULES chain, then the firewall will return to the INPUT chain,which will cause the RH-Firewall-1-INPUT rules to be processed.

6. Save your work.



Sequence 2: Installing Red Hat Directory Server

Scenario: In this sequence, you will configure one of your virtual machines as anLDAP directory server, using Red Hat Directory Server. If your studentworkstation is stationX.example.com, you will install the Red Hat DirectoryServer on serverX+100.example.com with an LDAP suffix of dc=serverX+100,dc=example,dc=com. For example, if your workstation isstation3.example.com then server103.example.com will be your LDAP serverwith dc=server103,dc=example,dc=com as your suffix.

Copy the LDIF files you created in an earlier lab to the virtual machine servingas the LDAP server, serverX+100.example.com. This server instance will alsobe your configuration directory, so you will have o=NetscapeRoot as asuffix as well. This server instance will run on the default LDAP port, 389/tcp.You have decided to run Administration Server on port 8008/tcp.

Instructions:

1. Log in as root into the virtual machine that will serve as your LDAP server (serverX+100.example.com).

Use rpm -q to verify the openldap-clients and openldap-servers RPM packagesare installed. If not, use yum to install them from the repository provided byserver1.example.com. The openldap-clients package provides command-line managementtools we will use to work with the directory. The openldap-servers RPM provides a userand group, ldap, we will use for Directory Server, although we will not be running theOpenLDAP directory server at this time.

2. First install the prerequisite RPM which provides the compatible JRE used by the Red HatDirectory Server software:

[root@serverX+100]# yum -y install java-1.5.0-ibm

3. Use yum to install the Red Hat Directory Server software itself:

[root@serverX+100]# yum -y install redhat-ds

4. Run the interactive setup-ds-admin.pl utility to configure Directory Server. Use the -koption to save a silent installation file based on this configuration:

[root@serverX+100]# setup-ds-admin.pl -k

The setup-ds-admin.pl program will ask if you want to continue. Hit Enter to continue.When you are asked to accept the license terms type yes. Depending on your systemconfiguration, some warnings may be reported regarding the amount of physical memoryavailable, the number of file descriptors, or the settings of the TCP keepalive timer. Youmay ignore these warnings and go on.



5. Select the Typical setup type (default). You should be presented with the fully qualifiedhostname of serverX+100.example.com. Accept the default as the hostname to use for thedirectory server.

6. Enter ldap for the System User and the System Group instead of the default whichis nobody.

7. When asked if you want to register this directory server with an existing configurationdirectory, answer no.

8. Since you aren't registering with an existing configuration directory server, you have todefine this server's administrator ID and domain name. Accept the default configurationadministrator ID (admin). Enter redhat (or some other string you will remember or writedown here) for the password. Accept the default administration domain.

9. Use the default (389) for your directory server network port. Accept the default string foryour server identifier (it should be serverX+100).

10. Set the suffix for your directory tree to dc=serverX+100,dc=example,dc=com.

11. Accept the default (cn=Directory Manager) for your local Directory Manager DN.Set its password to directory (or some other string you will remember or write downhere).

12. Set your server's administration port to 8008. The setup program will ask if you are readyto set up your servers. Accept the default value of yes and start the servers.

13. At this point setup-ds-admin.pl should start Directory Server and Administration Serverand exit. If you run netstat -tlpn you should see ns-slapd listening on :::389/tcp andhttpd.worker listening on 0.0.0.0:8008/tcp.

14. Look in /tmp for the setup*.inf file. This is the silent installation file created bythe setup-ds-admin -k command. Examine the file and look for directives you definedaccording to the instructions above. Copy this file to root's home directory for now.

15. Ensure the Directory Server and Administration Server will start after a reboot.

[root@serverX+100]# chkconfig dirsrv on[root@serverX+100]# chkconfig dirsrv-admin on



16. Configure your firewall to allow clients to access your directory server (port 636 will beused later for ldap over ssl):

[root@serverX+100]# iptables -A CLASS-RULES -p tcp --dport 389 -j ACCEPT[root@serverX+100]# iptables -A CLASS-RULES -p tcp --dport 636 -j ACCEPT[root@serverX+100]# iptables -A CLASS-RULES -p tcp --dport 8008 -j ACCEPT[root@serverX+100]# service iptables save



Sequence 3: Loading the directory data and testing the server

Instructions:

1. Find your addressbook.ldif file from earlier. Now it is time to load it into thedirectory server's database. Double-check the file for typos and errors then run:

# redhat-idm-console -a http://serverX+100.example.com:8008

A login window will appear. Log in as cn=Directory Manager using the passwordyou just set in setup-ds-admin.pl. Use http://serverX+100.example.com:8008for the administration URL.

2. The main management window for Red Hat Console should appear. In the topologynavigation tree in the left panel, expand your server's hostname, and then expand the ServerGroup item. You should see two items: Administration Server and Directory Server(serverX+100). Double-click on your Directory Server item to open the Directory Consolewindow.

3. On the Tasks tab, click the Import Databases button. A dialog window will open. Eitherbrowse or enter the path to your addressbook.ldif file in the LDIF file text box,and click OK. This will append your address book entries to the directory. Watch in thedialog that pops up for any rejected entries. You should see some entries rejected, at leastdc=serverX+100,dc=example,dc=com and the entry ou=People,dc=serverX+100,dc=example,dc=com. These conflicts occur because entries with these nameshave been created for you as part of the installation process. If other rejected entries appear,they may indicate typos in your addressbook.ldif file.

4. If all went well, your data is now installed in the directory! In the Directory Consolewindow, select the Directory tab. In the navigation tree, expand the stationX item, thenhighlight the item People (5 acis). Your address book user entries should appear in theright-hand information pane. You can double-click on any of them to see details of eachentry.

5. Close the Directory Console window but keep the main Console management windowopen. Select the Users and Groups tab. Search for the name Scully in the directory. Youshould see an entry appear in the Search Results pane. Double-click on the entry to seemore details of that entry.

6. Quit Console, and at the prompt run the following command to test the LDAP server:

$ ldapsearch -x -b dc=serverX+100,dc=example,dc=com -h serverX+100.example.com

You should see your entries on standard output. If all this worked, your LDAP server isworking! We will look more closely at the ldapsearch command in an upcoming unit.




4. Set up a new custom chain for our rules in this class, CLASS-RULES.

[root@serverX+100]# iptables -N CLASS-RULES

5. Now make sure that all incoming traffic is processed by the CLASS-RULES chain before itis processed by RH-Firewall-1-INPUT.

We want the CLASS-RULES chain to match first on the INPUT chain. If there are nomatches on the CLASS-RULES chain, then the firewall will return to the INPUT chain,which will cause the RH-Firewall-1-INPUT rules to be processed.

[root@serverX+100]# iptables -I INPUT 1 -j CLASS-RULES

6. Save your work.

[root@serverX+100]# service iptables save


RH423-RHEL5-en-2-20081020, Unit 430

Unit 4

Searching and Modifying the LDAP Directory

4-1



RH423-RHEL5-en-2-20081020, Lab 431

Lab 4Using the LDAP Directory

Goal: To gain experience with accessing and searching the LDAP directory.Configuration of user-friendly address book programs. Modifying data in arunning directory service.

System Setup: A working LDAP directory server, loaded with the data set from Lab 2.



Sequence 1: Searching the LDAP directory

Scenario: In this sequence we will gain some practice with search filters. After the firstcouple of examples, you will be on your own. Answers are at the end of thelab.

Instructions:

1. Ensure the openldap and openldap-clients RPMs are installed on your studentworkstation and on both of your virtual machines, serverX+100 and serverX+200.

2. To test the LDAP server, the command-line client configuration file needs to be edited.On your student workstation, stationX, comment out any uncommented lines in /etc/openldap/ldap.conf and add the following replacements:

HOST serverX+100.example.comBASE dc=serverX+100,dc=example,dc=com

3. Copy /etc/openldap/ldap.conf from your workstation to the same location on bothyour virtual machines. Ensure that it is world-readable but writable only by root. On yourworkstation as root:

[root@stationX ~]# cd /etc/openldap[root@stationX openldap]# scp ldap.conf serverX+100:/etc/openldap/[root@stationX openldap]# scp ldap.conf serverX+200:/etc/openldap/

4. On stationX, run the ldapsearch -x command. By default, it will perform a subtree searchusing the filter (objectClass=*) so all entries readable by the anonymous user indc=serverX+100,dc=example,dc=com should be returned.

5. You need to contact the owner of the local mrichards account, but you do not have hercontact information. Try to look it up with the ldapsearch -x '(uid=mrichards)' command.What results do you get?

6. You need the e-mail addresses of all your users living in California. What search filtershould you use to look this information up? Try it out.

7. What search filter would you use to find all Californians that have an organization attribute?Test your answer.



8. What search filter might you use to find all users with telephone numbers? Think carefullyabout where valid phone numbers might be stored. Test your answer.



Sequence 2: Modifying the directory

Instructions:

1. You have a new user to add to the directory service:

Elwood Blues1060 West AddisonChicago, IL 60613eblues (local username)

Login as student on stationX, with password student, and create a temporary file, /tmp/blues.ldif, containing the LDIF for Elwood's entry.

2. Use ldapadd to add Elwood's entry to the directory service without stopping the LDAPservice.

You will need to bind as a DN which has write access to the database to do this. Therootdn (cn=Directory Manager) has this access. Create a personal ~/.ldaprcfile for the account you intend to use to modify the directory, containing the contents:

BINDDN cn=Directory Manager

to reduce your typing. Otherwise, include the BINDDN above as a -D option to thecommand:

[student@stationX ~]$ ldapadd -x -W -f /tmp/blues.ldif

3. Use ldapsearch to verify that Elwood's information has been loaded.



4. Jed Clampett has moved from Bugtussle. You need to update his address to read:

Jed Clampett518 Crestview DriveBeverly Hills, CA 90210

Create the following LDIF modification file in /tmp/hillbilly.ldif:

dn: uid=jclampett,ou=People,dc=serverX+100,dc=example,dc=comchangetype: modifyreplace: streetstreet: 518 Crestview Drive-replace: ll: Beverly Hills-replace: stst: CA-replace: postalCodepostalCode: 90210-

5. Upload Jed's changes with the command:

[student@stationX ~]$ ldapmodify -x -W -f /tmp/hillbilly.ldif

(This assumes that you have specified a BINDDN with write access to the directory in your~/.ldaprc file in step 2.) Run ldapsearch to verify the changes have taken effect.

6. Elwood Blues has failed to pay his bills, so you are dropping him as a user. Use ldapdeleteto remove his entry entirely:

[student@stationX ~]$ ldapdelete -xW uid=eblues,ou=People,dc=serverX+100,dc=example,dc=com

Verify that it has been successfully removed.



7. You have a large number of new users to migrate into your directory service, but the suffixof their entries is not correct. Copy the sample LDIF file called /usr/share/dirsrv/data/Example.ldif, from serverX+100 to student's home directory and prepare it forloading into your server:

[student@stationX ~]$ scp root@serverX+100:/usr/share/dirsrv/data/Example.ldif .[student@stationX ~]$ sed -e 's/dc=example,dc=com/dc=serverX+100,dc=example,dc=com/g' -e 's/dc: example/dc: serverX+100/' Example.ldif > /tmp/serverX+100.ldif

8. Load the new users with ldapadd:

[student@stationX ~]$ ldapadd -c -x -W -f /tmp/serverX+100.ldif

The -c option allows this command to continue on errors even if one or more of the entriesare rejected because the DN is already loaded.



Sequence 3: Graphical address book clientsInstructions:

1. Ensure that you have the evolution and thunderbird RPMs installed.

2. Start the Mozilla Thunderbird e-mail client by selecting Applications -> Internet ->Thunderbird Email from the top menu bar in GNOME or by running the thunderbirdcommand.

The Thunderbird Import Wizard and Account Wizard may start up to prompt you to set upyour e-mail account. Any settings you make will not be important for this lab, as we aremainly interested in configuring the Address Book, not the e-mail client.

3. On the Edit menu, select Preferences. In the dialog window that comes up, select theComposition icon.

4. In the Composition pane, select Directory Server for address autocompletion. Click on theEdit directories... button.

5. Add a new LDAP directory server. Configure it as follows:

Name: ServerX+100 Test LDAP Hostname: serverX+100.example.com Base DN: ou=People,dc=serverX+100,dc=example,dc=comPort number: 389

Use secure connection (SSL): no

You should leave the Bind DN blank. The search base is set in ou=People to limit thepart of your directory that will be searched for user information. Since all users are inou=People, this is a useful optimization.

Save your settings.

6. On the main Thunderbird window, select the Address Book icon. The address bookapplication will open. Find the ServerX+100 Test LDAP address book and highlight it. Inthe Name or Email contains: field, enter the name of a person in your address book, andpress return. A list of matching entries should appear in the pane below. Highlight one ofthem and view the results.

7. Close Thunderbird, and open the Evolution e-mail client by clicking on the e-mail icon inGNOME or by running evolution.

Again, the Evolution Setup Assistant may run to help you configure the e-mail client. Thesettings you make here do not affect the address book, which is our primary interest in thislab. You may need to set an outbound SMTP server to complete the assistant; you may uselocalhost for this.



8. Once Evolution is running and you have completed any necessary work in the SetupAssistant, click on File->New->Address Book to open the LDAP Configuration Assistant.

9. In the LDAP Configuration Assistant, change the Type from On This Computerto On LDAP Servers. Set your display name to ServerX+100 LDAP Server.Set server name to serverX+100.example.com, and your Port to 389.For Use secure connection, set Whenever Possible. For Log in method, useAnonymously. On the Details tab, set Search base to ou=People,dc=serverX+100,dc=example,dc=com.

Click on the OK button to save these settings.

10. Quit Evolution, and then restart it. Click on the dropdown button for the New icon andselect Contact List. Expand On LDAP Servers and highlight your LDAP server. Searchfor a user in the interface that appears. You may double-click on any of the items thatappears to get a detailed view of the contents.


RH423-RHEL5-en-2-20081020, Lab 4 Challenge Sequence 439

Challenge Sequence 4: Converting Between LDAP Schemas

Scenario: One problem with our current entries is that they use Mozilla-style attributesfor postal address information; the street address, city, state, and zip codeare all stored in individual attributes instead of a single postalAddressattribute. That means that addresses for these entries do not show up properlyin Evolution or the Directory Server Gateway or Console tools. It would benice if we had some mechanism to take address information in existing entriesin the directory stored in Mozilla-style attribute values and synchronize themto a postalAddress value for Directory Server clients or Evolution.

Instructions:

1. As a challenge if you finish early, consider writing a script that can create an LDIFUpdate file containing postalAddress attributes for entries already stored inthe LDAP directory, generated from their street/l/st/postalCode values. (Remember,postalAddress takes as a value up to six lines of data, each line separated by a dollarsign, 30 characters maximum per line.)

2. The truly ambitious can consider how to handle addresses for international entries thathave the c attribute set. Remember that the value of c should be a two-letter ISO 3166country code and not the actual name of the country. The file /usr/share/zoneinfo/iso3166.tab, which should be provided by the tzdata package on your system, maybe used as a reference.

An example script written in the Perl scripting language may be downloaded from this url:

http://server1.example.com/pub/gls/rh423/addrsync.pl




6. (st=CA)

7. (&(st=CA)(o=*))

8. This one is tricky because there is more than one attribute which includes a telephonenumber; work telephones, mobiles, and so on. Depending on your definition of “telephone”,you could try

(|(homePhone=*)(mobile=*)(telephoneNumber=*))


RH423-RHEL5-en-2-20081020, Unit 541

Unit 5

Red Hat Directory Server:Authentication and Security

5-1



RH423-RHEL5-en-2-20081020, Lab 542

Lab 5Red Hat Directory Server and TLS/SSL

Goal: To protect simple binds to Directory Server with TLS, using a certificatesigned by an simple self-managed certificate authority.

System Setup: One virtual server installed with Red Hat Directory Server and a workingconfiguration from an earlier lab.

Lab Setup: The instructor machine, server1.example.com, should be configured as an FTPserver that allows students to anonymously upload files to a directory called /upload.



Sequence 1: Creating and installing a CA-signed server certificateScenario: Anonymous binds to the LDAP directory service may provide adequate

security for reading the address book. For write access, though, we need toprotect the security of the management password.

In this sequence, you will set up your LDAP server to use TLS in order tosecure network communications with clients. You will generate a privatekey and matching public server certificate for your LDAP server and havethe in-house Certificate Authority run by the instructor sign the public servercertificate. Clients will then be able to determine the authenticity of yourserver certificate if they have a copy of your in-house certificate authority'spublic CA certificate.

Instructions:

1. Run redhat-idm-console and authenticate as cn=Directory Manager. In thenavigation tree, find your Directory Server instance and double-click on it to openDirectory Console .

2. On the Tasks tab of Directory Console, click the Manage Certificates button.

3. Since this is the first time you have managed TLS certificates, you will be prompted to set asecurity device password. Use redhat (or some better password you can remember). Thispassword is used to protect your server's private key files from compromise by encryptingthem.

4. The Manage Certificates window will open. On the Server Certs tab, click the Request...button.

5. In the Certificate Request Wizard that opens, request a certificate manually. For Servername, enter serverX+100.example.com (your Red Hat Directory Server's FQDN).Use Example, Inc. for Organization (note that there must be a space between"Example," and "Inc"). For City/locality, use Raleigh. For State/province, use the drop-down menu to select North Carolina. For Country/region, use the drop-down menu toselect US United States. You may leave Organizational unit blank. Click Next.

6. You will be prompted for the security device password you just set. Enter it in the text boxand click Next.

7. Your certificate request is ready. Click Save to file... and save it to /tmp/serverX+100.csr.

8. Send the certificate request to your Certificate Authority for signing. Connect byanonymous FTP to server1.example.com and upload the /tmp/serverX+100.csr fileto the anonymous FTP server's /upload directory.

9. Indicate to the instructor that your certificate is ready for signing. The instructor willverify your identity as the owner of stationX.example.com, and sign the certificate.The signed certificate will then be available for download from the ftp://



server1.example.com/pub/certs/ URL. Save or copy the file to /tmp/stationX.crt. At the same time download the CA's public CA certificate from ftp://server1.example.com/pub/EXAMPLE-CA-CERT and save it as /tmp/my-ca.crt.

What happened on server1.example.com? The instructor has an OpenSSL-based certificateauthority set up with its own private key and public SSL certificate as part of standardclassroom preparation. The instructor ran the following command to sign your certificatewith the private CA key:

[root@server1 ~]# openssl ca -in /var/ftp/upload/serverX+100.csr -out /var/ftp/pub/certs/serverX+100.crt

The instructor was presented with information about the proposed subject of the certificate,its validity period, and for what uses to validate it. When approved through the openssl caprogram, it was assigned a serial number in the CA's database for tracking purposes, and thesigned certificate was created.

10. Install the signed TLS server certificate into Directory Server. In the Manage Certificateswindow of Directory Console, on the Server Certs tab, click the Install... button.

The certutil command-line tool provides an alternative to the Java-based console foradministering certificates. To list the existing certificates, run:

# certutil -L -d /etc/dirsrv/slapd-instance/

To import a new cert, run:

# certutil -d /etc/dirsrv/slapd-instance -A -i /path/to/signed.crt -n testcertname -t 'u,u,u'

11. In the Certificate Install Wizard, select in this local file: and enter /tmp/serverX+100.crt in the text box. Click Next. Review the certificate information, and click Next,and the certificate name, and click Next.

12. You will be prompted for your security device password one more time. Enter it and clickDone. Your CA server certificate should appear under the Server Certs tab now.

13. Install your CA certificate. Select the CA Certs tab, click the Install... button, and installthe CA certificate /tmp/my-ca.crt. Go through the installation wizard acceptingthe default settings otherwise. Your certificate should appear under the CA Certs tabafterwards.



Sequence 2: Enabling TLS in Directory Server

Scenario: Now that the TLS certificates are installed, it is time to turn on TLS/SSL forthe Directory Server.

Instructions:

1. In the Directory Console window, select the Configuration tab.

2. Highlight the top item in the navigation tree and select the Encryption tab. Check EnableSSL for this server and Use this cipher family: RSA. Verify that Check hostname againstname in certificate for outbound SSL connections is checked. Click Save.

3. Restart the Directory Server by running as root:

[root@serverX+100 ~]# service dirsrv restart serverX+100

When prompted for the security device password, enter it. The server should restart.

4. To avoid being prompted for the password on the next restart, create a file called /etc/dirsrv/slapd-serverX+100/pin.txt containing the text:

Internal (Software) Token:password

Restart the directory server instance for serverX+100 to confirm the service will restartwithout human invervention for the entry of a password.



Sequence 3: Confirming Directory Server TLS Operation

Scenario: Now it is time to confirm TLS/SSL is properly configured and workingon our Red Hat Directory Server. We will configure our workstation,stationX.example.com, to query our Directory Server using TLS/SSL.

Instructions:

1. To test the LDAP server with SSL, the command-line client configuration file onstationX.example.com needs to be edited. Comment out any uncommented lines in /etc/openldap/ldap.conf and add the following replacements:

HOST serverX+100.example.comBASE dc=serverX+100,dc=example,dc=comTLS_CACERT /etc/openldap/cacerts/my-ca.crt

Note the HOST directive must use the fully-qualified domain name of your Red HatDirectory Server and not the IP address, otherwise TLS verification of the server'scertificate will fail. This is because the hostname will be compared to the common name inthe subject of the server's TLS certificate to verify that it actually belongs to the server youare trying to contact.

2. Make sure that the /etc/openldap/cacerts directory exists, owned by user root andgroup root, with permissions 755. Copy the CA certificate from server1.example.com to /etc/openldap/cacerts/my-ca.crt and make sure it has permissions 644 and isowned by user root and group root.

3. Open a terminal window and create a shell as the user student. Search the LDAP serveragain, this time requiring StartTLS:

[student@stationX ~ ]$ ldapsearch -x -ZZ

If this command displays your directory entries, StartTLS is working.


RH423-RHEL5-en-2-20081020, Unit 647

Unit 6

Linux User Authentication with NSS and PAM

6-1



RH423-RHEL5-en-2-20081020, Lab 648

Lab 6PAM and NSS

Goal: To learn more about PAM and NSS services and authentication. A central NISserver will be used as a source of user information.

System Setup: Two workstations configured with Red Hat Enterprise Linux. A working NISdomain, notexample, served by server1.example.com.

Initial Troubleshooting Tip: In this lab, it is possible that a typo or mistake ina sequence can break authentication for all users, including root. To make iteasier for you to repair mistakes, try to keep a root shell open on at least oneterminal at all times.



Sequence 1: Name Service Switch (NSS) and NIS

Scenario: In this sequence, you will manually set up one of your systems as a NIS client.You will also manually configure NSS on that system to use NIS as a sourceof user information. Use the host computer, stationX that you are not using asyour LDAP server for this sequence.

Instructions:

1. Verify that the ypbind package is installed, and if not install it from server1.example.com.

2. You need to point your client machine at the NIS server. Run the command

nisdomainname notexample

Make this setting persist across reboots by changing /etc/sysconfig/network toinclude

NISDOMAIN=notexample

Edit /etc/yp.conf to include the line

domain notexample server server1.example.com

Activate your new settings with service ypbind restart.

3. At this point, you should be bound to server1.example.com as a member of the NIS domainnotexample, and you should be able to dump the contents of NIS maps:

[student@stationX ~]$ ypcat passwd... output omitted ...

You should see a number of guest20* password file entries listed. However, you are notyet using these NIS maps to provide authentication or naming information, because NIShas not been tied into NSS or PAM. To verify this, dump your user database by running thecommand

[student@stationX ~]$ getent passwd ... output omitted ...

You should see only local users, not NIS users.



4. Open /etc/nsswitch.conf and find the lines

passwd: filesshadow: filesgroup: files

Edit them to read:

passwd: files nisshadow: files nisgroup: files nis

This configures libc to look in NIS after local files to find users.

5. Run getent passwd again. This time, the NIS users should appear after your local users inthe output. The NIS users are now valid users on the system. Test this; as root, create a filein /tmp and chown it to guest2001. The operation should work, if NIS is being properlyconsulted for user information. As another test, run getent passwd root. You should seejust root's password file entry.

6. As an experiment, temporarily edit /etc/nsswitch.conf again to read

passwd: nis [NOTFOUND=return] filesshadow: nis [NOTFOUND=return] filesgroup: nis [NOTFOUND=return] files

Run getent passwd root again. What happens? The root account is not in NIS, so you shouldnot see that information.

Stop ypbind (with service ypbind stop) and run getent passwd root again. What happensnow? You should be able to use user information stored in local files.

Change each line back to files nis again and run service ypbind start.



Sequence 2: Pluggable Authentication Modules (PAM) and NISInstructions:

1. Take a look at the PAM stack used on a text-only terminal by login:

[student@stationX ~]$ cat /etc/pam.d/login#%PAM-1.0auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.soauth include system-authaccount required pam_nologin.soaccount include system-authpassword include system-auth# pam_selinux.so close should be the first session rulesession required pam_selinux.so closesession include system-authsession required pam_loginuid.sosession optional pam_console.so# pam_selinux.so open should only be followed by sessions to be executed in the user contextsession required pam_selinux.so opensession optional pam_keyinit.so force revoke

On initial authentication, we make sure that the user is not root on a insecure terminal andinclude the checks in /etc/pam.d/system-auth. The system-auth checks are:

[student@stationX ~]$ cat /etc/pam.d/system-auth#%PAM-1.0# This file is auto-generated.# User changes will be destroyed the next time authconfig is run.auth required pam_env.soauth sufficient pam_unix.so nullok try_first_passauth requisite pam_succeed_if.so uid >= 500 quietauth required pam_deny.so

account required pam_unix.soaccount sufficient pam_succeed_if.so uid < 500 quietaccount required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtokpassword required pam_deny.so



session optional pam_keyinit.so revokesession required pam_limits.sosession [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uidsession required pam_unix.so

Attempt to log in to your NIS client as one of the NIS users, with the password password.(Ignore any warnings about missing home directories for now.) Why does this work?

Run getent passwd again. Notice that there are valid password hashes listed for your NISusers. The pam_unix.so module can use this information for authentication just as if it werestored in the /etc/passwd file!

2. However, by default it does not know how to change NIS passwords. Look for thepam_unix.so line in the system-auth password stack and add the nis option to it. Theline should now look like this:

password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok nis

Attempt to change the password of one of the NIS guest accounts; for example, if you areon station15, use guest2015. If the instructor is running yppasswdd on server1, this shouldwork. (Note that root on the NIS client can not change a NIS user's password, but NIS userson the client can change their own passwords.)

[student@stationX ~]$ su - guest20XXPassword:[guest20XX@stationX ~]$ passwdChanging password for user guest20XX.(current) UNIX password: New UNIX password: Retype new UNIX password: passwd: all authentication tokens updated successfully.

3. Configure your LDAP server as a NIS client in the same NIS domain, the easy way. Login on the LDAP server and run system-config-authentication. Enter the root password ifprompted, enable NIS support, and configure NIS so server1.example.com is the NIS serverand notexample is the NIS domain. Compare the files you edited on the original NIS clientin the sequences above with the same files on the LDAP server.



Sequence 3: PAM-based authentication and local administrativetoolsScenario: In this sequence, we will experiment with making changes to PAM that affect

the behavior of system utilities that authenticate logged-in users. In particular,we will experiment with modifications to the PAM file for the su command.

Instructions:

1. Some Linux-like systems restrict use of su to members of the wheel group. Linux does nothave this behavior by default, but it may be implemented through PAM. Create a local user,and make it a member of group wheel.

[root@stationX ~]# useradd -G wheel wheeluser

2. As root, make a backup copy /etc/pam.d/su as /etc/pam.d/su.orig.

3. Uncomment the auth rule in /etc/pam.d/su which reads:

auth sufficient pam_wheel.so trust use_uid

Try to su - as wheeluser and as a user not in group wheel, such as one of the NIS users.What happens?

Comment this line back out and save the file.

4. The distinction between required and sufficient is vitally important. Add the following lineto the top of /etc/pam.d/su:

auth required pam_permit.so

Save the file and try to su - as some user. The pam_permit.so module always passes.The module should appear to have no effect on the overall authentication process. Why?Because it is only the first required module, and other modules such as pam_rootok.so andpam_unix.so get to veto the authentication.

5. Now change the line to read this way instead, and save the file:

auth sufficient pam_permit.so

Now try to su - as some user. Yikes! The module is checked first, it passes, and that vote isconsidered sufficient grounds to authenticate the user and stop checking the rest of the PAMstack. Anyone can su to anyone now!

6. For another odd experience, remove the pam_permit line, then comment out thepam_rootok.so line in /etc/pam.d/su and save the file. As root, try to su - someuser. Whathappens? What must this module do?



7. Put your configuration back the way it was:

cp /etc/pam.d/su.orig /etc/pam.d/su

If you have additional time, feel free to examine the other files in /etc/pam.d to see howthey work. If you make any changes, be careful to put things back together when you aredone!


RH423-RHEL5-en-2-20081020, Unit 755

Unit 7

Centralized User Authentication with LDAP

7-1



RH423-RHEL5-en-2-20081020, Lab 756

Lab 7Network Authentication with LDAP

Goal: Move existing users from a NIS server to your LDAP directory. Configureappropriate access control lists to directory information. Set up clients whichcan authenticate using this data.

System Setup: Working LDAP server and working NIS clients from previous labs.



Sequence 1: Preparing the LDAP directory server

Scenario: In this sequence, you will prepare your LDAP directory service for use asa replacement for the NIS server on server1.example.com. Before you startstoring sensitive account information in the directory, you will need to tightensecurity and adjust some settings on your LDAP server.

Instructions:

1. We will store new passwords for user entries set through the LDAP Password Changemechanism in system CRYPT format:

Run redhat-idm-console. Start up the Directory Console for your directory server instance,and select the Configuration tab. Highlight the Data item in the left navigation tree. Inthe right information pane, select the Passwords tab. At the bottom of the pane, findthe Password encryption drop-down menu and change it from Salted Secure HashingAlgorithm (SSHA) to Unix crypt algorithm (CRYPT).

Click Save.

2. Add a new administrative user, uid=client-root,dc=serverX+100,dc=example,dc=com. InDirectory Console, select the Directory tab and highlight and right-click on your suffix,serverX+100, in the navigation tree. In the pop-up menu, select New... then User. Set theUser ID to client-root, First Name to Client, Last Name to Root, and Common Name(s)to Client Root. Set the password to something you know. Click OK.

3. Right-click on your suffix in the navigation tree again, and select Set Access Permissions....In the Manage Access Control window that opens, click the New button. In the Edit ACIwindow that opens, click Edit Manually and edit the ACI in the text box to read:

(targetattr="userPassword||shadowLastChange||shadowMin||shadowMax||shadowWarning||shadowInactive||shadowExpire||shadowFlag")(version 3.0; acl "Allow client-root write on userPassword"; allow(all)(userdn="ldap:///uid=client-root,dc=serverX+100,dc=example,dc=com");)

Click OK to save your work.



4. In the Manage Access Control window from the previous step, highlight Enableanonymous access and click the Edit button. The ACI should appear in Edit Manuallymode automatically this time (displaying an Edit Visually button); if the window opensin visual editing mode, click the Edit Manually button. The ACI displayed in the windowshould read:

(targetattr != "userPassword")(version 3.0; acl "Enable anonymous access"; allow (read,compare,search)(userdn = "ldap:///anyone");)

Edit it so that it reads like this instead:

(targetattr != "userPassword||shadowLastChange||shadowMin||shadowMax||

shadowWarning||shadowInactive||shadowExpire||shadowFlag")(version 3.0; acl"Enable anonymous access"; allow (read,compare,search)(userdn = "ldap:///anyone");)

Click OK to save your work.



Sequence 2: Preparing and migrating NIS users to LDAP

Scenario: In this sequence, you will import user and group account data from the existingNIS server into your LDAP directory. You will take advantage of the /usr/share/openldap/migration scripts to simplify this process, butyou will still need to edit the LDIF output before uploading your data to thedirectory server.

Instructions:

1. First, you need to decide what data you will provide in the directory service. In this case,you need the passwd and group NIS maps. If you had a shadow map, you would want thatas well. Collect this data on your NIS client with the ypcat command:

[root@stationX ~]# ypcat passwd > /tmp/passwd.nis[root@stationX ~]# ypcat group > /tmp/group.nis[root@stationX ~]# scp /tmp/passwd.nis /tmp/group.nis root@serverX+100:/tmp/

2. You currently do not have a shadow password map in NIS. While it is not strictly speakingnecessary, create one for these users. Run the following command to construct one using thehashes in /tmp/passwd.nis as a base line.

[root@serverX+100 ~]# for i in $( cut -f1-2 -d: /tmp/passwd.nis ); do> echo "$i:$[$(date +%s)/86400]:0:99999:7:::"> done > /tmp/shadow.nis

3. Now that the hashes are in shadow.nis, clean them out of passwd.nis:

[root@serverX+100 ~]# sed -r 's/\$1\$.{8}\$.{22}/x/g' /tmp/passwd.nis > /tmp/passwd.nis-new[root@serverX+100 ~]# mv /tmp/passwd.nis-new /tmp/passwd.nis



4. Next, you need to prepare the migration scripts. The migration scripts use a directoryhierarchy that is very similar to the default one used by Red Hat Directory Server.

Edit these three lines in /usr/share/openldap/migration/migrate_common.ph:

$DEFAULT_MAIL_DOMAIN = "serverX+100.example.com";$DEFAULT_BASE = "dc=serverX+100,dc=example,dc=com";$EXTENDED_SCHEMA = 1;

Of these settings, $DEFAULT_BASE sets the suffix output by the migration scripts, and$EXTENDED_SCHEMA configures the scripts to create users with the inetOrgPersonobject class instead of the simpler account object class.

In addition, on line 61 find the reference to ou=Group and change it to ou=Groups. (Thedefault template entries for Directory Server use ou=Groups for group entries.)

5. Now run the migration scripts. Change directory to /usr/share/openldap/migration and run the migrate_base.pl script first:

[root@serverX+100 migration]# ./migrate_base.pl > /tmp/base.ldif

This sets up the LDIF for your basic naming hierarchy. There are a few corrections youwant to make before running ldapadd. Open base.ldif in a text editor.

Remove the first two entries. dn: dc=example,dc=com is created by a bug in themigration script. The dn: dc=serverX+100,dc=example,dc=com entry is alreadyset up on your directory server from the address book.

Also, look for the dn: ou=People,dc=serverX+100,dc=example,dc=comentry. Remove that, too, since you already set it up for the address book. Save the file andexit.

6. Next, prepare the user accounts. The migration script makes the hard-coded assumption thatyour shadow password file is /etc/shadow, so you will need to edit migrate_passwd.plbefore running it.

Open migrate_passwd.pl in an editor, and on line 188 or so, change the following line inthe read_shadow_file() subroutine:

open(SHADOW, "/etc/shadow") || return;

to instead read

open(SHADOW, "/tmp/shadow.nis") || return;

7. Migrating the user and group data should be simple at this point: run



[root@serverX+100 migration]# ./migrate_passwd.pl /tmp/passwd.nis /tmp/passwd.ldif[root@serverX+100 migration]# ./migrate_group.pl /tmp/group.nis /tmp/group.ldif

It is now time to upload your user and group data to the directory. Run the followingcommands. If you did not set BINDDN to your rootdn in your ~/.ldaprc in an earlierlab, remember to add the option -D 'cn=Directory Manager' to the commandsbelow:

[root@serverX+100 ~]# ldapadd -c -Z -x -W -f /tmp/base.ldif[root@serverX+100 ~]# ldapadd -c -Z -x -W -f /tmp/passwd.ldif[root@serverX+100 ~]# ldapadd -c -Z -x -W -f /tmp/group.ldif

Watch for any errors in the upload process. You will see some warnings since some entriesyou are importing already exist. In this case, these may be safely ignored. (Note whichentries are affected.) Use ldapsearch to verify your entries are present.



Sequence 3: Configuring clients for LDAP authenticationScenario: In this sequence, you will configure your workstation and both virtual

machines to authenticate users by using information stored in your LDAPdirectory, replacing the NIS server on server1.example.com.

Instructions:

1. Make sure your workstation and both virtual machines have the openldap, openldap-clients,and nss_ldap packages installed. Ensure there is a copy of /etc/openldap/cacerts/my-ca.crt owned by user root, group root, with permissions 0644 on all your systems.

2. On all your systems, run system-config-authentication.

On the User Information tab, uncheck Enable NIS Support if it is checked. Check EnableLDAP Support. Select the Configure LDAP... button. In the window that opens, checkUse TLS to encrypt connections, and set

LDAP Search Base DN: dc=serverX+100,dc=example,dc=comLDAP Server: serverX+100.example.com

Click the OK button to save your changes and exit. This will apply these changes to /etc/ldap.conf, /etc/nsswitch.conf, and /etc/pam.d/system-auth.

3. A few additional changes need to be manually applied. On all of your systems, edit /etc/ldap.conf. (This is a different file than /etc/openldap/ldap.conf!)

To authenticate the server's TLS certificate, add the following lines:

tls_checkpeer yestls_cacertfile /etc/openldap/cacerts/my-ca.crt

4. Also in /etc/ldap.conf, fix the password change mechanism. Change thepam_password line to read:

pam_password crypt

Save your changes and exit.

5. Anonymous simple binds are used by non-privileged users on the clients to get passwordinformation. The root account on the clients has a special account so that password changesmay work. Set nss_ldap to use this account by editing the following directive in /etc/ldap.conf:

rootbinddn uid=client-root,dc=serverX+100,dc=example,dc=com

6. Create and edit a file on all of your systems named /etc/ldap.secret that contains thecleartext password for the rootbinddn entry (not the encrypted password hash). Set itspermissions to 0600, user root, group root.



7. Run getent passwd and getent shadow. Do you see the LDAP users? (You should.) Checkgetent group as well. Do you see password hashes in the shadow map when getent shadowis run as root? (If you see the LDAP users, you should see the hashes.) If so, what happensif you run getent shadow as a regular user? (You should not get any output.)

8. On both machines, edit the password rules in /etc/pam.d/system-auth to read asfollows:

password requisite pam_cracklib.so try_first_pass retry=3password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtokpassword sufficient pam_ldap.so use_authtokpassword required pam_deny.so

9. Restart sshd so it sees the changes to authentication: service sshd restart. Attempt to log into all of your machines as one of the LDAP users. Ignore any home directory related errorsfor now. This should work.

10. Try changing the password of one of the users you just migrated into the LDAP directory.Try logging in as that user to ensure this change worked.



Challenge Sequence 4: Storing other NIS information in LDAP

Scenario: If you have extra time during this lab, take a moment to think aboutwhat would be required to make your posixGroup entries also begroupOfUniqueNames static group entries, assuming for the sake ofargument that posixGroup were really an auxiliary class. Do any of theexisting posixGroup entries have memberUid attribute values? Can youautomate a process to convert the memberUid values into uniqueMembervalues?

The user accounts stored in the LDAP directory still need home directoriesaccessible by your computers. Conveniently, server1.example.com has a NFSserver exporting home directories for these users. It would be nice if homedirectories could be automounted for each user at login. It would be nicer ifthe automount maps themselves could be managed centrally in the LDAPdirectory rather than through local files on each computer.

If local files were to be used with the automounter, /etc/auto.mastermight contain the line

/home/guests /etc/auto.guests --timeout 60

and /etc/auto.guests might contain the line

* -rw,soft,intr 192.168.0.254:/home/guests/&

It turns out that the automounter is LDAP capable. The auto.master andauto.guests files must be converted into the right format, and autofs mustbe pointed at the LDAP directory rather than /etc/auto.master.

Loading automount maps into the LDAP directory:

Instructions:



1. First you need a nisMap entry to hold the auto.master file, and then you need anisObject entry to hold one line from that file. Open /tmp/automount.ldif in atext editor.

dn: nisMapName=auto.master, ou=Mounts,dc=serverX+100,dc=example,dc=comobjectclass: topobjectclass: nisMapnisMapName: auto.master

dn: cn=/home/guests,nisMapName=auto.master, ou=Mounts,dc=serverX+100,dc=example,dc=comobjectclass: topobjectclass: nisObjectnisMapEntry: ldap:serverX+100.example.com:nisMapName=auto.guests, ou=Mounts,dc=serverX+100,dc=example,dc=com --timeout=60nisMapName: auto.mastercn: /home/guests

2. Next, you need a nisMap entry to hold the auto.guests file and a nisObject entryto hold one line from that file. In the LDAP version of the auto.guests file, a “/”replaces the asterisk. Add to /tmp/automount.ldif:

dn: nisMapName=auto.guests, ou=Mounts,dc=serverX+100,dc=example,dc=comobjectclass: topobjectclass: nisMapnisMapName: auto.guests

dn: cn=/,nisMapName=auto.guests, ou=Mounts,dc=serverX+100,dc=example,dc=comobjectclass: topobjectclass: nisObjectcn: /nisMapEntry: -rw,soft,intr 192.168.0.254:/home/guests/&nisMapName: auto.guests

3. Check and save your work. Upload these new entries to the directory with ldapadd. Verifythat they loaded properly.

4. On both of your computers, open /etc/nsswitch.conf in a text editor, and change theautomount line to read:

automount: files ldap



5. Unlike other NSS services, the automounter needs to have /etc/openldap/ldap.conf configured correctly in order to work. On all of your machines, make sure youhave edited that file to point to your directory server:

HOST serverX+100.example.comBASE dc=serverX+100,dc=example,dc=comTLS_CACERT /etc/openldap/cacerts/my-ca.crt

6. Start the autofs service. Switch to one of the LDAP users and cd directly into that user'shome directory. Is the automounter working? On all of your hosts, run chkconfig autofs on.



Sequence 5: LDAP authentication with pam_ldap

Scenario: Right now you have NIS-like LDAP user authentication working. Passwordhashes are provided along with user information to NSS, and pam_unixhandles authentication. Even with TLS encryption this mode exposes thepassword hashes of all user accounts to the compromised client stations.

With pam_ldap, client stations do not need to know any password hashes.User information is still provided to NSS, but when a user attempts to login, pam_ldap converts the username provided into the DN of an entry, andattempts to simple bind to the LDAP server using the password provided. Ifthe simple bind works, the user gave the correct password and gets to log in.

If pam_ldap is used without TLS, it is less secure than NIS since userpasswords are passed cleartext over the network on every local authentication.If it is used in conjunction with TLS, it can be more secure than NIS becausethe password hashes do not need to be exposed to client stations.

In this sequence, you will convert all of your hosts to use pam_ldap forLDAP user authentication. You will continue to use pam_unix for local userauthentication.

Instructions:

1. On all of your hosts, run system-config-authentication again. In the Authentication tab,check Enable LDAP support.

2. On the LDAP server, adjust the ACIs to suppress read access to the password attributes.Open Directory Console, and on the Directory tab highlight the serverX+100 suffix inthe navigation tree. On the Object menu, select Set Access Permissions. Highlight Allowclient-root to write userPassword and click Edit.... If the Edit Visually button is visible,click it to get to the visual ACI editor. Select the Rights tab, and uncheck read. Click OK.

Now the uid=client-root,dc=serverX+100,dc=example,dc=com entry can write andauthenticate but not read the userPassword attribute. If that user still had read access onuserPassword, pam_unix authentication using the LDAP name service would continueto be used in preference to pam_ldap authentication.

3. At this point, getent shadow as root should display a x for the password field.

4. The users stored in the LDAP directory should still be able to log in. Test this. If you arehaving trouble with graphical logins, log into a text virtual console as root and try runningthe command killall gdm-binary, then try again when the login screen reappears.


RH423-RHEL5-en-2-20081020, Unit 868

Unit 8

Kerberos and LDAP

8-1



RH423-RHEL5-en-2-20081020, Lab 869

Lab 8Kerberos and LDAP

Goal: Set up a Kerberos Key Distribution Center. Configure Kerberos-baseduser authentication. Set up a service which can use Kerberos tickets foruser authentication. Configure your LDAP server to support Kerberosauthentication and access control with SASL/GSSAPI.

System Setup: LDAP user authentication set up on all of your hosts after the completion ofthe previous lab.



Sequence 1: Configuring the Kerberos KDC

Scenario: Now, we will change how the system authenticates users. Account informationwill be obtained from the same source as before, but authentication will behandled by Kerberos. Install the KDC on serverX+100.example.com. YourKerberos realm should be SERVERX+100.EXAMPLE.COM. The machinestationX.example.com (and in a later lab serverX+200.example.com) will beclients and members of the Kerberos realm.

Instructions:

1. Make sure that you have the krb5-server and krb5-workstation packagesinstalled on your KDC. Open the necessary firewall ports.

2. On the KDC, open /etc/krb5.conf in a text editor. Make the following changes: In[libdefaults]:

default_realm = SERVERX+100.EXAMPLE.COM

[realms] should read in its entirety:

[realms] SERVERX+100.EXAMPLE.COM = { kdc = 192.168.0.X+100:88 admin_server = 192.168.0.X+100:749 }

[domain_realm] should read:

[domain_realm] serverX+100.example.com = SERVERX+100.EXAMPLE.COM serverX+200.example.com = SERVERX+100.EXAMPLE.COM stationX.example.com = SERVERX+100.EXAMPLE.COM

This [domain_realm] section tells the machine that all these stations are membersof the SERVERX+100.EXAMPLE.COM Kerberos realm. (If all realm members werethe only hosts in a DNS subdomain, we could have simply mapped the subdomain to theKerberos realm.)

In [appdefaults], add the following line inside the curly braces for the PAM block:

validate = true

This causes PAM to verify that it is talking to the true KDC by asking it for a ticket to thesystem's host principal. Save your work.



3. Initialize the Kerberos database on the KDC with a stash file so it can start up automatically.You will be prompted for a password to secure the master Kerberos database; you may pickanything. In practice, you want to save this password because you will need it if you everchoose to set up a backup KDC.

4. In /var/kerberos/krb5kdc/kdc.conf, edit the [realms] block to start:

[realms] SERVERX+100.EXAMPLE.COM = { master_key_type = des3-hmac-sha1 default_principal_flags = +preauth

... and so on.

5. Open /var/kerberos/krb5kdc/kadm5.acl in an editor. Change the file so it reads:

*/admin@SERVERX+100.EXAMPLE.COM *

6. On the KDC, use kadmin.local to add an administrative root/admin principal and aguest200X principal to the Kerberos database.

7. Still in kadmin.local, list the principals in the database. Note that some were automaticallycreated when you created the database. Also, examine the details of a single principal.

8. A number of files we just created may have incorrect SELinux types if you are using anoutdated SELinux targeted policy. Confirm that you have a reasonably current targetedpolicy. Every RHEL 5.1 machine should have version 2.4.6-136 or later of the selinux-policy-targeted package installed.

9. Start the KDC daemons.



Sequence 2: Configuring a Kerberos application server

Scenario: In this sequence, you will set up both of your computers to perform userauthentication using the new Kerberos KDC.

Instructions:

1. As root on your new KDC, serverX+100.example.com, run kadmin.local again. Create ahost principal for your KDC.

2. While still in kadmin.local on the KDC, extract the new principal into a local keytab filereadable only by root.

Ensure /etc/krb5.keytab has the correct SELinux type.

Quit kadmin.local.

3. Log in as root to stationX.example.com, which is not being used as the KDC. Make surethat the krb5-workstation package is installed. Copy /etc/krb5.conf from theKDC on serverX+100.example.com to stationX.example.com.

Ensure /etc/krb5.conf on stationX.example.com has the correct SELinux type.

Repeat this process, copying /etc/krb5.conf from serverX+100 to serverX+200.

4. Still logged in as root on stationX.example.com, run kadmin, authenticating as theroot/admin principal.

5. In kadmin on stationX, create a host principal for stationX.example.com and extract it tothat host's /etc/krb5.keytab file.


Exit kadmin.

6. On serverX+100, serverX+200 and stationX, run system-config-authentication. On theAuthentication tab, select the Enable Kerberos Support check box, and keep the currentKerberos configuration. Leave the User Information settings enabled.

7. Run getent passwd to verify that account information is still visible for guest200X.

8. On stationX.example.com, switch to a text login prompt. Try logging in as the guest200Xprincipal you created in the previous sequence. This should work. As that user, run klist.You should see that you have a Kerberos TGT.



9. As guest200X, ssh to serverX+100.example.com. You should be able to login withoutbeing prompted for a password! The sshd service has Kerberos ticket authentication turnedon by default.

Now try to ssh back to stationX again. You should be prompted for a password. Why? Runklist. You should not have any tickets, since you did not enter a password or run kinit whenyou logged in, and ssh did not forward your credentials.

10. Log out of serverX+100. It is possible to configure ssh to forward your credentials. Asroot, edit /etc/ssh/ssh_config, on both hosts, and add the following line to thebottom of the Host * section:

GSSAPIDelegateCredentials yes

11. Still logged in as guest200X on stationX, run klist to verify you still have a TGT. Try tossh to serverX+100 again. Run klist. You should have a TGT this time. Try to ssh backto stationX from serverX+100. This time it should work without prompting you for yourKerberos password.

If you find you are still prompted for a password, try running kdestroy on stationX andserverX+100 as the user you have been attempting to connect with and try again.

If the problem persists, try running kinit -f on stationX as guest200X and try again. If thatsucceeds, you should double-check that kdc.conf contains forwardable = yes.

12. The reason GSSAPIDelegateCredentials is off by default is so you do notaccidentally forward a TGT to an insecure system. You can explicitly ask not to forwardcredentials by specifying the -k option. Try using ssh to log into serverX+100 one moretime, but this time add -k. Run klist to verify that your credentials were not forwarded.

13. DEBUG hints:

If you are experiencing problems, check that time on the machines is synchronized. For aquick test do the following: On stationX:

[root@stationX]# chkconfig krb5-telnet on

On serverX+100:

[root@serverX+100]# telnet -Fxl guest200X stationX.example.com



Sequence 3: Making the LDAP server Kerberos-aware

Scenario: In this sequence, you will configure your LDAP directory service to acceptuser authentication by Kerberos ticket. In addition, you will adjust a user'sentry to allow simple binds to the directory using the DN of the user entryand an appropriate Kerberos password. Finally, you will adjust the securitypermissions on the directory to allow users to adjust their default shell,whether authenticated through simple bind or Kerberos ticket.

Instructions:

1. Ensure that the cyrus-sasl-gssapi package is installed on your LDAP server.

2. Create and extract a new ldap principal for your ns-slapd service. Log in as root on yourLDAP directory server, serverX+100.example.com. Start kadmin and create the principal:

kadmin: addprinc -randkey ldap/serverX+100.example.com

Still in kadmin, extract the principal to the file /etc/ldap.keytab:

kadmin: ktadd -k /etc/ldap.keytab ldap/serverX+100.example.com

Quit kadmin.

3. Change the permissions on /etc/ldap.keytab to 0640, user root, group ldap. TheDirectory Server's ns-slapd service runs as user ldap and must be the only non-root userable to read the file.

4. Next, ns-slapd needs to know where to find the correct keytab file. Edit /etc/sysconfig/dirsrv, uncomment line 20 and modify it to read:

KRB5_KTNAME=/etc/ldap.keytab ; export KRB5_KTNAME

Perform the same change on line 15 of /etc/sysconfig/dirsrv-admin.

5. Add a SASL identity map. In Directory Console for your server instance, select theConfiguration tab, the top item in the navigation tree, and then the SASL Mapping tab inthe information pane. In the Add SASL Mapping window, enter:

Name: gssapi-mapRegular Expression: uid=(.*),cn=SERVERX+100.EXAMPLE.COM,cn=gssapi,cn=authSearch Base DN: uid=\1,ou=People,dc=serverX+100,dc=example,dc=comSearch Filter: (objectclass=*)

Click OK on the dialog window, then Save in Directory Console.



6. Save your changes. Restart the ldap service by running, as root

[root@serverX+100]# service dirsrv restart[root@serverX+100]# service dirsrv-admin restart

7. Kerberos ticket authentication through SASL binds should be working now. Test this: useklist to verify that you have a current TGT, and then run the command

[root@serverX+100]# ldapsearch -Y GSSAPI '(uid=guest2004)'

You should get results back. If you get a “local error”, use klist to see if your TGT hasexpired or is missing, and if so run kinit guest200X to request a new one.

8. DIGEST-MD5 is the default mechanism used for SASL binds in the current version ofOpenLDAP, but Kerberos uses GSSAPI. To change this setting on a per-user basis, edit theuser's ~/.ldaprc file to add the following line:

SASL_MECH GSSAPI

Then try the ldapsearch command from the previous task again, without the -Y GSSAPIoption. The command should work and you should not be prompted for a DIGEST-MD5password.



Sequence 4: Troubleshooting Kerberos authentication

Scenario:

Instructions:

1. Check the logs. General messages go to /var/log/krb5libs.log. On the KDC,check /var/log/krb5kdc.log first, or /var/log/kadmin.log for problems withkadmin.

2. If you get the error “no principal in keytab matches desired name”, use ktutil to see whichprincipals have passwords stored in the keytab file.

3. In addition, make sure you know what principal the application is using, or that it isconfigured to use the correct principal.

For Directory Server, the primary for the principal is always ldap. The correct instance forthe principal is the computer's fully-qualified domain name.

For programs that authenticate users for interactive shell access, the primary is usuallyhost and the instance is the computer's fully-qualified domain name.

4. A service needs to have read access on the keytab file containing the password for itsprincipal; no other user should have any access to the keytab file. Services that run as rootusually use /etc/krb5.keytab. Services that run as non-privileged users generallyshould have their own separate keytab files.

5. The password stored in the keytab file must be the same as the password stored in theKDC. Every time you run the ktadd command in kadmin, the password is automaticallyrandomized.

Every password change increments the version number of the password. The ktutilcommand can determine the version number of passwords stored for a principal in thekeytab file. The kvno command can be used by a user holding a valid TGT to check theversion number of passwords stored for a principal in the KDC. If these version numbers donot match, recreate the keytab file with kadmin and ktadd.

A given principal will have multiple encrypted passwords, one for each encryptionalgorithm supported by the KDC. These are all managed together automatically, but willshow up separately in the utilities.

6. If you get a “local error” message, your TGT may have expired, or you may not have aTGT at all. You can diagnose this with klist. This can be fixed by running kinit to re-authenticate.

7. If GSSAPI/Kerberos authentication is not working with the LDAP server in Sequence 3,run ldapsearch -x -Z -b '' -s base to query the root DSE to see what SASL mechanisms aresupported by the server. If GSSAPI is not on the list, ensure the cyrus-sasl-gssapi packageis installed on the LDAP server.




1. Make sure that you have the krb5-server and krb5-workstation packagesinstalled on your KDC. Open the necessary firewall ports.

[root@serverX+100]# iptables -A CLASS-RULES -p udp --dport 88 -j ACCEPT[root@serverX+100]# iptables -A CLASS-RULES -p tcp --dport 88 -j ACCEPT[root@serverX+100]# iptables -A CLASS-RULES -p udp --dport 464 -j ACCEPT[root@serverX+100]# iptables -A CLASS-RULES -p tcp --dport 749 -j ACCEPT[root@serverX+100]# service iptables save

2. On the KDC, open /etc/krb5.conf in a text editor. Make the following changes: In[libdefaults]:

default_realm = SERVERX+100.EXAMPLE.COM

[realms] should read in its entirety:

[realms] SERVERX+100.EXAMPLE.COM = { kdc = 192.168.0.X+100:88 admin_server = 192.168.0.X+100:749 }

[domain_realm] should read:

[domain_realm] serverX+100.example.com = SERVERX+100.EXAMPLE.COM serverX+200.example.com = SERVERX+100.EXAMPLE.COM stationX.example.com = SERVERX+100.EXAMPLE.COM

This [domain_realm] section tells the machine that all these stations are membersof the SERVERX+100.EXAMPLE.COM Kerberos realm. (If all realm members werethe only hosts in a DNS subdomain, we could have simply mapped the subdomain to theKerberos realm.)

In [appdefaults], add the following line inside the curly braces for the PAM block:

validate = true

This causes PAM to verify that it is talking to the true KDC by asking it for a ticket to thesystem's host principal. Save your work.

3. Initialize the Kerberos database on the KDC with a stash file so it can start up automatically.You will be prompted for a password to secure the master Kerberos database; you may pick



anything. In practice, you want to save this password because you will need it if you everchoose to set up a backup KDC.

[root@serverX+100]# kdb5_util create -r SERVERX+100.EXAMPLE.COM -s

You will be prompted for the master database password.

6. On the KDC, use kadmin.local to add an administrative root/admin principal and aguest200X principal to the Kerberos database.

[root@serverX+100]# kadmin.localAuthenticating as principal root/admin@SERVERX+100.EXAMPLE.COM with password.kadmin.local: addprinc root/admin WARNING: no policy specified for root/admin@SERVERX+100.EXAMPLE.COM; defaulting to no policyEnter password for principal "root/admin@SERVERX+100.EXAMPLE.COM": Re-enter password for principal "root/admin@SERVERX+100.EXAMPLE.COM":Principal "root/admin@SERVERX+100.EXAMPLE.COM" created.kadmin.local: addprinc guest200X[...]

Remember the passwords you set for these principals.

7. Still in kadmin.local, list the principals in the database. Note that some were automaticallycreated when you created the database. Also, examine the details of a single principal.

kadmin.local: listprincsK/M@SERVERX+100.EXAMPLE.COMkadmin/admin@SERVERX+100.EXAMPLE.COMkadmin/changepw@SERVERX+100.EXAMPLE.COMkadmin/history@SERVERX+100.EXAMPLE.COMkrbtgt/SERVERX+100.EXAMPLE.COM@SERVERX+100.EXAMPLE.COMroot/admin@SERVERX+100.EXAMPLE.COMguest200X@SERVERX+100.EXAMPLE.COMkadmin.local: getprinc guest200XPrincipal: guest200X@SERVERX+100.EXAMPLE.COMExpiration date: [never]Last password change: Fri Jan 21 23:47:27 EST 2005[...]

8. A number of files we just created may have incorrect SELinux types if you are using anoutdated SELinux targeted policy. Confirm that you have a reasonably current targeted



policy. Every RHEL 5.1 machine should have version 2.4.6-136 or later of the selinux-policy-targeted package installed.

[root@serverX+100]# yum -y update selinux-policy-targeted[root@serverX+100]# restorecon -R -v /var/kerberos/krb5kdc/[root@serverX+100]# restorecon -R -v /var/log/

9. Start the KDC daemons:

[root@serverX+100]# service krb5kdc start; chkconfig krb5kdc on[root@serverX+100]# service kadmin start; chkconfig kadmin on




1. As root on your new KDC, serverX+100.example.com, run kadmin.local again. Create ahost principal for your KDC:

kadmin.local: addprinc -randkey host/serverX+100.example.com

2. While still in kadmin.local on the KDC, extract the new principal into a local keytab filereadable only by root:

kadmin.local: ktadd -k /etc/krb5.keytab host/serverX+100.example.com

Ensure /etc/krb5.keytab has the SELinux type krb5_keytab_t:

[root@serverX+100]# restorecon /etc/krb5.keytab

3. Log in as root to stationX.example.com, the computer which is not being used as theKDC. Make sure that the krb5-workstation package is installed. Copy /etc/krb5.conf from the KDC on serverX+100.example.com to stationX.example.com:

[root@stationX]# scp root@serverX+100.example.com:/etc/krb5.conf /etc/krb5.conf

Ensure /etc/krb5.conf on stationX.example.com has the correct SELinux type:

[root@stationX]# chcon -t krb5_conf_t /etc/krb5.conf

Repeat this process, copying /etc/krb5.conf from serverX+100 to serverX+200.

4. Still logged in as root on stationX.example.com, run kadmin, authenticating as theroot/admin principal.

[root@stationX]# kadmin -p root/admin

You will be prompted for the Kerberos password that you set for this principal when youcreated it in the previous sequence.

5. In kadmin on stationX, create a host principal for stationX.example.com and extract it tothat host's /etc/krb5.keytab file.

kadmin: addprinc -randkey host/stationX.example.comkadmin: ktadd -k /etc/krb5.keytab host/stationX.example.com


[root@stationX]# restorecon /etc/krb5.keytab



6. On serverX+100, serverX+200 and stationX, run system-config-authentication. On theAuthentication tab, select the Enable Kerberos Support check box, and keep the currentKerberos configuration. Leave the User Information settings enabled.

7. Run getent passwd to verify that account information is still visible for guest200X.

8. On stationX.example.com, switch to a text login prompt. Try logging in as the guest200Xprincipal you created in the previous sequence. This should work. As that user, run klist.You should see that you have a Kerberos TGT.

9. As guest200X, ssh to serverX+100.example.com. You should be able to login withoutbeing prompted for a password! The sshd service has Kerberos ticket authentication turnedon by default.

Now try to ssh back to stationX again. You should be prompted for a password. Why? Runklist. You should not have any tickets, since you did not enter a password or run kinit whenyou logged in, and ssh did not forward your credentials.

10. Log out of serverX+100. It is possible to configure ssh to forward your credentials. Asroot, edit /etc/ssh/ssh_config, on both hosts, and add the following line to thebottom of the Host * section:

GSSAPIDelegateCredentials yes

11. Still logged in as guest200X on stationX, run klist to verify you still have a TGT. Try tossh to serverX+100 again. Run klist. You should have a TGT this time. Try to ssh backto stationX from serverX+100. This time it should work without prompting you for yourKerberos password.

If you find you are still prompted for a password, try running kdestroy on stationX andserverX+100 as the user you have been attempting to connect with and try again.

If the problem persists, try running kinit -f on stationX as guest200X and try again. If thatsucceeds, you should double-check that kdc.conf contains forwardable = yes.

12. The reason GSSAPIDelegateCredentials is off by default is so you do notaccidentally forward a TGT to an insecure system. You can explicitly ask not to forwardcredentials by specifying the -k option. Try using ssh to log into serverX+100 one moretime, but this time add -k. Run klist to verify that your credentials were not forwarded.

13. DEBUG hints:

If you are experiencing problems, check that time on the machines is synchronized. For aquick test do the following: On stationX:

[root@stationX]#chkconfig krb5-telnet on

On serverX+100:



[root@serverX+100]# telnet -Fxl guest200X stationX.example.com


RH423-RHEL5-en-2-20081020, Unit 983

Unit 9

Directory Referrals and Replication

9-1



RH423-RHEL5-en-2-20081020, Lab 984

Lab 9LDAP Directory Replication

Goal: Create a slave LDAP server which will receive updates from and refer updatesto your master LDAP server.

System Setup: A working LDAP server from preceding labs and a workstation installed withRed Hat Enterprise Linux. A working TLS certificate authority from precedinglabs.



Sequence 1: Installing a slave LDAP server

Scenario: In this sequence, you will set up a slave LDAP server, serverX+200.example.com, starting with the silent installation file from your masterLDAP server (serverX+100.example.com) as a template. The slave needs tobe configured to use a TLS certificate, and it needs to be provided with its ownKerberos principal and keytab file.

Instructions:

1. Log into serverX+200.example.com as root. Verify that the openldap, openldap-devel, andopenldap-servers packages are installed.

2. Install the redhat-ds and java-1.5.0-ibm packages from server1.

[root@serverX+200 ~]# yum install -y java-1.5.0-ibm redhat-ds-*

3. Download the /root/setup*.inf on serverX+100.example.com (You copied it therefrom /tmp back when we first installed the directory on serverX+100) to /tmp on serverX+200.example.com.

4. On serverX+200, edit the setup file downloaded in the previous step (should look likesetupRANDOM_LETTERS.inf, changing the following lines:

FullMachineName= serverX+200.example.comServerIdentifier= serverX+200

5. Perform a silent installation on serverX+200.example.com:

[root@serverX+200 ~]# setup-ds-admin.pl --silent --file=/tmp/setup*.inf

6. At this point Directory Server and Administration Server should start up. Run chkconfig tomake sure they restart after the next reboot.

[root@serverX+200 ~]# echo "KRB5_KTNAME=FILE:/etc/ldap.keytab" >> /etc/sysconfig/dirsrv[root@serverX+200 ~]# chkconfig dirsrv on && chkconfig dirsrv-admin on

7. On serverX+200.example.com, open a separate console and run redhat-idm-console -ahttp://serverX+200.example.com:8008.



8. Open Directory Console for serverX+200.example.com: in the navigation tree ofManagement Console, look in the server group under serverX+200.example.com anddouble-click on the Directory Server instance.

In the window that opens, select the Directory tab and right-click on the config item in thenavigation tree. On the pop-up menu, select New, then User, and in the window that opensset User ID to Replication Manager, and the mandatory attributes to whatever you want.Set a password on the account and remember what it is. Click OK.

9. Now select the Configuration tab. In the navigation tree expand the Replication item andhighlight the userRoot database. On the Replica Settings tab in the information pane,check Enable Replica and Dedicated Consumer. In the Enter a New Supplier DN textbox, enter the DN uid=Replication Manager,cn=config and click Add. ClickSave.



Sequence 2: Creating and installing a CA-signed server certificate

Scenario: In this sequence, you will create and install a CA-signed server certificate toenable TLS on your slave server, using the certificate authority you created inLab 3. You will need to remember the password you used for your CA privatekey in that lab.

Instructions:

1. On serverX+200.example.com, run redhat-idm-console -a http://serverX+200:8008 andauthenticate as cn=Directory Manager. In the navigation tree, find your DirectoryServer instance and double-click on it to open Directory Console.

2. On the Tasks tab of Directory Console, click the Manage Certificates button.

3. Since this is the first time you have managed TLS certificates on serverX+200.example.com, you will be prompted to set a security device password. Use redhat(or some better password you can remember). This password is used to protect your server'sprivate key files from compromise by encrypting them.

4. The Manage Certificates window will open. On the Server Certs tab, click the Request...button.

5. In the Certificate Request Wizard that opens, request a certificate manually. For Servername, enter serverX+200.example.com (your server's FQDN). Make sure thatOrganization, City/locality, State/province, and Country/regionmatch what you used in your CA certificate. Click Next.

6. You will be prompted for the security device password you just set. Enter it in the text boxand click Next.

7. Your certificate request is ready. Click Save to file... and save it to /tmp/serverX+200.csr.

8. Send the certificate request to your CA for signing. Upload /tmp/serverX+200.csrby anonymous FTP to the FTP directory /upload on server1.example.com.

9. Indicate to the instructor that your certificate request is ready for signing. When theinstructor has verified that you are the administrator of serverX+200.example.com, thecertificate will be signed.

10. Download the certificate from the CA. It is located at the URL:

[root@serverX+200 ~]# ftp://server1.example.com/pub/certs/serverX+200.crt

11. Log in again on serverX+200.example.com. Install the signed TLS server certificate intoDirectory Server. In the Manage Certificates window of Directory Console, on the ServerCerts tab, click the Install... button.



12. In the Certificate Install Wizard, select in this local file: and enter /tmp/serverX+200.crt in the text box. Click Next. Review the certificate information, and click Next,and the certificate name, and click Next.

13. You will be prompted for your security device password one more time. Enter it and clickDone. Your server certificate should appear under the Server Certs tab now.

14. Install your CA certificate. Select the CA Certs tab, click the Install... button, andinstall the CA certificate /etc/openldap/cacerts/my-ca.crt. Go through theinstallation wizard accepting the default settings otherwise. Your certificate should appearunder the CA Certs tab afterwards.



Sequence 3: Enabling TLS in Directory Server

Scenario: Now that the TLS certificates are installed on serverX+200.example.com, it istime to turn on TLS/SSL for its Directory Server.

Instructions:

1. In the Directory Console window, select the Configuration tab.

2. Highlight the top item in the navigation tree and select the Encryption tab. Check EnableSSL for this server and Use this cipher family: RSA. Verify that Check hostname againstname in certificate for outbound SSL connections is checked. Click Save.

3. Restart the Directory Server by running as root:

[root@serverX+200 ~]# service dirsrv restart[root@serverX+200 ~]# service dirsrv-admin restart

When prompted for the security device password, enter it. The server should restart.

4. To avoid being prompted for the password on the next restart, create a file called /etc/dirsrv/slapd-serverX+200/pin.txt, containing the text:

Internal (Software) Token:password



Sequence 4: Preparing the slave server's Kerberos keytab

Scenario: In this sequence, you will prepare a ldap/serverX+200.example.com principaland keytab file for Kerberos authentication with your slave server.

Instructions:

1. Log in as root on your slave LDAP server (serverX+200.example.com) and start thekadmin tool. Executing the following commands while in kadmin:

[root@serverX+200 ~]# kadmin -p root/adminkadmin> addprinc -randkey ldap/serverX+200.example.comkadmin> ktadd -k /etc/ldap.keytab ldap/serverX+200.example.com

Exit kadmin.

2. Set correct permissions on the ldap.keytab file:

[root@serverX+200 ~]# chmod 600 /etc/ldap.keytab[root@serverX+200 ~]# chown ldap:ldap /etc/ldap.keytab

3. Restart the server:

[root@serverX+200 ~]# service dirsrv restart[root@serverX+200 ~]# service dirsrv-admin restart



Sequence 5: Configuration of the master LDAP server

Scenario:

Instructions:

1. Log in on serverX+100.example.com. Run redhat-idm-console -a http://serverX+100:8008. Start Directory Console for your serverX+100 directory server instance.

2. Turn on the changelog. Select the Configuration tab, highlight the Replication item in thenavigation tree, and on the Supplier Settings tab, check Enable Changelog. Then clickUse default for the Changelog database directory and click Save at the bottom of thewindow.

3. Enable the replica. Select the Configuration tab, expand the Replication item in thenavigation tree, and select the userRoot database. On the Replica Settings tab in theinformation pane, check Enable Replica and Single Master. Find the Replica ID text boxand enter a 1 there. Click Save at the bottom of the window.

4. Set up a replication agreement with the slave. Again, in the navigation tree on theConfiguration tab expand the Replication item and this time right-click on the userRootdatabase icon. In the pop-up menu, select New Replication Agreement.... You will firstbe prompted for an arbitrary Name and short Description for the agreement. On thenext window you will need to specify the consumer the supplier will push to; accept thedefault. Check Using encrypted SSL connection. Use Simple authentication, binding asuid=Replication Manager,cn=config with the password you specified in thepreceding sequence. On the next screen, take the defaults for full replication and immediatesynchronization; and finally for simplicity initialize the slave over the network.

At this point the initial synchronization is performed and replication is set up.



Sequence 6: Testing replication

Instructions:

1. The slave should automatically synchronize its copy of the directory with the master. Verifythat the slave is working properly:

[root@serverX+100 ~]# ldapsearch -x -ZZ -H ldap://serverX+200.example.com

This should display all the entries in the directory; the results should be identical if youquery serverX+100.example.com instead.

2. Prepare to add a new group entry to the directory. Create a file, /tmp/test.ldif, withthe following contents:

dn: cn=test,ou=groups,dc=serverX+100,dc=example,dc=comobjectclass: posixGroupobjectclass: topcn: testuserPassword: {crypt}xgidNumber: 1000

3. Try to apply the update to the slave server directly:

[root@serverX+100 ~]# ldapadd -x -W -Z -H ldap://serverX+200.example.com -f /tmp/test.ldif

This should fail with a referral directing you to serverX+100.example.com.

4. Try to apply the update to the master server instead:

[root@serverX+100 ~]# ldapadd -x -W -Z -H ldap://serverX+100.example.com -f /tmp/test.ldif

This should succeed. Test this by searching for (cn=test) on both servers. Both LDAPservers should see the update.

5. Try deleting the entry. Assuming the default HOST points to your master server, run:

[root@serverX+200 ~]# ldapdelete -x -W -Z cn=test,ou=groups,dc=serverX+100,dc=example,dc=com

Try searching for (cn=test) again on both servers. The entry should have been removedfrom both LDAP servers.



6. If everything is working, update both hosts to use the slave as a backup server. In /etc/openldap/ldap.conf edit the HOST line to read:

HOST serverX+100.example.com serverX+200.example.com

In /etc/ldap.conf, edit the host line to read:

host serverX+100.example.com serverX+200.example.com

What happens if you run service dirsrv stop on your master LDAP server, serverX+100?Does LDAP authentication continue to function? Note that updates to the directory will notbe possible as long as the master LDAP server is down.



Challenge Sequence 7: Multi-Master Replication

Scenario:

Instructions:

1. Configuring multi-master replication is not much different than configuring single masterreplication, except that master servers become both suppliers and consumers of data. If youfinish very early, consider attempting to configure multi-master replication following theinstructions in the Red Hat documentation for Directory Server at www.redhat.com or onthe classroom server at the URL:

ftp://server1.example.com/pub/docs/rh423/

In particular, try consulting Chapter 8 of the Administrator's Guide (ds80admin.pdf)


RH423-RHEL5-en-2-20081020, Unit 1095

Unit 10

Cross-Platform CentralizedIdentity Management

10-1



RH423-RHEL5-en-2-20081020, Lab 1096

Lab 10Authentication Using Windows

Goal: Reconfigure the Linux client to authenticate using information stored in aMicrosoft Active Directory server.

System Setup: Availability of a Windows Server 2003 Active Directory domain controllerinstalled with the schema provided by the NIS server from Microsoft Servicesfor UNIX 3.5.



Sequence 1: Linux Authentication using Active Directory with NSSEntry Mapping

Scenario: In this sequence, you will configure one of your computers to use LDAPauthentication with information stored in an Active Directory domain,ad.example.com. This sequence requires a Windows Server 2003 ActiveDirectory domain controller, installed with Services for UNIX 3.5, containingseveral user accounts set up in advance by the instructor.

This approach will use pam_ldap.so to test user passwords through simplebinds against the Active Directory server's LDAP interface. Mapping of LinuxNSS user information to Windows user accounts is stored in Active Directoryin the Windows user entries using the NIS server schema from Services forUNIX. Since we are using Services for UNIX 3.5 with Windows Server 2003and not the NIS server in Windows Server 2003 R2, that schema does notuse the normal posixAccount object class, and we will need to map itsattributes to those of posixAccount using NSS Entry Mapping on theLinux client.

The Linux system is not an actual domain member server of the ActiveDirectory domain in this scenario.

Instructions:

1. Backup your existing /etc/ldap.conf file by copying it to /etc/ldap.conf.premap.

2. LDAP authentication for user logins from dc=serverX+100,dc=example,dc=comshould currently be working on stationX.example.com. You will need to change thatstation so that it uses the Active Directory server, w2k3.ad.example.com, for central usermanagement instead. Edit the file /etc/ldap.conf on stationX.example.com as follows:

host w2k3.ad.example.combase dc=ad,dc=example,dc=com

3. In order to get information from the LDAP interface on w2k3.ad.example.com, you willneed to bind as a valid domain user. In /etc/ldap.conf, use the entry cn=Linux-NSS,cn=Users,dc=ad,dc=example,dc=com as your binddn, with p3ngu!n asyour bindpw. Comment out the rootbinddn.

4. Add the following object class mappings to the bottom of /etc/ldap.conf:

nss_map_objectclass posixAccount Usernss_map_objectclass shadowAccount Usernss_map_objectclass posixGroup Group



5. Map the following attributes in /etc/ldap.conf:

nss_map_attribute uid sAMAccountName nss_map_attribute uidNumber msSFU30uidNumbernss_map_attribute gidNumber msSFU30gidNumbernss_map_attribute gecos cnnss_map_attribute homeDirectory msSFU30homeDirectorynss_map_attribute loginShell msSFU30loginShell

6. Tune PAM searches better with the following settings in /etc/ldap.conf. Correct thepassword changing mechanism.

pam_login_attribute sAMAccountNamepam_filter objectclass=Usernss_base_passwd cn=Users,dc=ad,dc=example,dc=compam_password ad

7. Finally, the classroom Active Directory server may not have TLS enabled. If this is the case,make the following change in /etc/ldap.conf:

ssl no

8. Save /etc/ldap.conf and exit the editor.

9. Try running getent passwd now. You should see some Windows-managed users from theActive Directory server in addition to those in stationX's local files, including the Windowsuser gates.

10. Next, we need to modify PAM to not use Kerberos authentication for now. Edit /etc/pam.d/system-auth and use pam_ldap.so in place of pam_krb5.so

11. On stationX.example.com, create a directory /home/gates, with permissions 0700,owned by user gates, group users.

12. Attempt to log into stationX.example.com as user gates through a text login window. HisWindows password is m!cr0s0ft. (If you want to try ssh, restart sshd.)



Sequence 2: Linux Authentication using Microsoft ActiveDirectory with Samba Winbind

Scenario: In this sequence, you will configure serverX+200 to use LDAP authenticationwith information stored in an Active Directory domain, ad.example.com. Thissequence requires availability of an Active Directory domain controller set upin advance by the instructor with several user accounts.

This approach will use pam_winbind.so to test user passwords throughSMB communication with the domain controller. Mapping of Linux NSS userinformation to Windows accounts are stored in the Winbind database by theLinux clients; Active Directory only stores Windows user account information.

The system is an actual domain member server of the Active Directory domainin this scenario.

Instructions:

1. Verify that the time on your server is synchronised with the Active Directory Server byrunning the following command:

[root@serverX+200 ~]$ net time -S w2k3.ad.example.com

If the time is not correct, you can use system-config-date to make w2k3.ad.example.comone of your NTP time servers.

2. Due to a limitation in the classroom configuration of the Windows user which we will useto join serverX+200 to the Active Directory domain, we need to make the Samba net joincommand think that serverX+200 is in the same DNS subdomain as the Active Directoryserver, ad.example.com. Normally, this step should not be necessary.

Make the following change to the /etc/hosts file on serverX+200.example.com:

192.168.0.X serverX+200.ad.example.com serverX+200.example.com serverX+200

3. In addition, on serverX+200.example.com, in the /etc/krb5.conf file, edit the[domain_realm] section to read:

[domain_realm] .example.com = AD.EXAMPLE.COM example.com = AD.EXAMPLE.COM

4. Run system-config-authentication on your workstation (serverX+200.example.com) andconfigure it to use Winbind as a user information source and an authentication mechanism.

Uncheck the Enable Kerberos Support checkbox on the Authentication tab. (We willstill be using Kerberos with Winbind, but we do not want settings from earlier Kerberosconfigurations using this tool interfering with the settings this tool will make for Winbind.)



Check the Enable Winbind Support checkbox on both the User Information tab and onthe Authentication tab. Uncheck the Kerberos checkbox on the Authentication tab.

On either tab, click the Configure Winbind... button. Complete the fields in the WinbindSettings window, using the following settings:

• Winbind Domain: AD

• Security Model: ads

• Winbind ADS Realm: AD.EXAMPLE.COM

• Windows Domain Controllers: w2k3.ad.example.com

• Template Shell: /bin/bash

• Leave the Allow offline login checkbox unchecked.

Click on the Join Domain button and enter the following settings to create the machineaccount for your workstation in Active Directory:

• Domain Administrator: Linux-NSS

• Password: p3ngu!n

And click OK. Then click OK in the Authentication Configuration window to exitsystem-config-authentication.

5. On serverX+200.example.com, run the command wbinfo -u. You should see a list of userswith names of the form "AD\username". User AD\gates should be one of these users.Also run the command wbinfo -g to see a list of Windows groups.

6. This form of naming users can be inconvenient. Remove the domain prefix from the userand group names by editing /etc/samba/smb.conf on serverX+200.example.com.In that file, in the [global] section, look for the directive winbind use defaultdomain and edit it to read:

winbind use default domain = true

You may also find it useful to make the following two edits to the configuration file, tomake user information appear in the output of getent:

winbind enum users = yeswinbind enum groups = yes

Save the file and exit. Restart winbind with service winbind restart so your change takeseffect. Rerun wbinfo -u to verify that the usernames no longer start with the domain AD\prefix.



7. Create the /home/AD/gates directory, with permissions 0700, containing the files fromthe directory /etc/skel, and chown it and everything in it to be owned by user "gates"and group "domain users":

[root@serverX+200]# mkdir -p /home/AD/gates[root@serverX+200]# cp -af /etc/skel/.[^.]* /home/AD/gates[root@serverX+200]# chmod 0700 /home/AD/gates[root@serverX+200]# chown -R "gates:domain users" /home/AD/gates

8. Attempt to log in to serverX+200 as the Windows user gates. His Windows password ism!cr0s0ft.

9. Optional Challenge. The downside of the configuration is that the SID->UID/GIDmappings are stored in a local file and may differ on each Winbind client. What would ittake to implement storage of these identity mappings in shared LDAP directory entriesusing Red Hat Directory Server, so that all clients use the same mappings? Review thediscussion in the unit. You may need to manually set up some LDAP entries in yourdirectory for use by Winbind.


RH423-RHEL5-en-2-20081020, Unit 11102

Unit 11

Red Hat Enterprise IPA

11-1



RH423-RHEL5-en-2-20081020, Lab 11103

Lab 11IPA

Goal: Install and configure IPA on serverX+100.

Estimated Duration: 90 minutes

Situation: You need to install IPA on a server and connect a client for users and groups.



Sequence 1: Installing an IPA Server

Scenario: You need to install IPA and configure it for your environment.

Deliverable: A fully-configured IPA server.

Instructions:

1. Install the IPA server packages on serverX+100.

Note that on the 64-bit OS, there is an open bug (441579) that requires a manual update ofkrb5-libs first.

2. Run the ipa-server-install command with the -N option to configure the IPA server. Whenasked to remove the current Red Hat Directory Server instance, choose to do so. UseserverX+100.example.com as the host name, example.com as the domain name,and SERVERX+100.EXAMPLE.COM as the realm. Passwords are required to be at leasteight characters, so use password when asked to set the Directory Manager and adminpasswords. Find the sample zone file in /tmp/ to see examples for a zone file.

3. Add rules to your stationX+100's firewall, granting stationX and stationX+200 access to allof the IPA ports.

4. Restart the sshd service.

5. The IPA installation setup an admin account. Use kinit to get a ticket as this user and viewthe ticket information.

6. Use ssh with X Forwarding (-X) to connect to serverX+100 from stationX. Verify that youstill have a ticket. Install and configure Firefox to connect to the IPA server.

7. Enter http://serverX+100.example.com in the location bar. Accept the self-signedcertificated permanently when asked. Browse the options in the IPA server.

8. Click IPA Certificate Authority, check all of the Trust options and click OK.

9. Reload the page.

10. Click Configure Firefox and click Allow when prompted to run the configuration script.Click OK.

11. Reload the page again. You should now be presented with the Red Hat Enterprise IPA webadministratoin interface.



Sequence 2: Configuring an IPA Server

Scenario: You need to add user and group accounts to the currently running IPA server.

Deliverable: Users and groups on the IPA server.

Instructions:

1. Now that you have successfully logged into the web interface for the IPA server, add twonew users: ipauser1 and ipauser2.

2. Add two new groups: ipagroup1 and ipagroup2.

3. Include ipagroup1 in the admins group.

4. Add ipauser1 to the ipagroup1 group.

5. Close Firefox and get a ticket as the for the ipauser1 user. Run firefox again and tryadding ipauser2 to the ipagroup2 group. Were you able to do administrative tasks?

6. Close down Firefox and get a new ticket as the ipauser2 user. Open the browser andpoint to the IPA server. Can you do administrative tasks?

7. Get a ticket as the ipauser1 user again and add ipagroup2 to the ipagroup1 group.Get a ticket as the ipauser2 user and add a third user: ipauser3. Add ipauser3 tothe editors group. Were you able to do it?

8. Disable the ipagroup1 group. Can ipauser2 do administrator tasks? Why? Can theadmin do admin tasks?

9. Enable the ipagroup1 group again.



Sequence 3: Configure Multi-Master IPA Servers

Scenario: To add redundancy, you want to configure multi-master IPA servers. AddserverX+200 as a master IPA server.

Deliverable: Redundant IPA servers.

Instructions:

1. Since you will be working on both systems, open ssh -X sessions to serverX+100 andserverX+200.

2. On serverX+200, install ipa-server.

3. On serverX+100, prepare the replica server files by running the ipa-replica-preparecommand.

4. Copy the file generated (found in /var/lib/ipa/) to serverX+200.example.com, whichwill be your replica server.

5. On serverX+200, run the replica installation script (ipa-replica-install) using the file youjust copied. Use the -N option to skip NTP as we are using virtual machines.

6. Update the DNA plugin configuration for the replica server. Allow serverX+200 to use IDsranging from 1,000,000,001 to 2,000,000,000.

7. At this point, the DNS entries need to be updated for the replica server. Yourinstructor has already done this step for you. Verify by using dig to view the_ldap._tcp.example.com SRV entry.

Explore the ipa-replica-manage command to manage the replica information.

8. On serverX+200, request a kerberos ticket for ipauser1 and use firefox to access thesystem's IPA web administrative interface. You will need to configure your browser asbefore.

[root@serverX+200 ~]# kinit ipauser1... output omitted ...[root@serverX+200 ~]# firefox http://serverX+200.example.com

9. Note that you do not have administrative access to the replica. Changes may only be madeon the master IPA server (serverX+100), but any changes you make should be immediatelyvisible on the replica.



Sequence 4: Configuring an IPA Client

Scenario: Now that the IPA server is working, you want to connect a client for user andgroup accounts.

Deliverable: stationX configured to use the IPA accounts.

Instructions:

1. On stationX, install the ipa-client and ipa-admintools packages.

2. Run the ipa-client-install command. If the DNS entries are setup properly, it shouldautomatically discover information about the IPA server. Continue to configure the systemwith the default values.

Note that the DNS entries come from server1 in a view that we setup for each of themachines in class.

3. Run getent passwd to verify that you see the IPA accounts. Use kinit to get a ticket asadmin.

4. Attempt to ssh into stationX as the ipauser1 user. You should be able to login using yourIPA credentials.



Sequence 5: Using TLS to Encrypt Data

Scenario: You want to use TLS to encrypt all data passing from the server to the client.

Deliverable: A client that uses TLS for encryption.

Instructions:

1. Edit /etc/ldap.conf to include a CA certificate directory (/etc/openldap/cacerts/) and allow TLS certificate requests.

2. Download the certificate from the IPA server to the client, place it in the correct locationand rehash the file.



Sequence 1 Solutions1. Install the IPA server packages on serverX+100.

Note that on the 64-bit OS, there is an open bug (441579) that requires a manual update ofkrb5-libs first.

a. If you are running the 64-bit version of Red Hat Enterprise Linux, run the following:

[root@serverX+100 ~]# yum update -y krb5-libs...output omitted...

b. For both 64-bit and 32-bit, run the following:

[root@serverX+100 ~]# yum install -y ipa-server...output omitted...

2. Run the ipa-server-install command with the -N option to configure the IPA server. Whenasked to remove the current Red Hat Directory Server instance, choose to do so. UseserverX+100.example.com as the host name, example.com as the domain name,and SERVERX+100.EXAMPLE.COM as the realm. Passwords are required to be at leasteight characters, so use password when asked to set the Directory Manager and adminpasswords. Find the sample zone file in /tmp/ to see examples for a zone file.

a. [root@serverX+100 ~]# ipa-server-install -N

b. [root@serverX+100 ~]# cat /tmp/sample.zone.c*.db

3. Add rules to your stationX+100's firewall, granting stationX and stationX+200 access to allof the IPA ports.

Run the following iptables commands on serverX+100:

[root@serverX+100 ~]# iptables -I CLASS-RULES -m multiport -p tcp -s 192.168.0.X+200 --dport 80,443,8080,389,636,88,464 -j ACCEPT[root@serverX+100 ~]# iptables -I CLASS-RULES -m multiport -p udp -s 192.168.0.X --dport 88,464,123 -j ACCEPT[root@serverX+100 ~]# iptables -I CLASS-RULES -m multiport -p udp -s 192.168.0.X+200 --dport 88,464,123 -j ACCEPT[root@serverX+100 ~]# iptables -I CLASS-RULES -m multiport -p tcp -s 192.168.0.X --dport 80,443,8080,389,636,88,464 -j ACCEPT[root@serverX+100 ~]# service iptables saveSaving firewall rules to /etc/sysconfig/iptables: [ OK ]

4. Restart the sshd service.

a. [root@serverX+100 ~]# service sshd restart



5. The IPA installation setup an admin account. Use kinit to get a ticket as this user and viewthe ticket information.

a. [root@serverX+100 ~]# kinit adminPassword for [email protected]: password

b. [root@serverX+100 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: admin@SERVERX+100.EXAMPLE.COM

Valid starting Expires Service principal07/03/08 15:11:28 07/04/08 15:11:24 krbtgt/SERVERX+100.EXAMPLE.COM@SERVERX+100.EXAMPLE.COM

Kerberos 4 ticket cache: /tmp/tkt0klist: You have no tickets cached

6. Use ssh with X Forwarding (-X) to connect to serverX+100 from stationX. Verify that youstill have a ticket. Install and configure Firefox to connect to the IPA server.

a. [root@stationX ~]# ssh -X serverX+100

b. [root@serverX+100 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: admin@SERVERX+100.EXAMPLE.COM

Valid starting Expires Service principal07/03/08 14:40:29 07/04/08 14:40:26 krbtgt/SERVERX+100.EXAMPLE.COM@SERVERX+100.EXAMPLE.COM


c. [root@serverX+100 ~]# firefox &

7. Enter http://serverX+100.example.com in the location bar. Accept the self-signedcertificated permanently when asked. Browse the options in the IPA server.

8. Click IPA Certificate Authority, check all of the Trust options and click OK.

9. Reload the page.

10. Click Configure Firefox and click Allow when prompted to run the configuration script.Click OK.

11. Reload the page again. You should now be presented with the Red Hat Enterprise IPA webadministratoin interface.




1. Now that you have successfully logged into the web interface for the IPA server, add twonew users: ipauser1 and ipauser2.

a. Click on the Add User task. Enter IPA as the first name, and User1 as the last name.For the login name, use ipauser1, and for the password, use password. Click onthe Add User button (not the Add User task).

b. Click on the Add User task. Enter IPA as the first name, and User2 as the last name.For the login name, use ipauser2, and for the password, use password. Click onthe Add User button (not the Add User task).

2. Add two new groups: ipagroup1 and ipagroup2.

a. Click on the Add Group task. Enter ipagroup1 as the name. Click on the AddGroup button (not the Add Group task).

b. Click on the Add Group task. Enter ipagroup2 as the name. Click on the AddGroup button (not the Add Group task).

3. Include ipagroup1 in the admins group.

a. Click on the Find Groups task. Enter admins and click the Find Groups button.Click the admins group that you found, then click the Edit Group button. In theAdd Members box, enter ipagroup1, then click add next to the ipagroup1group. To accept your changes, click the Update Group button.

4. Add ipauser1 to the ipagroup1 group.

a. In the Find Groups task, enter ipagroup1 as the search term. Click on theipagroup1 group and then Edit Group. In the Add Members search field, find theipauser1 user and add this user to the group. Do not forget to click Update Group.

5. Close Firefox and get a ticket as the for the ipauser1 user. Run firefox again and tryadding ipauser2 to the ipagroup2 group. Were you able to do administrative tasks?

a. [root@serverX+100 ~]# kinit ipauser1Password for [email protected]: passwordPassword expired. You must change it now.Enter new password: ipauser1Enter it again: ipauser1

b. [root@serverX+100 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: [email protected]

Valid starting Expires Service principal07/03/08 15:57:56 07/04/08 15:57:54 krbtgt/[email protected]




c. [root@serverX+100 ~]# firefox server101.example.com

d. Click on the Find Groups task, enter ipagroup2, edit the group and find theipauser2 user. Add ipauser2 as a member of the group and click Update Group.

e. This shows that you were allowed to do administrative tasks.

6. Close down Firefox and get a new ticket as the ipauser2 user. Open the browser andpoint to the IPA server. Can you do administrative tasks?

a. [root@serverX+100 ~]# kinit ipauser2Password for [email protected]: passwordPassword expired. You must change it now.Enter new password: ipauser2Enter it again: ipauser2

b. [root@serverX+100 ~]# klistTicket cache: FILE:/tmp/krb5cc_0Default principal: [email protected]

Valid starting Expires Service principal07/03/08 15:57:56 07/04/08 15:57:54 krbtgt/[email protected]


c. [root@serverX+100 ~]# firefox serverX+100.example.com

d. Notice that there are a limited number of tasks, and you cannot do administrative tasks.

7. Get a ticket as the ipauser1 user again and add ipagroup2 to the ipagroup1 group.Get a ticket as the ipauser2 user and add a third user: ipauser3. Add ipauser3 tothe editors group. Were you able to do it?

a. [root@serverX+100 ~]# kinit ipauser1

b. [root@serverX+100 ~]# firefox serverX+100.example.com

c. Click Find Groups, find ipagroup1, click Edit Group. Under Add Members,enter ipa and click add next to the ipagroup2 group. Click Update Group andclose your browser.

d. [root@serverX+100 ~]# kinit ipauser2

e. [root@serverX+100 ~]# firefox serverX+100.example.com



f. Click Add User, enter IPA User3 for the first and last name and change the Loginto ipauser3. Near the bottom of the page, under Add Groups, enter editors andclick add next to the editors group. Click Add User.

g. You should have been able to add the new group as ipauser2 because ipagroup2members are now members of the admins group (through ipagroup1).

8. Disable the ipagroup1 group. Can ipauser2 do administrator tasks? Why? Can theadmin do admin tasks?

a. Click on the Find Groups and find and edit the ipagroup1 group. Under GroupStatus, choose inactive and update the group. Notice that the update page gets apermission denied error, and the task list has changed.

b. ipauser2 account is disabled because ipagroup2 is a sub-group of ipagroup1which has been disabled. When a group is disabled, all sub-groups and accounts aredisabled as well.

c. The admin account can still login. The admin group and the admin user cannot bedisabled.

9. Enable the ipagroup1 group again.

a. Note that you must close your browser and use kadmin to get a new ticket as theadmin account to regain access to the administrative functions of the web interface.

When you are back in the web interface, click on the Find Groups and find and editthe ipagroup1 group. Under Group Status, choose active and update the group.




1. Since you will be working on both systems, open ssh -X sessions to serverX+100 andserverX+200.

2. On serverX+200, install ipa-server.

[root@serverX+200 ~]# yum -y install ipa-server...output omitted...

3. On serverX+100, prepare the replica server files by running the ipa-replica-preparecommand.

[root@serverX+100 ~]# ipa-replica-prepare serverX+200.example.com

4. Copy the file generated (found in /var/lib/ipa/) to serverX+200.example.com, whichwill be your replica server.

[root@serverX+100 ~]# scp /var/lib/ipa/replica-info-serverX+200.example.com serverX+200.example.com:/var/lib/ipa/

5. On serverX+200, run the replica installation script (ipa-replica-install) using the file youjust copied. Use the -N option to skip NTP as we are using virtual machines.

[root@serverX+200 ~]# ipa-replica-install -N /var/lib/ipa/replica-info-serverX+200.example.comDirectory Manager (existin master) password: password...output omitted...

6. Update the DNA plugin configuration for the replica server. Allow serverX+200 to use IDsranging from 1,000,000,001 to 2,000,000,000.

Begin by adding the following to a dna.ldif file. Your instructor should have createdthis file for you already at ftp://server1/pub/gls/rh423/dna.ldif. Copy orcreate this file in the /root/ directory.

dn: cn=Accounts,cn=Posix,cn=ipa-dna,cn=plugins,cn=configchangetype: modifyreplace: dnaNextValuednaNextValue: 1000000001

dn: cn=Accounts,cn=Posix,cn=ipa-dna,cn=plugins,cn=configchangetype: modifyreplace: dnaMaxValuednaMaxValue: 2000000000

dn: cn=Groups,cn=Posix,cn=ipa-dna,cn=plugins,cn=configchangetype: modifyreplace: dnaNextValue



dnaNextValue: 1000000001

dn: cn=Groups,cn=Posix,cn=ipa-dna,cn=plugins,cn=configchangetype: modifyreplace: dnaMaxValuednaMaxValue: 2000000000

Next, use ldapmodify to apply the changes.

[root@serverX+200 ~]# ldapmodify -x -D "cn=Directory Manager" -W -f /root/dna.ldifEnter LDAP Password: password... output omitted ...

7. At this point, the DNS entries need to be updated for the replica server. Yourinstructor has already done this step for you. Verify by using dig to view the_ldap._tcp.example.com SRV entry.

[root@serverX+200 ~]# dig srv _ldap._tcp.example.com...output omitted...;; ANSWER SECTION:_ldap._tcp.example.com. 86400 IN SRV 0 0 389 serverX+100.example.com._ldap._tcp.example.com. 86400 IN SRV 0 0 389 serverX+200.example.com...output omitted...

8. On serverX+200, request a kerberos ticket for ipauser1 and use firefox to access thesystem's IPA web administrative interface. You will need to configure your browser asbefore.

[root@serverX+200 ~]# kinit ipauser1... output omitted ...[root@serverX+200 ~]# firefox http://serverX+200.example.com

9. Note that you do not have administrative access to the replica. Changes may only be madeon the master IPA server (serverX+100), but any changes you make should be immediatelyvisible on the replica.




1. On stationX, install the ipa-client and ipa-admintools packages.

[root@stationX ~]# yum install -y ipa-client ipa-admintools

2. Run the ipa-client-install command. If the DNS entries are setup properly, it shouldautomatically discover information about the IPA server. Continue to configure the systemwith the default values.

Note that the DNS entries come from server1 in a view that we setup for each of themachines in class.

[root@stationX ~]# ipa-client-install -NDiscovery was successful!Realm: SERVERX+100.EXAMPLE.COMDNS Domain: example.comIPA Server: serverX+100.example.comBaseDN: dc=serverX+100,dc=example,dc=com

Continue to configure the system with these values? [y/N]: y

3. Run getent passwd to verify that you see the IPA accounts. Use kinit to get a ticket asadmin.

[root@stationX ~]# getent passwd...output truncated...ipauser1:*:1100:1002:ipauser1:/home/ipauser1:/bin/sh...output truncated...[root@stationX ~]# kinit adminPassword for [email protected]: password

4. Attempt to ssh into stationX as the ipauser1 user. You should be able to login using yourIPA credentials.

[root@serverX+100 ~]# ssh ipauser@stationXipauser1@station21's password: ipauser1Could not chdir to home directory /home/ipauser1: No such file or directory-sh-3.1$ exit




1. Edit /etc/ldap.conf to include a CA certificate directory (/etc/openldap/cacerts/) and allow TLS certificate requests.

Add the following lines to the /etc/ldap.conf file.

tls_cacertdir /etc/openldap/cacertstls_reqcert allow

2. Download the certificate from the IPA server to the client, place it in the correct locationand rehash the file.

[root@stationX ~]# cd /etc/openldap/cacerts/[root@stationX ~]# wget --no-check-certificate http://serverX+100/ipa/errors/ca.crt[root@stationX ~]# cacertdir_rehash /etc/openldap/cacerts/


RH423-RHEL5-en-2-20081020, Appendix A118

Appendix A

Authenticating Windows Clients

A-1


Date post:	08-Feb-2016
Category:	Documents
Upload:	sanjiv-kumar-singh
View:	97 times
Download:	2 times

RH423 RedHat Enterprise Directory Services and Authentication-Lab Guide(1)

Documents