Date: 09-27-2024

OpenLDAP has two configuration methods, static and dynamic.

The static method stores settings in the slapd.conf configuration file which is more readable then trying to interpret the dynamic settings with cn=config. However, when settings are changed in slapd.conf, slapd must be restarted for the changes to be applied. 

The dynamic method stores settings in an LDAP database called cn=config. The cn=config database is stored in a directory named slapd.d.  Dynamic configuration allows most settings to be changed using the ldapadd and ldapmodify commands with immediate effect while slapd is running.

Not all settings should be modified while slapd is running. Generally, adding and modifying settings like ACLs, schemas, log levels, database sizes, sync provider, synchronization plugins and overlays are safe. Removing modules, overlays and databases should be done offline. 

Backup Important Data: It is strongly recommended that you create a backup of your configuration before making changes. See: LDAP Database Backup.

Converting Static to Dynamic Configuration

Static configuration (slapd.conf) can easily be converted dynamic configuration (cn=config) using the slaptest command. Please note that there's no built-in mechanism to convert dynamic configuration back to static configuration.

Access Control

For security, the cn=config database must have an ACL that specifies who has permission to modify the configuration database while slapd is running. The easiest way to add the ACL is to add a configuration database definition to the static configuration file before conversion (most static database configurations do not have it defined.) To update, add the following to slapd.conf:

database config
rootdn cn=config
rootpw <password>
access to * 
    by dn.exact="cn=config" manage
    by * none

The rootdn and rootpw settings are optional. You can leave these settings out and use the rootdn of your main database in the ACL, as long as the rootpw is set for the main database as well.

Configuration Conversion Steps

Stop slapd:

sudo systemctl stop slapd

Create the slapd.d configuration directory:

mkdir /opt/symas/etc/openldap/slapd.d

Convert slapd.conf to cn=config with the slapcat command:

/opt/symas/sbin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F /opt/symas/etc/openldap/slapd.d

Update the ownership of the slapd.d directory to the user and group that runs the slapd service:

sudo chown -R ldap:ldap /opt/symas/etc/openldap/slapd.d

Rename the slapd.conf file (optional):

mv /opt/symas/etc/openldap/slapd.conf /opt/symas/etc/openldap/slapd.conf.converted

Add or modify the slapd service environment variable file (/etc/default/symas-openldap) to start with slapd.d configuration:

SLAPD_OPTIONS="-F /opt/symas/etc/openldap/slapd.d"

Reload the slapd daemon configuration in systemd:

sudo systemctl daemon-reload

Start slapd:

sudo systemctl start slapd

Specifying an Alternate slapd.d Location

Normally, the slapd.d directory is located in /opt/symas/etc/openldap and slapd. However, the slapd.d directory can reside anywhere within the file system. If using an alternate location, simply add or update the file “/etc/default/symas-openldap” as follows:

SLAPD_OPTIONS="-F /<alt>/<path>/<to>/slapd.d"

This change will require a restart of the slapd service.

Exporting cn=config to Editable LDIF

The cn=config database can be exported to an LDIF file for a couple of reasons. First, it's the preferred method for backing up the configuration. Second, major changes to the configuration (adding/deleting modules and overlays, major schema modifications) should be done by performing a full reload of the cn=config database. To do this, the full configuration needs to be in a single LDIF file.

Exporting the cn=config database may be done while slapd is running.

To export, use the slapcat command (the -l parameter sets the name of the output file):

/opt/symas/sbin/slapcat -F /opt/symas/etc/openldap/slapd.d -l config.ldif -b cn=config -o ldif-wrap=no

The ‘-o ldif-wrap=no’ parameter is optional. By default, the slapcat command wraps lines at 79 characters. In some cases, it's desirable to disable line wrapping to increase readability and make editing easier. Setting ldif-wrap to “no” makes this possible.

Reloading the cn=config Database

The safest way to reload the cn=config database is to first load the configuration LDIF into a temporary directory.  This way the database can be reloaded offline and if any issues are encountered, things can be fixed without worry of extended downtime. To perform the reload:

