1

Open Source Lightweight Directory

Access Protocol

2

Interoperability with Windows and Unix/Linux

A hot topic in enterprise networks where unique O/S is not always possibleAuthentication is a major concern to provide users the keys to get on the network services running on different O/SOlder Windows authentication used NT authentication (LM (Lan Manager), NTLM and NTLM2 protocols)Modern Windows uses Kerberos with user information stored in Active Directory for centralised authenticationUnix/Linux traditionally store accounts and passwords locally in a file called /etc/passwd and /etc/shadow/etc/shadow contains the hashed password plus information about when the password will expire

3

Centralised Authentication - Linux

Linux provides a shared networked alternative to /etc/passwd files. Options areNISOpenLDAPSambaKerberos

4

NIS (Network Information Service)

NIS – originally designed by Sun Microsystems helps centralise accounts by looking up passwords stored on master and secondary servers instead of on local machineNIS is not hierarchical – there is not efficient way to examine for instance only the users in the marketing departmentNIS has difficulties working through a firewallSubject to many network security problemsNIS+ attempts to solve some of these problems – some support for hierarchical structure and security protections are added (not included in Fedora)

5

OpenLDAP

Provides directory services to Unix clientsHierarchical – potentially a better choice than NIS when a large number of accounts is involvedMuch easier to pass through a firewall than NIS

6

Samba

Samba 3 allows a Linux machine to pretend to be a Windows file server, print server or NT4 Primary Domain Controller (PDC) or Backup Domain Controller (BDC)Samba 4 pretends to be an Active Directory Domain ControllerSamba store accounts centrally in its own database or in an LDAP database and then Windows users can authenticate to Samba

7

Kerberos

Kerberos is a network authentication protocol. It is designed to provide strong authentication for client/server applications by using symmetrical key cryptography and and requires a trusted third party (timed ticket).Both Linux and windows clients and servers can use Kerberos to authenticate logonsKerberos is not a directory service, its task is to authenticate user identities, not to store information such as user and group IDs

8

Centralised Authentication - Windows

Microsoft Windows Services for UNIX SFU 3.5 – Interoperability Toolkit from Microsoft enables Windows and UNIX clients and servers to share network resources, integrates account management, simplifies cross-platform management and provides a full UNIX scripting and application execution environment that runs natively on Windows

9

Integrated Authentication for Network Resources

As number of enterprise users increases, account management is becoming more complex.Imagine how many passwords an user has to remember if he has to access several servers POP3, Webmail, FTP server etc. besides system login.System Administrator has to notify all users in case passwords and permission of each service have changed.LDAP Directory Services can help to simplify account and password management.

10

What LDAP Can/Cannot Do

LDAP provides central management of access, authentication and authorization.

What LDAP can do: Centralize users and group management Centralize information stores Set security and access control Securely delegate read and modification authority Serve almost any platform Scale efficiently

What LDAP cannot do: Be a heavy-duty relational or transactional

database Be a file system

11

Is LDAP a Database or Not?LDAP – Lightweight Directory Access Protocol - is a protocol, not a database.It accesses a special kind of database that is optimised for fast reads Use it for relatively static information, such as company directories, user data, customer data, passwords and security keysOpenLDAP uses the Sleepycat Berkeley DBIt is not a good choice when you need fast, frequent changes - for a retail backend, for exampleIts structure is very different from a relational databaseData are stored in attribute type/attribute value pairsNew types of data can be added without having to re-design the entire database

12

Roots and Hierarchies

An LDAP directory follows the familiar Unix filesystem structure – root directory at the top of the “tree” with sub-directories branching offA typical design is to have a single master root directory for the company. Sub-directories are then organised by department, location, function and anything that makes sense for you.A nice and tidy way to organise the master directory and let you grant access permissions to specific pieces of a central data pool in a precise, controlled fashion.Any individual subdirectory can be replicated elsewhere Updates can be initiated in either direction. E.g. the accounting department can make updates to their directory then push the updates to the master server.

13

Directory SystemsDirectories organise complex information, making it easy to find.They list resources – people, books in library, goods in department store and give details about each one. E.g. telephone books, library catalog, department

store catalog.

Enterprises with distributed computer systems use online directories for fast searches, cost-effective management of users and security, and a central integration point for multiple applications and services.LDAP is used by almost all commercial directory systems.

14

LDAP Specifications

Lightweight Directory Access Protocol (LDAP) is one of the pre-eminent directory services deployed in the world.LDAP is based on ITU X.500 standard but significantly simpler and more readily adapted to meet custom needs.Unlike X.500 which is too tied to the OSI protocols, LDAP supports TCP/IP (uses port 389) which is necessary for Internet access.The core LDAP specifications are all defined in RFC’s 1777-1779; 1959-1960; 2251-2256 and 2819-2830.Strictly speaking, LDAP is not a database but a protocol used to access information stored in an information directory (a.k.a LDAP directory).Using LDAP, data will be stored in and retrieved from the correction within an LDAP information directory.

15

Advantages of LDAP DirectoriesCompanies can access the LDAP directory from almost any computing platforms.LDAP protocol is Internet standards-based and is finding much wider industry acceptance.LDAP-aware applications are readily available.Unlike many relational databases, you do not have to pay for either client connection software or for licensing.LDAP servers can replicate their data via push or pull methods, allowing you to push data to remote offices to increase security.Replication technology is built-in and easy to configure (By contrast, many of the big DBMS vendors charge extra for this features and it is far more difficult to manage).Read and modification authority can be delegated based on your needs using Access Control Instances (ACI).

16

Access Control Instances (ACIs)LDAP access control instances (ACIs) which collectively form an access control list allow extremely fine-grained control. Examples are:

Users can modify their own personal information – home address, phone extension, email – but no one else’s

All of the information for a particular user can be kept in a single record, but access to individual entries is completely configurable

Give managers a precise level of read and read/write permissions for their group

Put usernames and passwords and other sensitive data under the control of the sysadmin.

Let groups and group leaders determine who gets what kind of access to resource under their control.

17

Figure 1. Integration of applications & infrastructure with LDAP

18

LDAP Data OrganizationAction in LDAP takes place around a data structure known as an entry.

Figure 2. The LDAP entry data structure

19

LDAP Entry Structure An entry has a set of named component parts called attributes that hold the data for that entry.To use database terms, they are like the fields in database record.

If we keep a list of machines in an LDAP directory, each machine entry can have attributes like names, model, location, owner, etc.

Besides its name, an attribute consists of a type and a set of values that conform to that type.

If we store employee information, each entry might have a phone attribute that has a type of telephoneNumber.

The values of this attribute might be that employee’s phone numbers.

A type also has a syntax that dictates what kind of data can be used (strings, numbers, etc.), how it is stored and how it is used in a search.

20

LDAP’s Naming Model When we consider a directory populated with many entries, we are immediately faced with the question that “ How do you find anything?”To answer this question, we need to look to LDAP’s “naming model”. A common set of naming rules called namespace is needed.Namespace serves two functions:

To identify objects and To define the hierarchical structure

Each entry indicates a location in the directory, its name must be unique.Management control can be delegated at multiple points in the hierarchical structure (natural inheritance of hierarchy)LDAP namespace is very similar to DNS so works seamlessly with DNS. (DNS is preferred by not required).

21

Relative Distinguished Name (1)In Figure 2, each entry has a name known as its Distinguished Name (DN). The DN consists of a string of Relative Distinguished Names (RDNs).An RDN is composed of one or several attribute name-value pairs. E.g. cn=Jay Sekora (where cn stands for “common name”) could be an RDN.The attribute name is cn and the value is Jay Sekora.Neither the LDAP nor the X.500 specifications dictate which attributes should be used to form an RDN. They do require RDNs to be unique at each level in a directory hierarchy to distinguish between individual entries at that level.

22

Relative Distinguished Name (2)

Take another example RDN: cn=Robert Smith Not a good RDN choice. There is likely to be more than one Robert Smith

in an organisation of even moderate size. If you have a large number of people in your

organisaton and your LDAP hierarchy is flat, name collisions like this are to be expected.

A better entry would combine two attributes, cn=Robert Smith+l=Boston Attributes in RDNs are combined with a plus

sign.

23

Relative Distinguished Name (3)The revised RDN which appends a locality attribute may have postponed a name clash but have not eliminated the possibility.Furthermore, if Smith moves to some other locality, we will have to change both the RDN for the entry and the location attribute in the entry.The best RDN would be one with a unique and immutable user ID for this person. e.g., we could use that person’s email address

so the RDN would be uid=rsmith.

24

Directory Information Tree (DIT)Entries exist in a tree-like structure known as Directory Information Tree (DIT) or just directory tree.The root of the directory has a name known as the directory’s base DN.

