RH423labs-only

RH423 Red Hat Enterprise Directory Services and Authentication RH423-RHEL5-en-2-20081020

Table of Contents RH423 - Red Hat Enterprise Directory Services and Authentication 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

Copyright © 2008 Red Hat, Inc. All rights reserved

RH423-RHEL5-en-2-20081020, Table of Contents i


RH423-RHEL5-en-2-20081020, Table of Contents ii

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 be photocopied, duplicated, stored in a retrieval system, or otherwise reproduced without prior written consent of Red Hat, Inc. If you believe Red Hat training materials are being improperly used, copied, or distributed please email or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700.


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

Lab 1 Directory Schema and LDIF Goal:

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


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

Sequence 1: Reading Schema Scenario:

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, and schema 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 be of object class locality without being of object class top?)


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

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 is included? 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 cn attributes?

9.

The uid attribute is a mandatory attribute of posixAccount. Is it also a mandatory attribute 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=US objectclass: country objectclass: top c: US

2.

Is this entry valid? Why or why not?

dn: uid=john,dc=example,dc=com objectclass: labeledURIObject objectclass: account objectclass: top uid: john

3.


dn: uid=philip,dc=example,dc=com objectclass: posixAccount objectclass: top uid: philip uidNumber: 500 gidNumber: 500 homeDirectory: /home/philip



4.


dn: userid=marta,dc=example,dc=com objectclass: account objectclass: top o: MPVK Enterprises, Inc. l: Hassadar userid: martya

5.


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

6.


dn: userid=avi,o=Epiphyte Inc.,l=Mountain View,st=California,c=US objectclass: top objectclass: account userid: avi



Sequence 1 Solutions 1.

Object class country has two mandatory attributes; c, and objectclass, which it inherits 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 have exactly one structural object class. If either locality or country were a superior class of the other (and therefore inherited attributes from the other), then both could be in the entry.

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 must be as well. Another way to put this is to say that an entry of object class locality is also always of object class top.

6.

No. Since posixAccount is an auxiliary class, it may not be the only object class in an entry, even including top. (Adding top does not help because it is an abstract object class, a special kind of class that is only used as a parent for defining structural and auxiliary classes.) Since country is a structural class, posixAccount may be used with it in a valid entry. (In practice, this would be a strange combination of classes, since normally posixAccount represents objects that are people, not entire nations.)

7.

No. posixAccount does not require loginShell, since loginShell is an optional attribute.

8.

An entry may have multiple cn or uid attributes, but only one gecos attribute, because gecos 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.


RH423-RHEL5-en-2-20081020, Lab 1 Sequence 1 Solutions 8


Yes. Optional attributes need not appear.

2.

Yes. The labeledURIObject class has no mandatory attributes! The object class account 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 a misspelling.

5.

No. The entry has no structural class.

6.

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



Unit 2

The LDAP Naming Model



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

Lab 2 Preparing Directory Data Goal:

To prepare contact information for upload to a LDAP directory.

System Setup:

Workstation installed with Red Hat Enterprise Linux.


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

Sequence 1: Selecting a schema and naming plan Instructions: 1.

The first thing which must be determined is the suffix to use for the directory partition. The usual choice is between a X.500-based naming plan or a modern “Internet” naming plan. In practice, 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. You will use serverX+100 as your first LDAP server for these labs. Use the fully-qualified host 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 t he 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 containers for other sorts of objects. You need to create LDIF to specify the initial naming structure and container entries. Create a new file, /tmp/addressbook.ldif. Since dc=serverX +100,dc=example,dc=com is the suffix of this directory partition, there should be no entries for dc=example,dc=com or other suffixes present. Your entries could be structured in a number of ways, but the following will work:

dn: dc=server X+100,dc=example,dc=com objectclass: organizationalUnit organizationalUnit objectclass: dcObject objectclass: top ou: station X .example.com .example.com dc: server X+100 dn: ou=People,dc=server ou=People,dc=server X+100,dc=example,dc=com objectclass: organizationalUnit organizationalUnit objectclass: top ou: People

3.

You know that you currently want to store names, e-mail addresses, postal addresses, and phone numbers for your contacts. Later on, you may also store other information about your users as well. There are many different object classes that might be applied to people. Some of the more interesting ones are listed on the next page. Look over them for a moment. Each of them has advantages and disadvantages. disadvantages.



organization is great for representing a company, not so good for a single person, since it does not include cn or sn attributes for the person's full name or last name. person is

very limited by itself; only name and phone number, with name attributes mandatory. The remaining three classes inherit from person. The problem with pilotPerson is that its mix of attributes is somewhat strange, since it was originally defined for one of the X.500 pilot projects. Between the last two, inetOrgPerson has two advantages; it includes all 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 Hat Directory 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. Bush 1600 Pennsylvania Avenue NW Washington, DC 20500



202-456-1111 (work) [email protected] (e-mail) gwbush (local login name) Look over inetOrgPerson, its parent organizationalPerson , and its parent person , for applicable attributes to use. For practice, you might tr y to work out a plan yourself first, before we walk through one. You may use the following references on your system to help: /usr/share/doc/openldap-devel-2*/rfc/

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

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

5.

Here is one possible plan: George W. Bush 1600 Pennsylvania Avenue NW Washington DC 20500 202-456-1111 (work) [email protected] (e-mail) gwbush (local login name)

cn street l st postalCode telephoneNumber mail uid

