When modifying the LDAP schema to enable Lost Password Management, the LDIF file has to be run against LDAPMODIFY using the command:
ldapmodify -h hostname -p port -D "cn=Directory Manager" -w password -f c:\add.ldif
where add.ldif is the file containing:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
# ----------- Object class ---------------
#
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC
'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
as per the docs.
Sometimes when you do so, the object class is attempted to be created before the attributes are already created, and this gives an error:
ldap_modify: object class violation
to fix this, separate it into two ldif files, one to create the attributes:
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.204 NAME 'Challenge2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
dn: cn=schema
changetype: modify
add: attributetypes
attributetypes: ( 1.3.6.1.4.1.9999.1.1094.205 NAME 'Response2' SYNTAX
1.3.6.1.4.1.1466.115.121.1.15 )
, and the other to create the object class:
# ----------- Object class ---------------
#
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( 1.3.6.1.4.1.9999.1.1094.206 NAME 'oblixAuxPerson4LPM' DESC
'User defined objectclass' SUP top AUXILIARY MAY ( Challenge2 $ Response2 ) )
Wednesday, April 30, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment