• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Open Source
 

Open Source

on

  • 869 views

 

Statistics

Views

Total Views
869
Views on SlideShare
869
Embed Views
0

Actions

Likes
0
Downloads
29
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Open Source Open Source Presentation Transcript

      • Open Source
      • Lightweight Directory
      • Access Protocol
    • 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
    • Centralised Authentication - Linux
      • Linux provides a shared networked alternative to /etc/passwd files. Options are
      • NIS
      • OpenLDAP
      • Samba
      • Kerberos
    • 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)
    • 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
    • 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
    • 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
    • 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
    • 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.
    • 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
    • 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
    • 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.
    • 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.
    • 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 .
    • 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).
    • 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.
    • Figure 1. Integration of applications & infrastructure with LDAP
    • LDAP Data Organization
      • Action in LDAP takes place around a data structure known as an entry.
      • Figure 2. The LDAP entry data structure
    • 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.
    • 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).
    • 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.
    • 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.
    • 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 .
    • 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.
    • 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
    • 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).
    • 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: 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
    • Figure 4. Person and part records with DNs in an LDAP directory that integrates with the DNS namespace Example to illustrate DN usage
      • 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=com
      • Notice 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.
    • 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;
      • 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.
      • base DN derived from Internet presence: o=ldap_abc.org
        • This format uses the company’s Internet domain name as the base
      • 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
    • 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: [email_address]
      • Mobile: (0049) 89 671 293
    • 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.
    • 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 ”:
          • o=ldap_abc.de
        • The individual departments, called “ organizationalUnit ” abbreviated with “ ou ”:
          • ou=IT,o=ldap_abc.de
          • ou=HR,o=ldap_abc.de
        • 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.
    • 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.
    • 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.
    • 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: “ 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.
    • 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
      • )
      • )
    • 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
          • )
          • )
    • 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
          • )
          • )
    • 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
          • )
          • )
    • 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
          • )
          • )
    • 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 .
    • organizationalUnit Object Class
    • domain Object Class
    • person, organizationalPerson and inetOrgPerson objectClasses
    • posixAccount (above) Auxiliary object class posixGroup (below) Structural object class
    • shadowAccount Object Class
    • 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 .
    • 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 .
    • 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.
    • 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.
    • 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.
    • 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.
    • 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: dc=tyict,dc=vtc,dc=edu,dc=hk
    • 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: dc=ldapabc,dc=org
      • objectclass: top
      • objectclass: dcObject
      • objectclass: o
      • dc: ldapabc
      • dc: org
      • o: ABC’s of LDAP
      • description: Organization promoting LDAP
      • l: Munich
    • 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.