in LDAP all configurations can be registered inside a file /etc/openldap/slapd.con, or inside the DB itself, using the cn=config subtree. The version of openldap >=2.4 use by default the cn=config method, the slapd.conf system can be used but it must be considered abandoned.
Once the slapd configuration is moved to cn=config, all the information about the structure and/or permissions to access the DB must be managed using the cn=config sub-tree whit the manager defined for this tree.
the manager can be defined as you like, but is common to use “cn=manager,cn=config” or “cn=admin,cn=config” as identification.
the passage to cn=config method means that all the variation to the configuration are activated using the standard ldap<modify/add/modrn/search/delete> commands we use to manage the principal DB (the one containing the users/computers/groups/mounts/email informations) and are active immediately, there's no need to stop/relaunch the slapd daemon.
the cn=config manager is defined inside one of the files used by slapd to run the service: /etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif. looking inside you should find 2 fields:
olcRootDN: cn=manager,cn=config
olcRootPW: {SSHA}2c.......
As you probably imagined, they define the name of the manager and the password associated.
in both cases you can change the values of these fields by writing directly inside the file but you must relaunch the slapd service, so it's better to configure these fields correctly before going in production.
In case you need to change the password you can use the slappasswd command that generate an encrypted password of what you passed on the command line or entered interactively.
if you need to add a schema to the slapd configuration, you cannot just add a line, as it happens with the slapd.conf file. Instead you must generate a .ldif file that contain the schema you want to add and only then you can add the schema to the DB in production.
To generate the ldif file containing the schema you can use the same command used to generate the initial cn=config structure from the existing slapd.conf file, but as this means that a new cn=config structure will be created, never use the transform command inside the production slapd.d directory.
It's for sure better that you create a new directory somewhere in the disc and move inside this to create the new ldif and cn=config structure.
mkdir /tmp/newschema
cd /tmp/newschema
cp /usr/share/doc/krb5-server-ldap-1.9/kerberos.schema .
echo >newschema.conf <<EOF
#
include /etc/openldap/schema/kerberos.schema
EOF
slaptest -f newschema.conf -F /tmp/newschema
ls -R /tmp/newschema
/tmp/newschema/:
cn=config
cn=config.ldif
schema.conf
/tmp/newschema/cn=config:
cn=schema
cn=schema.ldif
olcDatabase={0}config.ldif
olcDatabase={-1}frontend.ldif
/tmp/newschema/cn=config/cn=schema:
cn={8}kerberos.ldif
With the code lines above we created the .ldif file containing the information about the kerberos schema we want to add:
Once we have the needed .ldif file, we must edit it so it can be added to an existing structure (the structure files created by slaptest are considered always as independent, so you must not misc existing files with new ones). We do this by changing some lines in the .ldif file the define the schema we want to add:
in our case, we changed the first 3 lines of the file “cn=config/cn=schema/cn={0}kerberos.ldif” from:
dn: cn={0}kerberos
objectClass: olcSchemaConfig
cn: {0}kerberos
to
dn: cn=kerberos,cn=schema,cn=config objectClass: olcSchemaConfig cn: kerberos
then we deleted the last 7 lines of the files, from:
entryUUID: ........ creatorsName: cn=config createTimestamp: ..... entryCSN: ...... modifiersName: cn=config modifyTimestamp: ......
to
[empty line]
Remember that every .ldif file must contain an empty line to complete the command.
Once we do this we can add the new schema to the existing structure of the ldap server we have in production using the command:
ldapadd -x -D "cn=manager,cn=config" -W -f /tmp/newschema/cn\=config/cn\=schema/cn\=\{0\}kerberos.ldif
once inserted the correct password (the -W option means:“ask for the password”), the schema is applied to the existing structure without the need to stop the production DB.
if we need to change the information about who can access in read/write mode certain type of attributes, se can ask to change the cn=config using a ldif file that contain the modifications we want to apply, like this:
dn: olcDatabase={-1}frontend,cn=config
changetype: modify
delete: olcAccess
olcAccess: {0}
-
add: olcAccess
olcAccess: {0} to attrs=sambaLMPassword,sambaNTPassword,sambaPwdMustChange,sambaPwdLastSet,
shadowLastChange by dn.base="cn=manager,dc=....." write by dn.base="uid=sambamanager,
dc=....." write by dn.base="uid=....,ou=...,dc=...." write by
dn.base="uid=....,ou=...,dc=...." write by anonymous auth by self write by * none
with this file we want to change the permission access to certain attributes. these attributes are contained inside the cn=config DB as all the attributes once recorded inside the file slapd.conf. in this case the file ask for:
to apply the modification we must use the ldapmodify utility using this syntax:
* ldapmodify -x -D "cn=manager,cn=config" -W -f <name of the .ldif file>
the system will ask for the password associated with the manager of the cn=config subtree and then it will apply the modification (if the ldif file doesn't contain errors).