Modifying the LDAP schema to enable LPM

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 ) )

Attribute Access Control

From OAM documentation:

The Attribute Access Control function lets you specify permissions that determine who can read and modify the values for each LDAP attribute. It also lets you create a list of users or groups to be notified when an attribute is changed. As with setting the searchbase, this functionality only applies to LDAP attributes. You configure permissions for template objects when you add participants to workflow steps. See "Chaining Identity Functions Into Workflows" for details.Users must have a searchbase defined as well as read permissions to be able to view an attribute. For instance, to be able to view the class attribute on the User Manger, Group Manager, or Organization Manager tab, a user must be a trustee of the appropriate searchbase domain for the class attribute, and they must have read permissions for this attribute.