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:
1 Integration and LDAPConsistent Sign-on and Directory Enabled Networking An LDAP Master ClassEdmund J. Sutcliffe Thoughtful Solutions; Creatively Implemented and Communicated< +44 (0)
2 Welcome to Class Welcome to ... Integration and LDAP While waiting for the class to begin …Please fill out your tent cardClass will begin at ...
3 Class AudienceConsultants, systems engineers, and other technical personnel responsible for designing and implementing directory services usingBest suited to those with Heterogeneous OS knowledge and good Networking knowledgeYou don’t have to be an LDAP expertSNThis 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.INDN
4 Class Objectives Document Directory Data Requirements Develop a Directory SchemaDesign a Directory Tree HierarchyCreate Directory Access Control RulesSelect Indexes to Support Your DesignDemonstrate Directory Service Interoperability
5 Facility InformationPlease listen carefully while your instructor gives you important information about the training facility:Emergency Exits and First AidWhere to go for breaks and lunchRestroomsTelephonesOther important facts
6 Introductions Who are you ? Where are you from ? What do you do ? What do you know ?What do you want from the class ?
7 LDAP Module Objectives Upon completion of this module, you should be able to:Describe the role of directory servicesDescribe LDAP, the underlying protocol used in directory service implementationUse LDAP client applications to access directory service data
8 What is a directory ?A centralised structured repository of configuration, authentication and other network and system related information.A system optimised for lookup based applicationsIt is not a databaseIt doesn’t have RelationshipIt isn’t TransactionalIt has poor modification performance
9 The Role of Directory Services Facilitate integrated application designStore two data typesUser and application dataApplication configuration dataProvide high performance query capabilitiesUses platform independent technologies (LDAP)
10 Current SituationUsersProcessAdministratorsSystemsDays / Weeks
13 Application Configuration Data Application settingsPhysical location of application componentsVersion information for application componentsApplication’s object definitionsAllows applications to query the directory for configuration information
18 Why does it Work ? LDAP Common Schema between Applications Common known Directory Information Tree (DIT)Directory Enabled NetworkingCommon Encryption (I wish )
19 How ? Build Install LDAP Server Install pam_ldap Install nss_ldap Build Install Samba 2.2.2Client Windows Servers into DomainDrink Beer
20 Build OpenLDAPOpenLDAP #./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc --libexecdir=/usr/sbin --mandir=/usr/share/man --with-subdir=ldap --enable-wrappers --without-cyrus-sasl #make #make installConfigure /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
21 Make it work Design a Schema Find out which apps require what Design a Tree (DIT)See where control is in your organisationPopulate 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
23 Configure LDAPConfigure /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?oneFind the other ldap.conf’s and point here #rm /etc/ldap.conf #ln –s /etc/ldap/ldap.conf /etc/ldap.conf
24 Why PAM and NSS ?Traditional Services (telnet/ftp etc) authenticate via PAMTraditional C programs do name searches via NSS gethostbyxxxx getpwent, getpwnam getpw(well everywhere but Microsoft) They do ADSI (sometimes !)
34 JumpStart and PXe Jumpstart (autobuild of Solaris Hosts) PXe (Jumpstart for Intel)Extensions to DHCP andDEN systemsPossible to build systems automatically based on the roles stored within LDAPPXe can build Linux & Windows (bpbatch + easyInternet)
35 Why Bother ? Infrastructure that just works Ubiquity of configuration informationRich personalisation Users want to set their screen colours !Universal access not just people but also ApplicationsSingle Point of ControlWe want to Drink BEER !
37 LDAP Background LDAP - Lightweight Directory Access Protocol Protocol for providing directory services over TCP/IPDescribed in RFC 1823LDAP is a standard, extensible directory access protocolAllows client and server software from many different vendors to interoperateIs lightweight, efficient, straightforward, easy to implementUses a simplified set of encoding methods and runs directly on top of TCP/IPAPIs include C APIs, Java APIs and PerLDAP
39 Directory Structure - Entries An entry is a collection of attribute/value pairsUser AttributesApplication Attributesattributevalueattributevalueuides26336uidNumber26336snSutcliffeprimaryGroupID1793cnEdmunddefaultdomainfluff.orgManchesterlsambahome/export/home
40 Directory Structure – Data Tree SuffixEntries are arranged in a hierarchical tree-like structureEntries are identified by a unique distinguished name (DN)dn:dc=fluff,dc=orgDNdcfluff.orgouGroupsouPeopleAdministratorsStaffMartinEdmundDNdn:uid=es26336,ou=People,dc=fluff,dc=org
44 Topology How should the directory contents be designed? How should the directory be deployed in the physical infrastructure?
45 Directory Replication Replication is the mechanism that…Copies information between Directory Servers so that the same information exists on several different physical serversAllows a master server to hold a master copy of the information and automatically copy updates to all replicas
46 Directory Referrals A Directory Referral is a … Redirection mechanism An alternate LDAP address given back to a client requesting informationTypes of referrals…SuffixReplicationClients have to handle this !
47 What Is LDIF? LDAP Directory Interchange Format dn: dc=fluff,dc=orgobjectclass: topobjectclass: domaindc: fluffdn: ou=People, dc=fluff,dc=orgobjectclass: organizationalunitou: Peopledn: uid=es26336, ou=People,dc=fluff,dc=orgobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersoncn: Edmund Sutcliffesn: Sutcliffegivenname: Edmundou: Staffuid: es26336LDAP Directory Interchange FormatASCII representation of directory entriesUses in Directory Serverconfiguration dataimport/export operationsBackup filesschema filesCommand-line utilitiesldapsearch, ldapmodify, etc.Space = ??
48 Search Criteria based Allows the client to specify Where to begin searching in the directory treeHow much of the tree to searchWhich attribute values to returnThe pattern to match
49 Using LDAP URLsldap[s]:// <hostname>:<port> / <base_dn> ? <attributes> ? <scope> ? <filter>Request for Comments: DRAFTObsoletes: RFC 2255Tim Howes Loudcloud IncMark 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 / xtokenexvalue = <LDAPString from section of [RFC2251]>token = <oid from section 4.1 of [RFC2252]>xtoken = "x-" tokenldap://ldap.fluff.org:389/dc=fluff,dc=org?telephoneNumber?sub?(cn=Ed*)base :== where to startattributes :== what is shownscope : == base| one | subfilter :== (|(filter)(filter)) | (&(filter)(filter)) etc
55 Schema Module Objectives Upon completion of this module, you should be able to:Determine definitive sources of dataUnderstand and extend LDAP Schema
56 Identify Directory Data & Users Perform a Directory Data RequirementsPerform a Directory Applications AnalysisData Store 1Data Store 2.Data Store xApplication 1Application 2Application nDirectorydB(s)
57 Review Directory Data Requirements What Kinds of Data Belong in a Directory?What Should Not Go Into the Directory?Examples of Directory Data
58 What Belongs Data that is read often and written infrequently Data that can be expressed in attribute formData useful for more than one audienceData accessed from more than one physical location
59 What Doesn’t Data that changes frequently Large unstructured chunks of data designed for file systems, FTP servers, web servers, or relational databases
60 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 ExtranetsSoftware application configuration preferencesUser preferences for applicationsResource locations, such as pointers to web servers, FTP servers, and file system locations
61 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 1Application 2.Application nDirectorydB(s)
63 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 1Data Store 2.Data Store xDirectorydB(s)
64 Exercise: Identify Directory Data Stores Application 1Application 2.Application nData Store 1Data Store 2.Data Store xDirectorydB(s)
65 Glasgow examples Admin Unix/username Exchange Username NDS Username CS UsernameRadius uses CS Username 50% have static hardwired password !!Admin IngressCommon password Student Record System, Delphi (Personnel Payroll), Advisors Online, Agresso (Finance system)Reference Manager System Bibliographic Database (RAE)Senate PapersDepartment SystemsModification of Central NDSUnix system (Physics has NT DOMAIN)NT DomainsDesktop Support Team WinTERM DomainHelpDesk Authentication System and associated NT DOMAINContract record hangs people off it….. And this record is tied to departmentAnd so the pay cost department…but this doesn’t match to departmental membershipsProblems of recording line management--- in department(s)21% of Personal records are without good NI numbers..It will match to fee records related people… honoureeSo pay costs map to department.
66 Document Directory Application Fields App xoooWhat 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?DirectoryApplicationFieldsSampleValuesDescriptionDirectoryApplicationFieldsSampleValuesDescriptionfield 1field 2field xsample 1sample 2sample xdescription 1description 2description xVendorSchemaattribute 1attribute 2attribute xfield 1sample 1description 1DirectoryApplicationFieldsSampleValuesDescriptionfield 2sample 2description 2field 1sample 1description 1field xsample xdescription xfield 2sample 2description 2field xsample xdescription x
67 Examples of Documenting Application Fields Directory Server GatewayCommunicator Address BookConference Room LocatorNetMeeting (RTPerson class)Sendmail (mail attribute)
68 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?DirectoryApplicationFieldsSampleValuesDescriptionfield 1field 2field xsample 1sample 2sample xdescription 1description 2description xVendorSchemaattribute 1attribute 2attribute xData StoreDataStore 1Store 2Store Xooo
69 Examples of Documenting Data Store Fields HR DatabaseNTFacilitiesPBX SystemAccess Control System (Badging)Excel Spreadsheet with Departmental ContactsAdmin Spreadsheets
72 Glasgow Attributes Room Allocation (Standardisation) Phone Number User-idMultiple users of a single user-idData Protection Act Difficulties with Multiple useStamp out shared usernames… POLICY STATEMENTPasswordYellow Sticky Issue !!!AuthorizationPer app, Per Department, Per PositionThe problem of temps accruing permissions..Departmental PrivilegesRight to have access to Chemicals/animal experimentations
73 TipsAs you develop your plan, share information about goals and milestones with everyone involvedActively use the milestones to track progress toward your goalsThrough advertising what you hope to accomplish and your schedule, you secure the aid of others and set expectations for the deployment process
75 Develop Directory Schema App 1App 2App nFieldsDirectory Server SchemaObjectClassDefault Object ClassesCustom Object ClassesOID-----AttributeSyntax------DirS1S2SnASIdentifierMVChangeNotesDuring 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.
76 Develop a Directory Schema Review the Default SchemaMatch Directory Application FieldsMatch Directory Data Store FieldsExtend the SchemaIdentify Authoritative SourcesIdentify Processes and ProceduresUpon 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.
77 Review the Default Schema Directory Server SchemaObjectClassDefault Object ClassesCustom Object ClassesOID-----AttributeSyntax------Review a Typical Directory EntryReview Object Classes and AttributesReview Object Class InheritanceReview Default iPlanet Directory Server SchemaYour 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.
78 Typical Directory Entry dn: uid=es26336,ou=People,dc=fluff,dc=orgcn: Edmund Sutcliffesn: Sutcliffegivenname: Edmundobjectclass: topobjectclass: personobjectclass: organizationalPersonobjectclass: inetOrgPersonou: Peoplel: Manchesteruid: es26336mail: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).RDNDistinguished NameorganizationalPersonrequires objectclass, sn, cnallowsdescription, streetaddress, telephonenumber, pagernumber,mail, title, etc...
79 Schema and Objectclasses AttributesObject Classesobjectclassacicnsntelephonenumberdescriptiontoppersonuidmailhostmailquotaorganizationalpersonlstreetpostalcodest.
81 Review the Default iPlanet Directory Server Schema <server-root>/slapd-<instance>/config/schema/00core.ldif05rfc2247.ldif05rfc2927.ldif10rfc2307.ldif20subscriber.ldif25java-object.ldif28pilot.ldif30ns-common.ldif50ns-admin.ldif50ns-calendar.ldif50ns-certificate.ldif50ns-compass.ldif50ns-delegated-admin.ldif50ns-directory.ldif50ns-legacy.ldif50ns-mail.ldif50ns-mcd-browser.ldif50ns-mcd-config.ldif50ns-mcd-li.ldif50ns-mcd-mail.ldif50ns-media.ldif50ns-mlm.ldif50ns-msg.ldif50ns-netshare.ldif50ns-news.ldif50ns-proxy.ldif50ns-value.ldif50ns-wcal.ldif50ns-web.ldif99user.ldifThe Directory Server schema is defined by a series of LDIF files found in the subdirectory:<Directory Server instance Root>/config/schemaLDIF 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 interoperability25java-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 Services50ns-calendar.ldif: iPlanet Calendar Server schema.50ns-certificate.ldif: Schema for iPlanet Certificate Management System50ns-compass.ldif: Schema for the iPlanet Compass Server50ns-delegated-admin.ldif: Schema for iPlanet Delegated Administrator 4.550ns-directory.ldif: Additional schema used by iPlanet Directory Server 5.x50ns-legacy.ldif: Legacy iPlanet Schema50ns-mail.ldif: Schema for iPlanet Messaging Server50ns-mcd-browser.ldif: Schema for iPlanet Mission Control Desktop - Browser50ns-mcd-config.ldif: Schema for iPlanet Mission Control Desktop - Configuration50ns-mcd-li.ldif: Schema for iPlanet Mission Control Desktop - Location Independence50ns-mcd-mail.ldif: Schema for iPlanet Mission Control Desktop - Mail50ns-media.ldif: Schema for iPlanet Media Server50ns-mlm.ldif: Schema for iPlanet Mailing List Manager50ns-msg.ldif: Schema for iPlanet Web Mail50ns-netshare.ldif: Schema for iPlanet Netshare50ns-news.ldif: Schema for iPlanet Collabra Server50ns-proxy.ldif: Schema for iPlanet Proxy Server50ns-value.ldif: iPlanet servers "value item" schema50ns-wcal.ldif: Schema for iPlanet Web Calendaring50ns-web.ldif: Schema for iPlanet Web Server99user.ldif: Site specific schema[IN] Show the students all the files stored in the ./schema directory.
82 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 definitionobjectClasses: ( 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).
83 OID NumbersObject IDentifier numbers uniquely identify objects globallyEach new Object Class and Attribute must be assigned a unique OIDDefault is based on object name followed by the characters -oidfluffPerson-oid (Object Class)TShirtSize-oid (Attribute)Option is to maintain a unique OID registry for your organization
84 Attribute SYNTAXSYNTAX key word defines the type of data an attribute can storeEach new attribute must be assigned a SYNTAX numberSYNTAXSUP name (derived from this other AttributeType)RFC 2252 defines attribute syntaxLightweight Directory Access Protocol (v3): Attribute Syntax Definitions
86 Sample 99user.ldif File dn: cn=schema objectClass: top objectClass: ldapSubentryobjectClass: subschemacn: schemaaci: ......objectClasses: ( siroePerson-oid NAME 'siroePerson' SUPinetorgperson STRUCTURAL MAY TShirtSize X-ORIGIN 'userdefined' )attributeTypes: ( TShirtSize-oid NAME 'TShirtSize' SYNTAXSINGLE-VALUE X-ORIGIN'user defined' )
87 Default Directory Server Operation Schema CheckingDefault=OnChecks if proper attributes are presentRequired values for objectclassAllowed attributes for objectclassReplicationSchema changes made on a replica master are recorded in the changelogDuring replication, changes are replicatedDo NOT modify the schema on a read-only replicaSchema CheckingSchema 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.
88 Match Directory Application Fields Application 2Application nDirectory MatrixDirectory ApplicationsApp 2App nDirectory Server SchemaObject ClassAttributeDefault Object ClassesSo upon completion of this section, you have matched fields required by your directory application with attributes from the default schema.Identify the Type of ObjectSelect a Similar Object ClassSelect a Similar AttributeTransfer Application Field to MatrixList Unmatched Application Fields
89 Identify the Type of Object Conference RoomObjectsPersonFor 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 objectdoes this field describe?
90 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
91 Unmatched Application Fields Address BookPhoneBookBuilding Number*Floor Number*Capacity*Directory ApplicationsEMT*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 FieldsBuilding NumberFloor NumberCapacityEMTList unmatched application fields
92 Match Directory Data Store Fields Directory Server SchemaObject ClassDefault Object ClassesAttributeDirSampleDescriptionS1S2SnUpon 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 ObjectSelect a Similar Object ClassSelect a Similar AttributeTransfer Field to MatrixList Unmatched Data Store Fields
93 Exercises Review the Default Schema /etc/ldap/schema Match Directory Application FieldsMatch Directory Data Store FieldsIn 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 describesuse the documentation to find a similar object class and attribute in the default schematransfer the application field and authoritative source to the new matrix that contains the default schema for iPlanet Directory Server 5.xcreate a list of the unmatched application fieldsNote that for application fields that describe multiple objects, you simply transfer the application field and authoritative source multiple times.
95 Extend the Schema Group Unmatched Fields into Objects Unmatched Application FieldsBuilding NumberFloor NumberCapacityEMTDirectory Server SchemaObject ClassCustom Object ClassesAttributeCustomAttributesUnmatched Data Store AttributesBuilding_NumberFloor_NumberGroup Unmatched Fields into ObjectsSelect Similar Attributes or Create New OnesCreate New Object Class and Attribute NamesTransfer New Definitions to MatrixDefine Attribute and Object Class RulesWhile 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.
96 Group Unmatched Fields in Objects Building NumberFloor NumberCapacityEMTWhat type of object does it describe?Are there standard attributes?Person (inetOrgPerson)Conference Room (top)NamePhone NumberDescriptioncntelephoneNumberdescriptionbuildingNameApplication FieldDefault Schema AttributeIs 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.
97 Select Similar Attributes or Create New Ones Identify the typeof objectSelect a similarobject classYou 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 similarattribute?PersonConference Room
98 Create New Object Class Names fluffPerson (inetorgPerson)Unmatched FieldsCreate new object class names that avoid present and future name conflictsBuilding NumberFloor NumberbuildingNameApplication FieldDefault Schema AttributeEMTBuilding NumberFloor NumberCapacityEMTOnce 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 FieldDefault Schema AttributeBuilding NumberbuildingNameFloor NumberCapacityNamecnPhone NumbertelephoneNumberDescriptiondescription
99 Create New Attribute Names fluffPerson (inetorgPerson)Unmatched FieldsBuilding NumberFloor NumberCapacityEMTApplication FieldDefault & New Schema AttributeBuilding NumberbuildingNameFloor NumberfluffBuildFloorEMTfluffEMTAt 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 FieldDefault & New Schema AttributeBuilding NumberbuildingNameFloor NumberfluffBuildFloorCreate new attribute names that avoid present and future name conflictsCapacityfluffConfRoomCapacityNamecnPhone NumbertelephoneNumberDescriptiondescription
100 Define Attribute and Object Class Rules Define attribute typesDirectoryString, IA5String, DN, binary, INTEGER, and TelephoneNumberSingle or Multi-valueDefine object class rulesInheritanceRequired attributesAllowed attributesObtain OID NumbersX.500 compatibilityYou 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.
101 Identify Authoritative Sources What Data Store is the authoritative source for each attribute?App 1App 2App nDirectory Server SchemaDirDirDirASIdentifierS1MVS2SnChangeApp 1App 2App nS1S2SnUpon 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.FieldsFieldsFieldsObjectClassOIDAttributeOIDSyntaxFieldsFieldsFieldsNotesDefault Object Classes----------------Custom Object Classes----------------
102 Examples of Authoritative Sources Human Resources system: Name, AddressPhone switch: Phone Number, Cube NumberFacilities systems: Building, Floor, AccessOther directories (NT, NIS)Other Application servers (such as Certificate): Certificates publishedThe 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.
103 Data Ownership Who makes sure data is up-to-date? Individuals accessing their own recordManagers accessing subordinate recordsRole or Group (rather than individuals) for other accessesData 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.
104 Identify Processes and Procedures Processes that need to change to accommodate directory designNow that HomePhoneNumber is displayed, who will maintain data accuracy?Does current contractor process need to be changed?IdentifyCorrect level of authorityWho owns the informationChangeNotesYou 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.
105 Exercises Identify Processes and Procedures Identify Authoritative SourcesExtend the Schema
106 TipsDefining 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 possibleDefine several smaller auxiliary object classes to mix needed attributes into existing objects.Minimize the number of mandatory attribute types within your object classesDo not define more than one object class or attribute type to hold the same kind of informationWhen in doubt, keep it simple
108 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”
109 DIT Design: People By Department c=UKo=glasgowou=Lifeou=CSou=Engineeringou=Adminou=Estatescn=I Brunel
110 DIT Design: Types of People c=UKo=glasgowou=Staffou=Contractorsou=Studentou=PostGradcn=James Currall
111 DIT Design: By Location c=UKo=glasgowl=Watts Bldl=Oakfield Avel=Libraryl=Admin Bldl=Gallerycn=D Montgomery
112 DIT Design: Deep Tree By Department dc=comdc=Acmeou=Peoplel=North Americal=Asial=Europel=New Yorkl=Dallasl=Los Angelesl=Japanl=Singaporel=Manchesterl=Munichl=Pariscn=Mike Smith
113 An Example DIT dc=com o=Acme ou=People ou=Groups ou=Locations ou=Apps ou=Systemsou=Schemacn =SmithETcn=Directory Usersite=TX-SDcn =AikmanTAcn=Mail Adminsite=TX-RIcn =SandersDJcn=Medical Adminsite=SW-BKcn = GonzalesJcn=Medical Usersite=NY-AAcn =ModanoMWou=Web Sitesou=Medicalou=Resumes
114 DIT Design: Deep -vs- Flat Trees Can result in long Distinguished Names (DN)May reflect your actual corporate structureCan result in administrative problems if your organization is constantly changingBetter chance of having unique names within a subtreeWorks well if you want to distribute the data across multiple Directory Servers
115 DIT Design: Flat -vs- Deep Trees No need to categorize peopleShort Distinguished Names, easy to typeDIT is very stable: not affected by organizational changes, and easy to administerHigher chance of name collisionsNot well suited for BrowsingCan result in longer load times or startup times, depending on the Directory Product you use
116 DIT Design: Selecting a Distinguished Name + DN Guaranteed to be unique+ DN Never Changes+ More robust searching using name componentsdc=UKdc=Glasgow- Browser shows useless information- Microsoft and Netscape mail clients expected a real name in the commonName (cn) field.ou=Peoplecn =givenName = Michaelnickname = Mikesurname = Smithcn= , ou=People, dc=Glasgow, dc=UK
117 DIT Design: Selecting a Distinguished Name + DN Guaranteed to be unique+ DN Never Changes+ More robust searching using name components- Browser shows useless informationdc=UKdc=Glasgow+ commonName (cn) field contains a real name to work well with other LDAP applications.ou=Peopleuid =cn = Mike SmithgivenName = Michaelnickname = Mikesurname = Smithuid= , ou=People, dc=Glasgow, dc=UK
118 DIT Design: Selecting a Distinguished Name + DN Guaranteed to be unique+ More robust searching using name components+ commonName (cn) field contains a real namedc=UKdc=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 = smithmjcn = Mike SmithgivenName = Michaelnickname = Mikesurname = Smithuid=smithmj, ou=People, dc=Glasgow, dc=UK
119 DIT Design: Selecting a Distinguished Name + 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 changedc=UKdc=Glasgowou=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 = smithmjgivenName = Michaelnickname = Mikesurname = Smithcn=Mike Smith + uid=smithmj, ou=People, dc=Glasgow, dc=UK
120 DIT Design: Selecting a Distinguished Name 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 changedc=Glasgowou=People- Data is duplicated in several areas (uid and cn)- Value displayed for commonName may vary.cn = smithmjcn = Mike SmithgivenName = Michaelnickname = Mikesurname = Smithuid = smithmjcn=smithmj, ou=People, dc=Glasgow,dc=UK
121 DIT Design: Selecting a Distinguished Name + 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 DNdc=UKdc=Glasgowou=Peopleou=Certificates- DN has the potential to change- Problems with X.500 aliases:- no built-in referential integrityuid = smithmjcn = Mike SmithgivenName = Michaelnickname = Mikesurname = Smithcn = smithmjALIAS POINTERcn=smithmj, ou=People, dc=Glasgow, dc=UKuid=smithmj, ou=Certificates, dc=Glasgow,dc=UK
122 DIT Design: DIT Naming Proposal (rfc2377) The dc named attribute stands for domain componentThe idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com)dc=comdc=acmeNaming Plan for Internet Directory-Enabled Applications
123 DIT Design: DIT Naming Proposal (rfc2377) The dc named attribute stands for domain componentThe idea is to map the upper levels of the tree with registered DNS Names (in this case acme.com)dc=comdc=acmeLower levels of the tree will also use the dc named attributedc=Corporatedc=Customers
124 DIT Design: DIT Naming Proposal (rfc2377) The dc named attribute stands for domain componentThe 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 attributedc=comdc=acmedc=Corporatedc=DalSiteEach user is identified with the uid named attribute containing the address.uid =cn = Mike SmithgivenName = Michaelsurname = Smithuid =cn = Jane DoegivenName = Janesurname = Doe
125 Carrots and SticksRobust DIT Naming and design standards are not in place yetThere is currently no single “right way” to design your DIT that applies to everyoneTake into consideration your organizationthe organizational structurethe organization’s tendency to changethe organization’s current size and potential to growTake into consideration the how you want to use the directorywhat information will be stored in the directorywho will own what data and how will be be masteredwhat what other systems in the infrastructure will be using/storing the datahow and what applications will be accessing the data
126 Conclusions" If you think technology can solve your problems, then you don't understand the problems and you don't understand the technology. " Bruce SchneierThe 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.
128 Security Technologies Successful e-business is highly dependent on securitySecurity services provide:ConfidentialityIntegrityAuthenticationNon-RepudiationAccess-ControlRemember…CIANA
129 Security Threats Information disclosure Integrity violation Assumed identities/MasqueradingDenial of serviceGeneric Threats:Backdoors, Trojans, Insider Attacks, Viruses
130 Home Security Analogy Systems Security is like home security Policy DefinitionYou choose who and what can be done in your homeAccess control and passwords are the keysWindow and door locks keep out intrudersLog files and monitoring scriptA security camera watches open doorsTry to make your environment less inviting to those looking for easy pickings
131 In the absence of a formal policy, the policy is… A policy is a set of instructions that determine an organization’s view of securityA policy sets the limits of acceptable behavior and outlines responses to violationsA policy always existsIn the absence of a formal policy, the policy is…Anything goes!
132 Security Implementations Two key implementations of security are:SSLS/MIMEEach is implemented at different layersSSLNetwork Layer(IP)Application LayerNon-secureSecurecommunicationS/MIME
133 SSL as a Security Solution SSL ensures safe and secure client-server transactionsProvides authentication, privacy, and message integrityData going over the network is point-to-point encryptedSSLv3.1 approved by IETF, called Transport Layer SecuritySSLNetwork Layer (TCP/IP)Application LayerSecurecommunication
134 SSL Server Authentication Client initiates contact via https“Here’s my certificate”Public Key included1. Generate secret key2. Encrypt secret key with Server’s public keyValidate Server certificateSSL establishedTransmitt data using session keysClientServer“I’d like to talk SSL”Decrypt secret key using private keyUse secret key to make session keys
135 SSL With Client Authentication “Here’s my certificate. Where’s yours?”Public Key included1. Generate secret key2. Encrypt secret key with Server’s public key3. Send encrypted key and Client certificateValidate Server certificateServer validates Client certificate and decryptsSSL establishedClientServerClient initiates contact via https“I’d like to talk SSL”Transmitt data using session keys