We also must store sn=Bush , since person requires a sn attribute. For good measure, add givenName=George . An alternative to spelling out all the components of his postal address would be to use the special postalAddress attribute. It expects six lines, separated by dollar signs, of no more than 30 characters each: 1600 Pennsylvania Avenue NW$Washington, DC$20500$USA. The disadvantage of the postalAddress attribute is that it is unclear to client applications what the meaning of each line should be. The advantage of the postalAddress attribute is that, since postalAddress can take multiple values, it is clear how to represent multiple postal addresses for an entry without confusing things like which 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 address book entries. You may choose any attribute, as long as it will be unique to an entry. The most obvious choice is cn, the person's full name. The problem with cn is that full names collide. George W. Bush and George H. W. Bush would be hard to distinguish without the initials. 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 a company directory, employeeNumber might be attractive. We will use uid, the uniquely assigned login names for our users, which is a common choice. So the full DN for George W. Bush's entry is: dn: uid=gwbush,ou=People,dc=server X+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=server X+100,dc=example,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: gwbush cn: George W. Bush sn: Bush givenName: George street: 1600 Pennsylvania Avenue NW l: Washington st: DC postalCode: 20500 telephoneNumber: +1 202 456 1111 mail: [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 l isted. The telephone number has been placed in a standard international format. If you want to add other attr ibutes from inetOrgPerson, 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.ldif in a text editor and create the LDIF equivalents for these users. Some of them may be able to take advantage of or need to use additional attributes from those available. Save your work for use in a later lab. Homer Simpson 742 Evergreen Terrace Springfield, NT 60066 248-555-6754 (home) donuts (local user) Fred G. Sanford Sanford and Son Salvage 9114 South Central Los Angeles, CA 90002 650-555-1079 (work) fsanford (local user) Dr. Dana Scully Federal Bureau of Investigations 3170 W. 53rd Street Annapolis, MD 21402 202-555-7117 (fax) 202-555-6431 (mobile) [email protected] (e-mail) dscully (local user) Jed Clampett Rural Route 1 Bugtussle, TN 65616 jclampett (local user) Mary Richards 119 N. Weatherly Ave. Minneapolis, MN 55403 [email protected] (e-mail) mrichards (local user) 612-555-7862 (home) Buffy Summers 1630 Revello Drive Sunnydale, CA 94086 408-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 titl e: “Chief of Thoracic Surgery”. It is generally assumed that attributes like postalAddress and telephoneNumber are for addresses and phone numbers at work unless otherwise specified, which is why some of the object classes have special attributes for personal addresses and telephone numbers at home. Some attributes have short names that make them easy to miss. The o attribute (also known as organizationName) is normally the name of an organization; a company, a club, a governmental department, and the like. The ou attribute (also known as organizationalUnitName) is a subcomponent, division, or department of an organization. The st attribute (also stateOrProvinceName) represents a major political 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 minor political or geographical subdivision. Not all of these attributes may be available in the particular object classes you will use for encoding your users.




dn: uid=donuts,ou=People,dc=server X+100,dc=example,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: donuts cn: Homer Simpson sn: Simpson givenname: Homer street: 742 Evergreen Terrace l: Springfield st: NT postalCode: 60066 homePhone: +1 248 555 6754 dn: uid=fsanford,ou=People,dc=server X+100,dc=example,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: fsanford cn: Fred G. Sanford sn: Sanford givenname: Fred street: 9114 South Central l: Los Angeles st: CA postalCode: 90002 o: Sanford and Son Salvage telephoneNumber: +1 650 555 1079 dn: uid=dscully,ou=People,dc=server X+100,dc=example,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: dscully cn: Dr. Dana Scully sn: Scully givenname: Dana street: 3170 West 53rd Street l: Annapolis st: MD postalCode: 21402 facsimileTelephoneNumber: +1 202 555 7117 mobile: +1 202 555 6431



mail: [email protected] o: Federal Bureau of Investigations dn: uid=jclampett,ou=People,dc=server X+100,dc=example,dc=co m objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: jclampett cn: Jed Clampett sn: Clampett givenname: Jed street: Rural Route 1 l: Bugtussle st: TN postalCode: 65616 dn: uid=mrichards,ou=People,dc=server X+100,dc=example,dc=co m objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: mrichards cn: Mary Richards sn: Richards givenname: Mary street: 119 N. Weatherly Avenue l: Minneapolis st: MN postalCode: 55403 homePhone: +1 612 555 7862 mail: [email protected] dn: uid=slayer,ou=People,dc=server X+100,dc=example,dc=com objectclass: inetOrgPerson objectclass: organizationalPerson objectclass: person objectclass: top uid: slayer cn: Buffy Summers sn: Summers givenname: Buffy street: 1630 Revello Drive l: Sunnydale st: CA



postalCode: 94086 pager: +1 408 555 4291



Unit 3

Red Hat Directory Server: Basic Configuration



RH423-RHEL5-en-2-20081020, Unit 3 22

Lab 3 Installing Red Hat Directory Server Goal:

To prepare a basic Red Hat Directory Server service containing address book information.

System Setup:

One workstation installed with Red Hat Enterprise Linux called station X . There should be two virtual machines installed and running on station X called serverX+100 and serverX+200. All of these machines are in the example.com DNS domain. Configure all three of your hosts to refer to yum repositories on server1.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.


RH423-RHEL5-en-2-20081020, Lab 3 23

Sequence 1: Controlling the default host-based firewall Scenario:

By default, the installer sets up some basic connection-based packet filtering rules on inbound network traffic. The intention of this is to block access to network services which a system administrator may turn on inadvertently. In this sequence, we will ensure that the firewall is enabled. Over the course of subsequent labs, we will open access to your local services only as needed. As a quick review, remember that you can delete rules with iptables -D CHAIN rule-number if you make a mistake. The iptables -L --linenumbers command can help you determine the correct line number of your broken rule. Do not forget to use service iptables save to save your work, or you 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 see three standard chains and a custom chain, RH-Firewall-1-INPUT, on the filter table. Rules are set in the INPUT and FORWARD chains directing all traffic to the custom chain. 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 related to communications initiated by your host. It should also accept inbound traffic to port 22/tcp , for sshd. Any other traffic will be rejected by the firewall with an ICMP Host Prohibited 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 it is processed by RH-Firewall-1-INPUT. We want the CLASS-RULES chain to match first on the INPUT chain. If there are no matches 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 an LDAP directory server, using Red Hat Directory Server. If your student workstation is stationX .example.com, you will install the Red Hat Directory Server on server X+100.example.com with an LDAP suffix of dc=serverX +100,dc=example,dc=com. For example, if your workstation is station3.example.com then server103.example.com will be your LDAP server with dc=server103,dc=example,dc=com as your suffix. Copy the LDIF files you created in an earlier lab to the virtual machine serving as the LDAP server, serverX+100.example.com. This server instance will also be your configuration directory, so you will have o=NetscapeRoot as a suffix 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 (server X +100.example.com). Use rpm -q to verify the openldap-clients and openldap-servers RPM packages are installed. If not, use yum to install them from the repository provided by server1.example.com. The openldap-clients package provides command-line management tools we will use to work with the directory. The openldap-servers RPM provides a user and group, ldap, we will use for Directory Server, although we will not be running the OpenLDAP directory server at this time.

2.

First install the prerequisite RPM which provides the compatible JRE used by the Red Hat Directory 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 -k option 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 system configuration, some warnings may be reported regarding the amount of physical memory available, the number of file descriptors, or the settings of the TCP keepalive timer. You may ignore these warnings and go on.



5.

Select the Typical setup type (default). You should be presented with the fully qualified hostname of server X+100.example.com. Accept Accept the default as the hostname to use for the directory server.

6.

Enter ldap for the System User and the System Group instead of the default which nobody. is nobody.

7.

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

8.

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

9.

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

10.

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

11.

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

12.

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

13.

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

14.

Look in /tmp for the setup*.inf file. This is the silent installation i nstallation file created by the setup-ds-admin -k command. Examine the file and look for directives you defined according 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]# +100]# chkconfig dirsrv on [root@serverX +100]# +100]# chkconfig dirsrv-admin on



16.

Configure your firewall to allow clients to access your directory server (port 636 will be used later for ldap over ssl): [root@serverX +100]# +100]# iptables -A CLASS-RULES -p tcp --dport

389 -j ACCEPT [root@serverX +100]# +100]# iptables -A CLASS-RULES -p tcp

--dport

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

8008 -j ACCEPT [root@serverX +100]# +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 the directory server's database. Double-check the file for typos and errors then run: # redhat-idm-console redhat-idm-console -a http://server X+100.example.com:8008

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

2.

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

3.

On the Tasks tab, click the Import Databases button. A dialog window will open. Either browse 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 the dialog that pops up for any rejected entries. You should see some entries rejected, at least dc=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 names have 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 Console window, select the Directory tab. In the navigation tree, expand the stationX item, then highlight the item People (5 acis). Your address book user entries should appear in the right-hand information pane. You can double-click on any of them to see details of each entry.

5.

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

6.

Quit Console, and at the prompt run the following command to test the LDAP server: $ ldapsearch -x -b dc=server X+100,dc=example,dc=com ,dc=example,dc=com -h

serverX+100.example.com You should see your entries on standard output. If all this worked, your LDAP server is working! We will look more closely at the ldapsearch command in an upcoming unit.




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 it is processed by RH-Firewall-1-INPUT. We want the CLASS-RULES chain to match first on the INPUT chain. If there are no matches 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



Unit 4

Searching and Modifying the LDAP Directory



RH423-RHEL5-en-2-20081020, Unit 4 30

Lab 4 Using the LDAP Directory Goal:

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

System Setup:

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


RH423-RHEL5-en-2-20081020, Lab 4 31

Sequence 1: Searching the LDAP directory Scenario:

