Hi!
I've browsed the configuration page for slapd[1] and it mentions that, for starting from version 2.3, "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect."
What is the user and password required to update the LDAP configuration database?
I'm using slapd 2.4.23-7 on a Debian Squeeze (testing). I've tried using the admin user (cn=admin,dc=...,dc=...) and it fails. This link[2] mentions using the cn=admin,dc=config account and a password found in ldap.secret. I've not found that file and don't know what is the password for the cn=admin,dc=config account.
Thanks, Razvan
Razvan Deaconescu wrote:
Hi!
I've browsed the configuration page for slapd[1] and it mentions that, for starting from version 2.3, "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect."
What is the user and password required to update the LDAP configuration database?
I'm using slapd 2.4.23-7 on a Debian Squeeze (testing). I've tried using the admin user (cn=admin,dc=...,dc=...) and it fails. This link[2] mentions using the cn=admin,dc=config account and a password found in ldap.secret. I've not found that file and don't know what is the password for the cn=admin,dc=config account.
The rootdn of the cn=config database, like any other database. By default, it's cn=config.
p.
On 28/01/11 16:54 +0200, Razvan Deaconescu wrote:
Hi!
I've browsed the configuration page for slapd[1] and it mentions that, for starting from version 2.3, "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect."
What is the user and password required to update the LDAP configuration database?
I'm using slapd 2.4.23-7 on a Debian Squeeze (testing). I've tried using the admin user (cn=admin,dc=...,dc=...) and it fails. This link[2] mentions using the cn=admin,dc=config account and a password found in ldap.secret. I've not found that file and don't know what is the password for the cn=admin,dc=config account.
Try 'slapcat -n0', and see what, if any, olcRootDN and olcRootPW settings you have listed under olcDatabase={0}config,cn=config. The config backend maintains it's own rootdn and rootpw settings.
If those options are missing, you could try rebuilding your config from scratch from your own slapd.conf, by explicitly setting those options with this config snippet:
database config rootdn "cn=admin,dc=example,dc=org" rootpw xxx
That would involve moving your existing /etc/ldap/slapd.d and /var/lib/ldap directories out of the way and regenerating them.
Another option might be to stop slapd, and manually edit the /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif file to add those options, but I believe that approach is considered unsupported.
Dan White wrote:
On 28/01/11 16:54 +0200, Razvan Deaconescu wrote:
Hi!
I've browsed the configuration page for slapd[1] and it mentions that, for starting from version 2.3, "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect."
What is the user and password required to update the LDAP configuration database?
I'm using slapd 2.4.23-7 on a Debian Squeeze (testing). I've tried using the admin user (cn=admin,dc=...,dc=...) and it fails. This link[2] mentions using the cn=admin,dc=config account and a password found in ldap.secret. I've not found that file and don't know what is the password for the cn=admin,dc=config account.
Try 'slapcat -n0', and see what, if any, olcRootDN and olcRootPW settings you have listed under olcDatabase={0}config,cn=config. The config backend maintains it's own rootdn and rootpw settings.
If those options are missing, you could try rebuilding your config from scratch from your own slapd.conf, by explicitly setting those options with this config snippet:
database config rootdn "cn=admin,dc=example,dc=org" rootpw xxx
You can't set the "rootpw" for a "rootdn" outside the naming context of a database. Either set
database config rootdn "cn=admin,dc=example,dc=org"
or
database config rootdn "cn=admin,cn=config" rootpw xxx
In the first case, the user "cn=admin,dc=example,dc=org" will need to authenticate otherwise (e.g. from within another database, or using SASL).
That would involve moving your existing /etc/ldap/slapd.d and /var/lib/ldap directories out of the way and regenerating them.
Another option might be to stop slapd, and manually edit the /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif file to add those options, but I believe that approach is considered unsupported.
Manually modifying those files is *strongly discouraged*.
p.
On 28/01/11 16:34 +0100, Pierangelo Masarati wrote:
You can't set the "rootpw" for a "rootdn" outside the naming context of a database. Either set
Ok, I'm finally starting to get a grasp on cn=config. If I understand correctly, there will always be a rootdn for cn=config, regardless if one one specified in the original slapd.conf. If one was not, the rootdn will default to 'cn=config' (or is it cn=admin,dc=config?).
database config rootdn "cn=admin,dc=example,dc=org"
or
database config rootdn "cn=admin,cn=config" rootpw xxx
In the first case, the user "cn=admin,dc=example,dc=org" will need to authenticate otherwise (e.g. from within another database, or using SASL).
Is there a supported way to generate or modify the appropriate authz-regexp config for SASL authentication, assuming that one did not exist within the original slapd.conf?
I've heard mention of a slapmodify command in a future version, so I'm assuming that's going to be the supported solution.
On 01/28/2011 05:24 PM, Dan White wrote:
On 28/01/11 16:54 +0200, Razvan Deaconescu wrote:
Hi!
I've browsed the configuration page for slapd[1] and it mentions that, for starting from version 2.3, "The LDAP configuration engine allows all of slapd's configuration options to be changed on the fly, generally without requiring a server restart for the changes to take effect."
What is the user and password required to update the LDAP configuration database?
I'm using slapd 2.4.23-7 on a Debian Squeeze (testing). I've tried using the admin user (cn=admin,dc=...,dc=...) and it fails. This link[2] mentions using the cn=admin,dc=config account and a password found in ldap.secret. I've not found that file and don't know what is the password for the cn=admin,dc=config account.
Try 'slapcat -n0', and see what, if any, olcRootDN and olcRootPW settings you have listed under olcDatabase={0}config,cn=config. The config backend maintains it's own rootdn and rootpw settings.
There is only the olcRootDN setting: --- # slapcat -n0 | grep -C 5 '^(olcRootDN|olcRootPW)' olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: ed743d3a-adc6-102f-9a18-f1967b980507 creatorsName: cn=config ---
If those options are missing, you could try rebuilding your config from scratch from your own slapd.conf, by explicitly setting those options with this config snippet:
database config rootdn "cn=admin,dc=example,dc=org" rootpw xxx
That would involve moving your existing /etc/ldap/slapd.d and /var/lib/ldap directories out of the way and regenerating them.
So I have to regenerate all configuration and database files?
I might have done something wrong, but it seems pretty strange that a default Debian installation wouldn't provide the config user/password for this.
Razvan
On 28/01/11 19:10 +0200, Razvan Deaconescu wrote:
# slapcat -n0 | grep -C 5 '^(olcRootDN|olcRootPW)' olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: ed743d3a-adc6-102f-9a18-f1967b980507 creatorsName: cn=config
If those options are missing, you could try rebuilding your config from scratch from your own slapd.conf, by explicitly setting those options with this config snippet:
database config rootdn "cn=admin,dc=example,dc=org" rootpw xxx
That would involve moving your existing /etc/ldap/slapd.d and /var/lib/ldap directories out of the way and regenerating them.
So I have to regenerate all configuration and database files?
I might have done something wrong, but it seems pretty strange that a default Debian installation wouldn't provide the config user/password for this.
I have discovered this myself, and I personally just rebuild from my own slapd.conf. I just took a look at the debian/slapd.conf template file in squeeze, which presumably is what the package installation uses to ultimately generate the slapd.d config backend. I've copied it here:
http://web.olp.net/dwhite/openldap/slapd-squeeze-default.conf
This config is missing two pretty important items in my opinion:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,@SUFFIX@"
and
database config rootdn "cn=admin,@SUFFIX@"
See:
http://www.openldap.org/lists/openldap-technical/201101/msg00047.html
Dan White wrote:
I have discovered this myself, and I personally just rebuild from my own slapd.conf. I just took a look at the debian/slapd.conf template file in squeeze, which presumably is what the package installation uses to ultimately generate the slapd.d config backend. I've copied it here:
http://web.olp.net/dwhite/openldap/slapd-squeeze-default.conf
This config is missing two pretty important items in my opinion:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,@SUFFIX@"
and
database config rootdn "cn=admin,@SUFFIX@"
See:
http://www.openldap.org/lists/openldap-technical/201101/msg00047.html
Your recommendation assumes that a typical slapd installation has only one main database, and the local host sysadmin is also the LDAP DB admin. In other scenarios where there are multiple databases, it's more appropriate to leave the cn=config rootdn at its default and separate the role of slapd administrator from regular database admin.
On 28/01/11 12:06 -0800, Howard Chu wrote:
Dan White wrote:
This config is missing two pretty important items in my opinion:
authz-regexp "gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=admin,@SUFFIX@"
and
database config rootdn "cn=admin,@SUFFIX@"
Your recommendation assumes that a typical slapd installation has only one main database, and the local host sysadmin is also the LDAP DB admin. In other scenarios where there are multiple databases, it's more appropriate to leave the cn=config rootdn at its default and separate the role of slapd administrator from regular database admin.
I now understand that reasoning.
The approach that package maintainers, like Debian, have taken is:
Answer these 3 basic questions and you've got a minimally functioning server.
If you like, customize slapd.conf to your heart's content, and restart.
But that approach no longer works with the move to the config backend. To be fair, it's not really feasible to have a one-size-fits-all config within the package that's going to lead to a robust installation.
I suppose the correct approach would be for the package to offer to configure a rootdn and rootpw for the config backend on installation, however, since the package that will be released with squeeze will probably not have those options, it's inevitable that the OP's question is going to be posted here a lot, and generally annoy list members.
On 01/28/2011 10:51 PM, Dan White wrote:
I suppose the correct approach would be for the package to offer to configure a rootdn and rootpw for the config backend on installation, however, since the package that will be released with squeeze will probably not have those options, it's inevitable that the OP's question is going to be posted here a lot, and generally annoy list members.
As there was no slapd.conf ("old" way) config file, I found the easiest way was to add a olcRootPW option to the olcDatabase={0}config file (password generated using slappasswd) and then restarting the server.
I understood Pierangelo's point that manually editing these files is discouraged, but I didn't find a better way.
Razvan
On Friday, 28 January 2011 22:51:05 Dan White wrote:
I suppose the correct approach would be for the package to offer to configure a rootdn and rootpw for the config backend on installation, however, since the package that will be released with squeeze will probably not have those options, it's inevitable that the OP's question is going to be posted here a lot, and generally annoy list members.
But questions specific to one distribution's default OpenLDAP configuration really should be asked and answered on that distributions support fora (documentation, mailing lists, web forum etc.).
Regards, Buchan
Yeah, it's an S.E.P.
Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs@apollogrp.edu
----- Original Message ----- From: openldap-technical-bounces@OpenLDAP.org openldap-technical-bounces@OpenLDAP.org To: openldap-technical@openldap.org openldap-technical@openldap.org Cc: Dan White dwhite@olp.net Sent: Mon Jan 31 00:15:26 2011 Subject: Re: Authentication for on the fly configuration updates in OpenLDAP 2.4
On Friday, 28 January 2011 22:51:05 Dan White wrote:
I suppose the correct approach would be for the package to offer to configure a rootdn and rootpw for the config backend on installation, however, since the package that will be released with squeeze will probably not have those options, it's inevitable that the OP's question is going to be posted here a lot, and generally annoy list members.
But questions specific to one distribution's default OpenLDAP configuration really should be asked and answered on that distributions support fora (documentation, mailing lists, web forum etc.).
Regards, Buchan
This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
openldap-technical@openldap.org