Create a new, empty config database:

mkdir /opt/symas/etc/openldap/slapd.d.tmp
sudo chown --reference=/opt/symas/etc/openldap/slapd.d /opt/symas/etc/openldap/slapd.d.tmp

Use slapadd to load the database:

/opt/symas/sbin/slapadd -F /opt/symas/etc/openldap/slapd.d.tmp -l config.ldif -b cn=config

If any issues are encountered, correct the configuration LDIF, empty the temporary configuration directory and try slapadd again.

Stop slapd:

sudo systemctl stop slapd

Move the current configuration directory and replace it with the new configuration database:

mv /opt/symas/etc/openldap/slapd.d /opt/symas/etc/openldap/slapd.d.out
mv /opt/symas/etc/openldap/slapd.d.tmp /opt/symas/etc/openldap/slapd.d

Start slapd:

sudo systemctl start slapd

If issues are encountered, stop slapd if running and put the old configuration directory back in place:

sudo systemctl stop slapd
mv /opt/symas/etc/openldap/slapd.d /opt/symas/etc/openldap/slapd.d.new
mv /opt/symas/etc/openldap/slapd.d.out /opt/symas/etc/openldap/slapd.d
sudo systemctl start slapd

Working With Ordered Values

Throughout the cn=config database entries and attributes are given a unique identifier in curly brackets {#} known as an “ordered value.” This method of identification indicates the weight or priority of the attribute. When adding attributes or entries, be sure to check for the next available ordered value. This instructs slapd how to order the entries or attributes, {0}processed first, {1}, {2}, {3}... processed subsequently. If an ordered value is not specified the next available identifier will be assigned. For loaded modules, access control lists, overlays, etc. the order can be particularly important. Pay attention!

Example of Ordered Values

olcAccess: {0}to attrs=userPassword  by self write  by * auth
olcAccess: {1}to dn.subtree="ou=people,dc=example,dc=com"  by group/groupOfNam
 es/member.exact="cn=admins,ou=groups,dc=example,dc=com" write  by users read
olcAccess: {2}to dn.subtree="ou=buildings,dc=example,dc=com"  by group/groupOf
 Names/member.exact="cn=building-admins,ou=groups,dc=example,dc=com" write  by
  users read
olcAccess: {3}to dn.subtree="ou=webapps,dc=example,dc=com"  by group/groupOfNa
 mes/member.exact="cn=web-admins,ou=groups,dc=example,dc=com" write  by group/
 groupOfNames/member.exact="cn=web-applications,ou=groups,dc=example,dc=com" r
 ead  by * none

Adding Ordered Values

When adding ordered values, slapd will handle numbering for you. If you're adding an ordered value to the end of a list, you can number it with the number of the last value incremented by one, or you can leave the order number out and slapd will add it for you.

If you need to insert a value in the middle of the list, give the new value the number at the position where you need it and slapd will automatically renumber the remaining values.

Replacing and Deleting Ordered Values

To delete an ordered value, specify the value to delete in the LDIF used for modification:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {2}to dn.exact="uid=foo,ou=people,dc=example,dc=com" by * none

To replace an ordered value, you must first delete the value and then add the new value:

dn: olcDatabase={1}mdb,cn=config
changetype: modify
delete: olcAccess
olcAccess: {2}to dn.exact="uid=foo,ou=people,dc=example,dc=com" by * none
-
add: olcAccess
olcAccess: {2}to dn.exact="uid=foo,ou=people,dc=example,dc=com" by * read

In both cases, slapd will handle the renumbering of values.

Working With The cn=config Directory Tree

cn=config

The cn=config container holds the global configuration settings including TLS, SASL, Authz, ServerID and Loglevel.

Global Configuration Change Examples

Note, these examples use ldapadd/ldapmodify interactive mode. In interactive mode, changes are applied when enter is pressed twice. To exit interactive mode, enter CTRL+d.

Add a Global Configuration Setting

/opt/symas/binldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: cn=config
changetype: modify
add: olcLogFile
olcLogFile: /<full>/<path>/<to>/<logfile>

Remove a Global Configuration Setting

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
DN: cn=config
changetype: modify
delete: olcLogLevel
olcLogLevel: Stats

Modify a Global Configuration Setting

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: cn=config
changetype: modify
replace: olcThreads
olcThreads: 8

Add Database

Update olcDatabase's weight {#} accordingly. Create the directory before performing the ldapmodify. Update database maxsize, required indices and root credentials as needed.

/opt/symas/bin/ldapadd -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={2}mdb,cn=config
objectClass: olcMdbConfig
objectClass: olcDatabaseConfig
olcDatabase: {2}mdb
olcDbDirectory: /var/symas/openldap-data/example1
olcSuffix: dc=example1,dc=com
olcAddContentAcl: FALSE
olcReadOnly: FALSE
olcRootDN: dc=example1,dc=com
olcRootPW: secret
olcSizeLimit: unlimited
olcTimeLimit: unlimited
olcMaxDerefDepth: 15
olcDbNoSync: FALSE
olcDbIndex: default eq
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq
olcDbMode: 0600
olcDbMaxEntrySize: 0
olcDbMaxReaders: 0
olcDbMaxsize: 85899345920
olcDbRtxnSize: 10000
olcDbSearchStack: 16
olcLastMod: TRUE
olcMirrorMode: FALSE
olcMonitoring: TRUE

For Consumer servers add attributes for olcSyncrepl, olcSyncUseSubentry and olcUpdateRef as needed. For multi-master replication switch olcMirrorMode to True

olcSyncrepl: rid=001 provider=ldap://gb1scoltest01.symas.net
bindmethod=simple timeout=0 network-timeout=0
binddn="dc=example,dc=com" credentials="secret" keepalive=0:0:0
starttls=no filter="(objectclass=*)"
searchbase="dc=example,dc=com" scope=sub schemachecking=off
type=refreshAndPersist retry="60 +"
olcSyncUseSubentry: FALSE
olcUpdateRef: ldap://<producer server's FQDN>
olcMirrorMode: TRUE

cn=module,cn=config

The cn=module,cn=config entry contains the path to the OpenLDAP modules and a list of all included modules as operational attributes. It is safe to add modules, but removing modules should be done with an offline reload of the cn=config database.

Example of Adding a Module

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

cn=schema,cn=config

Modifying the SchemaConfig object is more complicated in slapd.d and special instructions for doing so are included at the end of this document. The cn=schema container shows all defined attribute types, syntaxes, object classes and object identifiers as multi-valued operational attributes from all schemas in use. However, each schema file is listed as a separate subtree with its own defined attribute types and object classes. Again, note the ordered values of the subtrees and the attribute values. Also note, the cn=schema,cn=config entry (not its children) contains built in attribute types and object classes and can not be modified.

olcDatabase={-1}frontend,cn=config

The frontend contains backend-specific parameters applied globally such as Access Control Lists (ACLs). olcAccess is an ordered attribute by weight signified by {#}. This instructs slapd how to order the ACLs, {0} processed first, {1}, {2}, {3}... processed subsequently.

Note: ACLs defined in the frontend database have less precedence than ACLs defined in subsequent databases.  ACLs in the frontend database should be specific to the frontend and not contain any rules to a particular subtree.

Frontend also contains sub-containers for globally applied overlays such as Chaining. Note that the overlay contains subtrees for each database to which the overlay is applied.

Adding a Frontend Access Control List

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
add: olcAccess
olcAccess: to * by dn.base="cn=config" write break

olcDatabase={0}config

This section defines database 0, cn=config. Adding olcRootDN and olcRootPW to this section will allow modifications to the entire slapd.d configuration. By default, viewing and modification privileges to the cn=config database are restricted to the rootDN.

Change cn=config RootPW

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}cuz7UaNFrHvzk57ugRC3lQqnLHrcWKt+

Add write permission for regular database user to modify cn=config database

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcAccess
olcAccess: {1}to * by dn="uid=<username>,ou=people,dc=example,dc=com" write olcDatabase={1}mdb

The database subtree contains all the configurations required for the database, plus subtrees for any applied overlays. The database subtree is automatically created when added to cn=config. Modifications to the individual tree can include olcRootDN, olcDbIndex, olcDbMaxSize, olcDbMultivalHi|Lo, olcSuffix, olcRootDN and olcRootPW.

Add Index

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: entryUUID eq

Modify Database Maxsize

/opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcDbMaxSize
olcDbMaxSize: 10737418240

Additionally, overlays for the database can be configured.

Add Overlay

 /opt/symas/bin/ldapadd -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
 dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
 objectClass: olcOverlayConfig
 objectClass: olcSyncProvConfig
 olcOverlay: syncprov
 olcSpNoPresent: TRUE
 olcSpReloadHint: TRUE

Modify Overlay

 /opt/symas/bin/ldapmodify -x -H ldap://<ldap server fqdn> -D cn=config -w <password>
 dn: olcOverlay={0}pcache,olcDatabase={1}mdb,cn=config
 changetype: modify
 replace: olcPcachePersist
 olcPcachePersist: TRUE

olcDatabase={2}Monitor

The monitor database contains a predefined set of analytics which generate statistics. No modifications to this configuration are required.

Modifying Existing Attributes

When attempting to modify an existing attribute in the cn=config database, you may encounter the UnwillingToPerform (53) error code. This often indicates that other attributes are required before the existing attribute can be changed. For example, if you want to change olcTLSVerifyClient from never to demand, you must first add the olcTLSCACertificateFile, olcTLSCertificateFile, and olcTLSCertificateKeyFile attributes. Without these, TLS authentication would be required, but no certificate/key pair would be recognized, potentially locking you out.

Returning to Static Configuration Files

Although there is no direct way to convert slapd.d back to a static slapd.conf file, you may need to revert to a static configuration for troubleshooting, development, or other purposes. To do this, simply move, rename, or delete the /opt/symas/etc/openldap/slapd.d directory.

By default, the slapd service reads /opt/symas/etc/openldap/slapd.d before /opt/symas/etc/openldap/slapd.conf. If the slapd.d directory is found, the slapd.conf file will be ignored. Renaming, moving, or deleting the slapd.d directory forces slapd to use the static slapd.conf file.

NOTE: The slapd.conf file is not kept up-to-date by changes made to the slapd.d configuration. The slapd.conf file will need to be updated and slapd restarted to match the current slapd.d settings.

Updating Schemas

Remember: Custom schemas should always been saved in a directory apart from /opt/symas/etc/openldap/schema. This directory is replaced during uninstall and upgrade operations.

Adding/Removing Schemas

For slapd.conf

Additional schema files can be added by including them in the global section of the /opt/symas/etc/openldap/slapd.conf file. Comment out or delete those to be removed.

# Schema files. Note that not all of these schemas co-exist peacefully.
# Use only those you need and leave the rest commented out.
Include /opt/symas/etc/openldap/schema/core.schema
# Include /opt/symas/etc/openldap/schema/cosine.schema
Include /opt/symas/etc/openldap/schema/inetorgperson.schema
Include /opt/symas/etc/openldap/custom-schema/customcosine.schema

Warning: Restart the slapd service before adding attributes from new schemas to the index.

Warning: DO NOT remove a schema if attributes and object classes defined in that schema are in use in the database. Doing so will result if a variety of errors including corrupting the database and preventing database restoration. If this is done accidentally, slapcat the database and remove any entries in CAPS (indicative of undefined attributes/object classes) from the resulting ldif file. Then recreate the database minus the undefined attributes/object classes using slapadd.

For slapd.d

Copy your custom schema to the /opt/symas/etc/openldap/custom-schema directory.

cd /opt/symas/etc/openldap/
cp schema/cosine.schema custom-schema/customcosine.schema

Then, create a config file that contains the new schema plus all related "top" schema files.

cat > schema_conf << EOL
> include /opt/symas/etc/openldap/schema/core.schema
> include /opt/symas/etc/openldap/custom-schema/customcosine.schema
> EOL

Convert the custom schema to an ldif file

slaptest -f schema_conf -F custom-schema

Confirm file creation

ll -r custom-schema
?Should see the following:
?total 8
?drwxr-x--- 3 root root 4096 Apr 14 14:40 cn=config
?-rw------- 1 root root 1029 Apr 14 14:40 cn=config.ldif
ll custom-schema/cn=config/cn=schema
Should see the following:
total 36
-rw------- 1 root root 15546 Apr 14 14:40 cn={0}core.ldif
-rw------- 1 root root 11363 Apr 14 14:40 cn={1}customcosine.ldif

Adjust the name of the schema ldif to be next in the list of schemas already in use and then import the schema to the slapd.d configuration

ll /opt/symas/etc/openldap/slapd.d/cn=schema
Should return
total 2
cn={0}core
cn={1}inetorgperson
cd custom-schema/cn=config/cn=schema
vi cn={1}customcosine.ldif
Update the DN from
cn=**{2}**customcosine
To
cn=**{3}**customcosine**,cn=schema,cn=config**
Update the CN from
**{2}**customcosine
To
**{3}**customcosine

Important: Delete the following lines from the end of the file

structuralObjectClass: olcSchemaConfig
entryUUID: <random string>
creatorsName: cn=config
createTimestamp: <date time>
entryCSN: <CSN info>
modifiersName: cn=config
ModifyTimestamp: <date time>
ldapadd -x -H ldap://<server FQDN>/ -D <cn=config rootDN> -W -f customcosine.ldif

Use the cn=config database rootPW

Modifying ObjectClasses / MUST Attributes

For slapd.conf

Stop slapd on all LDAP servers:

sudo systemctl stop slapd

Update the schema file and add it to the includes in the global section of /opt/symas/etc/openldap/slapd.conf

vi /opt/symas/etc/openldap/slapd.conf
include </full/path/to/schema file>
:wq (Save and Quit)

Import the database

/opt/symas/sbin/slapadd -f /opt/symas/etc/openldap/slapd.conf -b <suffix> -l /tmp/data.ldif

Repeat on all LDAP servers.

Start slapd on Producer servers, then on Consumer servers

sudo systemctl start slapd

For slapd.d

To add an attribute or objectClass first obtain the DN of the schema you wish to update

/opt/symas/sbin/ldapsearch -x -H ldap://<server FQDN>/ -D <CN=Config rootDN> -W -b cn=schema,cn=config -LLL dn

Results should look similar to this:

dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2]inetorpperson,cn=schema,cn=config
dn: cn={3}customcosine,cn=schema,cn=config

For objectClasses you will also need the next available number of objectClass entry in the cn=config database.

/opt/symas/bin/ldapsearch -x -H ldap:/// -D <CN=Config rootDN> -W -b cn={3}customcosine,cn=schema,cn=config -LLL olcObjectClasses

Use the cn=config database rootPW

Results should look similar to this:

dn: cn={3}nis,cn=schema,cn=config
olcObjectClasses: {0}( 1.3.6.1.1.1.2.0 NAME 'posixAccount'
DESC 'Abstraction of an account with POSIX attributes' SUP
top AUXILIARY MUST ( cn $ uid $ uidNumber $ gidNumber $
homeDirectory ) MAY ( userPassword $ loginShell $ gecos $
description ) )
olcObjectClasses: {1}( 1.3.6.1.1.1.2.1 NAME
'shadowAccount' DESC 'Additional attributes for shadow
passwords' SUP top AUXILIARY MUST uid MAY ( userPassword
$ shadowLastChange $ shadowMin $ shadowMax $
shadowWarning $ shadowInactive $ shadowExpire $ shadowFlag $
description ) )
olcObjectClasses: {2}( 1.3.6.1.1.1.2.2 NAME 'posixGroup'
DESC 'Abstraction of a group of accounts' SUP top
STRUCTURAL MUST ( cn $ gidNumber ) MAY ( userPassword $
memberUid $ description ) )
olcObjectClasses: {3}( 1.3.6.1.1.1.2.3 NAME 'ipService'
DESC 'Abstraction an Internet Protocol service' SUP top
STRUCTURAL MUST ( cn $ ipServicePort $ ipServiceProtocol )
MAY description )
olcObjectClasses: {4}( 1.3.6.1.1.1.2.4 NAME 'ipProtocol'
DESC 'Abstraction of an IP protocol' SUP top STRUCTURAL
MUST ( cn $ ipProtocolNumber $ description ) MAY
description )
olcObjectClasses: {5}( 1.3.6.1.1.1.2.5 NAME 'oncRpc' DESC
'Abstraction of an ONC/RPC binding' SUP top STRUCTURAL
MUST ( cn $ oncRpcNumber $ description ) MAY description )
olcObjectClasses: {6}( 1.3.6.1.1.1.2.6 NAME 'ipHost' DESC
'Abstraction of a host, an IP device' SUP top AUXILIARY
MUST ( cn $ ipHostNumber ) MAY ( l $ description $ manager
) )

NOTE: the numbers in the {brackets}. The new objectclass will use the next available number.

Next, create an ldif with the attributeType or objectClass information you wish to add:

vi customattribute.ldif

Enter the following statements modified for the attributeType or objectClass:

dn: cn={3}customcosine,cn=schema,cn=config
changetype: modify
add: olcAttributeTypes
olcAttributeTypes: (1.3.6.1.1.1.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match SUBSTR
caseExactIA5SubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.26 )

Or (remember to update the number in the {brackets} from the search results above):

dn: cn={3}customcosine,cn=schema,cn=config
changetype: modify
add: olcObjectClasses
olcObjectClasses: {6}( 1.3.6.1.1.1.2.9 NAME 'nisMap' DESC
'A generic abstraction of a NIS map' SUP top STRUCTURAL
MUST nisMapName MAY description )

Finally, import the ldif using ldapmodify:

/opt/symas/bin/ldapmodify -x -H ldap://<server FQDN>/ -D <cn=config rootDN> -W -f
customattribute.ldif

Use the cn=config database rootPW when removing ObjectClasses or Attributes, ensure the value is not used by performing a simple ldapsearch:

/opt/symas/bin/ldapsearch -x -H ldap://<server FQDN>/ -D <rootDN> -w <rootPW> -b dc=example,dc=com -LLL '(<attribute>=*)'

