Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented.

Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented and Communicated < +44 (0)

Welcome to Class Welcome to ... Integration and LDAP
While waiting for the class to begin … Please fill out your tent card Class will begin at ...

Class Audience Consultants, systems engineers, and other technical personnel responsible for designing and implementing directory services using Best suited to those with Heterogeneous OS knowledge and good Networking knowledge You don’t have to be an LDAP expert SN This course is for consultants, systems engineers, and other technical personnel responsible for designing and implementing directory services using Netscape Directory Server 3.0. This course focuses on the analysis and planning phase of deploying a directory service. IN DN

Class Objectives Document Directory Data Requirements
Develop a Directory Schema Design a Directory Tree Hierarchy Create Directory Access Control Rules Select Indexes to Support Your Design Demonstrate Directory Service Interoperability

Facility Information Please listen carefully while your instructor gives you important information about the training facility: Emergency Exits and First Aid Where to go for breaks and lunch Restrooms Telephones Other important facts

Introductions Who are you ? Where are you from ? What do you do ?
What do you know ? What do you want from the class ?

LDAP Module Objectives
Upon completion of this module, you should be able to: Describe the role of directory services Describe LDAP, the underlying protocol used in directory service implementation Use LDAP client applications to access directory service data

What is a directory ? A centralised structured repository of configuration, authentication and other network and system related information. A system optimised for lookup based applications It is not a database It doesn’t have Relationship It isn’t Transactional It has poor modification performance

The Role of Directory Services
Facilitate integrated application design Store two data types User and application data Application configuration data Provide high performance query capabilities Uses platform independent technologies (LDAP)

Current Situation Users Process Administrators Systems Days / Weeks

The Digital Persona of Tomorrow

Desired Architecture Users Systems LDAP-Based Directory Real-Time

Application Configuration Data
Application settings Physical location of application components Version information for application components Application’s object definitions Allows applications to query the directory for configuration information

Application Integration
LDAPServer Client File Server IIS Server SQL Server Samba PDC NT Domain SMB HTTP LDAP LDAP (ASP) SQL (ASP) SMTP Server SMTP POP / IMAP Server POP / IMAP

Why does it Work ? LDAP Common Schema between Applications
Common known Directory Information Tree (DIT) Directory Enabled Networking Common Encryption (I wish )

Coffee --1 A quick 10 minute Break

Integration The How and the Why of it

Why does it Work ? LDAP Common Schema between Applications
Common known Directory Information Tree (DIT) Directory Enabled Networking Common Encryption (I wish )

How ? Build Install LDAP Server Install pam_ldap Install nss_ldap
Build Install Samba 2.2.2 Client Windows Servers into Domain Drink Beer

Build OpenLDAP OpenLDAP #./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --libexecdir=/usr/sbin --mandir=/usr/share/man --with-subdir=ldap --enable-wrappers --without-cyrus-sasl #make #make install Configure /etc/ldap/slapd.conf include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/samba.schema # RUN Stuff pidfile /var/run/slapd.pid argsfile /var/run/slapd.args database ldbm suffix "dc=fluff,dc=org“ rootdn "cn=Directory Manager,dc=fluff,dc=org“ rootpw xxxxxx directory /var/openldap-ldbm ## Access Control Restrictions access to attr=userPassword by self write by anonymous read by * none access to * by self write by anonymous read by users read

Make it work Design a Schema Find out which apps require what
Design a Tree (DIT) See where control is in your organisation Populate the LDAP server #/etc/init.d/slapd stop #rm -f /var/openldap-ldbm/* #/etc/init.d/slapd start #cd /etc/ldap #ldapadd -D "cn=Directory_Manager,dc=fluff,dc=org" w xxxx -f base.ldif

LDAP Tree

Configure LDAP Configure /etc/ldap/ldap.conf BASE dc=levenshulme,dc=fluff,dc=org host ldap_version 2 port 389 pam_member_attribute uniquemember pam_login_attribute uid pam_password crypt nss_base_passwd ou=People,dc=levenshulme,dc=fluff,dc=org?one nss_base_shadow ou=People,dc=levenshulme,dc=fluff,dc=org?one nss_base_group ou=Groups,dc=levenshulme,dc=fluff,dc=org?one Find the other ldap.conf’s and point here #rm /etc/ldap.conf #ln –s /etc/ldap/ldap.conf /etc/ldap.conf

Why PAM and NSS ? Traditional Services (telnet/ftp etc) authenticate via PAM Traditional C programs do name searches via NSS gethostbyxxxx getpwent, getpwnam getpw (well everywhere but Microsoft) They do ADSI (sometimes !)

Configure PAM Plug-able Authentication Modules
Build PAM ftp://ftp.padl.com/pub/pam_ldap-124.tgz #tar -zxvf pam_ldap-124.tgz #./configure #make #make install Edit /etc/pam.d/files e.g. login auth required /lib/security/pam_securetty.so debug auth required /lib/security/pam_nologin.so debug auth sufficient /lib/security/pam_ldap.so debug auth required /lib/security/pam_unix_auth.so account sufficient /lib/security/pam_ldap.so debug session required /lib/security/pam_unix_session.so Or ssh auth required /lib/security/pam_nologin.so auth sufficient /lib/security/pam_ldap.so auth required /lib/security/pam_unix_auth.so try_first_pass account sufficient /lib/security/pam_ldap.so account required /lib/security/pam_unix_acct.so #password required /lib/security/pam_cracklib.so #password sufficient /lib/security/pam_ldap.so #password required /lib/security/pam_pwdb.so use_first_pass session required /lib/security/pam_unix_session.so watts:/etc/pam.d# more ftp #%PAM-1.0 auth required /lib/security/pam_listfile.so item=user sense=deny file= /etc/ftpusers onerr=succeed auth required /lib/security/pam_shells.so auth sufficient /lib/security/pam_ldap.so auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so #session sufficient /lib/security/pam_ldap.so session required /lib/security/pam_pwdb.so watts:/etc/pam.d#

Configure NSS Name Services Libraries
Build libnss #ftp://ftp.padl.com/pub/libnss-172.tgz #./configure --enable-rfc2307bis #make #make install Configure /etc/nsswitch.conf passwd: files ldap group: files ldap hosts: files dns ldap services: files ldap [NOTFOUND=return] files networks: files ldap [NOTFOUND=return] files protocols: files ldap [NOTFOUND=return] files rpc: files ldap [NOTFOUND=return] files ethers: files ldap [NOTFOUND=return] files # no support for netmasks, bootparams, publickey yet. netmasks: files bootparams: files publickey: files automount: files

Why Samba PDC ? Scalability of File and Print Services
Integration with NetAtalk (Mac services) Source (fix the features) Performance Cost !

Samba Through put

Response time

