1)
first add the new attribute in the Objectclass, and then load the objectclass of this entry.
2)
Any attribute you use in an LDAP directory must have a definition in the schema
as an attributetype. This defines the meaning of the attribute and the types of
data it holds. The schema for an objectclass defines what attributes can be
contained within the object.
Attribute syntax.<---
----------------
An attribute syntax defines the allowable values for an attribute. The server uses the syntax definition for an attribute to validate data and determine how to match values. For example, a "Boolean" attribute can only have the values "TRUE" and "FALSE"..
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahysyntax.htm
Matching rules.<---
---------------
A matching rule provides guidelines for string comparison during a search operation. These rules are divided into three categories:
* Equality
* Ordering
* Substring
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahymatchrules.htm
*************************
The objectclass attribute
=========================
The objectclasses attribute lists the object classes supported by the server. Each value of this attribute represents a separate object class definition. Object class definitions can be added, deleted, or modified by appropriate modifications of the objectclasses attribute of the cn=schema entry. Values of the objectclasses attribute have the following grammar, as defined by RFC 2252:
ObjectClassDescription = "(" whsp
numericoid whsp ; Objectclass identifier
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ] ; Superior objectclasses
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; default is structural
[ "MUST" oids ] ; AttributeTypes
[ "MAY" oids ] ; AttributeTypes
whsp ")"
For example, the definition of the person objectclass is:
( 2.5.6.6 NAME 'person' DESC 'Defines entries that generically represent people. ' STRUCTURAL SUP top MUST ( cn $ sn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
* The OID for this class is 2.5.6.6
* The name is "person"
* It is a structural object class
* It inherits from the object class "top"
* The following attributes are required: cn, sn
* The following attributes are optional: userPassword, telephoneNumber, seeAlso, description
The attributetypes attribute
============================
The attributetypes attribute lists the attribute supported by the server. Each value of this attribute represents a separate attribute definition. Attribute definitions can be added, deleted, or modified by appropriate modifications of the attributetypes attribute of the cn=schema entry. Values of the attributetypes attribute have the following grammar, as defined by RFC 2252:
AttributeTypeDescription = "(" whsp
numericoid whsp ; AttributeType identifier
[ "NAME" qdescrs ] ; name used in AttributeType
[ "DESC" qdstring ] ; description
[ "OBSOLETE" whsp ]
[ "SUP" woid ] ; derived from this other AttributeType
[ "EQUALITY" woid ; Matching Rule name
[ "ORDERING" woid ; Matching Rule name
[ "SUBSTR" woid ] ; Matching Rule name
[ "SYNTAX" whsp noidlen whsp ]
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ]; default user modifiable
[ "USAGE" whsp AttributeUsage ]; default userApplications
whsp ")"
AttributeUsage =
"userApplications" /
"directoryOperation" /
"distributedOperation" / ; DSA-shared
"dSAOperation" ; DSA-specific, value depends on server
The matching rules and syntax values must be one the values defined by the following:
* Matching rules
* Attribute syntax
Only "userApplications" attributes can be defined or modified in the schema. The "directoryOperation", "distributedOperation" and "dSAOperation" attributes are defined by the server and have specific meaning to the server operation.
For example, the "description" attribute has the following definition:
( 2.5.4.13 NAME 'description' DESC 'Attribute common to CIM and LDAP schema to provide lengthy description of a directory object entry.' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE userApplications )
* Its OID is 2.5.4.13
* Its name is "description"
* Its syntax is 1.3.6.1.4.1.1466.115.121.1.15 (Directory String)
*****************************************
To Create an Attribute Type
---------------------------
The cn=schema entry has a multivalued attribute, attributeTypes, that contains definitions of each attribute type in the directory schema. You add custom schema definitions by using the ldapmodify command. This example adds an attribute named blog.
Manipulation of the cn=schema suffix is regarded as an administrative action and, as such, it is recommended that you use the administration connector when accessing this suffix. See Managing Administration Traffic to the Server for more information.
1. Using a text editor, create an LDIF file with your schema extensions.
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590
NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
X-ORIGIN 'OpenDS Directory Server'
USAGE userApplications )
2. Use ldapmodify to add the file.
$ ldapmodify -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
-a -f blogURL.ldif
Processing MODIFY request for cn=schema
MODIFY operation successful for DN cn=schema
3. Verify the addition by displaying it using ldapsearch.
$ ldapsearch -h localhost -p 4444 -D "cn=Directory Manager" -w password -X --useSSL \
-b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep 'blog'
attributeTypes: ( 1.3.6.1.4.1.32473.1.1.590 NAME ( 'blog' 'blogURL' )
DESC 'URL to a personal weblog' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE X-ORIGIN 'OpenDS Directory Server' USAGE userApplications )
Note - The directory server automatically adds new attribute definitions to the 99user.ldif file.
Managing Attribute Types
You can add new attribute types to the schema by using the ldapmodify command. The attribute types syntax requires that you provide at least a valid OID to define a new element. In typical applications, you can optionally include the following identifiers for the attribute type. To see the full set of attribute type elements, see Understanding Attribute Types in Sun OpenDS Standard Edition 2.2 Architectural Reference.
OID
Required. Specifies the OID that uniquely identifies the attribute type in the directory server. The LDAP v3 specification requires the OID to be a numeric number, but the directory server supports the use of non-numeric OIDs for easy identification as long as the schema is used internally within the organization. The format is attributename-oid, for example, telephoneNumber-oid. Each non-numeric OID must have its corresponding numeric OID defined in the schema.
NAME
Optional. Specifies the set of human-readable names that are used to refer to the attribute type. If there is a single name, enclose it in single quotes, for example, 'blogURL'. If there are multiple names, enclose each name in single quotes separated by spaces, and then enclose the entire set of names within parentheses, for example, ( 'blog' 'blogURL' ). Ensure that there is a space between the left parenthesis and the name, and a space before the closing parenthesis.
SUP
Optional. Specifies the superior attribute type when you want one attribute type to inherit elements from another attribute type. The matching rule and attribute syntax specifications from the superior attribute type can be inherited by the subordinate type if it does not override the superior attribute type definition. The OID, any of the human-readable names associated with the superior attribute type or both can be used to collectively reference all of the subordinate attribute types.
DESC
Optional. Specifies a human-readable description of the attribute type.
SYNTAX
Optional. Specifies the attribute syntax for use with the attribute type. If provided, it should be given as a numeric OID. The core syntaxes are defined in section 3.3. of RFC 4517 and in Appendix A of the same document.
SINGLE-VALUE
Optional. Specifies whether the attributes of that type are allowed to have only a single value in any entry in which they appear. If SINGLE-VALUE is not present, the attributes are allowed to have multiple distinct values in the same entry.
NO-USER-MODIFICATION
Optional. Indicates that the values of the attributes of the given type cannot be modified by external clients (that is, the values can be modified only by internal processing within the directory server).
USAGE
Optional. Indicates how the attribute is to be used. Possible values are as follows: userApplications. Used to store user data. directoryOperation. Used to store data required for internal processing within the directory server. distributeOperation. Used to store operational data that must be synchronized across directory servers in the topology. dSAOperation. Used to store operational data that is specific to a particular directory server and should not be synchronized across the topology.
extensions
Optional. Specifies the extensions available to the attribute type. The directory server provides the following extensions: X-ORIGIN. Provides information on where the attribute type is defined. The element is a non-standard tool that the user can use to locate the schema element. Examples could include the RFC number (RFC4517), Sun OpenDS SE Directory Server and others. X-SCHEMA-FILE. Indicates which schema file contains the attribute type definition. Used for internal purposes only and is not exposed to clients. You can use this extension to specify where the directory server should store your custom schema definitions. X-APPROX. Indicates which approximate matching rule should be used for the attribute type. If specified, the value should be the name of the OID of a registered approximate matching rule.
*****************************************
http://www.yolinux.com/TUTORIALS/LinuxTutorialLDAP-DefineObjectsAndAttributes.html
http://www.bind9.net/manual/openldap/2.0/schema.html ------> 8.2.4. Attribute Type Specification ---> IMP
http://www.zytrax.com/books/ldap/ch3/ <----- IMP
ldap add Objectclass and Attribute command line
-----------------------------------------------
ldapmodify -D
google search ---> changetype: modify add: attributetypes
http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=/rzahy/rzahyaddattr.htm
https://www.opends.org/2.0/page/ManagingAttributeTypes
http://www.novell.com/coolsolutions/assets/Schema.ldif
http://www.nmi-edit.org/resources/Docs/gsuPerson.ldif <--------------
http://docs.sun.com/source/821-0506/managing-attribute-types.html <-------------IMP
http://docs.sun.com/app/docs/doc/819-0995/6n3cq3avf?a=view <-------------IMP
http://www.ietf.org/rfc/rfc4517.txt <-----------V IMP
http://groups.google.com/group/ibm.software.ldap/browse_thread/thread/3d3b85a348994000#
*****************************************
/usr/bin/ldapadd -x -D 'uid=root,dc=localhost,dc=localdomain' -W -f /etc/openldap/user.ldif
ldapsearch -x -D 'uid=root,dc=localhost,dc=localdomain' -b cn=schema -s base --dontWrap "(objectclass=*)" attributeTypes | grep 'group_id'
-------- new_attribute.ldif
dn: cn=schema
changetype: modify
add: attributeTypes
attributeTypes: (
group_id-oid
NAME group_id
DESC 'user group'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
ldapmodify -x -D 'uid=root,dc=localhost,dc=localdomain' -W -a -f new_attribute.ldif
******************************************
No comments:
Post a Comment