The server’s base DN typically matches the DNS name of the directory server and uses the domain component (dc) attribute to represent the DNS zones (however, the match is not compulsory).

Each entry in a directory tree can be located by its Distinguished Name (DN).A DN is composed of an entry’s RDN followed by all of the RDNs (separated by comma or semicolons) found as you walk your way back up the tree towards the root entry.If we follow the arrows in Figure 3 and accumulate RDNs as we go, we’ll construct DNs for each highlighted entry.

25

In the left pane of Figure 3, our DN would be: cn=Robert Smith,l=main campus,ou=CCS,o=Hogwarts School,c=US

In the right pane of Figure 3, it is: uid=rsmith,ou=systems,ou=people,dc=ccs,dc=hogwarts,dc=edu

Figure 3. Walking Back up the tree to produce a DN

26

Distinguished Name (DN)DN is the name of an entry

ou is short for organizational unit o is short for organization dc stands for “domain component” c is for country

DNs are more like postal addresses than absolute pathname in a filesystem because they have a “most specific component first” ordering. In a postal address like:

Chan Tai Man20 Tsing Yi RoadTsing Yi, NTHK

You start off with the most specific object (the person) and get more vague from there, eventually winding up at the least specific component (the country).

27

Summary – DN and RDNThe concept of the distinguished name is the heart of the naming model. DN is used to construct the namespace and the directory information tree.Each model has an attributed called “distinguished name” (DN) used to identify the entry unambiguouslyDN must be unique throughout the whole directoryRDN has to be unique only in its scope. For example, if the parent is

DN: ou=sales, l=Europe, o=ldap_abc.org under this subtree there can be only one RDN: uid=usr1 resulting in the DN: DN: uid=urs1,ou=sales,l=Europe,o=ldap_abc.org

This means that you can have an entry with an RDN of uid=usr1 under l=Asia, resulting in the unique DN:

DN: uid=usr1,ou=sales,l=Asia,o=ldap_abc.org

28

Figure 4. Person and part records with DNs in an LDAP directory

that integrates with the DNS namespace

Example to illustrate DN usage

29

The name of the root of the directory is known as the directory’s base DN (e.g. dc=mycompany,dc=com).The DN of the person entry shown in Figure 4 could have been

cn=Brian Arkills,ou=People,dc=mycompany,dc=com instead of uid=barkills,ou=People,dc=mycompany,dc=comNotice that each RDN component includes both the attribute type and value. For example, the single component cn=Brian Arkills has both the attribute type cn and the attribute value Brian Arkills. Attribute value without the attribute type would be be sufficient to distinguish the entry.The common name (cn) of the entry is Brian Arkills. It must be unique among all entries in the container ou=People to qualify as an RDN.Since uniqueness of a person’s name is not guaranteed, so another attribute is often used instead as the RDN. E.g. user identity uid=barkills is chosen because login IDs must be unique.The DN uid=barkills,ou=People,dc=mycompany,dc=com refers to exactly the same record in the directory namespace as the DN above. It simply uses a different RDN to identify the entry.

30

base DN (Directory Suffix)The top level (or root) of the LDAP directory tree is the base, referred to as the “base DN”, a.k.a “directory suffix”.For example DN: ou=sales,l=Europe,o=ldap_abc.de

base DN takes one of the three forms listed below; 1. base DN in X.500 format: o=ldap_abc,c=de

o=ldap_abc refers to the organization i.e., company name and c=de indicates that the company headquarters is in Germany.

With Internet globalization, using a country code in the base DN makes things more confusing.

2. base DN derived from Internet presence: o=ldap_abc.org This format uses the company’s Internet domain name as the base

3. base DN derived from domain components: dc=ldap_abc,dc=org

As with the previous format, this uses the DNS domain name as its basis. This format is split into domain components: ldap_abc.org becomes dc=ldap_abc,dc=org

If ldap_abc.org merges with ldap_xyz.org, you simply think of “dc=org” as the base DN and new records can be placed into your existing directory under dc=ldap_xyz,dc=org

31

Example - Content of a directory exported to a LDIF file

dn: o=ldap_abc.de objectclass: top objectclass: organization o: ldap_abc.de l: Munich

dn: ou=IT, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: IT description: Information

Technologies