Configure Samba 2.2.2 Build Samba #./configure --sysconfdir=/etc/samba --with-privatedir=/etc/samba with-lockdir=/var/state/samba --localstatedir=/var with-syslog --with-utmp --withreadline --with-sambabook with-ldapsam --with-msdfs --with-acl-support #make #make install Configure samba /etc/samba/smb.conf [global] workgroup = levenshulme domain logons = yes domain admin group unix password sync = yes passwd program = /etc/samba/passwdsync %u passwd chat = *OLD* %o\n *NEW* %n\n *AGAIN* %n\n *changed* passwd chat debug = true encrypt passwords = yes guest account = nobody status = yes os level = domain master = yes security = user log level = log file = /var/log/samba/%m.log logon drive = U: ldap admin dn = "cn=Directory Manager,dc=fluff,dc=org“ ldap filter = "(&(uid=%u)(objectclass=sambaAccount))“ ldap suffix = "ou=people,dc=levenshulme,dc=fluff,dc=org“ [homes] comment = Home Directories read only = no public = no writeable = yes smbpasswd –w xxxxxx

Samba as PDC Grouping across platforms hold true
Single Sign-on into the Microsoft Environment Login to Windows Logs into SQL Server/Exchange Password kept in sync with other OS’s and tools

NDS Integration Possibilities
Novell NetWare 5.0 NDS Replica Apple MacOS Solaris 2.6 PAM NSS Directory Service Novell NetWare 5.0 NDS Master Windows Workstation Novell NetWare 5.0 NDS Replica

Apache Apache 1.3.2 mod_auth_ldap mod_ssl

JumpStart and PXe Jumpstart (autobuild of Solaris Hosts)
PXe (Jumpstart for Intel) Extensions to DHCP and DEN systems Possible to build systems automatically based on the roles stored within LDAP PXe can build Linux & Windows (bpbatch + easyInternet)

Why Bother ? Infrastructure that just works
Ubiquity of configuration information Rich personalisation Users want to set their screen colours ! Universal access not just people but also Applications Single Point of Control We want to Drink BEER !

Coffee --2 A quick 10 minute Break

LDAP Background LDAP - Lightweight Directory Access Protocol
Protocol for providing directory services over TCP/IP Described in RFC 1823 LDAP is a standard, extensible directory access protocol Allows client and server software from many different vendors to interoperate Is lightweight, efficient, straightforward, easy to implement Uses a simplified set of encoding methods and runs directly on top of TCP/IP APIs include C APIs, Java APIs and PerLDAP

Databases vs. Directories
Conventional Databases Directory Services Characteristic SQL Yes No Read / Write ratio 1 / 1 1000 / 1 Common Access Protocol Transaction Oriented

Directory Structure - Entries
An entry is a collection of attribute/value pairs User Attributes Application Attributes attribute value attribute value uid es26336 uidNumber 26336 sn Sutcliffe primaryGroupID 1793 cn Edmund defaultdomain fluff.org Manchester l sambahome /export/home

Directory Structure – Data Tree
Suffix Entries are arranged in a hierarchical tree-like structure Entries are identified by a unique distinguished name (DN) dn:dc=fluff,dc=org DN dc fluff.org ou Groups ou People Administrators Staff Martin Edmund DN dn:uid=es26336,ou=People,dc=fluff,dc=org

Typical Directory Entry
dn: uid=es26336,ou=People,dc=fluff,dc=org cn: Edmund Sutcliffe sn: Sutcliffe givenname: Edmund objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: People l: Manchester uid: es26336 mail: telephonenumber: RDN Distinguished Name organizationalPerson requires objectclass, sn, cn allows description, streetaddress, telephonenumber, pagernumber, mail, title, etc...

Schema and Objectclasses
Attributes Object Classes objectclass aci cn sn telephonenumber description top person uid mailhost mailquota organizationalperson l street postalcode st .

Objectclass Inheritance
top objectclass (req) aci person (top) (person) objectclass cn (req) sn (req) description organizationalperson o ou givenname title employeenumber

Topology How should the directory contents be designed?
How should the directory be deployed in the physical infrastructure?

Directory Replication
Replication is the mechanism that… Copies information between Directory Servers so that the same information exists on several different physical servers Allows a master server to hold a master copy of the information and automatically copy updates to all replicas

Directory Referrals A Directory Referral is a … Redirection mechanism
An alternate LDAP address given back to a client requesting information Types of referrals… Suffix Replication Clients have to handle this !

What Is LDIF? LDAP Directory Interchange Format
dn: dc=fluff,dc=org objectclass: top objectclass: domain dc: fluff dn: ou=People, dc=fluff,dc=org objectclass: organizationalunit ou: People dn: uid=es26336, ou=People, dc=fluff,dc=org objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson cn: Edmund Sutcliffe sn: Sutcliffe givenname: Edmund ou: Staff uid: es26336 LDAP Directory Interchange Format ASCII representation of directory entries Uses in Directory Server configuration data import/export operations Backup files schema files Command-line utilities ldapsearch, ldapmodify, etc. Space = ? ?

Search Criteria based Allows the client to specify
Where to begin searching in the directory tree How much of the tree to search Which attribute values to return The pattern to match

Using LDAP URLs ldap[s]:// <hostname>:<port> / <base_dn> ? <attributes> ? <scope> ? <filter> Request for Comments: DRAFT Obsoletes: RFC 2255 Tim Howes Loudcloud Inc Mark Smith, Netscape Communications Corp. 21 February 2001ldapurl = scheme "://" [hostport] ["/" [dn ["?" [attributes] ["?" [scope] ["?" [filter] ["?" extensions]]]]]] scheme = "ldap" hostport = <hostport from Section of RFC 2396 [RFC2396]> dn = <distinguishedName from Section 3 of [RFC2253]> attributes = attrdesc *("," attrdesc) attrdesc = <AttributeDescription from Section of [RFC2251]> / "*" scope = "base" / "one" / "sub" filter = <filter from Section 4 of [RFC2254]> extensions = extension *("," extension) extension = ["!"] extype ["=" exvalue] extype = token / xtoken exvalue = <LDAPString from section of [RFC2251]> token = <oid from section 4.1 of [RFC2252]> xtoken = "x-" token ldap://ldap.fluff.org:389/dc=fluff,dc=org?telephoneNumber?sub?(cn=Ed*) base :== where to start attributes :== what is shown scope : == base| one | sub filter :== (|(filter)(filter)) | (&(filter)(filter)) etc

Command Line Tools

ldapdelete ldapdelete “cn=DeleteMe,dc=fluff,dc=org” -D “cn=Directory Manager,dc=fluff,dc=org” -w xxxxxxx -h ldap -p 389

ldapmodify ldapmodify –b –r –f/tmp/entrymod
dn:cn=modifyme,dc=fluff,dc=org changetype: modify replace: mail mail: add: title title: Grand Poobah delete: description add: jpegPhoto jpegPhoto: /tmp/modme.jpg