In this sequence we will gain some practice with search filters. After the first couple of examples, you will be on your own. Answers are at the end of the lab.

Instructions: 1.

Ensure the openldap and openldap-clients RPMs are installed on your student workstation and on both of your virtual machines, server X+100 and serverX+200.

2.

To test the LDAP server, the command-line client configuration file needs to be edited. On your student workstation, station X , comment out any uncommented lines in /etc/ openldap/ldap.conf and add the following replacements: HOST server X+100.example.com BASE dc=server X+100,dc=example,dc=com

3.

Copy /etc/openldap/ldap.conf from your workstation to the same location on both your virtual machines. Ensure that it is world-readable but writable only by root. On your workstation as root: [root@stationX ~]# cd /etc/openldap [root@stationX openldap]# scp ldap.conf server X+100:/etc/op

enldap/ [root@stationX openldap]# scp ldap.conf server X+200:/etc/op

enldap/

4.

On stationX , run the ldapsearch -x command. By default, it will perform a subtree search using the filter (objectClass=*) so all entries readable by the anonymous user in dc=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 her contact 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 filter should 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 carefully about 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 Blues 1060 West Addison Chicago, IL 60613 eblues (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 LDAP service. You will need to bind as a DN which has write access to the database to do this. The rootdn (cn=Directory Manager) has this access. Create a personal ~/.ldaprc file 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 the command: [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 Clampett 518 Crestview Drive Beverly Hills, CA 90210

Create the following LDIF modification file in /tmp/hillbilly.ldif: dn: uid=jclampett,ou=People,dc=server X+100,dc=example,dc=co m changetype: modify replace: street street: 518 Crestview Drive replace: l l: Beverly Hills replace: st st: CA replace: postalCode postalCode: 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 ldapdelete to 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 suffix of 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 for loading into your server: [student@stationX ~]$ scp root@server X+100:/usr/share/dirsr

v/data/Example.ldif . [student@stationX ~]$ sed -e 's/dc=example,dc=com/dc=server X+100,dc=example,dc=com/g'

-e 's/dc: example/dc: server X+100 /' Example.ldif > /tmp/server X+100.ldif

8.

Load the new users with ldapadd: [student@stationX ~]$ ldapadd -c -x -W -f /tmp/server X+100.

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



Sequence 3: Graphical address book clients Instructions: 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 thunderbird command. The Thunderbird Import Wizard and Account Wizard may start up to prompt you to set up your e-mail account. Any settings you make will not be important for this lab, as we are mainly 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 the Composition icon.

4.

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

5.

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

Name: Hostname: Base DN: Port number:

Server X+100 Test LDAP server X+100.example.com ou=People,dc=server X+100,dc=example,dc=com 389

Use secure connection (SSL): no

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

6.

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

7.

Close Thunderbird, and open the Evolution e-mail client by clicking on the e-mail icon in GNOME or by running evolution. Again, the Evolution Setup Assistant may run to help you configure the e-mail client. The settings you make here do not affect the address book, which is our primary interest in this lab. You may need to set an outbound SMTP server to complete the assistant; you may use localhost for this.



8.

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

9.

In the LDAP Configuration Assistant, change the Type from On This Computer to 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 , use Anonymously. 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 and select Contact List. Expand On LDAP Servers and highlight your LDAP server. Search for a user in the interface that appears. You may double-click on any of the items that appears to get a detailed view of the contents.



Challenge Sequence 4: Converting Between LDAP Schemas Scenario:

One problem with our current entries is that they use Mozilla-style attributes for postal address information; the street address, city, state, and zip code are all stored in individual attributes instead of a single postalAddress attribute. That means that addresses for these entries do not show up properly in Evolution or the Directory Server Gateway or Console tools. It would be nice if we had some mechanism to take address information in existing entries in the directory stored in Mozilla-style attribute values and synchronize them to 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 LDIF Update file containing postalAddress attributes for entries already stored in the 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 dollar sign, 30 characters maximum per line.)

2.

The truly ambitious can consider how to handle addresses for international entries that have the c attribute set. Remember that the value of c should be a two-letter ISO 3166 country 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, may be 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


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


(st=CA)

7.

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

8.

This one is tricky because there is more than one attribute which includes a telephone number; work telephones, mobiles, and so on. Depending on your definition of “telephone”, you could try (|(homePhone=*)(mobile=*)(telephoneNumber=*))



Unit 5

Red Hat Directory Server: Authentication and Security



RH423-RHEL5-en-2-20081020, Unit 5 41

Lab 5 Red Hat Directory Server and TLS/SSL Goal:

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

System Setup:

One virtual server installed with Red Hat Directory Server and a working configuration from an earlier lab.

Lab Setup:

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


RH423-RHEL5-en-2-20081020, Lab 5 42

Sequence 1: Creating and installing a CA-signed server certificate Scenario:

Anonymous binds to the LDAP directory service may provide adequate security for reading the address book. For write access, though, we need to protect the security of the management password. In this sequence, you will set up your LDAP server to use TLS in order to secure network communications with clients. You will generate a private key and matching public server certificate for your LDAP server and have the in-house Certificate Authority run by the instructor sign the public server certificate. Clients will then be able to determine the authenticity of your server certificate if they have a copy of your in-house certificate authority's public CA certificate.

Instructions: 1.

Run redhat-idm-console and authenticate as cn=Directory Manager . In the navigation tree, find your Directory Server 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, 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's private 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 Server name , 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 dropdown menu to select North Carolina. For Country/region, use the drop-down menu to select 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 box and 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 by anonymous FTP to server1.example.com and upload the /tmp/serverX+100.csr file to the anonymous FTP server's /upload directory.

9.

Indicate to the instructor that your certificate is ready for signing. The instructor will verify your identity as the owner of station X .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/myca.crt .

What happened on server1.example.com? The instructor has an OpenSSL-based certificate authority set up with its own private key and public SSL certificate as part of standard classroom preparation. The instructor ran the following command to sign your certificate with the private CA key: [root@server1 ~]# openssl ca -in /var/ftp/upload/server X+10 0.csr -out /var/ftp/pub/certs/server X+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 ca program, it was assigned a serial number in the CA's database for tracking purposes, and the signed certificate was created.

10.

Install the signed TLS server certificate into Directory Server. In the Manage Certificates window 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 for administering 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 click Done . 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 install the CA certificate /tmp/my-ca.crt. Go through the installation wizard accepting the default settings otherwise. Your certificate should appear under the CA Certs tab afterwards.



Sequence 2: Enabling TLS in Directory Server Scenario:

Now that the TLS certificates are installed, it is time to turn on TLS/SSL for the 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 Enable SSL for this server and Use this cipher family: RSA. Verify that Check hostname against name 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 server X+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 restart without 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 working on 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 on stationX .example.com needs to be edited. Comment out any uncommented lines in /etc/ openldap/ldap.conf and add the following replacements: HOST server X+100.example.com BASE dc=server X+100,dc=example,dc=com TLS_CACERT /etc/openldap/cacerts/my-ca.crt

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

2.

Make sure that the /etc/openldap/cacerts directory exists, owned by user root and group 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 is owned by user root and group root.

3.

Open a terminal window and create a shell as the user student. Search the LDAP server again, this time requiring StartTLS: [student@stationX ~ ]$ ldapsearch -x -ZZ

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



Unit 6

Linux User Authentication with NSS and PAM



RH423-RHEL5-en-2-20081020, Unit 6 47

Lab 6 PAM and NSS Goal:

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

System Setup:

Two workstations configured with Red Hat Enterprise Linux. A working NIS domain, notexample, served by server1.example.com. Initial Troubleshooting Tip: In this lab, it is possible that a typo or mistake in a sequence can break authentication for all users, including root. To make it easier for you to repair mistakes, try to keep a root shell open on at least one terminal at all times.


RH423-RHEL5-en-2-20081020, Lab 6 48

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 source of user information. Use the host computer, station X that you are not using as your 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 to include 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 domain notexample, 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 not yet using these NIS maps to provide authentication or naming information, because NIS has not been tied into NSS or PAM. To verify this, dump your user database by running the command [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: files shadow: files group: files

Edit them to read: passwd: files nis shadow: files nis group: 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 in the output. The NIS users are now valid users on the system. Test this; as root, create a file in /tmp and chown it to guest2001. The operation should work, if NIS is being properly consulted for user information. As another test, run getent passwd root. You should see just root's password file entry.

6.

As an experiment, temporarily edit /etc/nsswitch.conf again to read passwd: nis [NOTFOUND=return] files shadow: nis [NOTFOUND=return] files group: nis [NOTFOUND=return] files

Run getent passwd root again. What happens? The root account is not in NIS, so you should not see that information. Stop ypbind (with service ypbind stop) and run getent passwd root again. What happens now? 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 NIS Instructions: 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.0 auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so auth include system-auth account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session include system-auth session required pam_loginuid.so session optional pam_console.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open session optional pam_keyinit.so force revoke

On initial authentication, we make sure that the user is not root on a insecure terminal and include 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.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth required pam_deny.so account account account

required sufficient required

pam_unix.so pam_succeed_if.so uid < 500 quiet pam_permit.so

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



session optional pam_keyinit.so revoke session required pam_limits.so session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session 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 NIS users. The pam_unix.so module can use this information for authentication just as if it were stored in the /etc/passwd file!

2.

However, by default it does not know how to change NIS passwords. Look for the pam_unix.so line in the system-auth password stack and add the nis option to it. The line 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 are on station15, use guest2015. If the instructor is running yppasswdd on server1, this should work. (Note that root on the NIS client can not change a NIS user's password, but NIS users on the client can change their own passwords.) [student@stationX ~]$ su - guest20XX Password: [guest20XX@stationX ~]$ passwd Changing 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. Log in on the LDAP server and run system-config-authentication. Enter the root password if prompted, enable NIS support, and configure NIS so server1.example.com is the NIS server and notexample is the NIS domain. Compare the files you edited on the original NIS client in the sequences above with the same files on the LDAP server.



Sequence 3: PAM-based authentication and local administrative tools Scenario:

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 not have 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 line to 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 and pam_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 is considered sufficient grounds to authenticate the user and stop checking the rest of the PAM stack. Anyone can su to anyone now!

6.

For another odd experience, remove the pam_permit line, then comment out the pam_rootok.so line in /etc/pam.d/su and save the file. As root, try to su - someuser. What happens? 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 how they work. If you make any changes, be careful to put things back together when you are done!



Unit 7

Centralized User Authentication with LDAP



RH423-RHEL5-en-2-20081020, Unit 7 55

Lab 7 Network Authentication with LDAP Goal:

Move existing users from a NIS server to your LDAP directory. Configure appropriate access control lists to directory information. Set up clients which can authenticate using this data.

System Setup:

Working LDAP server and working NIS clients from previous labs.


RH423-RHEL5-en-2-20081020, Lab 7 56

Sequence 1: Preparing the LDAP directory server Scenario:

In this sequence, you will prepare your LDAP directory service for use as a replacement for the NIS server on server1.example.com. Before you start storing sensitive account information in the directory, you will need to tighten security and adjust some settings on your LDAP server.

Instructions: 1.

We will store new passwords for user entries set through the LDAP Password Change mechanism 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. In the right information pane, select the Passwords tab. At the bottom of the pane, find the Password encryption drop-down menu and change it from Salted Secure Hashing Algorithm (SSHA) to Unix crypt algorithm (CRYPT) . Click Save.

2.

Add a new administrative user, uid=client-root,dc=serverX+100,dc=example,dc=com. In Directory Console, select the Directory tab and highlight and right-click on your suffix, server X+100, in the navigation tree. In the pop-up menu, select New... then User. Set the User 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 ACI window 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=server X+100,dc=example, dc=com");)

Click OK to save your work.



4.

In the Manage Access Control window from the previous step, highlight Enable anonymous access and click the Edit button. The ACI should appear in Edit Manually mode automatically this time (displaying an Edit Visually button); if the window opens in visual editing mode, click the Edit Manually button. The ACI displayed in the window should 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")(v ersion 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 existing NIS server into your LDAP directory. You will take advantage of the /usr/ share/openldap/migration scripts to simplify this process, but you will still need to edit the LDIF output before uploading your data to the directory 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 that as 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 i s not strictly speaking necessary, create one for these users. Run the following command to construct one using the hashes 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 directory hierarchy 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 = "server X+100.example.com"; $DEFAULT_BASE = "dc=server X+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 inetOrgPerson object 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. (The default 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 you want 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 the migration script. The dn: dc=server X+100,dc=example,dc=com entry is already set up on your directory server from the address book. Also, look for the dn: ou=People,dc=server X+100,dc=example,dc=com entry. Remove that, too, since you already set it up for t he address book. Save the file and exit.

6.

Next, prepare the user accounts. The migration script makes the hard-coded assumption that your shadow password file is /etc/shadow, so you will need to edit migrate_passwd.pl before running it. Open migrate_passwd.pl in an editor, and on line 188 or so, change the following line in the 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: r un



[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 following commands. If you did not set BINDDN to your rootdn in your ~/.ldaprc in an earlier lab, remember to add the option -D 'cn=Directory Manager' to the commands below: [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 entries you are importing already exist. In this case, these may be safely ignored. (Note which entries are affected.) Use ldapsearch to verify your entries are present.



Sequence 3: Configuring clients for LDAP authentication Scenario:

In this sequence, you will configure your workstation and both virtual machines to authenticate users by using information stored in your LDAP directory, 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 Enable LDAP Support . Select the Configure LDAP... button. In the window that opens, check Use TLS to encrypt connections, and set LDAP Search Base DN: dc=serverX+100,dc=example,dc=com LDAP 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 yes tls_cacertfile /etc/openldap/cacerts/my-ca.crt

4.

Also in /etc/ldap.conf, fix the password change mechanism. Change the pam_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 password information. The root account on the clients has a special account so that password changes may work. Set nss_ldap to use this account by editing the following directive in /etc/ ldap.conf: rootbinddn m

6.

uid=client-root,dc=server X+100,dc=example,dc=co

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



7.

Run getent passwd and getent shadow. Do you see the LDAP users? (You should.) Check getent group as well. Do you see password hashes in the shadow map when getent shadow is run as root? (If you see the LDAP users, you should see the hashes.) If so, what happens if 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 as follows: password requisite pam_cracklib.so try_first_pass retry=3 password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok password sufficient pam_ldap.so use_authtok password required pam_deny.so

9.

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

10.

Try changing the password of one of the users you just migrated into the LDAP dir ectory. 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 about what would be required to make your posixGroup entries also be groupOfUniqueNames static group entries, assuming for the sake of argument that posixGroup were really an auxiliary class. Do any of the existing posixGroup entries have memberUid attribute values? Can you automate a process to convert the memberUid values into uniqueMember values? The user accounts stored in the LDAP directory still need home directories accessible by your computers. Conveniently, server1.example.com has a NFS server exporting home directories for these users. It would be nice if home directories could be automounted for each user at login. It would be nicer if the automount maps themselves could be managed centrally in the LDAP directory rather than through local files on each computer. If local files were to be used with the automounter, /etc/auto.master might 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 and auto.guests files must be converted into the right format, and autofs must be 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 a nisObject entry to hold one line from that file. Open /tmp/automount.ldif in a text editor. dn: nisMapName=auto.master, ou=Mounts,dc=serverX+100,dc=example,dc=com objectclass: top objectclass: nisMap nisMapName: auto.master dn: cn=/home/guests,nisMapName=auto.master, ou=Mounts,dc=serverX+100,dc=example,dc=com objectclass: top objectclass: nisObject nisMapEntry: ldap:server X+100.example.com:nisMapName=auto.g uests, ou=Mounts,dc=serverX+100,dc=example,dc=com --timeout=60 nisMapName: auto.master cn: /home/guests

2.

Next, you need a nisMap entry to hold the auto.guests file and a nisObject entry to 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=com objectclass: top objectclass: nisMap nisMapName: auto.guests dn: cn=/,nisMapName=auto.guests, ou=Mounts,dc=serverX+100,dc=example,dc=com objectclass: top objectclass: nisObject cn: / 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. Verify that they loaded properly.

4.

On both of your computers, open /etc/nsswitch.conf in a text editor, and change the automount 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 you have edited that file to point to your directory server: HOST server X+100.example.com BASE dc=server X+100,dc=example,dc=com TLS_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's home 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. Password hashes are provided along with user information to NSS, and pam_unix handles authentication. Even with TLS encryption this mode exposes the password 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 log in, pam_ldap converts the username provided into the DN of an entry, and attempts to simple bind to the LDAP server using the password provided. If the 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 user passwords 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 because the 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 for LDAP user authentication. You will continue to use pam_unix for local user authentication.

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 in the navigation tree. On the Object menu, select Set Access Permissions. Highlight Allow client-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 and authenticate but not read the userPassword attribute. If that user still had read access on userPassword, pam_unix authentication using the LDAP name service would continue to 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 are having trouble with graphical logins, log into a text virtual console as root and try running the command killall gdm-binary, then try again when the login screen reappears.



Unit 8

Kerberos and LDAP



RH423-RHEL5-en-2-20081020, Unit 8 68

Lab 8 Kerberos and LDAP Goal:

Set up a Kerberos Key Distribution Center. Configure Kerberos-based user authentication. Set up a service which can use Kerberos tickets for user authentication. Configure your LDAP server to support Kerberos authentication and access control with SASL/GSSAPI.

System Setup:

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


RH423-RHEL5-en-2-20081020, Lab 8 69

Sequence 1: Configuring the Kerberos KDC Scenario:

Now, we will change how the system authenticates users. Account information will be obtained from the same source as before, but authentication will be handled by Kerberos. Install the KDC on server X+100.example.com. Your Kerberos realm should be SERVERX+100.EXAMPLE.COM. The machine stationX .example.com (and in a later lab server X+200.example.com) will be clients and members of the Kerberos realm.

Instructions: 1.

Make sure that you have the krb5-server and krb5-workstation packages installed 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 = SERVER X+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 = SERVER X+100.EXAMPLE.COM serverX+200.example.com = SERVER X+100.EXAMPLE.COM stationX .example.com = SERVER X+100.EXAMPLE.COM

This [domain_realm] section tells the machine that all these stations are members of the SERVERX+100.EXAMPLE.COM Kerberos realm. (If all realm members were the only hosts in a DNS subdomain, we could have simply mapped the subdomain to the Kerberos 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 the system'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 ever choose 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 a guest200X principal to the Kerberos database.

7.

Still in kadmin.local, list the principals in the database. Note that some were automatically created 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 an outdated 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.

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 user authentication using the new Kerberos KDC.

Instructions: 1.

As root on your new KDC, server X+100.example.com, run kadmin.local again. Create a host principal for your KDC.

2.

While still in kadmin.local on the KDC, extract the new principal into a local keytab file readable 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 sure that the krb5-workstation package is installed. Copy /etc/krb5.conf from the KDC 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 the root/admin principal.

5.

In kadmin on stationX , create a host principal for station X .example.com and extract it to that host's /etc/krb5.keytab file. Ensure /etc/krb5.keytab has the correct SELinux type. Exit kadmin.

6.

On serverX+100, serverX+200 and stationX , run system-config-authentication. On the Authentication tab, select the Enable Kerberos Support check box, and keep the current Kerberos 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 guest200X principal 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 without being prompted for a password! The sshd service has Kerberos ticket authentication turned on by default. Now try to ssh back to stationX again. You should be prompted for a password. Why? Run klist. You should not have any tickets, since you did not enter a password or run kinit when you logged in, and ssh did not forward your credentials.

10.

Log out of server X+100. It is possible to configure ssh to forward your credentials. As root , edit /etc/ssh/ssh_config, on both hosts, and add the following line to the bottom of the Host * section: GSSAPIDelegateCredentials yes

11.

Still logged in as guest200X on stationX , run klist to verify you still have a TGT. Try to ssh to serverX+100 again. Run klist. You should have a TGT this time. Try to ssh back to stationX from serverX+100. This time it should work without prompting you for your Kerberos password. If you find you are still prompted for a password, try running kdestroy on stationX and server X+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 that succeeds, you should double-check that kdc.conf contains forwardable = yes .

12.

The reason GSSAPIDelegateCredentials is off by default is so you do not accidentally forward a TGT to an insecure system. You can explicitly ask not to forward credentials by specifying the -k option. Try using ssh to log into server X+100 one more time, 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 a quick test do the following: On station X : [root@stationX ]# chkconfig krb5-telnet on

On serverX+100: [root@serverX+100]# telnet -Fxl guest 200X stationX .example.

com



Sequence 3: Making the LDAP server Kerberos-aware Scenario:

In this sequence, you will configure your LDAP directory service to accept user authentication by Kerberos ticket. In addition, you will adjust a user's entry to allow simple binds to the directory using the DN of the user entry and an appropriate Kerberos password. Finally, you will adjust the security permissions 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 your LDAP directory server, server X+100.example.com. Start kadmin and create the principal: kadmin: addprinc -randkey ldap/server X+100.example.com

Still in kadmin, extract the principal to the file /etc/ldap.keytab: kadmin: ktadd -k /etc/ldap.keytab ldap/server X+100.example.

com Quit kadmin.

3.

Change the permissions on /etc/ldap.keytab to 0640, user root, group ldap. The Directory Server's ns-slapd service runs as user ldap and must be the only non-root user able 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 the Configuration tab, the top item in the navigation tree, and then the SASL Mapping tab in the information pane. In the Add SASL Mapping window, enter: Name: Regular Expression: Search Base DN: Search Filter:

gssapi-map uid=(.*),cn=SERVERX+100.EXAMPLE.COM,cn=gssapi,cn=auth uid=\1,ou=People,dc=serverX+100,dc=example,dc=com (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: use klist 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 has expired 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 of OpenLDAP, but Kerberos uses GSSAPI. To change this setting on a per-user basis, edit the user's ~/.ldaprc file to add the following line: SASL_MECH GSSAPI

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



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 with kadmin.

2.

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

3.

In addition, make sure you know what principal the application is using, or that it is configured to use the correct principal. For Directory Server, the primary for the principal is always ldap. The correct instance for the principal is the computer's fully-qualified domain name. For programs that authenticate users for interactive shell access, the primary is usually host 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 its principal; no other user should have any access to the keytab file. Services that run as root usually use /etc/krb5.keytab. Services that run as non-privileged users generally should have their own separate keytab files.

5.

The password stored in the keytab file must be the same as the password stored in the KDC. Every time you run the ktadd command in kadmin, the password is automatically randomized. Every password change increments the version number of the password. The ktutil command can determine the version number of passwords stored for a principal in the keytab file. The kvno command can be used by a user holding a valid TGT to check the version number of passwords stored for a principal in the KDC. If these version numbers do not match, recreate the keytab file with kadmin and ktadd. A given principal will have multiple encrypted passwords, one for each encryption algorithm supported by the KDC. These are all managed together automatically, but will show up separately in the utilities.

6.

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

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 are supported by the server. If GSSAPI is not on the list, ensure the cyrus-sasl-gssapi package is installed on the LDAP server.




Make sure that you have the krb5-server and krb5-workstation packages installed 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 = SERVER X+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 = SERVER X+100.EXAMPLE.COM serverX+200.example.com = SERVER X+100.EXAMPLE.COM stationX .example.com = SERVER X+100.EXAMPLE.COM

This [domain_realm] section tells the machine that all these stations are members of the SERVERX+100.EXAMPLE.COM Kerberos realm. (If all realm members were the only hosts in a DNS subdomain, we could have simply mapped the subdomain to the Kerberos 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 the system'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 ever choose to set up a backup KDC. [root@serverX+100]#

X+100.EXAMPL kdb5_util create -r SERVER

E.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 a guest200X principal to the Kerberos database. [root@serverX+100]# kadmin.local Authenticating as principal root/admin@SERVER X+100.EXAMPLE. COM with password. kadmin.local: addprinc root/admin WARNING: no policy specified for root/admin@SERVER X+100.EXA MPLE.COM; defaulting to no policy Enter password for principal "root/admin@SERVER X+100.EXAMPL E.COM": Re-enter password for principal "root/admin@SERVER X+100.EXA MPLE.COM": Principal "root/admin@SERVER X+100.EXAMPLE.COM" created. kadmin.local: addprinc guest 200X [...]

Remember the passwords you set for these principals.

7.

Still in kadmin.local, list the principals in the database. Note that some were automatically created when you created the database. Also, examine the details of a single principal. kadmin.local: listprincs K/M@SERVERX+100.EXAMPLE.COM kadmin/admin@SERVERX+100.EXAMPLE.COM kadmin/changepw@SERVERX+100.EXAMPLE.COM kadmin/history@SERVERX+100.EXAMPLE.COM krbtgt/SERVERX+100.EXAMPLE.COM@SERVERX+100.EXAMPLE.COM root/admin@SERVERX+100.EXAMPLE.COM guest200X @SERVERX+100.EXAMPLE.COM kadmin.local: getprinc guest 200X Principal: guest 200X @SERVERX+100.EXAMPLE.COM Expiration 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 an outdated 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




As root on your new KDC, server X+100.example.com, run kadmin.local again. Create a host principal for your KDC: kadmin.local: addprinc -randkey host/server X+100.example.co

m

2.

While still in kadmin.local on the KDC, extract the new principal into a local keytab file readable only by root: kadmin.local: ktadd -k /etc/krb5.keytab host/server X+100.ex

ample.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 the KDC. Make sure that the krb5-workstation package is installed. Copy /etc/ krb5.conf from the KDC on server X+100.example.com to stationX .example.com: [root@stationX ]# scp root@server X+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 the root/admin principal. [root@stationX ]# kadmin -p root/admin

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

5.

In kadmin on stationX , create a host principal for station X .example.com and extract it to that host's /etc/krb5.keytab file. kadmin: addprinc -randkey host/station X .example.com kadmin: ktadd -k /etc/krb5.keytab host/station X .example.com

Ensure /etc/krb5.keytab has the correct SELinux type. [root@stationX ]# restorecon /etc/krb5.keytab



6.

On serverX+100, serverX+200 and stationX , run system-config-authentication. On the Authentication tab, select the Enable Kerberos Support check box, and keep the current Kerberos 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 guest200X principal 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 without being prompted for a password! The sshd service has Kerberos ticket authentication turned on by default. Now try to ssh back to stationX again. You should be prompted for a password. Why? Run klist. You should not have any tickets, since you did not enter a password or run kinit when you logged in, and ssh did not forward your credentials.

10.

Log out of server X+100. It is possible to configure ssh to forward your credentials. As root , edit /etc/ssh/ssh_config, on both hosts, and add the following line to the bottom of the Host * section: GSSAPIDelegateCredentials yes

11.

Still logged in as guest200X on stationX , run klist to verify you still have a TGT. Try to ssh to serverX+100 again. Run klist. You should have a TGT this time. Try to ssh back to stationX from serverX+100. This time it should work without prompting you for your Kerberos password. If you find you are still prompted for a password, try running kdestroy on stationX and server X+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 that succeeds, you should double-check that kdc.conf contains forwardable = yes .

12.

The reason GSSAPIDelegateCredentials is off by default is so you do not accidentally forward a TGT to an insecure system. You can explicitly ask not to forward credentials by specifying the -k option. Try using ssh to log into server X+100 one more time, 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 a quick test do the following: On station X : [root@stationX ]#

chkconfig krb5-telnet on On serverX+100:



[root@serverX+100]# telnet -Fxl guest 200X stationX .example.

com



Unit 9

Directory Referrals and Replication



RH423-RHEL5-en-2-20081020, Unit 9 83

Lab 9 LDAP Directory Replication Goal:

Create a slave LDAP server which will receive updates from and refer updates to your master LDAP server.

System Setup:

A working LDAP server from preceding labs and a workstation installed with Red Hat Enterprise Linux. A working TLS certificate authority from preceding labs.


RH423-RHEL5-en-2-20081020, Lab 9 84

Sequence 1: Installing a slave LDAP server Scenario:

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

Instructions: 1.

Log into serverX+200.example.com as root. Verify that the openldap , openldap-devel , and openldap-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 there from /tmp back when we first installed the directory on server X+100) to /tmp on serverX +200.example.com.

4.

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

FullMachineName= ServerIdentifier=

5.

server X+200.example.com server X+200

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 to make 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 -a http://serverX+200.example.com:8008.



8.

Open Directory Console for server X+200.example.com: in the navigation tree of Management Console, look in the server group under server X+200.example.com and double-click on the Directory Server instance. In the window that opens, select the Directory tab and right-click on the config item in the navigation tree. On the pop-up menu, select New, then User, and in the window that opens set 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 and highlight 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 text box, enter the DN uid=Replication Manager,cn=config and click Add. Click Save.



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

In this sequence, you will create and install a CA-signed server certificate to enable TLS on your slave server, using the certificate authority you created in Lab 3. You will need to remember the password you used for your CA private key in that lab.

Instructions: 1.

On serverX+200.example.com, run redhat-idm-console -a http://serverX+200:8008 and authenticate as cn=Directory Manager . In the navigation tree, find your Directory Server 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 server X +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's private 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 Server name , enter serverX+200.example.com (your server's FQDN). Make sure that Organization, City/locality, State/province , and Country/region match 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 box and 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.csr by 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 the instructor has verified that you are the administrator of server X+200.example.com, the certificate 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/s

erverX+200.crt

11.

Log in again on server X+200.example.com. Install the signed TLS server certificate into Directory Server. In the Manage Certificates window of Directory Console, on the Server Certs 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 click Done . 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, and install the CA certificate /etc/openldap/cacerts/my-ca.crt. Go through the installation wizard accepting the default settings otherwise. Your certificate should appear under the CA Certs tab afterwards.



Sequence 3: Enabling TLS in Directory Server Scenario:

Now that the TLS certificates are installed on server X+200.example.com, it is time 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 Enable SSL for this server and Use this cipher family: RSA. Verify that Check hostname against name 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/server X+200.example.com principal and keytab file for Kerberos authentication with your slave server.

Instructions: 1.

Log in as root on your slave LDAP server (server X+200.example.com) and start the kadmin tool. Executing the following commands while in kadmin: [root@serverX+200 ~]# kadmin -p root/admin kadmin> addprinc -randkey ldap/server X+200.example.com kadmin> ktadd -k /etc/ldap.keytab ldap/server X+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 server X+100 directory server instance.

2.

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

3.

Enable the replica. Select the Configuration tab, expand the Replication item in the navigation tree, and select the userRoot database. On the Replica Settings tab in the information pane, check Enable Replica and Single Master . Find the Replica ID text box and 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 the Configuration tab expand the Replication item and this time right-click on the userRoot database icon. In the pop-up menu, select New Replication Agreement.... You will first be prompted for an arbitrary Name and short Description for the agreement. On the next window you will need to specify the consumer the supplier will push to; accept the default. Check Using encrypted SSL connection . Use Simple authentication, binding as uid=Replication Manager,cn=config with the password you specified in the preceding sequence. On the next screen, take the defaults for full replication and immediate synchronization; 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. Verify that the slave is working properly: [root@serverX+100 ~]# ldapsearch -x -ZZ -H ldap://server X+2 00.example.com

This should display all the entries in the directory; the r esults should be identical if you query serverX+100.example.com instead.

2.

Prepare to add a new group entry to the directory. Create a file, /tmp/test.ldif, with the following contents: dn: cn=test,ou=groups,dc=server X+100,dc=example,dc=com objectclass: posixGroup objectclass: top cn: test userPassword: {crypt}x gidNumber: 1000

3.

Try to apply the update to the slave server directly: [root@serverX+100 ~]# ldapadd -x -W -Z -H ldap://server X+20 0.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://server X+10 0.example.com

-f /tmp/test.ldif

This should succeed. Test this by searching for (cn=test) on both servers. Both LDAP servers 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 removed from 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 server X+100.example.com server X+200.example.com

In /etc/ldap.conf, edit the host line to read: host server X+100.example.com server X+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 not be 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 master replication, except that master servers become both suppliers and consumers of data. If you finish very early, consider attempting to configure multi-master replication following the instructions in the Red Hat documentation for Directory Server at www.redhat.com or on the 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)



Unit 10

Cross-Platform Centralized Identity Management



RH423-RHEL5-en-2-20081020, Unit 10 95

Lab 10 Authentication Using Windows Goal:

Reconfigure the Linux client to authenticate using information stored in a Microsoft Active Directory server.

System Setup:

Availability of a Windows Server 2003 Active Directory domain controller installed with the schema provided by the NIS server from Microsoft Services for UNIX 3.5.


RH423-RHEL5-en-2-20081020, Lab 10 96

Sequence 1: Linux Authentication using Active Directory with NSS Entry Mapping Scenario:

In this sequence, you will configure one of your computers to use LDAP authentication with information stored in an Active Directory domain, ad.example.com. This sequence requires a Windows Server 2003 Active Directory domain controller, installed with Services for UNIX 3.5, containing several user accounts set up in advance by the instructor. This approach will use pam_ldap.so to test user passwords through simple binds against the Active Directory server's LDAP interface. Mapping of Linux NSS user information to Windows user accounts is stored in Active Directory in the Windows user entries using the NIS server schema from Services for UNIX. Since we are using Services for UNIX 3.5 with Windows Server 2003 and not the NIS server in Windows Server 2003 R2, that schema does not use the normal posixAccount object class, and we will need to map its attributes to those of posixAccount using NSS Entry Mapping on the Linux client. The Linux system is not an actual domain member server of the Active Directory 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=com should currently be working on station X .example.com. You will need to change that station so that it uses the Active Directory server, w2k3.ad.example.com, for central user management instead. Edit the file /etc/ldap.conf on stationX .example.com as follows: host w2k3.ad.example.com base dc=ad,dc=example,dc=com

3.

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

4.

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


posixAccount shadowAccount posixGroup

User User Group


5.

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

6.

sAMAccountName msSFU30uidNumber msSFU30gidNumber cn msSFU30homeDirectory msSFU30loginShell

Tune PAM searches better with the following settings in /etc/ldap.conf. Correct the password changing mechanism. pam_login_attribute pam_filter nss_base_passwd pam_password

7.

uid uidNumber gidNumber gecos homeDirectory loginShell

sAMAccountName objectclass=User cn=Users,dc=ad,dc=example,dc=com ad

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 the Active Directory server in addition to those in station X 's local files, including the Windows user 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 station X .example.com as user gates through a text login window. His Windows password is m!cr0s0ft. (If you want to try ssh, restart sshd.)



Sequence 2: Linux Authentication using Microsoft Active Directory with Samba Winbind Scenario:

In this sequence, you will configure serverX+200 to use LDAP authentication with information stored in an Active Directory domain, ad.example.com. This sequence requires availability of an Active Directory domain controller set up in advance by the instructor with several user accounts. This approach will use pam_winbind.so to test user passwords through SMB communication with the domain controller. Mapping of Linux NSS user information to Windows accounts are stored in the Winbind database by the Linux clients; Active Directory only stores Windows user account information. The system is an actual domain member server of the Active Directory domain in this scenario.

Instructions: 1.

Verify that the time on your server is synchronised with the Active Directory Server by running 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.com one of your NTP time servers.

2.

Due to a limitation in the classroom configuration of the Windows user which we will use to join serverX+200 to the Active Directory domain, we need to make the Samba net join command think that server X+200 is in the same DNS subdomain as the Active Directory server, 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 server X+200.example. com server X+200

3.

In addition, on server X+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 (server X+200.example.com) and configure it to use Winbind as a user information source and an authentication mechanism. Uncheck the Enable Kerberos Support checkbox on the Authentication tab. (We will still be using Kerberos with Winbind, but we do not want settings from earlier Kerberos configurations 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 on the Authentication tab. Uncheck the Kerberos checkbox on the Authentication tab. On either tab, click the Configure Winbind... button. Complete the fields in the Winbind Settings 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 machine account 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 exit system-config-authentication.

5.

On serverX+200.example.com, run the command wbinfo -u. You should see a list of users with 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 user and 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 default domain 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, to make user information appear in the output of getent: winbind enum users = yes winbind enum groups = yes

Save the file and exit. Restart winbind with service winbind restart so your change takes effect. 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 from the 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 is m!cr0s0ft.

9.

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



Unit 11

Red Hat Enterprise IPA



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

Lab 11 IPA 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.


RH423-RHEL5-en-2-20081020, Lab 11 103

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 server X+100. Note that on the 64-bit OS, there is an open bug (441579) that requires a manual update of krb5-libs first.

2.

Run the ipa-server-install command with the -N option to configure the IPA server. When asked to remove the current Red Hat Directory Server instance, choose to do so. Use server X+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 least eight characters, so use password when asked to set the Directory Manager and admin passwords. Find the sample zone file in /tmp/ to see examples for a zone file.

3.

Add rules to your station X+100's firewall, granting stationX and stationX+200 access to all of 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 view the ticket information.

6.

Use ssh with X Forwarding (-X) to connect to server X+100 from stationX . Verify that you still 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-signed certificated 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 web administratoin 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 two new 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 try adding 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 and point 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 to the editors group. Were you able to do it?

8.

Disable the ipagroup1 group. Can ipauser2 do administrator tasks? Why? Can the admin 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. Add serverX+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 and serverX+200.

2.

On serverX+200, install ipa-server.

3.

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

4.

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

5.

On serverX+200, run the replica installation script ( ipa-replica-install) using the file you just 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 server X+200 to use IDs ranging 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. Your instructor 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 the system's IPA web administrative interface. You will need to configure your browser as before. [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 made on the master IPA server (server X+100), but any changes you make should be immediately visible 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 and group 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 should automatically discover information about the IPA server. Continue to configure the system with the default values. Note that the DNS entries come from server1 in a view that we setup for each of the machines in class.

3.

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

4.

Attempt to ssh into station X as the ipauser1 user. You should be able to login using your IPA 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 location and rehash the file.




Install the IPA server packages on server X+100. Note that on the 64-bit OS, there is an open bug (441579) that requires a manual update of krb5-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.

3.

Run the ipa-server-install command with the -N option to configure the IPA server. When asked to remove the current Red Hat Directory Server instance, choose to do so. Use server X+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 least eight characters, so use password when asked to set the Directory Manager and admin passwords. 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

Add rules to your station X+100's firewall, granting stationX and stationX+200 access to all of the IPA ports. Run the following iptables commands on server X+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 save Saving 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 view the ticket information. a.

[root@serverX+100 ~]# kinit admin Password for [email protected]: password

b.

[root@serverX+100 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@SERVERX+100.EXAMPLE.COM Valid starting Expires Service principal 07/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/tkt0 klist: You have no tickets cached

6.

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

[root@stationX ~]# ssh -X server X+100

b.

[root@serverX+100 ~]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin@SERVERX+100.EXAMPLE.COM Valid starting Expires Service principal 07/03/08 14:40:29 07/04/08 14:40:26 krbtgt/SERVERX+100.EXAMPLE.COM@SERVERX+100.EXAMPLE.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached

c.

[root@serverX+100 ~]# firefox &

7.

Enter http://serverX+100.example.com in the location bar. Accept the self-signed certificated 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 web administratoin interface.




2.

3.

Now that you have successfully logged into the web interface for the IPA server, add two new 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 on the 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 on the Add User button (not the Add User task).

Add two new groups: ipagroup1 and ipagroup2. a.

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

b.

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

Include ipagroup1 in the admins group. a.

4.

Add ipauser1 to the ipagroup1 group. a.

5.

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 the Add Members box, enter ipagroup1, then click add next to the ipagroup1 group. To accept your changes, click the Update Group button.

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

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

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

b.

[root@serverX+100 ~]# klist [root@serverX+100 Ticket cache: FILE:/tmp/krb5cc_0 FILE:/tmp/krb5cc_0 Default principal: [email protected] [email protected] Valid starting Expires Service principal 07/03/08 15:57:56 07/04/08 15:57:54 krbtgt/SERVER101.EXAMPLE.COM krbtgt/[email protected] @SERVER101.EXAMPLE.COM MPLE.COM



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

6.

c.

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

d.

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

e.

This This shows shows that that you you were were allo allowed wed to do do admin administ istrat rative ive tasks. tasks.

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

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

b.

[root@serverX+100 ~]# klist [root@serverX+100 Ticket cache: FILE:/tmp/krb5cc_0 FILE:/tmp/krb5cc_0 Default principal: [email protected] [email protected] Valid starting Expires Service principal 07/03/08 15:57:56 07/04/08 15:57:54 krbtgt/SERVER101.EXAMPLE.COM krbtgt/[email protected] @SERVER101.EXAMPLE.COM MPLE.COM Kerberos 4 ticket cache: /tmp/tkt0 klist: You have no tickets cached

7.

c.

[root@serverX+100 [root@serverX+1 00 ~]# firefox server X+100.example.com

d.

Notice that there there are a limited number number of tasks tasks,, and you canno cannott do admini administrati strative ve tasks. tasks.

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 to the editors group. Were you able to do it? a.

[root@serverX+100 [root@serverX+1 00 ~]# kinit ipauser1

b.


c.

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

d.

[root@serverX+100 [root@serverX+1 00 ~]# kinit ipauser2

e.




8.

f.

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

g.

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

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

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

b.

ipauser2 account is disabled because ipagroup2 is a sub-group of ipagroup1

which has been disabled. When a group is disabled, all sub-groups and accounts are disabled as well. c.

9.

The admin account can still login. The admin group and the admin user cannot be disabled.

Enable the ipagroup1 group again. a.

Note Note tha thatt you you must must clo close se you yourr brow browse serr and and use use kadmin to get a new ticket as the admin 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 edit the ipagroup1 group. Under Group Status, choose active and update the group.




Since you will be working on both systems, open ssh -X sessions to serverX+100 and serverX+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-prepare command. [root@serverX+100 ~]# ipa-replica-prepare server X+200.examp

le.com

4.

Copy the file generated (found in /var/lib/ipa/) to serverX+200.example.com, which will be your replica server. [root@serverX+100 ~]# scp /var/lib/ipa/replica-info-server X +200 .example.com

5.

server X+200.example.com:/var/lib/ipa/

On serverX+200, run the replica installation script ( ipa-replica-install) using the file you just 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.com Directory Manager (existin master) password: password ...output omitted...

6.

Update the DNA plugin configuration for the replica server. Allow server X+200 to use IDs ranging from 1,000,000,001 to 2,000,000,000. Begin by adding the following to a dna.ldif file. Your instructor should have created this file for you already at ftp://server1/pub/gls/rh423/dna.ldif. Copy or create this file in the /root/ directory. dn: cn=Accounts,cn=Posix,cn=ipa-dna,cn=plugins,cn=config changetype: modify replace: dnaNextValue dnaNextValue: 1000000001 dn: cn=Accounts,cn=Posix,cn=ipa-dna,cn=plugins,cn=config changetype: modify replace: dnaMaxValue dnaMaxValue: 2000000000 dn: cn=Groups,cn=Posix,cn=ipa-dna,cn=plugins,cn=config changetype: modify replace: dnaNextValue



dnaNextValue: 1000000001 dn: cn=Groups,cn=Posix,cn=ipa-dna,cn=plugins,cn=config changetype: modify replace: dnaMaxValue dnaMaxValue: 2000000000

Next, use ldapmodify to apply the changes. [root@serverX+200 ~]# ldapmodify -x -D "cn=Directory

Manager" -W -f /root/dna.ldif Enter LDAP Password: password ... output omitted ...

7.

At this point, the DNS entries need to be updated for the replica server. Your instructor 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 the system's IPA web administrative interface. You will need to configure your browser as before. [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 made on the master IPA server (server X+100), but any changes you make should be immediately visible on the replica.




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 should automatically discover information about the IPA server. Continue to configure the system with the default values. Note that the DNS entries come from server1 in a view that we setup for each of the machines in class. [root@stationX ~]# ipa-client-install -N Discovery was successful! Realm: SERVER X+100.EXAMPLE.COM DNS Domain: example.com IPA Server: server X+100.example.com BaseDN: dc=server X+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 as admin. [root@stationX ~]# getent passwd ...output truncated... ipauser1:*:1100:1002:ipauser1:/home/ipauser1:/bin/sh ...output truncated... [root@stationX ~]# kinit admin Password for [email protected]: password

4.

Attempt to ssh into station X as the ipauser1 user. You should be able to login using your IPA credentials. [root@serverX+100 ~]# ssh ipauser@station X ipauser1@station21's password: ipauser1 Could not chdir to home directory /home/ipauser1: No such file or d -sh-3.1$ exit




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/cacerts tls_reqcert allow

2.

Download the certificate from the IPA server to the client, place it in the correct location and 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/



RH423labs-only

Recommend Documents