Hardware Requirements for Red Hat Enterprise IPA 360 Software Requirements for Red Hat Enterprise IPA

361 Port Requirements for Red Hat Enterprise IPA 362 IPA Assumptions 363 IPA and DNS 364 Example DNS Zone File 365 Installing and Configuring IPA 366 Firefox Configuration 367 Multi-Master Replication 368 Updated DNS Zone File Example 370 Supported IPA Clients 371 Configure Red Hat Enterprise Linux 5 IPA Client 372 Configure Red Hat Enterprise 5 IPA Client 373 Configure Red Hat Enterprise 5 IPA Client 374 E- of Unit 11 375 L . 11: IPA 376 Sequence 1: Installing an IPA Server 377

RH423-Rh . 1 -en-2-20080905 viiiSequence 2: Configuring an IPA Server 378 Sequence 3: Configure Multi-Master IPA Servers 379 Sequence 4: Configuring an IPA Client 380 Sequence 5: Using TLS to Encrypt Data 381 Appendix A - Authenticating Windows Clients Objectives 392 Linux Authentication Server 393 Windows Domains 394 NetBIOS Name Registration 395 Network Browsing 396 Samba Domain Controllers 397 LDAP Configuration 398 sambaSamAccount 399 Other Samba Object Classes 400 User Database Settings 401 Samba and LDAP Replicas 402 Account Management Scripts 403 Configuring WINS 404 Global DC Settings 405 Domain Controller Shares 406 Post Configuration Details 407 User/Group Mapping 408 Password Synchronization 409 End of Appendix A 411 Copyright 2008 Red Hat, Inc.

Introduction RH423: Red Hat Enterprise Directory Services and Authentication