Exercises Perform an LDAP URL Search
Perform and LDAP Command Line Search Dump LDAP Command line search into LDIF Add an entry for yourself into the LDIF Using Directory Manager add new LDIF

Coffee –3 Lunch LUNCH Back by 1:00pm

Schema Module Objectives
Upon completion of this module, you should be able to: Determine definitive sources of data Understand and extend LDAP Schema

Identify Directory Data & Users
Perform a Directory Data Requirements Perform a Directory Applications Analysis Data Store 1 Data Store 2 . Data Store x Application 1 Application 2 Application n Directory dB(s)

Review Directory Data Requirements
What Kinds of Data Belong in a Directory? What Should Not Go Into the Directory? Examples of Directory Data

What Belongs Data that is read often and written infrequently
Data that can be expressed in attribute form Data useful for more than one audience Data accessed from more than one physical location

What Doesn’t Data that changes frequently
Large unstructured chunks of data designed for file systems, FTP servers, web servers, or relational databases

Examples of Directory Data
Contact information for people, places, or things (telephone numbers, addresses, , etc.) Descriptive information (employee number, job title, manager, etc.) Device information (printer type, location, speed, color, etc.) Contact and billing information for Extranets Software application configuration preferences User preferences for applications Resource locations, such as pointers to web servers, FTP servers, and file system locations

Perform a Directory Applications Analysis
What directory applications and tools do you currently have deployed, and who uses them? What LDAP directory- enabled applications will you deploy, and who will use them? How will these applications be used? What other iPlanet Servers are you planning to deploy? Application 1 Application 2 . Application n Directory dB(s)

Directory Enabled Applications
Samba sambaAccount sambaGroup Messaging Systems Sendmail/Exim ListServe Exchange Posix(Unix) Login posixAccount posixGroup Web Servers Apache Zeus Netscape/iPlanet Application Servers Oracle iAS Windows Services IIS SQL Server

Perform a Directory Data Stores Analysis
Where does current directory data exist in your environment? What applications and tools do you have to support your current directory data? What applications, tools, and processes need to change if the data is accessed using LDAP? Data Store 1 Data Store 2 . Data Store x Directory dB(s)

Exercise: Identify Directory Data Stores
Application 1 Application 2 . Application n Data Store 1 Data Store 2 . Data Store x Directory dB(s)

Glasgow examples Admin Unix/username Exchange Username NDS Username
CS Username Radius uses CS Username 50% have static hardwired password !! Admin Ingress Common password Student Record System, Delphi (Personnel Payroll), Advisors Online, Agresso (Finance system) Reference Manager System Bibliographic Database (RAE) Senate Papers Department Systems Modification of Central NDS Unix system (Physics has NT DOMAIN) NT Domains Desktop Support Team WinTERM Domain HelpDesk Authentication System and associated NT DOMAIN Contract record hangs people off it….. And this record is tied to department And so the pay cost department…but this doesn’t match to departmental memberships Problems of recording line management--- in department(s) 21% of Personal records are without good NI numbers.. It will match to fee records related people… honouree So pay costs map to department.

Document Directory Application Fields
App x ooo What are the required fields for all of the identified LDAP directory applications? What is the purpose of each field and how is it formatted? Are there any additional fields that can be viewed by special users? Are there any hidden fields? Is there a vendor supplied schema? Directory Application Fields Sample Values Description Directory Application Fields Sample Values Description field 1 field 2 field x sample 1 sample 2 sample x description 1 description 2 description x Vendor Schema attribute 1 attribute 2 attribute x field 1 sample 1 description 1 Directory Application Fields Sample Values Description field 2 sample 2 description 2 field 1 sample 1 description 1 field x sample x description x field 2 sample 2 description 2 field x sample x description x

Examples of Documenting Application Fields
Directory Server Gateway Communicator Address Book Conference Room Locator NetMeeting (RTPerson class) Sendmail (mail attribute)

Document Directory Data Store
What directory information exists for each identified data store? What is the purpose of each field and how is it formatted? Is there a vendor supplied schema? Directory Application Fields Sample Values Description field 1 field 2 field x sample 1 sample 2 sample x description 1 description 2 description x Vendor Schema attribute 1 attribute 2 attribute x Data Store Data Store 1 Store 2 Store X ooo

Examples of Documenting Data Store Fields
HR Database NT Facilities PBX System Access Control System (Badging) Excel Spreadsheet with Departmental Contacts Admin Spreadsheets

HR Database

NT, Facilities, and PBX

Glasgow Attributes Room Allocation (Standardisation) Phone Number
User-id Multiple users of a single user-id Data Protection Act Difficulties with Multiple use Stamp out shared usernames… POLICY STATEMENT Password Yellow Sticky Issue !!! Authorization Per app, Per Department, Per Position The problem of temps accruing permissions.. Departmental Privileges Right to have access to Chemicals/animal experimentations

Tips As you develop your plan, share information about goals and milestones with everyone involved Actively use the milestones to track progress toward your goals Through advertising what you hope to accomplish and your schedule, you secure the aid of others and set expectations for the deployment process

Coffee --4

Develop Directory Schema
App 1 App 2 App n Fields Directory Server Schema Object Class Default Object Classes Custom Object Classes OID ----- Attribute Syntax ------ Dir S1 S2 Sn AS Identifier MV Change Notes During schema design, you select and define the object classes and attributes used to represent the entries stored by Directory Server. It is best to use existing schema elements defined in the standard schema provided with Directory Server. Choosing standard schema elements helps ensure compatibility with directory-enabled applications. In addition, as the schema is based on a standard, you are assured it has been reviewed and agreed to by a wide number of directory users.

Develop a Directory Schema
Review the Default Schema Match Directory Application Fields Match Directory Data Store Fields Extend the Schema Identify Authoritative Sources Identify Processes and Procedures Upon completion of this module, you will be able to do the following: Review the default schema. Review all of the default schema files for iPlanet Directory Server 5.x before matching the application fields to the default schema. Match directory application fields to the default iPlanet Directory Server 5.x schema. Match the application fields identified in the previous module to the appropriate object classes and attributes found in the default schema shipped with iPlanet Directory Server 5.x. [+]Match directory Data Store Fields. Match the identified schema attributes to appropriate fields in the various enterprise data stores. Extend the schema to include custom object classes and attributes. Extend the default schema by creating your own object classes and attributes for the unmatched application fields and unmatched data source fields. [+]Identify Authoritative Sources. For each directory attribute, identify which data source is the authoritative source for that attribute. [+]Identify Processes and Procedures. For each attribute, identify any processes or procedures that need to modified or added to insure directory data accuracy.