dn: ou=HR, o=ldap_abc.de objectclass: top objectclass: organizationalUnit ou: HR description: Human Resources

dn: uid=SParker, ou=HR, o=ldap_abc.de

objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: HR cn: Sarah Parker sn: Parker givenName: Sarah uid: SParker mail: SarahParker@ldap_abc.deMobile: (0049) 89 671 293

32

Relationship between Entries and Attributes

The previous directory can be broken down into smaller data structure called “entries” or objects.First type of entry describes the whole organization, the second a single organizational unit and the third a single person.Each entry contains information describing what it is or, to which object class it belongs – called objectClass.

33

Different Types of ObjectsTo summarize, we have three different types of objects. Each representing a different object class;

1. The whole organization is identified by an “o”: o=ldap_abc.de

2. The individual departments, called “organizationalUnit” abbreviated with “ou”:

ou=IT,o=ldap_abc.de ou=HR,o=ldap_abc.de

3. The entry for a single person, called “inetOrgPerson” is identified as follows: uid=SParker,ou=HR,o=ldap_abc.de

Each entry corresponds directly to an object in the real world, i.e, a person, a printer, a computer, an organization, etc.

34

Object Class LDAP is object-oriented.Object classes define what entries are possible in an LDAP directory.Each entry has a special attribute called objectClass.objectClass contains multiple values that when combined with server and user settings, dictate which attributes must and may exist in that particular entry.Each of the values of an objectClass attribute is a name of an object class. These classes either define the set of attributes that can or must be in an entry, or expand on the definitions inherited from another class.Provides a convenient way for a user to query for all the entries with a particular objectClass attribute.

E.g. to query just with objectclass=user identifies all user accounts in a Microsoft Active Directory.

35

Inheriting characteristics of object class

New object classes can be constructed hierarchically by inheriting characteristics from an existing object class.

Object class “organization” is derived from the “root” object class by inheritance.

The root of all object classes from which all other object classes are inheriting is the “top” object class.

Object class “inetOrgPerson” derives from the previous class “organizationalPerson”, which inherits from the previous class “person”, which in turn inherits from the root object class “top”.

Given this hierarchical system of inheritance, we can see why most entries “belong” to more than one object class:

Each entry belongs to a specific object class as well as the ladder of increasingly broader classes from which it was derived.

The attribute “objectClass” describes all of the object classes to which the entry belongs.

36

Object Class DefinitionsThe root object class “top” is the ancestor of all object classes and contains the required attribute “objectClass”.Since all entries inherit directly or indirectly from the root “top”, every object class MUST contain the attribute “objectClass”.In the previous directory, the object with DN: “o=ldap_abc.de” implements the object class “organization”. The attribute “objectClass” of this entry has the two values: “top” and “organization”.

The definition shows which attribute are required (MUST) and which attributes are optional (MAY)

“top” must only contain the attribute “objectClass” “organization” inherits all attributes from “top” and must also

contain o (organization) “top” has no optional attribute, “organization” has many

optional attributes.

37

Object Class Definition for top and organization

Objectclass top:(2.5.6.0 Name ‘top’ ABSTRACT MUST ( objectClass ))

Objectclass organization:(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 postalAddress physicalDeliveryOfficeName st l description ))

38

Examples – Object Class Definitions (1)Object class “top”

All object classes derived from the object class “top” Its purpose is to ensure every object contains the

“objectClass” attribute It exists only to be subclassed i.e., ABSTRACT You will not find an entry for object class “top” Because every object class inherits from “top”, every

object class must contain the attribute “objectClass”

(2.5.6.0 NAME ‘top’ ABSTRACT MUST ( objectClass ))

39

Examples – Object Class Definitions (2)Object class “person”

Derived from “top” Besides the attribute “objectClass” inherited from “top” every

“person” entry must have the attributes “sn” and “cn” The line with “SUP top” expresses that the object class “top” is its

ancestor We can use the numeric OID here: SUP ‘2.5.6.0’

(2.5.6.6 NAME ‘person’ SUP top STRUCTURAL MUST ( sn $ cn )MAY ( userPassword $ telephoneNumber $ seeAlso $ description ))

40

Examples – Object Class Definitions (3)Object class “organizationalPerson”

Derived from “person” This object class has a number of attributes useful for implementing

an employee object such as fax number, organizational unit and so on.

It adds more optional attributes in addition to those provided by “person”.