/opt/symas/bin/ldapsearch -x -H ldap://<server FQDN>/ -D <rootDN> -w <rootPW> -b dc=example,dc=com -LLL '(Objectclass=<objectClass>)'

Next, create an ldif with the attributeType or objectClass information you wish to delete:

vi customattribute.ldif

Enter the following statements modified for the attributeType or objectClass:

dn: cn={3}customcosine,cn=schema,cn=config
changetype: delete
add: olcAttributeTypes
olcAttributeTypes: (1.3.6.1.1.1.1.12 NAME 'memberUid'
EQUALITY caseExactIA5Match SUBSTR
caseExactIA5SubstringsMatch SYNTAX
1.3.6.1.4.1.1466.115.121.1.26 )

Or (remember to update the number in the {brackets} from the search results above):

dn: cn={3}customcosine,cn=schema,cn=config
changetype: modify
delete: olcObjectClasses
olcObjectClasses: {6}

Finally, import the ldif using ldapmodify:

/opt/symas/bin/ldapmodify -x -H ldap://<server FQDN>/ -D <cn=config rootDN> -W -f customattribute.ldif

Use the cn=config database rootPW.

Adding/Removing MAY Attributes

For slapd.conf

Add the MAY attribute to the custom schema file on all servers.

Restart slapd on all servers (Consumers first, then Producers)

sudo systemctl start slapd

For slapd.d

Follow the process for ObjectClasses and MUST Attributes above.