Review the Default Schema
Directory Server Schema Object Class Default Object Classes Custom Object Classes OID ----- Attribute Syntax ------ Review a Typical Directory Entry Review Object Classes and Attributes Review Object Class Inheritance Review Default iPlanet Directory Server Schema Your directory schema maintain the integrity of the data stored in your directory by imposing constraints on the size, range, and format of data values. You decide what types of entries your directory contains (people, devices, organizations, and so forth) and the attributes available to each entry. The pre-defined schema included with Directory Server contains both the standard LDAP schema as well as additional application-specific schema to support the features of the server. While this schema meets most directory requirements, you may need to extend it with new object classes and attributes to accommodate the unique requirements of your directory.

Typical Directory Entry
dn: uid=es26336,ou=People,dc=fluff,dc=org cn: Edmund Sutcliffe sn: Sutcliffe givenname: Edmund objectclass: top objectclass: person objectclass: organizationalPerson objectclass: inetOrgPerson ou: People l: Manchester uid: es26336 mail: telephonenumber: This is a sample directory entry taken from the file Siroe.ldif, which is shipped with iPlanet Directory Server 5.x. The first entry is the distinguished name. This entry uniquely identifies the entry in the directory database and where it is located in the directory hierarchy. This directory uses the uid attribute in the distinguished name to uniquely identify the entry. The left- most part of the distinguished name is known as the Relative Distinguished Name (RDN). The cn (common name), sn (surname) and givenname attributes describe the entry in more detail. The objectclass attributes define the rules for the entry. An object class is a special attribute type called objectclass that basically defines which attributes are mandatory and which are optional for a specific entry. The objectclass attribute also establishes the entry type based on its given value. In the example above, you can tell this entry is a person by looking at the values given for the objectclass attributes (objectclass:person, objectclass:organizationalPerson, etc.). The top object class defines the first rule for the entry. This rule states that the entry must use the attribute objectclass. This is a self-defining rule and is needed to maintain schema consistency. The person object class defines the second set of rules for the entry. This rule states that you must define the attributes cn (common name) and sn (surname). These rules also allow a small list of optional attributes. The organizationalPerson object class further defines the rules set forth in the person object class. This object class inherits all of the rules from the person object class and defines additional attributes that are optional. The inetOrgPerson object class is similar in that it further defines the rules set forth by the person and organizationalPerson object classes. The first three object classes are defined by X.500, and the fourth is an extension developed by iPlanet to define a person on the Internet. [+] This was necessary in order to include attributes required for an Internet person, like address, not part of the existing standard. The inetOrgPerson object class is currently documented in an Internet RFC 2578 document dated April This is an “informational” RFC, rather than a standard. The remaining attributes in the example describe the entry in more detail. [+] [IN] Most vendors and third party developers are adhering to the use of “inetOrgPerson”, even if it is only “informational”. Microsoft Active Directory does NOT currently support “inetOrgPerson”, but replaces it with a new object class named “user”. Microsoft has already stated that they will support “inetOrgPerson” in their next OS release (codename Whistler). RDN Distinguished Name organizationalPerson requires objectclass, sn, cn allows description, streetaddress, telephonenumber, pagernumber, mail, title, etc...

Schema and Objectclasses
Attributes Object Classes objectclass aci cn sn telephonenumber description top person uid mailhost mailquota organizationalperson l street postalcode st .

Objectclass Inheritance
top objectclass (req) aci person (top) (person) objectclass cn (req) sn (req) description organizationalperson o ou givenname title employeenumber

Review the Default iPlanet Directory Server Schema
<server-root>/slapd-<instance>/config/schema/ 00core.ldif 05rfc2247.ldif 05rfc2927.ldif 10rfc2307.ldif 20subscriber.ldif 25java-object.ldif 28pilot.ldif 30ns-common.ldif 50ns-admin.ldif 50ns-calendar.ldif 50ns-certificate.ldif 50ns-compass.ldif 50ns-delegated-admin.ldif 50ns-directory.ldif 50ns-legacy.ldif 50ns-mail.ldif 50ns-mcd-browser.ldif 50ns-mcd-config.ldif 50ns-mcd-li.ldif 50ns-mcd-mail.ldif 50ns-media.ldif 50ns-mlm.ldif 50ns-msg.ldif 50ns-netshare.ldif 50ns-news.ldif 50ns-proxy.ldif 50ns-value.ldif 50ns-wcal.ldif 50ns-web.ldif 99user.ldif The Directory Server schema is defined by a series of LDIF files found in the subdirectory: <Directory Server instance Root>/config/schema LDIF files are read in numerical and then alphabetic order. Schema can be re-defined by putting a new definition in a file that is loaded after the original definition. 00core.ldif: Recommended core schema from the X.500 and LDAP standards (RFCs), and schema used by the Directory Server itself. 05rfc2247.ldif: Schema from RFC 2247 and related pilot schema- "Using Domains in LDAP/X.500 Distinguished Names" 05rfc2927.ldif: Schema from RFC "MIME Directory Profile for LDAP Schema" 10rfc2307.ldif: Schema from RFC "An Approach for Using LDAP as a Network Information Service" 20subscriber.ldif: Common schema elements for iPlanet-Nortel subscriber interoperability 25java-object.ldif: Schema from RFC "Schema for Representing Java(tm) Objects in an LDAP Directory" 28pilot.ldif: Schema from the pilot RFCs, especially RFC 1274, that is no longer recommended by iPlanet for use in new deployments. Please be aware that future RFCs that succeed RFC 1274 may deprecate some or all of these attribute types and classes. 30ns-common.ldif: Common iPlanet schema. 50ns-admin.ldif: Schema used by iPlanet Administration Services 50ns-calendar.ldif: iPlanet Calendar Server schema. 50ns-certificate.ldif: Schema for iPlanet Certificate Management System 50ns-compass.ldif: Schema for the iPlanet Compass Server 50ns-delegated-admin.ldif: Schema for iPlanet Delegated Administrator 4.5 50ns-directory.ldif: Additional schema used by iPlanet Directory Server 5.x 50ns-legacy.ldif: Legacy iPlanet Schema 50ns-mail.ldif: Schema for iPlanet Messaging Server 50ns-mcd-browser.ldif: Schema for iPlanet Mission Control Desktop - Browser 50ns-mcd-config.ldif: Schema for iPlanet Mission Control Desktop - Configuration 50ns-mcd-li.ldif: Schema for iPlanet Mission Control Desktop - Location Independence 50ns-mcd-mail.ldif: Schema for iPlanet Mission Control Desktop - Mail 50ns-media.ldif: Schema for iPlanet Media Server 50ns-mlm.ldif: Schema for iPlanet Mailing List Manager 50ns-msg.ldif: Schema for iPlanet Web Mail 50ns-netshare.ldif: Schema for iPlanet Netshare 50ns-news.ldif: Schema for iPlanet Collabra Server 50ns-proxy.ldif: Schema for iPlanet Proxy Server 50ns-value.ldif: iPlanet servers "value item" schema 50ns-wcal.ldif: Schema for iPlanet Web Calendaring 50ns-web.ldif: Schema for iPlanet Web Server 99user.ldif: Site specific schema [IN] Show the students all the files stored in the ./schema directory.

