Como o LDIF pode representar as operações de atualização do LDAP, você pode usar o LDIF para modificar o esquema.
Para adicionar uma classe, simplesmente adicione um valor de atributo que corresponda à especificação NDSObjectClassDescription para o atributo objectClasses do subschemaSubentry.
NDSObjectClassDescription = "(" whsp
numericoid whsp
[ "NAME" qdescrs ]
[ "DESC" qdstring ]
[ "OBSOLETE" whsp ]
[ "SUP" oids ]
[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
[ "MUST" oids ]
[ "MAY" oids ]
[ "X-NDS_NOT_CONTAINER" qdstrings ]
[ "X-NDS_NONREMOVABLE" qdstrings ]
[ "X-NDS_CONTAINMENT" qdstrings ]
[ "X-NDS_NAMING" qdstrings ]
[ "X-NDS_NAME" qdstrings ]
whsp ")"
O exemplo a seguir do arquivo LDIF adiciona a classe do objeto da pessoa ao esquema.
1 version: 1 2 dn: cn=schema 3 changetype: add 4 objectClasses: ( 2.5.6.6 NAME ’person’ DESC ’Standard 5 ObjectClass’ SUP ndsLoginProperties STRUCTURAL MUST 6 (cn $ sn) MAY (description $ seeAlso $ telephoneNum 7 ber $ fullName $ givenName $ initials $ uid $ userPa 8 ssword) X-NDS_NAMING (’cn’ ’uid’) X-NDS_CONTAINMENT 9 (’organization’ ’organizationalUnit’ ’domain’) X-NDS 10 _NAME ’Person’ X-NDS_NOT_CONTAINER ’1’ X-NDS_NONREMO 11 VABLE ’1’) 12
Os atributos obrigatórios estão relacionados na seção MUST da descrição da classe do objeto. No caso da classe do objeto Pessoa, os atributos obrigatórios são cn e sn.
Os atributos opcionais estão relacionados na seção MAY da descrição da classe de objeto. Os atributos opcionais na classe de objeto pessoa sãodescription, seeAlso, telephoneNumber, fullName, givenName, initials, uid e userPassword.
NOTA:O atributo userPassword não pode ser usado como opcional (MAY). A operação falhará se você tentar usá-lo como um atributo obrigatório (MUST) na nova objectClass usando este formato de LDIF para estender o esquema.
As classes do objeto que podem conter a classe do objeto que está sendo definido são determinadas na seção X-NDS_CONTAINMENT da descrição da classe do objeto. A classe do objeto pessoa pode ser contida pelas classes de objeto organization, organizationalUnit e domain.
Para adicionar um atributo, simplesmente adicione um valor de atributo que corresponda à especificação NDSAttributeTypeDescription para o atributo do subschemaSubentry.
NDSAttributeTypeDescription = "(" 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 ] ; Syntax OID
[ "SINGLE-VALUE" whsp ] ; default multi-valued
[ "COLLECTIVE" whsp ] ; default not collective
[ "NO-USER-MODIFICATION" whsp ] ; default user modifiable
[ "USAGE" whsp AttributeUsage ] ; default userApplications
[ "X-NDS_PUBLIC_READ" qdstrings ]
; default not public read (’0’)
[ "X-NDS_SERVER_READ" qdstrings ]
; default not server read (’0’)
[ "X-NDS_NEVER_SYNC" qdstrings ]
; default not never sync (’0’)
[ "X-NDS_NOT_SCHED_SYNC_IMMEDIATE" qdstrings ]
; default sched sync immediate (’0’)
[ "X-NDS_SCHED_SYNC_NEVER" qdstrings ]
; default schedule sync (’0’)
[ "X-NDS_LOWER_BOUND" qdstrings ]
; default no lower bound(’0’)
;(upper is specified in SYNTAX)
[ "X-NDS_NAME_VALUE_ACCESS" qdstrings ]
; default not name value access (’0’)
[ "X-NDS_NAME" qdstrings ] ; legacy NDS name
whsp ")"
O exemplo a seguir do arquivo LDIF adiciona o tipo de atributo Título ao esquema:
1 version: 1
2 dn: cn=schema
3 changetype: add
4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa
5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} X-NDS_NAME ’Title’ X-NDS_NOT_SCHED_SYNC_IMMEDIA
7 TE ’1’ X-NDS_LOWER_BOUND ’1’)
8
Um atributo é padronizado para valor composto a não ser que ele seja explicitamente um valor único. O exemplo a seguir do arquivo LDIF faz o valor único do título, adicionando a palavra-chave SINGLE-VALUE após a seção SYNTAX:
1 version: 1
2 dn: cn=schema
3 changetype: add
4 attributeTypes: ( 2.5.4.12 NAME ’title’ DESC ’Standa
5 rd Attribute’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{
6 64} SINGLE-VALUE X-NDS_NAME ’Title’ X-NDS_NOT_SCHED
7 _SYNC_IMMEDIATE ’1’ X-NDS_LOWER_BOUND ’1’)
8
Embora adicionar novos elementos de esquema seja uma prática aceitável, modificar ou estender elementos de esquemas existentes geralmente é algo perigoso. Como cada elemento de esquema é identificado com exclusividade por um OID, ao estender o elemento de esquema padrão, você estará efetivamente criando uma segunda definição para o elemento, mesmo que ele ainda use o OID original. Isso pode causar falhas de incompatibilidade.
Existem momentos em que é adequado alterar os elementos do esquema. Por exemplo, pode ser necessário estender ou modificar novos elementos de esquema ao refiná-los durante o desenvolvimento. Em vez de adicionar novos atributos diretamente a uma classe, pois geralmente classes auxiliares somente devem ser usadas para
Adicionar novos atributos a uma classe de objeto existente.
Sub-classe da classe do objeto existente.
O arquivo de amostra LDIF a seguir cria dois novos atributos, uma classe auxiliar com esses novos atributos e então acrescenta uma entrada inetOrgPerson à classe auxiliar como uma classe de objeto da entrada e com valores para os atributos da classe auxiliar.
version: 1 # Add an attribute to track a bear’s hair. The attribute is # multi-valued, uses a case ignore string syntax, # and has public read rights # Values may include: long hair, short, curly, straight, # none, black, and brown # X-NDS_PUBLIC_READ ’1’ The 1 allows public read, # 0 denies public read dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.10 NAME ’bearHair’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-NDS_PUBLIC_READ ’1’ ) # add an attribute to store a bear’s picture dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.16.840.1.113719.1.186.4.11 NAME ’bearPicture’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.5 SINGLE-VALUE ) # create an Auxiliary class for the bearfeatures dn: cn=schema changetype: modify add: objectclasses objectclasses: (2.16.840.1.113719.1.186.6.101 NAME ’bearFeatures’ MAY (bearHair $ bearPicture) AUXILIARY) # now create a user named bobby dn: cn=bobby,o=bearcave changetype: add cn: bobby sn: bear givenName: bobby bearHair: Short bearHair: Brown bearHair: Curly bearPicture:< file:///c:/tmp/alien.jpg objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: bearFeatures # now create a person named john that will later be changed # into a bear when bearFeatures is added to its objectClass # list dn: cn=john,o=bearcave changetype: add cn: John sn: bear givenName: john objectClass: top objectClass: person objectClass: inetOrgPerson # now morph john into a bear by adding bearFeatures dn: cn=john,o=bearcave changetype: modify add: objectClass objectClass: bearFeatures - add: bearHair bearHair: long bearHair: black #bearPicture:< file:///c:/tmp/john.jpg> - # to morph john back to a person, simply delete the # objectClass bearFeatures dn: cn=john,o=bearcave changetype: modify delete: objectClass objectClass: bearFeatures
Ao remover as classes auxiliares, não é necessário apagar todos os valores associados à classe auxiliar ao removê-la da lista objectClass. O eDirectory faz isto automaticamente.
Se a classe auxiliar possuir atributos MUST, todos eles deverão ser especificados na mesma operação de modificação que adiciona a classe auxiliar à lista de objectClass ou a modificação falhará.
O processamento de XML de qualquer registro LDIF (formato LDIF ou registros gerados pelo servidor LDAP) não será executado se os registros individuais são satisfizerem todas as regras de XML especificadas no arquivo XML.