For use only by 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 <training@redhat.com> or phone tollfree (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Copyright The contents of this course and all its modules and related materials, including handouts to audience members, are copyright 2008 Red Hat, Inc No part of this publication may be stored in a retrieval system, transmitted or reproduced in any way, including, but not limited to, photocopy, photograph, magnetic, electronic or other record, without the prior written permission of Red Hat, Inc. This instructional program, including all material provided herein, is supplied without any guarantees from Red Hat, Inc. Red Hat, Inc. assumes no liability for damages or legal action arising from the use or misuse of contents or details contained herein. If you believe Red Hat training materials are being used, copied, or otherwise improperly distributed please email training@redhat.com or phone toll-free (USA) +1 866 626 2994 or +1 919 754 3700.
For use only by 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 <training@redhat.com> or phone tollfree (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Welcome Please let us know if you have any special needs while at our training facility.
For use only by 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 <training@redhat.com> or phone tollfree (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Phone and network availability Please only make calls during breaks. Your instructor will show you which phone to use. Network access and analog phone lines may be available: your instructor will provide information about these facilities. Please turn pagers to silent and cell phones off during class. Restrooms Your instructor will notify you of the location of these facilities. Lunch and breaks Your instructor will notify you of the areas to which you have access for lunch and for breaks In case of Emergency Please let us know if anything comes up that will prevent you from attending. Access Each facility has its own opening and closing limes. Your instructor will provide you with this information.

Participant Introductions Please introduce yourself to the rest of the class!

For use only by 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 <training@redhat.com> or phone tollfree (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Red Hat Enterprise Linux Enterprise-targeted operating system Focused on mature open source technology 18-24 month release cycle - Certified with leading OEM and ISV products Purchased with one year Red Hat Network subscription and - Support contract - Support available for seven years after release Up to 24x7 coverage plans available

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

The Red Hat Enterprise Linux product family is designed specifically for organizations planning to use Linux in production settings. All products in the Red Hat Enterprise Linux family are built on the same software foundation and maintain the highest level of ABI/API compatibility across releases and errata. Extensive support services are available: a one year support contract and Update Module entitlement to Red Hat Network are included with purchase. Various Service Level Agreements are available that may provide up to 24x7 coverage with guaranteed one hour response time. Support will be available for up to seven years after a particular release. Red Hat Enterprise Linux is released on an eighteen to twenty-four month cycle. It is based on code developed by the open source community and adds performance enhancements, intensive testing, and certification on products produced by top independent software and hardware vendors such as Dell. IBM. Fujitsu. BEA, and Oracle. Red Hat Enterprise Linux provides a high degree of standardization through its support for five processor architectures (Intel, x86-compatible. AMD64/Intel 64. Intel Itanium 2, IBM POWER, and IBM mainframe on System z).

Red Hat Enterprise Linux Variants Server: - Red Hat Enterprise Linux Advanced Platform Red Hat Enterprise Linux Client: - Red Hat Enterprise Linux Desktop - with Workstation option - with Multi-OS option with Workstation and Multi-OS options

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Currently, on the x86 and x86-64 architectures, the product family includes: Red Hat Enterprise Linux Advanced Platform: the most cost-effective server solution, this product includes support for the largest x86-compatible servers, unlimited virtualized guest operating systems, storage virtualization. high-availability application and guest fail-over clusters, and the highest levels of technical support. Red Hat Enterprise Linux: the basic server solution, supporting servers with up to two CPU sockets and up to four virtualized guest operating systems. Red Hat Enterprise Linux Desktop: a general-purpose client solution, offering desktop applications such as the OpenOffice.org office suite and Evolution mail client. Add-on options provide support for highend technical and development workstations and for running multiple operating systems simultaneously through virtualization. Two standard installation media kits are used to distribute variants of the operating system. Red Hat Enterprise Linux Advanced Platform and Red Hat Enterprise Linux are shipped on the Server media kit. Red Hat Enterprise Linux Desktop and its add-on options are shipped on the Client media kit. Media kits may be downloaded as ISO 9660 CD-ROM file system images from Red Hat Network or may be provided in a boxed set on DVD-ROMs. Please visit http://www.redhat.com/rhel/ for more information about the Red Hat Enterprise Linux product family.

Red Hat Network A comprehensive software delivery, system management, and monitoring framework - Update Module: Provides software updates Included with all Red Hat Enterprise Linux subscriptions - Management Module: Extended capabilities for large deployments - Provisioning Module: Bare-metal installation, configuration management, and multi-state configuration rollback capabilities - Monitoring Module provides infrastructure health monitoring of networks, systems, applications, etc.

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Red Hat Network is a complete systems management platform. It is a framework of modules for easy software updates, systems management, and monitoring, built on open standards. There are currently four modules in Red Hat Network: the Update Module, the Management Module, the Provisioning Module, and the Monitoring Module.

The Update Module is included with all subscriptions to Red Hat Enterprise Linux. It allows for easy software updates to all your Red Hat Enterprise Linux systems. The Management Module is an enhanced version of the Update Module, which adds additional features tailored for large organizations. These enhancements include system grouping and set management, multiple organizational administrators, and package profile comparison among others. In addition, with RHN Proxy Server or Satellite Server, local package caching and management capabilities become available. The Provisioning Module provides mechanisms to provision and manage the configuration of Red Hat Enterprise Linux systems throughout their entire life cycle. It supports bare metal and existing state provisioning, storage and editing of kickstart files in RHN. Configuration file management and deployment, multi-state rollback and snapshot-based recovery, and RPM-based application provisioning. If used with RHN Satellite Server, support is added for PXE bare-metal provisioning, an integrated network tree, and configuration management profiles.

Other Red Hat Supported Software Red Hat Application Stack JBoss Enterprise Middleware Suite Red Hat Directory Server Red Hat Certificate System Red Hat Global File System

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Red Hat offers a number of additional open source application products and operating system enhancements which may be added lo the standard Red Hat Enterprise Linux operating system. As with Red Hat Enterprise Linux, Red Hat provides a range of maintenance and support services for these addon products. Installation media and software updates are provided through the same Red Hal Network interface used to manage Red Hat Enterprise Linux systems. Red Hat Application Stack: the first fully integrated open source stack, supplying everything needed to run standards-based web applications, including Red Hat Enterprise Linux. JBoss Application Server with Tomcat, JBoss Hibernate, and a choice of open source databases: MySQL or PostgreSQL... and Apache Web Server. JBoss Enterprise Middleware Suite: enterprise-class open source software to build, deploy, integrate, orchestrate, and present web applications and services in a Service-Oriented Architecture. Red Hat Directory Server: an LDAP-based server that centralizes directory storage and data distribution, such as user and group data. Red Hat Certificate System: a security framework for deploying and maintaining a Public Key Infrastructure (PKI) for identity management, fully integrated with Red Hat Directory Server to enable enterprise deployment of secure Web-based authentication. S/MIME, VPNs, and SSL.

Red Hat Global File System: an open source cluster file system appropriate for enterprise deployments, allowing severs to share a common pool of storage. Includes Red Hat Cluster Suite or providing application fail-over between servers for critical services. Part of Red Hat Enterprise Linux version 5 Advanced Platform, an add-on product for Red Hat Enterprise Linux version 3 and Red Hat Enterprise Linux version 4. For additional information, see the following web pages: Red Hat Application Stack: http://www.redhat.com/appstack/ JBoss Enterprise Middleware Suite: http://www.redhat.com/jboss/ Red Hat Directory Server: http://www.redhat.com/directory_server/ Red Hat Certificate System: http://www.redhat.com/certificate_system/ Red Hal Global File System: http://www.redhat.com/gfs/

The Fedora Project Open source projects sponsored by Red Hat Fedora distribution is focused on latest open source technology - Rapid four to six month release cycle - Available as free download from the Internet EPEL provides add-on software for Red Hat Enterprise Linux Open, community-supported proving grounds for technologies which may be used in upcoming enterprise products Red Hat does not provide formal support

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

The Fedora Project is a collection of community supported open source projects sponsored by Red Hat intended to encourage rapid progress of free and open source software. The flagship project is Fedora, a rapidly evolving, technology-driven Linux distribution with an open, highly scalable development and distribution model. It is designed to be an incubator and test bed for new technologies that may be used in later Red Hat Enterprise products. The basic Fedora distribution is available for free download from the Internet. The Fedora Project produces releases of Fedora on a short four to six month release cycle, to bring the latest innovations of open source technology to the community. This may make it attractive for power users and developers who want access to cutting-edge technology and can handle the risks of adopting rapidly changing new technology. Red Hat does not provide formal support for the Fedora Project. The Fedora Project also supports EPEL, Extra Packages for Enterprise Linux. EPEL is a volunteer-based community effort to create a repository of high-quality add-on packages which can be used with Red Hat Enterprise Linux and compatible derivatives. Red Hat does not provide commercial support or service level agreements for EPEL packages.

Visit http://fedoraproject. org/ for more information about the Fedora Project. Visit http://fedoraproject.org/wiki/EPEL/ for more information about EPEL.

Objectives of RH423 Develop skills required to manage and deploy directory services on Red Hat Enterprise Linux systems Gain a better understanding of PAM and user authentication on Red Hat Enterprise Linux

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Audience and Prerequisites Audience: Senior Red Hat Linux and Red Hat Enterprise Linux system administrators and other IT professionals who need to provide enterprise-wide authentication or information services Prerequisites: RHCE certification or comparable skills and knowledge.

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

RH423 requires RHCR-level skills. The RHCE certificate on Red Hat Linux 7.1 or higher is recommended but not required. Prerequisite skills can be shown by passing the RHCE exam in either RH302 or RH300. Equivalent certification or skills and know ledge is acceptable. Persons should not enroll in RH423 without meeting the above prerequisites. Classroom Network example.com network (192 .168 . 0 . 0/24) server1 .example.com (192 .168. 0 .254) Main classroom server: Provides DHCP, DNS, routing and other services stationx.example.com (192 .168 .0 .x) Student systems serverx+100.example.com (192 .168.0 .x+100) Virtual server hosted on student stations serverx+200.example.com (192 .168 . 0. x+200) Secondary virtual server hosted on student stations

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Most major network services during class will he provided by the classroom server, server1.example.com. This server has the IP address 192.168.0.254. Student systems use the IP range 192.168.0.1-192.168.0.20. Every student system is assigned the DNS hostname stationx.example.com. where x is the last octet of its IP address. So station1.example.com would have the IP address 192.168.0.1. In most labs. students will also use a virtual server hosted on their classroom computer. This station is called serverx+ 100.example.com. with the IP address 192.168.0.X+100. where X is the student s station number. For example, the student with station1.example.com will also have server101.example.com for his or her virtual server. Likewise, the student with station20.example.com will also have server120.example.com for his or her virtual server. Some exercises may involve a second virtual server. In these cases, students will use the serverX+200 virtual machine, also hosted on their classroom computer. For this system, station1 would use server201, stalion20 would use server220, and so on. Notes on Internationalization Red Hat Enterprise Linux supports nineteen languages Default language can be selected: During installation With system-config-language System->Administration->Language Alternate languages can be used on a per-command basis:
$ LANG=en_US.UTF8 date

Language settings are stored in /etc/sysconfig/i18n

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Red Hal Enterprise Linux 5 supports nineteen languages: English, Bengali, Chinese (Simplified), Chinese (Traditional), French, German, Gujarati, Hindi, Italian, Japanese, Korean, Malayalam, Marathi, Oriya, Portuguese, (Brazilian), Punjabi, Russian, Spanish and Tamil. Support for Assamese, Kannada, Sinhalese and Telugu are provided as technology previews. A system's language can be selected during installation, but the default is US English. To use other languages, you may need to install extra packages to provide the appropriate fonts, translations and so forth. These can be selected during system installation or with system-config-packages ( Applications>Add/Remove Software). The currently selected language is set with the LANG shell variable. Programs read this variable to determine what language to use for output:
[student@stationX ~]$ echo $LANG ru_RU.UTF8

A system s default language can be changed with system-config-language ( System->Administration>Language). which affects the /etc/sysconfig/i18n file.

Languages with non-ASCII characters may have problems displaying in some environments. Kanji characters, for example, may not display as expected on a virtual console. Individual commands can be made to use another language by setting LANG on the command-line:
[student@stationX ~]$ LANG=en_DS.UTF8 date Thu Feb 22 13:54:34 EST 2007

Subsequent commands will revert to using the system's default language for output. SCIM (Smart Common Input Method) can be used to input text in various languages under X if the appropriate language support packages are installed. Type Ctrl-Space to switch input methods.

Unit 1 Introduction to Directory Services

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Objectives Upon completion of this unit, you should be able to: Explain what a directory service is Explain the history of LDAP and X500 Understand the LDAP information model Read and write simple LDIF Explore issues of data management
For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

What is a Directory? A directory is a specialized database that normally stores small pieces of information Special-purpose directories are common: A telephone book is a directory of names to telephone numbers DNS is a directory of hostnames to IP addresses NIS is a directory of system information; username to password file data, name to e-mail alias, mount point to device, and so on

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

What is a directory? A directory is simply a specialized database that stores small pieces of information. Directories tend to be write-once/read-many systems, unlike relational databases which are often write-many/read-rarely

systems. Special purpose directories are common in real life and on the Internet. It has been argued that DNS is one of the most successful special-purpose electronic directories in existence. In many ways, a directory is like a specialized database or file system, in that it stores many small pieces of information for search and retrieval. Unlike a file system, a directory is not optimized to deal with large random blocks of data, nor to seek to a random block of that data and retrieve it.

Ideal Directory Data Small pieces of information will be stored Potentially many small pieces of information! Data will be frequently read but rarely written Individual entries are based on collections of attributes (phone number, address, etc.) Information will need to be searched for or looked up by multiple client users

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Ideal directory data Typically, a directory is designed to store many small pieces of information, which is frequently read or searched but rarely written or updated. Individual entries tend to be based on collections of common attributes, like phone numbers, names, and addresses. Information will need to be searched for or looked up by many different people. Uses of a Directory Look up e-mail addresses and contact information in mail clients and web browsers Manage and synchronize user authentication centrally from a network server Centrally coordinate informational databases used by various network services Store and search for arbitrary data

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Directory uses There are many different ways an organization may make use of a directory. A directory may be used to store internal or external contact information. That information may then be accessed from networkcapable address book clients or other applications. A directory may manage user authentication information in a centralized way. to unify usernames and passwords. It may be used to centrally coordinate configuration files or other informational databases for network services. Or. it may simply store arbitrary data for later search and retrieval.

X.500 Directory Service General-purpose directory service designed by ISO and CCITT starting in the 1980s The Directory: a fully-connected global directory, information organized in a tree Flexible information model Intended for "white pages" telephone and X.400 e-mail directories, OSI name service DAP: client/server communication protocol

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

What is X.500? In the 1980s, the Comite Consuliatif International Telephonique et Telegraphique (CCITT, now known as the International Telecommunication Union-Telecommunication Standardization Sector, or ITU-T) and the International Standards Organization (ISO) began joint development of a global directory service. It was envisioned that this directory service would become a single, unified, distributed directory service much like DNS, but capable of storing many more kinds of information. ITU-T wanted a service that could act as a global telephone directory. The ISO was interested in a name service for OSI networking, much as DNS is for TCP/IP networking. It was also expected that the Directory could be used by X.400 email accounts to easily publish their public X.509 certificates for authenticating and encrypting e-mail. But the designers of the Directory also wanted it to be usable for new, general-purpose applications that had not yet been invented. This development effort culminated in the OSI networking-based X.500 family of ITU-T Recommendations, first approved in 1988 and updated in 1993, 1997. and 2001. The Directory is distributed across many directory servers on the network. Information stored in the Directory is organized in a tree-like hierarchical name space to simplify delegation of authority to servers and to improve the efficiency of searches. It was designed to have a very flexible information model, which could store information about objects of almost any type. These objects and the schema controlling their structure were described and defined using an object description language called ASN.1 ("Abstract Syntax Notation One"). A suite of different OSI application-layer protocols were developed for various purposes for X.500. including the Directory Access Protocol (DAP) used for communication between clients and servers. At the networking presentation-layer. "Basic Encoding Rules" (BER) are applied to objects described by ASN. 1 syntax, and these BER-encoded objects are used by the application-layer protocols. Both ASN.1 and BER are standardized with their own ITU-T Recommendations (X.680 and X.690 respectively). X.500 Problems X.500 (and DAP) is complex and resource hungry to implement The standards process did not require test implementations to prove feasibility! Early implementations were slow, buggy, and did not interoperate well X.500 is tied to the OSI network model The Internet is based on TCP/IP, not OSI Deployment was therefore slow

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Why not X.500? X.500 suffered from a number of problems in development and deployment, not least of which was the fact that it was built on top of the OSI networking model. The protocol suite itself was very complex and resource hungry to implement. Since the standards process did not require test implementations to prove feasibility, this should not be a surprise. Early implementations tended to be slow, buggy, and did not interoperate well. In addition, the standards process was driven in a top-down manner, and deployments tended to be slowed down by bureaucratic issues in the telecommunications industry and in national governments.

LDAP Lightweight Directory Access Protocol Originally for use by desktop computer clients LDAP improves X.500 DAP in several ways: Uses TCP transport in place of OSI networking Simplifies protocol to nine basic operations Uses a subset of X.500 message encoding rules Data elements are simple text strings

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Introducing LDAP LDAP is a lightweight version of DAP originally intended for desktop computers with TCP/IP networking. The first implementations of LDAP used it as a gateway protocol. Early TCP/IP clients used LDAP to talk to a server running ldapd, which convened the messages into DAP and sent them over an OSI network to a central X.500 server for processing, and vice versa. Therefore. LDAP allowed simple personal computers on TCP/IP networks to access X.500 directory services. The LDAP protocol improved on DAP in several ways. First, it uses TCP as the transport protocol rather than an OSI networking stack. Secondly, it simplified the core protocol to nine basic operations, while leaving the capability for future extensions. Thirdly, while the protocol itself is still defined in ASN. 1, the message encoding rules permitted are a simpler subset of BER. Finally, most protocol data elements are encoded in messages as simple UTF-8 text strings, not as ASN. 1 defined data structures.

LDAP Directory Service Initial ldapd daemon acted as a gateway In 1995, UMich LDAP group realized over 99% of X.500 queries came through Idapd A standalone LDAP daemon (slapd) replaced Idapd and the X.500 service Removed overhead of LDAP-to-DAP translation Improved performance and reduced directory service complexity

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

LDAP directory service LDAP was originally intended to simply be a gateway protocol for X.500 services. One of the earliest organizations to implement LDAP was at the University of Michigan. After a few years of operation, the LDAP group at the University of Michigan realized that the vast majority of their X.500 traffic, more than 99% of it, was passing through the LDAP gateway. Therefore, they redesigned their system to remove the overhead of translating to and from OSI networking, and made the LDAP gateway a standalone LDAP daemon, slapd. This improved performance of the directory service significantly, and reduced the complexity of the overall system.

LDAP Models Information Model How individual entries in the directory are structured Naming Model Where entries are stored in the hierarchical directory tree Functional Model What operations can be performed on the directory Security Model How directory information is protected from unauthorized access

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

The LDAP data models The four models above are different ways of looking at how data in the LDAP directory is managed, as proposed by Timothy Howes, Mark Smith, and Gordon Good in Understanding and Deploying LDAP Directory Services. The Information Model defines how the individual entries in the directory are structured. The Naming Model, discussed in the next unit, determines how we store entries in the directory hierarchy. The Functional Model defines the basic operations which the protocol allows us to perform on the directory. The Security Model defines how information in the directory is protected from

unauthorized access; it involves authentication and authorization of users as well as access control mechanisms on data and how accesses are audited and logged. The protocol itself will determine some of the ways these models work: others may depend on details of how particular LDAP directory server software is implemented. We will look at our directory from the perspective of each of these models as we progress through this course.

Information Model An entry stores information about an object of interest in the directory The basic unit of information storage Each entry is made up of attributes which describe characteristics of the object Each attribute in an entry has a type and takes one or more values The unique distinguished name of an entry is based on one of its attributes

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

The LDAP information model The entry is the fundamental unit of data storage in the directory. Each entry represents some object, and describes selected characteristics, or attributes, of that object. Attributes have different types, indicating what sort of information is stored in the attribute. Each attribute in an entry has a value associated with it. The unique distinguished name that identifies an individual entry in the directory tree is constructed from its attributes. For example, consider the entry:
dn: cn=Victor Frankenstein,ou=People, dc=example, dc=com objectclass: person objectclass: top cn: Victor Frankenstein sn: Frankenstein telephoneNumber: +1 919 754 3700

This entry has six attributes of five types: dn (distinguished name, the unique name of the entry), objectclass, cn (the"common name" or full name of the object), sn (the "surname" or last name of the object), and telephoneNumber. The dn attribute indicates the entry's location in the naming hierarchy, and consists of a commaseparated list of attribute-value pairs. The left-most component is the relative distinguished name of this entry, cn=Victor Frankenstein above, and must match an attribute-value pair in the entry. Most attributes are user attributes; that is, they contain normal data. Some attributes are maintained internally by the LDAP server and store meta-information about the entry such as last-modified time. These attributes are called operational attributes, and generally must be specifically requested if wanted as the result of a search or query.

Directory Schema The schema defines rules on what attributes can be used in which entries and how their values are formatted and compared Keeps directory data consistent and useful Reduces redundant or inappropriate information stored in entries Constraints on size and format help avoid bogus data values being assigned to attributes

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Directory Schema The schema defines the basic rules on what user attributes can be used in which entries and how the values of the attributes may be formatted and compared with one another. Schema restrictions can seem restricting and frustrating at first, but they are helpful because they can help you keep your data consistent and useful, rather than a jumbled mess. The schema helps reduce redundant or inappropriate information stored in entries, and they can also place restraints on the size of format of data to help avoid bogus information from being inadvertently assigned to an attribute. In theory, X.500 sees the schema as being universal; there is one consistent set of schema definitions world-wide, but it is administered in a distributed manner and not all directory servers know the entire set of schema definitions. Parts of the schema may be standardized and public, while other parts of the schema may be locally developed and potentially private. The schema definitions for X.500 were written using ASN. 1 and each definition in the schema was assigned a globally-unique object identifier, or OID number. From this perspective on schema definition comes the term subschema, which is defined as the part of the schema definition installed on or known to a particular directory server. Many LDAP directory administrators refer to the subschema as simply "the schema installed on this LDAP server." Directory Schema attribute types: name/OID tied to attribute syntax: used by the attribute to define how its value should be formatted matching rules: used by the attribute to define how to compare two attributes of the same type object classes: name/OID to attributes that Represent a family of similar objects Define what attributes must or may be included in an entry

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

What does a schema definition define? On an LDAP server, the schema files basically define the attribute types and object classes that are available. Attribute type definitions set a name and unique OID number for the attribute type. The type is tied to an attribute syntax which determines the format of the value of the attribute, and matching

rules for equality, sorting, and substring matches between two attributes of the same type. Syntaxes and matching rules are also assigned OID numbers and names to identify them. (Theoretically, in X.500 the attribute syntaxes and matching rules were also defined as ASN.1 code in a server's subschema. In a LDAP server, the syntaxes and matching rules that are available are generally hard-coded into the server and may be difficult to extend. In Red Hat Directory Server, syntaxes and matching rules are actually implemented as plug-in modules, and new syntax or matching rule definitions may be added by creating and installing new plug-ins.) Object class definitions set a name and unique OID number to an attribute value that will represent a family of objects that have similar characteristics. These definitions specify which attributes must be or may be part of a particular entry.

Directory Schema Each item in the schema is assigned a unique object ID ("OID") number OID arcs assigned on request by IANA Better to use standard schema definitions than to invent a custom ones Simplifies searches on the directory Better interoperation with different software Easier to maintain and understand

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

How the schema works? Each type of object used or defined in the schema, whether an attribute type, an object class, a syntax, or a matching rule, is assigned a globally unique ASN.1 object ID number, or OID. These OID numbers are assigned hierarchically; each child node is either used to store the abstract definition of some object or is the root of a subtree delegated to a responsible party for further delegation. All objects with OIDs in the same subtree (starting with the same prefix) are said to be in the same OID arc. OID numbers are used with many ASN.1-based protocols, including LDAP and SNMP. For example, the arc 1.3.6.1.1 contains many object definitions related to directory services. Organizations that want to develop their own schema definitions may request a subtree of the OID space from one of a number of Internet naming authorities. Then these OIDs can be used to help organizations coordinate what objects have been defined for which purposes. In general, it is better to use standard schema objects than to write locally customized ones from scratch. User applications generally expect certain attribute types and object classes to be used to store standard data, so using standard schema objects helps simplify searches on the directory and makes it more likely that client software will interoperate well. It also makes it easier for directory administrators to maintain and understand the information in thedirectory.

Standard Schema Definitions Core LDAP schema is defined in RFCs 4519, 4517, and 4512 Updates of older definitions in RFC 2252 and RFC 2256 RFCs 2247, 2307, 2798, and 4524 provide commonly-used extensions Servers come with pre-installed schema files Vendors may provide non-standard schema extensions of their own

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Following the standard The ITU-T Recommendations X.520 and X.521 defined standard attribute types and object classes for X.500 directory services. Early directory service pilot projects such as COSINE found they needed additional X.500 attribute types and object classes, and a number were defined in RFC 1274 (since revised as RFC 4524). When LDAP was developed, many of these definitions found their way into the standardized core LDAP schema defined by Internet RFCs 2252 and 2256 (since revised as RFCs 4512.4517. and 4519), which every LDAP server is expected to understand. Internet RFCs specify a number of other schema definitions. For example. RFC 2798 dedines the inetOrgPerson object class and its supporting attribute types, which are a de-facto, if not official, industry standard for representing people in LDAP directories. RFC 2307 defines attribute types and object classes useful for storing NIS data as directory entries. RFC 2247 specifies attribute types and object classes used to represent components of DNS domain names. Internet RFCs are freely available from http://tools.ietf.org/rfc/index. If the openldap-devel package is installed on the system, a number of these RFCs can be found in /usr/share/doc/openldap-devel-*/rfc. Schema definitions can theoretically be represented as pure ASN. 1 or by following an LDIF format specified by RFC 2251 for subschema entries: the second approach is more common today, since most LDAP servers only understand schema files which use that format. Usually, LDAP servers come from the software vendor pre-installed with standard or semi-standard schema files. Vendors also often provide non-standard schemas or extensions of their own. and this is often where interoperability problems start between two directory deployments. The openldap-servers package installs its schema files in the /etc/openldap/schema directory. Red Hat Directory Server installs schema files in /etc/dirsrv/slapd-instance/schema. Example Attribute Definition
attributeTypes: ( 2.5.4.20 NAME 'telephoneNumber EQUALITY telephoneNumberMatch SUBSTR telephoneNumberSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.50{32})

2.5.4.20 is the OID for the attribute SYNTAX OID defined as TelephoneNumber

Value should have a form like +1 919 555 1212

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

An example attribute The slide above shows an example attribute type definition.
2.5.4.20 is the OID number identifying this particular schema item. NAME identifies the attribute's name: "telephoneNumber". The name of an attribute should be

unique. However, an attribute may be known by several different names (for instance, a long name and a short name). One example of this is the uid attribute, which also has the alternative name userid. In this case the first name listed in the schema is usually considered the primary name.
EQUALITY and SUBSTRING define matching rules which may be used: support for them must be built

into the LDAP server. (These particular rules mandate a case-insensitive match, ignoring hyphens and whitespace.) The SYNTAX specifies an attribute syntax, also supported by the LDAP server, that restricts what values this attribute may hold. It turns out that the schema, following RFC 2252. defines this OID as the syntax TelephoneNumber, which should be a telephone number consistently formatted following the guidelines in ITU-T Recommendation E.123. (Standard international format, with spaces separating number groups.) There is a {32} at the end of the OID number. That indicates that the LDAP server must permit values of up to 32 characters in length for this attribute: it may optionally allow longer values. Some attributes may include the keyword SINGLE-VALUE. Such attributes must only appear with one value in an entry. Otherwise, attributes may appear multiple times, each time with a different value. (For example, one person may have two telephone numbers or e-mail addresses, but only one Social Security number.)

Sample Attribute Syntaxes Usually listed in schema by OID, not name TelephoneNumber: in E.123 format DirectoryString: text stored as UTF-8 IA5String: text stored as ASCII INTEGER: integer number as a digit string Octetstring: arbitrary binary data CountryString: an ISO 3166 country code

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

A number of syntaxes you may run across in real life are listed on the slide above. The matching OIDs are
TelephoneNumber DirectoryString IA5String 1.3.6.1.4.1.1466.115.121.1.50 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.26

INTEGER OctetString CountryString

1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.40 1.3.6.1.4.1.1466.115.121.1.11

The syntaxes available on a particular LDAP server are usually hard-coded in, but some implementations may allow extension through code modification and recompilation, a plug-in architecture, or ASN.1 definitions.

Sample Matching Rules Many different rules to test for equality caseIgnoreMatch: case insensitive caseExactMatch: case is significant integerMatch: compare two numbers octetstringMatch: compare byte-by-byte Sorting and substring matching rules

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Matching rules also have OID numbers, but in schema files they are commonly referred to by their names. Like attribute syntaxes, the available matching rules are generally hard-coded into a particular implementation of a LDAP directory, but some implementations may allow extensions through a plug-in architecture, code changes, or ASN.1 definitions. Different types of matching rules are defined. There are exact equality tests, substring matches, rules that determine approximate matches, and rule that determine how to sort attributes by value. Not all types of matching rules need to be defined for a particular attribute type.

Commonly Seen Attributes

dn cn sn uid c o ou mail

The unique DN identifying the entry The entry's common name (full name) The surname (last name) of a user Login name Two letter country code Name of an organization Name of an organizational unit Internet e-mail address

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Listed on the slide above are some names of commonly used attributes. In some cases, attributes may have alternate names or aliases that may also be used to represent them in schema or entry definitions. The names used above are the most commonly used or "primary names" of these attributes. In many cases, the alternative names for the attributes are from older standards or are longer to type, and the short names were developed because the attributes are frequently needed in entries. Some attributes with their alternative names: primary name | alternative name
cn sn uid c o ou mail | | | | | | | commonName surname userid countryName organizationName organizationalUnitName rfc822Mailbox

Object Classes An object class groups related information Defines which attributes are mandatory and which are permitted in an entry objectclass attributes specify which object classes an entry belongs to There are different kinds of object classes An entry must have one structural object class An entry may add one or more additional auxiliary object classes

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Defining entries An object class defines which attributes may be used in a particular entry. Each object class may assign a set of attributes which are mandatory -- they must be set in any object using that object class. Each object class may also assign a set of optional attributes, which may be set but do not have to be. Any attributes which are not included in one of the object classes of an entry may not be used in that entry. There are different types of object classes. An entry must have exactly one structural object class, which cannot be changed for the life of the object. An entry may add one or more additional auxiliary object classes, which enable it to use additional attributes. The structural object class of an object defines a great deal about its basic characteristics and uses.

Example Object Class

objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY { userPassword $ telephoneNumber $ seeAlso $ description ) )

The person object class has OID 2.5.6.6 It is a structural object class, and top is its immediate superclass It has two mandatory attributes, sn and cn, and four optional attributes

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Derived Object Classes An object class may be a subclass derived from another object class The derived class inherits the required and optional attribute lists from its superclass The derived class may then add additional required and optional attributes

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Object class inheritance Object classes may be children of other object classes. In that case they inherit the mandatory and optional attributes of their parent class, and may add additional mandatory and optional attributes. This means that the previous slide lied to you -- the person object class actually has three mandatory attributes. The third one, objectclass, is hidden because it was inherited from the object class's parent, top. The top object class is a special type of object class, abstract, which is neither structural or auxiliary and represents the lop of the tree of inheritance. Object classes may inherit attributes from grandparent classes and great-grandparent classes, and so on. The structural object class of an entry may inherit attributes from parent object classes that are also structural object classes. The basic rule is that an entry is characterized by exactly one structural object class chain, which has a single structural object class as the most subordinate in the chain. This object class is the structural object class of the entry. There may not be any other structural object classes in the entry that are not a part of this chain of inheritance.

Example Object Class

objectClasses: ( 2.5.6.0 NAME 'top' ABSTRACT MUST ( objectclass ) ) objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Therefore person inherits a third required attribute from top, objectclass

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Object classes for naming user accounts The person object class illustrated in the slide above was originally specified in ITU-T Recommendation X.521, and is intended for use with entries that represent information about generic people. Two other subclasses of person are also defined in X.521. organizationalPerson (for people associated with an organization) and residentialPerson (for representing people in a residential environment). RFC 2256 adopted these object classes were adopted as part of the core LDAP schema. The organizationalPerson object class has the deinition:
objectClasses: ( 2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121address $ registeredAddress $ destinationlndicator $ preferredDeliveryMethod $ telexNumber $ telexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsitmileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ ou $ st $ 1 $ physicalDeliveryAddress ) )

Other object classes used for defining people have been derived from organizationalPerson. For example, the default object class used to represent people by Red Hat Directory Server is inetOrgPerson. defined by RFC 2798:
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 $ userCertificate $ uid $ xBOOuniqueldentifier $ preferredLanguage $ userSMIMECertificate $ userPKCS12 ) )

Note that inetOrgPerson also inherits all the attributes on the MUST and MAY lists for organizationalPerson, person, and top. Also, remember that these are all user attributes. The server, not the schema, controls the operational attributes that are automatically maintained for an entry.

extensible Object A special auxiliary object class in the core LDAPv3 schema Entries which include this object class can include any attribute This effectively disables schema checking for those entries Which can lead to a mess later on.... Avoid using this object class in entries

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

extensibleObject The special object class extensibleObject is a schema safety hatch. This auxiliary object class includes all possible attributes as optional ones. Any object including this object class is effectively immune to schema restrictions. This may seem convenient, but in practice this can rapidly lead to a nightmare as entries pick up stray attributes that are not appropriate for them through programming mistakes that schema checking would have caught. Avoid using extensibleObject whenever possible. It is almost always possible. For the same reason, if a directory server implementation allows schema checking to be turned off, it is almost always a better idea to leave it turned on even when testing early pilot implementations of the directory service.

LDIF A standard text-based format for describing directory entries May be used to describe an existing directory or changes to be made to an existing directory An entry consists of a list of attributes, one attribute per line dn, the entry's distinguished name, must be first Entries are separated by blank lines

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

LDIF Attributes and values are colon separated Two colons indicate that the value is base-64 encoded (can use openssl utility to convert) If a line starts with #, it is a comment If a line starts with a single space, it is continued from the previous line

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

LDIF syntax Sometimes, you may run into an attribute that is separated from its value by two colons. That usually means it has been Base64 encoded for some reason. If you need to decode the data, you can pipe it through the openssl base64 -d command.
dn: cn=Joe Shmoe,dc=example,dc=com objectclass: person objectclass: top cn: Joe Shmoe sn: Shmoe description:: QXd3dy4uLi55b3UgbG9va2VkIQo= bash$ echo 'QXd3dy4uLi55b3UgbG9va2VkIQo= | openssl base64 -d

Sample Entry in LDIF Form

dn: uid=bjensen, ou=people, dc=example, dc=com objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Barbara Jensen cn: Barb Jensen sn: Jensen uid: bjensen mail: bjensen@example.com telephoneNumber: +1 919 754 3700 postalAddress: Example, Inc.$123 Main Street$Any Town, NC 12345$USA title: Account Manager
For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Troubleshooting an LDIF Entry Does the RDN match an attribute-value pair? Is there exactly one structural class, not counting parent superclasses? Do all mandatory attributes have a value? Are there any attributes set which the object class or classes for this entry do not allow? Do any single-value attributes have multiple values?

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Manually checking entries It is a useful skill to be able to check entries in LDIF by hand to ensure that they are correct and meet the requirements of the schema. When reading an entry in LDIF. remember to check the following items: 1. Look at the relative distinguished name of the entry (the left-most comma-separated component of the value of the DN attribute). Does the relative distinguished name match an attribute-value pair in the entry? 2. All entries must have exactly one structural class. The entry should list its structural class, and all of its parent classes. Parent classes of the structural class may also be structural classes. Any other object classes listed should be auxiliary or abstract, and if they have parent classes those classes should also be listed. 3. Examine the object class definitions. Determine what attributes are mandatory for this entry. Do not forget that mandatory attributes may be inherited from parent classes! Make sure that all mandatory attributes have a value 4. Look carefully over the entry. All attributes that have a value must either be listed as a mandatory attribute or an optional attribute in one of the object classes for that entry! 5. Do any attributes have multiple values set? If so they will appear more than once in the LDIF listing, with different values. Some attributes may only be single-valued; make sure that none of the attributes with multiple values require this!

Managing Directory Data What attributes do your applications need? Are they hard-wired to use a particular schema? Do applications have conflicting needs? Correct object class selection is important Helps avoid poor quality or badly formatted data An entry cannot change its structural object class after creation!

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Planning the directory service When looking at schema files for suitability, there are a number of considerations to keep in mind. What attributes do you need for your purposes? Do your client applications have particular requirements? Are the schema definitions commonly used, or are they only used by this software vendor?

Correct object class selection can help you avoid expensive data conversions later on.

Managing Directory Data Use standard schema definitions if possible Auxiliary classes may help Avoid storing identical or redundant data in multiple attributes Otherwise, ensure the values stay synchronized Plan for change What attributes might you need in the future? How will current data be kept up to date?

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

Tips and thoughts In general, try to slick to the standard schema definitions. Even if they are not supported perfectly by your current software vendors, the likelihood of the standard attributes being supported tends to be high. Try to avoid storing identical data in different attributes, even in the same entry. If you do store identical data in different attributes, you run the risk of that data getting out of synchronization at some point in the future, where one attribute is up to date and one is not. Think about how the data you plan to store will be kept up to date, and what attributes and uses you might make of the directory service in the future.

Developing a Data Policy What data will and will not be stored in the directory service Who has the ability to modify which entries Who has the ability to access which entries Legal considerations affecting the above How exceptions may be made if needed

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

The directory data policy One last thing to think about is your data policy. What data will you and will you not allow to be stored in the directory service? Who will be in charge of making sure updates happen? Who will be permitted to perform updates? Are there entries which are private or should have restricted access. In most if not all organizations, there may be legal limitations on the sorts of information you may make available about an employee, for example.

In addition, you should think about specifying how exceptional situations will be dealt with, if the data policy turns out not to be adequate at some point in the future.

End of Unit 1 Questions and Answers Summary LDAP and X.500 Schemas, object classes, and attributes LDIF Management of directory data

For use only by 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 <training@redhat.com> or phone toll-free (USA) +1 (866) 626 2994 or +1 (919) 754 3700

. Unit 1 33Labi 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. Copyright 2008 Red Hat, Inc. , Lab 1 34Sequence 1: Reading Schema Scenario: The ability to read LDAP schema iles is important in order to make sure that your data is easy to maintain. Schema iles 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 'country1 SUP top STRUCTURAL MUST c MAY ( searchGuide $ description )) objectClasses: ( 2.5.6.3 NAME 'locality' SUP top STRUCTURAL MAY ( street $ seeAlso $ searchGuide $ st $ 1 $ description )) objectClasses: ( 1.3.6.1.4.1.250.3.15 NAME 'labeledURIObject'