Schema Entries in LDIF Typical schema attribute definition
attributeTypes: ( NAME ( 'sn' 'surName' ) DESC 'Standard LDAP attribute type' SUP name X-ORIGIN 'RFC 2256' ) attributeTypes:( NAME ‘telephoneNumber' DESC 'Standard LDAP attribute type' SYNTAX X-ORIGIN 'RFC 2256' ) Typical schema object class definition objectClasses: ( NAME 'person' DESC 'Standard LDAP objectclass' SUP top MUST ( sn $ cn ) MAY ( description $ seeAlso $ telephoneNumber $ userPassword ) X-ORIGIN 'RFC 2256' ) Directory Server bases its schema format on version 3 of the LDAP protocol (LDAPv3). This protocol requires directory servers to publish their schemas through LDAP itself, allowing directory client applications to programmatically retrieve the schema and adapt their behavior based on it. The global set of schema for Directory Server can be found in the entry named cn=schema. The Directory Server schema differs slightly from the LDAPv3 schema, as it adds its own proprietary object classes and attributes. In addition, it uses a private field in the schema entries called X-ORIGIN, which describes where the schema entry was defined originally. For example, if a schema entry is defined in the standard LDAPv3 schema, the X-ORIGIN field refers to RFC If the entry is proprietary to Directory Server, the X-ORIGIN field contains the value iPlanet Directory Server. For example, the standard person object class appears in the schema as shown in the above slide. This schema entry states the object identifier (OID) for the class ( ), the name of the object class (person), a description of the class (standard person), then lists the required (MUST) and allowed (MAY) attribute types. For more information about the LDAPv3 schema format, refer to Section 6 of the LDAPv3 Attribute Syntax Definitions document (RFC2252).

OID Numbers Object IDentifier numbers uniquely identify objects globally Each new Object Class and Attribute must be assigned a unique OID Default is based on object name followed by the characters -oid fluffPerson-oid (Object Class) TShirtSize-oid (Attribute) Option is to maintain a unique OID registry for your organization

Attribute SYNTAX SYNTAX key word defines the type of data an attribute can store Each new attribute must be assigned a SYNTAX number SYNTAX SUP name (derived from this other AttributeType) RFC 2252 defines attribute syntax Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions

Attribute Syntax Types
bin < > Binary ces < > IA5String cis < > DirectoryString dn < > DN int < > INTEGER tel < > TelephoneNumber OctetString Boolean GeneralizedTime Country Name Postal Address

Sample 99user.ldif File dn: cn=schema objectClass: top
objectClass: ldapSubentry objectClass: subschema cn: schema aci: ... ... objectClasses: ( siroePerson-oid NAME 'siroePerson' SUP inetorgperson STRUCTURAL MAY TShirtSize X-ORIGIN 'user defined' ) attributeTypes: ( TShirtSize-oid NAME 'TShirtSize' SYNTAX SINGLE-VALUE X-ORIGIN 'user defined' )

Default Directory Server Operation
Schema Checking Default=On Checks if proper attributes are present Required values for objectclass Allowed attributes for objectclass Replication Schema changes made on a replica master are recorded in the changelog During replication, changes are replicated Do NOT modify the schema on a read-only replica Schema Checking Schema checking ensures that all new or modified directory entries conform to the schema rules. When the rules are violated, the directory rejects the requested change. Note: Schema checking only checks that the proper attributes are present. It does not verify whether attribute values are in the correct syntax for the attribute. By default, the directory enables schema checking. We do not recommend turning it off. With schema checking on, you must be attentive to required and allowed attributes as defined by the object classes. Object class definitions usually contain at least one required attribute, and one or more optional attributes. Optional attributes are attributes that you are allowed, but not required, to add to the directory entry. If you attempt to add an attribute to an entry that is neither required nor allowed according to the entry's object class definition, then Directory Server returns an object class violation. For example, if you define an entry to use the organizationalPerson object class, then the commonName (cn) and surname (sn) attributes are required for the entry (you must specify values for these attributes when you create the entry). In addition, there is a fsiroely long list of attributes that you can optionally use on the entry. This list includes such descriptive attributes as telephoneNumber, uid, streetAddress, and userPassword.

Match Directory Application Fields
Application 2 Application n Directory Matrix Directory Applications App 2 App n Directory Server Schema Object Class Attribute Default Object Classes So upon completion of this section, you have matched fields required by your directory application with attributes from the default schema. Identify the Type of Object Select a Similar Object Class Select a Similar Attribute Transfer Application Field to Matrix List Unmatched Application Fields

Identify the Type of Object
Conference Room Objects Person For each application field in your matrix, ask the following question: “What type of object does this application field describe?” Ask this question in context to the directory applications that apply. This will limit the number of objects you identify. For example, if the application field is Phone Number, ask “What type of object or objects does this application field describe?” You might also ask “Is this a valid object in the directory that clients will need to access?” It may turn out that the application field describes various objects. In this example, the Phone Number attribute describes a person’s telephone number and a conference room’s telephone number. Both of these are valid objects that clients would expect to find in the directory. What type of object does this field describe?

Transfer Application Field to Matrix
Transfer the application field name and authoritative source information from the original matrix to the new matrix that contains the default schema. Note that the new matrix contains the most commonly used object classes and attributes from the default schema and not the entire default schema. Please see the configuration files and documentation for a complete list. Transfer Application Field

Unmatched Application Fields
Address Book Phone Book Building Number* Floor Number* Capacity* Directory Applications EMT* The final step in matching application fields to the default schema is to create a list of all the unmatched application fields. These will be used as input to a later step when we “Extend the Schema”. Unmatched Fields Building Number Floor Number Capacity EMT List unmatched application fields

Match Directory Data Store Fields
Directory Server Schema Object Class Default Object Classes Attribute Dir Sample Description S1 S2 Sn Upon completion of this section, you have documented in the S1 thru Sn columns on the directory matrix all data fields from other data sources that are required by your directory application. They have also been matched up with the appropriate schema attribute. Identify the Type of Object Select a Similar Object Class Select a Similar Attribute Transfer Field to Matrix List Unmatched Data Store Fields

Exercises Review the Default Schema /etc/ldap/schema
Match Directory Application Fields Match Directory Data Store Fields In Exercises 2 and 3, you identified the directory application fields and authoritative information sources in a simpler version of the above matrix. Now you can match your application fields to the default schema using the process explained in the previous pages: identify what type of object or objects each application field in your original data matrix describes use the documentation to find a similar object class and attribute in the default schema transfer the application field and authoritative source to the new matrix that contains the default schema for iPlanet Directory Server 5.x create a list of the unmatched application fields Note that for application fields that describe multiple objects, you simply transfer the application field and authoritative source multiple times.

Coffee --5 Quick 10 Minutes

Extend the Schema Group Unmatched Fields into Objects
Unmatched Application Fields Building Number Floor Number Capacity EMT Directory Server Schema Object Class Custom Object Classes Attribute Custom Attributes Unmatched Data Store Attributes Building_Number Floor_Number Group Unmatched Fields into Objects Select Similar Attributes or Create New Ones Create New Object Class and Attribute Names Transfer New Definitions to Matrix Define Attribute and Object Class Rules While trying to match application fields to the default schema, you will probably find that you cannot find a match for all of your application fields. You should now have a list of application fields that do not have matching object classes and/or attributes in the default schema. Use the following guidelines to help you extend the default schema: Group unmatched application fields into objects. The first step is to group all of the unmatched application fields into objects. You may find, as before, that an attribute can be used in multiple objects. Select similar attributes or create new ones. Try to use standard attributes if possible. Search the default attributes for a similar attribute and use that attribute in a new object class or create a new attribute if a match is not found. Create new object class names for your new objects. Give each new object an object class name. Create new attribute names for your application fields. Give each application field an attribute name. Define attribute and object class rules. Define the data type of each new attribute and what attributes are required and allowed for each new object class. Document the purpose and use of each custom attribute and object class. Document the purpose and use of each new attribute and object class for your enterprise. Use iPlanet Console to extend the schema. Use either iPlanet Console to create your new attributes and object classes, or manually edit the schema user files. Note that iPlanet does not recommend changing or extending the default schema directly, even though you could manually edit the default schema files. You risk losing these changes each time you upgrade and losing interoperability with other servers in the future if the default schema changes between releases. Also, the default schema is read-only via LDAP.

Group Unmatched Fields in Objects
Building Number Floor Number Capacity EMT What type of object does it describe? Are there standard attributes? Person (inetOrgPerson) Conference Room (top) Name Phone Number Description cn telephoneNumber description buildingName Application Field Default Schema Attribute Is the object an extension of a standard object class? For each unmatched application field, identify what type of object or objects the attribute describes. You can do this by asking, “what type of object does this application field describe?” Create a two-column table for each object you identify and label the table with the type of object. The object or objects you identify should be real to your directory applications and your directory tree. Copy the application field to the first column of each table. Do the same for all of the remaining application fields. Group them into the appropriate objects or create new objects if necessary. The next step is to determine whether the new object is an extension of a standard object class in the default schema or a new object class. If the new object is simply an extension of an existing object class, then write the name of the standard object class in brackets next to the object name. If the new object is not an extension of an existing object class, then write the name top in brackets next to the object name. The final step is to identify any standard attributes that belong to the new object. This will probably be the case for new objects that are not an extension of an existing object class. Remember that when you define entries in your directory tree, you need to specify what object class or object classes the entry supports. You want to include the attributes in the object class that you will need for your entry. In the new object table, specify in the first column the name of the application field, and in the second column, the name of the standard attribute. Use the following flow to explain the diagram; remember that this is a bit of a review of what they just did in the last Exercise. What type of object does it describe? Take the first application field, Building Number, and ask students what type of object it describes. The answer really depends on your directory applications and the directory objects you want to store in the server. For example, the attribute describes what building a person is located in and also describes what building a conference room is located in. These should be real objects in the tree that are used by real directory applications. In this example, a phone book application displays the building number for a person, and a conference room locator application displays the building number for a conference room. Note that the phone book could also display conference room information. Is the object an extension of a standard object class? Is this object simply an extension of a standard object class in the default schema that didn’t have a matching attribute, or is this a completely new type of object? For example, Building Number describes a person, but the person object class and related object classes do not have a matching attribute. In this case, you want to extend the people-related object classes. Normally you make inetOrgPerson the superior object class. Are there standard attributes associated with this object? Usually on new objects, you want to use whatever standard attributes are available to describe that object and then add your custom attributes to that object. Emphasize that you want to search for standard attributes first before going off and creating your own custom attributes. For example, when you create a conference room object in the directory, you not only want to tell what building number it is, but the telephone number, etc. All these are standard attributes.

Select Similar Attributes or Create New Ones
Identify the type of object Select a similar object class You will probably find that some application fields have a matching object class in the default schema but no matching attribute within the desired object class. In this case, you want to search the unrelated object classes for a similar attribute. If a similar attribute does not exist in the entire schema, you need to extend the schema. For example, the Building Number application field describes a person. The person object class and related object classes do not contain a similar attribute. If you search the unrelated object classes, you will find that one object class called pilotOrganization contains an attribute called buildingName. The description of the attribute describes exactly what you want. In this case, you would extend the schema by creating a new object class and using the buildingName attribute to match the application field. Note that you would not use the pilotOrganization object class within a person entry, since this object class is not related to the actual object. Technically it would work, but if an application were searching for pilotOrganization, it would return people objects. You will find that some application fields have no matching object class in the default schema but have a matching attribute in an unrelated object class. In this case, you want to extend the schema by creating a new object class with the standard attribute as part of the definition. Last, some application fields have no matching object class or attribute in the default schema. In this case, you want to extend the schema by creating a new object class with a new attribute. Even though there may not be a matching attribute within a desired object class, you should still search the remaining object classes and attributes to see if you can find a similar attribute in a unrelated object class. You still extend the schema, but you use standard attributes in your new object classes. Select a similar attribute? Person Conference Room

Create New Object Class Names
fluffPerson (inetorgPerson) Unmatched Fields Create new object class names that avoid present and future name conflicts Building Number Floor Number buildingName Application Field Default Schema Attribute EMT Building Number Floor Number Capacity EMT Once you have defined your new objects, you need to name them. Try to select a name that will not cause conflicts with any existing name or names that might be added to the default schema in the future. Most companies tend to use their company name followed by a descriptive name for the object. The Person and Conference Room titles are changed to siroeChocPerson and siroeChocConfRoom. Note that the administration interface does not allow you to modify the standard schema. fluffConfRoom (top) Application Field Default Schema Attribute Building Number buildingName Floor Number Capacity Name cn Phone Number telephoneNumber Description description

Create New Attribute Names
fluffPerson (inetorgPerson) Unmatched Fields Building Number Floor Number Capacity EMT Application Field Default & New Schema Attribute Building Number buildingName Floor Number fluffBuildFloor EMT fluffEMT At this time you can also create names for your new attributes. Most companies use their company name followed by a descriptive name to name attributes. This avoids potential naming conflicts when the default schema is expanded. This slide should be a bit more obvious. The attribute names are given for the new or custom attributes. fluffConfRoom (top) Application Field Default & New Schema Attribute Building Number buildingName Floor Number fluffBuildFloor Create new attribute names that avoid present and future name conflicts Capacity fluffConfRoomCapacity Name cn Phone Number telephoneNumber Description description

Define Attribute and Object Class Rules
Define attribute types DirectoryString, IA5String, DN, binary, INTEGER, and TelephoneNumber Single or Multi-value Define object class rules Inheritance Required attributes Allowed attributes Obtain OID Numbers X.500 compatibility You can define the rules for the new object classes and attributes in the matrix by following a convention of using italics for attributes that are allowed and normal type for attributes that are required. The name in brackets indicates the superior object class. Finally, you can include the data type in brackets next to each custom attribute. This makes it easier when you go to actually extend the schema in the server. This might be a little more difficult if you are writing this by hand. Emphasize that this is just a way of documenting the rules for the new object classes and attributes in the matrix so that when students go to physically extend the schema, they have all the data they need in the matrix. Students can use whatever method they like. The goal is to somehow identify the rules. You should also be prepared to answer questions about the data types. See the documentation for further details.

Identify Authoritative Sources
What Data Store is the authoritative source for each attribute? App 1 App 2 App n Directory Server Schema Dir Dir Dir AS Identifier S1 MV S2 Sn Change App 1 App 2 App n S1 S2 Sn Upon completion of this section, you have documented in the Authoritative Source column on the directory matrix which data source is the authoritative data source for all data fields required by your directory application. Fields Fields Fields Object Class OID Attribute OID Syntax Fields Fields Fields Notes Default Object Classes ----- ----- ------ Custom Object Classes ----- ----- ------

Examples of Authoritative Sources
Human Resources system: Name, Address Phone switch: Phone Number, Cube Number Facilities systems: Building, Floor, Access Other directories (NT, NIS) Other Application servers (such as Certificate): Certificates published The Directory itself (attributes not available anywhere else or not shared by other systems for legal reasons): Home Phone Number [+]Individual pieces of information may be store in multiple data stores.For example, an employee’s phone number may already exist in the HR, Security, and Phone System(PBX) databases. However, in a well-defined environment, a single data element is mastered in one data source and then distributed from that master source. In our example, the phone number is set in the Phone System (so that called will actually be routed to that phone) and then distributed to the HR and Security databases. The key is determining for data element which is its master source. Specific systems vary from company to company. But you can use the above list as a tickler to help when you’re reviewing customer applications. Once you identify the specific sources, you also have to determine how to get the information into Directory Server. For some of the information, this is a one-time migration; for other information you have to identify – and probably create – processes to import information regularly. [IN] Make sure students understand that the Directory Server can be the authoritative source for some information. This includes attributes that do not exist in any other systems or that replace information in systems that will be discontinued once the Directory is implemented (for example, the old phone book or the admin spreadsheets). In some cases the information may exist in other places, such as Home Phone Number in the HR system, but may not be used as an authoritative source for legal reasons or potential liability. For example, the company may not publish home phone numbers because of the potential of an employee being stalked, but they may give the employees the option of publishing their own home numbers. The Directory could be used as the authoritative source.

Data Ownership Who makes sure data is up-to-date?
Individuals accessing their own record Managers accessing subordinate records Role or Group (rather than individuals) for other accesses Data ownership refers to the person or organization responsible for making sure the data is up-to-date. As you plan your data management, decide who can write data to the directory. Some common strategies for deciding data ownership follow: - Allow read-only access to the directory for everyone except a small group of directory content managers. - Allow individual users to manage some strategic subset of information for themselves. This subset of information might include their passwords, descriptive information about themselves and their role within the organization, their automobile license plate number, and contact information such as telephone numbers or office numbers. - Allow a person's manager to write to some strategic subset of that person's information, such as contact information or job title. - Allow an organization's administrator to create and manage entries for that organization. This approach makes your organization's administrators your directory content managers. - Create roles that give groups of people read or write access privileges. For example, you might create roles for human resources, finance, or accounting. Allow each of these roles to have read access, write access, or both to the data needed by the group, such as salary information, government identification number (in the US, social security number), and home phone numbers and address. For more information about roles and grouping entries, refer to the “Directory Tree” chapter. As you determine who can write to the data, you may find that multiple individuals need to have write access to the same information. For example, you will want an information systems (IS) or directory management group to have write access to employee passwords. You may also want the employee themselves to have write access to their own passwords. While it is generally necessary to allow multiple people to have write access to the same information, try to keep this group small and easily identifiable. Doing so helps ensure your data's integrity.

Identify Processes and Procedures
Processes that need to change to accommodate directory design Now that HomePhoneNumber is displayed, who will maintain data accuracy? Does current contractor process need to be changed? Identify Correct level of authority Who owns the information Change Notes You may find that processes need to change to accommodate the directory design. This is one of the most difficult parts of the deployment. Many people may not see the reason for a change or may not have the resources available to make the necessary changes. You will find conflicts of interest and different needs in different organizations. This often involves negotiation, give-and-take, and executive level mandates. Critical tasks include identifying individuals with the correct level of authority to make changes and determining who will create the new directory entities, this is, who owns the information. DepartmentalPhone Book to be phased out.

Exercises Identify Processes and Procedures
Identify Authoritative Sources Extend the Schema

Tips Defining a good schema is as much art as science, and the more of it you do, the easier the process becomes. In general, good principles to follow include: Reuse existing elements as much as possible Define several smaller auxiliary object classes to mix needed attributes into existing objects. Minimize the number of mandatory attribute types within your object classes Do not define more than one object class or attribute type to hold the same kind of information When in doubt, keep it simple

Coffee –6

Directory Tree Design Everyone has different views of the organization
Network Administrators “Everyone in a domain” “Everyone in a subnet” Administration “Everyone in a cost-accounting group” Facilities “Everyone in this building” Telecom “Everyone on a particular switch”

DIT Design: People By Department
c=UK o=glasgow ou=Life ou=CS ou=Engineering ou=Admin ou=Estates cn=I Brunel

DIT Design: Types of People
c=UK o=glasgow ou=Staff ou=Contractors ou=Student ou=PostGrad cn=James Currall

DIT Design: By Location
c=UK o=glasgow l=Watts Bld l=Oakfield Ave l=Library l=Admin Bld l=Gallery cn=D Montgomery

DIT Design: Deep Tree By Department
dc=com dc=Acme ou=People l=North America l=Asia l=Europe l=New York l=Dallas l=Los Angeles l=Japan l=Singapore l=Manchester l=Munich l=Paris cn=Mike Smith

An Example DIT dc=com o=Acme ou=People ou=Groups ou=Locations ou=Apps
ou=Systems ou=Schema cn =SmithET cn=Directory User site=TX-SD cn =AikmanTA cn=Mail Admin site=TX-RI cn =SandersDJ cn=Medical Admin site=SW-BK cn = GonzalesJ cn=Medical User site=NY-AA cn =ModanoMW ou=Web Sites ou=Medical ou=Resumes

DIT Design: Deep -vs- Flat Trees
Can result in long Distinguished Names (DN) May reflect your actual corporate structure Can result in administrative problems if your organization is constantly changing Better chance of having unique names within a subtree Works well if you want to distribute the data across multiple Directory Servers

DIT Design: Flat -vs- Deep Trees
No need to categorize people Short Distinguished Names, easy to type DIT is very stable: not affected by organizational changes, and easy to administer Higher chance of name collisions Not well suited for Browsing Can result in longer load times or startup times, depending on the Directory Product you use

DIT Design: Selecting a Distinguished Name
+ DN Guaranteed to be unique + DN Never Changes + More robust searching using name components dc=UK dc=Glasgow - Browser shows useless information - Microsoft and Netscape mail clients expected a real name in the commonName (cn) field. ou=People cn = givenName = Michael nickname = Mike surname = Smith cn= , ou=People, dc=Glasgow, dc=UK

+ DN Guaranteed to be unique + DN Never Changes + More robust searching using name components - Browser shows useless information dc=UK dc=Glasgow + commonName (cn) field contains a real name to work well with other LDAP applications. ou=People uid = cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid= , ou=People, dc=Glasgow, dc=UK

+ DN Guaranteed to be unique + More robust searching using name components + commonName (cn) field contains a real name dc=UK dc=Glasgow + Browser shows more useful information (although not as ideal as a full name) + Directly maps to a user’s logon ID (can be used for single sign-on) ou=People - DN has the potential to change if the name or UID changes - Entrust product requires the commonName (cn) to be part of the DN. uid = smithmj cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid=smithmj, ou=People, dc=Glasgow, dc=UK

+ DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single signon) + commonName (cn) field contains a real name + commonName (cn) is part of the DN - DN has the potential to change dc=UK dc=Glasgow ou=People - Very artificial way of achieving uniqueness - Complicated DN syntax - More complicated Directory Logon procedures - This syntax may not be accepted as standard in the future. cn = Mike Smith + uid = smithmj givenName = Michael nickname = Mike surname = Smith cn=Mike Smith + uid=smithmj, ou=People, dc=Glasgow, dc=UK

