Open Source

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 possible
• Authentication is a major concern to provide
  users the keys to get on the network services
  running on different O/S
• Older 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 authentication
• Unix/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 are
• NIS
• OpenLDAP
• Samba
• Kerberos

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 machine
• NIS is not hierarchical there is not efficient
  way to examine for instance only the users in the
  marketing department
• NIS has difficulties working through a firewall
• Subject to many network security problems
• NIS 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 clients
• Hierarchical potentially a better choice than
  NIS when a large number of accounts is involved
• Much 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
  Controller
• Samba 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 logons
• Kerberos 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 keys
• OpenLDAP uses the Sleepycat Berkeley DB
• It is not a good choice when you need fast,
  frequent changes - for a retail backend, for
  example
• Its structure is very different from a relational
  database
• Data are stored in attribute type/attribute value
  pairs
• New 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 off
• A 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 Systems

• Directories 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
  RFCs 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 Directories

• Companies 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
  elses
• 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 Organization

• Action 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
  employees 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
LDAPs 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
  LDAPs 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. cnJay 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 cnRobert 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,
  cnRobert SmithlBoston
• 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 persons email address so
  the RDN would be uidrsmith.

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
  directorys base DN.
• The servers 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 entrys 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, well construct DNs for
  each highlighted entry.

25
In the left pane of Figure 3, our DN would be
cnRobert Smith,lmain campus,ouCCS,oHogwarts
School,cUSIn the right pane of Figure 3, it
is uidrsmith,ousystems,oupeople,dcccs,dcho
gwarts,dcedu

• 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 Man
• 20 Tsing Yi Road
• Tsing Yi, NT
• HK
• 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 RDN

• The 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 unambiguously
• DN must be unique throughout the whole directory
• RDN has to be unique only in its scope. For
  example, if the parent is
• DN ousales, lEurope, oldap_abc.org
• under this subtree there can be only one RDN
• uidusr1
• resulting in the DN
• DN uidurs1,ousales,lEurope,oldap_abc.org
  
• This means that you can have an entry with an RDN
  of uidusr1 under lAsia, resulting in the unique
  DN
• DN uidusr1,ousales,lAsia,oldap_abc.org

28
Example to illustrate DN usage
Figure 4. Person and part records with DNs in an
LDAP directory that integrates with the DNS
namespace
29

• The name of the root of the directory is known as
  the directorys base DN (e.g. dcmycompany,dccom)
  .
• The DN of the person entry shown in Figure 4
  could have been
• cnBrian Arkills,ouPeople,dcmycompany,dccom
  instead of uidbarkills,ouPeople,dcmycompany,dc
  com
• Notice that each RDN component includes both the
  attribute type and value. For example, the
  single component cnBrian 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 ouPeople to qualify as an RDN.
• Since uniqueness of a persons name is not
  guaranteed, so another attribute is often used
  instead as the RDN. E.g. user identity
  uidbarkills is chosen because login IDs must be
  unique.
• The DN uidbarkills,ouPeople,dcmycompany,dccom
  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 ousales,lEurope,oldap_abc.de
• base DN takes one of the three forms
  listed below
• base DN in X.500 format oldap_abc,cde
• oldap_abc refers to the organization i.e.,
  company name and cde indicates that the company
  headquarters is in Germany.
• With Internet globalization, using a country code
  in the base DN makes things more confusing.
• base DN derived from Internet presence
  oldap_abc.org
• This format uses the companys Internet domain
  name as the base
• base DN derived from domain components
  dcldap_abc,dcorg
• 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
  dcldap_abc,dcorg
• If ldap_abc.org merges with ldap_xyz.org, you
  simply think of dcorg as the base DN and new
  records can be placed into your existing
  directory under dcldap_xyz,dcorg

31
Example - Content of a directory exported to a
LDIF file

• dn oldap_abc.de
• objectclass top
• objectclass organization
• o ldap_abc.de
• l Munich
• dn ouIT, oldap_abc.de
• objectclass top
• objectclass organizationalUnit
• ou IT
• description Information Technologies
• dn ouHR, oldap_abc.de
• objectclass top
• objectclass organizationalUnit
• ou HR
• description Human Resources

• dn uidSParker, ouHR, oldap_abc.de
• objectclass top
• objectclass person
• objectclass organizationalPerson
• objectclass inetOrgPerson
• ou HR
• cn Sarah Parker
• sn Parker
• givenName Sarah
• uid SParker
• mail SarahParker_at_ldap_abc.de
• Mobile [phone]

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 Objects

• To summarize, we have three different types of
  objects. Each representing a different object
  class
• The whole organization is identified by an o
• oldap_abc.de
• The individual departments, called
  organizationalUnit abbreviated with ou
• ouIT,oldap_abc.de
• ouHR,oldap_abc.de
• The entry for a single person, called
  inetOrgPerson is identified as follows
• uidSParker,ouHR,oldap_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 objectclassuser
  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 Definitions

• The 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
  oldap_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 preferredDeliveryMet
  hod telexNumber teletexTerminal Identifier
  telephoneNumber internationaliSDNNumber
  facsimileTelephoneNumber street postOfficeBox
  postalCode postalAddress physicalDeliveryOff
  iceName 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 Definitions

• In 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 Categories

• Three 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 Class

• Not 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 Class

• Objects 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 Class

• This 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 Class

• dcObject 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 dctyict,dcvtc,dced
  u,dchk

55
More example Auxiliary Object Class

• You cannot use objectClass o, because this
  cbjectClass does not allow the attribute dc.
• 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 dcldapabc,dcorg
• objectclass top
• objectclass dcObject
• objectclass o
• dc ldapabc
• dc org
• o ABCs of LDAP
• description Organization promoting LDAP
• l 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.