(2.5.6.7 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $destination Indicator $

preferredDeliveryMethod $ telexNumber $ teletexTerminal Identifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ 1

) )

41

Examples – Object Class Definitions (4)Object class “inetOrgPerson”

This class was intended to accommodate information about a person in a typical Internet/Intranet environment

(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

) )

42

Summary Object Class DefinitionsIn most cases, we use the pre-defined standard object classes. If you need to construct entries with attributes not found in an existing object class, it is usually good form to locate the closest existing object class and build upon it, like organizationalPerson, builds upon person above.A collection of object classes that specify attributes for the entries in an LDAP server is called a schema.

43

organizationalUnit Object Class

44

domain Object Class

45

person, organizationalPerson and inetOrgPerson objectClasses

46

posixAccount (above) Auxiliary object class

posixGroup (below) Structural object class

47

shadowAccount Object Class

48

Elements of an Object Class (1)Object class definition contains several key fields that help to define an entry of the object class and what rules that entry follows. OID – the unique object identifier for this object

class. Name – the name used to refer to the object class. Description – brief description of what the object

class represents. Inactive status – indicated by OBSOLETE which

means the object class is inactive. Superior class – lists the object class(es) on which

this object class is based (some schema formats label this field SUP while others call it SUBCLASS OF.

49

Elements of an Object Class (2)

Category of object class – specified with the presence of abstract, auxiliary, or structural By default, structural is assumed. The categories indicate to the schema checking

process how to create an entry of that object class and what attributes are required or allowed.

Mandatory attributes – usually noted by a MUST field, which lists all the attributes that must have values for an entry of this object class to exist.

Optional attributes – usually noted by a MAY field, which lists all the attributes that are allowed on an entry of this object class.

50

Object Class CategoriesThree categories of object classes: abstract, auxiliary and structural.Every entry in the directory has at least one structural class and one abstract class, and may have auxiliary classes.Any particular object class may build on another object class definition or pick the attractive parts of another object class definition – this functionality is enabled by object class categories.Object classes can either include or inherit existing definitions thereby forming relationships between object classes

one object class has a whole set of object classes depending on it, so a hierarchy is formed.

51

Abstract Object ClassNot intended to be actually implemented e.g., TOP class

No entry implementing the object class TOP, but it is from this class that all other classes are derived.Exists to ensure that all classes derived from it contain the attribute objectClass.No need to use an object of this class.

52

Structural Object ClassObjects whose object class is of the type “structural” can be stored in the directory. e.g., person, organizatioalPerson, inetOrgPerson

Some server implementations use structural classes to define where in the directory information tree a certain object can be stored.You cannot have more than one structural objectClass in your schema.

53

Auxiliary Object ClassThis is for situations when you need a new object class extending from an existing one.You can define all the data the new object needs to hold together in an auxiliary class.An object of type “auxiliary” can be attached anywhere in the directory information tree. An example is the subschema object, which

holds the schema for the directory server, i.e., object-class definitions, attribute-type definitions, matching rules, etc.

54

Example of Auxiliary Object ClassdcObject – stands for “domain component object”.Used to describe objects having DN being similar to DNS like domain names.It has the attribute “dc”, which stands for “domain component”.This dcObject class can be used to implement an organization object with DN: dc=tyict,dc=vtc,dc=edu,dc=hk

55

More example – Auxiliary Object

Class 1. You cannot use objectClass o, because this

cbjectClass does not allow the attribute dc.2. The objectClass dcObject,on the other hand, does

not allow the attribute o or description.Solution: Mix the two; auxiliary object class allows

mixing.DN: dc=ldapabc,dc=orgobjectclass: topobjectclass: dcObjectobjectclass: odc: ldapabcdc: orgo: ABC’s of LDAPdescription: Organization promoting LDAPl: Munich

56

Object Identifiers (O.I.D.)Object identifiers are not only used for object classes, but also for attribute types.It is not only used for LDAP and X.500, but also for other protocols such as SNMP.The namespace of all OIDs implements an OID tree. A subtree in the OID tree is an arc

OID 2.5.6.6. stands for object class person 2.16.840.1.113730.3.2.2 for object class inetOrgPerson

You need an OID subtree whenever you need to extend the directory schema – you can get your OID subtree from IANA (Internet Assigned Numbers Authority)

All attributes and objects defined by IETF begin with 2.5.4, e.g. 2.5.4.0 for attribute “object-Class.”

You can invent your own OIDs.