dc=UK + DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single sign-on) + commonName (cn) field contains a real name + commonName (cn) is part of the DN - DN has the potential to change dc=Glasgow ou=People - Data is duplicated in several areas (uid and cn) - Value displayed for commonName may vary. cn = smithmj cn = Mike Smith givenName = Michael nickname = Mike surname = Smith uid = smithmj cn=smithmj, ou=People, dc=Glasgow,dc=UK

+ DN Guaranteed to be unique + More robust searching using name components + Directly maps to a user’s logon ID (can be used for single sign-on) + commonName (cn) field contains a real name + commonName (cn) is part of the DN dc=UK dc=Glasgow ou=People ou=Certificates - DN has the potential to change - Problems with X.500 aliases: - no built-in referential integrity uid = smithmj cn = Mike Smith givenName = Michael nickname = Mike surname = Smith cn = smithmj ALIAS POINTER cn=smithmj, ou=People, dc=Glasgow, dc=UK uid=smithmj, ou=Certificates, dc=Glasgow,dc=UK

DIT Design: DIT Naming Proposal (rfc2377)
The dc named attribute stands for domain component The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) dc=com dc=acme Naming Plan for Internet Directory-Enabled Applications

The dc named attribute stands for domain component The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) dc=com dc=acme Lower levels of the tree will also use the dc named attribute dc=Corporate dc=Customers

