IPG Doc

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== cn=config ======
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.

===== cn=config manager =====
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:
<code>
olcRootDN: cn=manager,cn=config
olcRootPW: {SSHA}2c.......
</code>
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.

===== add a schema =====
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.
<code>
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

</code>
With the code lines above we created the //.ldif// file containing the information about the kerberos schema we want to add:
  * The schema is provided by the //krb5-server-ldap// package on Centos 6.2.
  * The ls -R command shows the structure created by the **slaptest** conversion utility inside the /tmp/newschema, **the base directory, passed with the -F option MUST exist**.\\
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:
  - the line defining the record must be changed to remove any reference to the index position of the record
  - the lines defining the creation of the record must be deleted from the file.
in our case, we changed the first 3 lines of the file "cn=config/cn=schema/cn={0}kerberos.ldif" from:
<code>
dn: cn={0}kerberos
objectClass: olcSchemaConfig
cn: {0}kerberos
</code>
to
<code>
dn: cn=kerberos,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: kerberos
</code>

then we deleted the last 7 lines of the files, from:
<code>
entryUUID: ........
creatorsName: cn=config
createTimestamp: .....
entryCSN: ......
modifiersName: cn=config
modifyTimestamp: ......
</code>
to
<code>
[empty line]
</code>
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:
<code>
ldapadd -x -D "cn=manager,cn=config" -W -f /tmp/newschema/cn\=config/cn\=schema/cn\=\{0\}kerberos.ldif
</code>
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.


===== change informations about the user rigths =====
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:
<code>
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

</code>

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 access the "olcDatabase={-1}frontend,cn=config"
  - modify the record by
  - deleting an olcAccess field
  - the olcAccess field to delete is the one called "{0}"
  - then (the line with just a - [dash] is to tell the ldap utility that the command is not complete)
  - we wand to add a new olcAccess field
  - the content of the new olcAccess field must be ..... (all the text following the ":")
  - [empty line] is used to inform the ldap utility that he command is complete
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).