The dc named attribute stands for domain component The idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com) Lower levels of the tree will also use the dc named attribute dc=com dc=acme dc=Corporate dc=DalSite Each user is identified with the uid named attribute containing the address. uid = cn = Mike Smith givenName = Michael surname = Smith uid = cn = Jane Doe givenName = Jane surname = Doe

Carrots and Sticks Robust DIT Naming and design standards are not in place yet There is currently no single “right way” to design your DIT that applies to everyone Take into consideration your organization the organizational structure the organization’s tendency to change the organization’s current size and potential to grow Take into consideration the how you want to use the directory what information will be stored in the directory who will own what data and how will be be mastered what what other systems in the infrastructure will be using/storing the data how and what applications will be accessing the data

Conclusions " If you think technology can solve your problems, then you don't understand the problems and you don't understand the technology. " Bruce Schneier The Directory, to be useful, needs to become part of the Business Process and the repository of the highest quality and timely information. Remember that you are doing it FOR not TO the organisation.

Coffee –6

Security Technologies
Successful e-business is highly dependent on security Security services provide: Confidentiality Integrity Authentication Non-Repudiation Access-Control Remember…CIANA

Security Threats Information disclosure Integrity violation
Assumed identities/Masquerading Denial of service Generic Threats: Backdoors, Trojans, Insider Attacks, Viruses

Home Security Analogy Systems Security is like home security
Policy Definition You choose who and what can be done in your home Access control and passwords are the keys Window and door locks keep out intruders Log files and monitoring script A security camera watches open doors Try to make your environment less inviting to those looking for easy pickings

In the absence of a formal policy, the policy is…
A policy is a set of instructions that determine an organization’s view of security A policy sets the limits of acceptable behavior and outlines responses to violations A policy always exists In the absence of a formal policy, the policy is… Anything goes!

Security Implementations
Two key implementations of security are: SSL S/MIME Each is implemented at different layers SSL Network Layer(IP) Application Layer Non-secure Secure communication S/MIME

SSL as a Security Solution
SSL ensures safe and secure client-server transactions Provides authentication, privacy, and message integrity Data going over the network is point-to-point encrypted SSLv3.1 approved by IETF, called Transport Layer Security SSL Network Layer (TCP/IP) Application Layer Secure communication

SSL Server Authentication
Client initiates contact via https “Here’s my certificate” Public Key included 1. Generate secret key 2. Encrypt secret key with Server’s public key Validate Server certificate SSL established Transmitt data using session keys Client Server “I’d like to talk SSL” Decrypt secret key using private key Use secret key to make session keys

SSL With Client Authentication
“Here’s my certificate. Where’s yours?” Public Key included 1. Generate secret key 2. Encrypt secret key with Server’s public key 3. Send encrypted key and Client certificate Validate Server certificate Server validates Client certificate and decrypts SSL established Client Server Client initiates contact via https “I’d like to talk SSL” Transmitt data using session keys

Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented.

Similar presentations

Presentation on theme: "Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented.

Similar presentations

Presentation on theme: "Integration and LDAP Consistent Sign-on and Directory Enabled Networking An LDAP Master Class Edmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented."— Presentation transcript:

Similar presentations

About project

Feedback