1

I have an OpenBSD 7.1 server with the LDAPD service running. At the moment it is working as expected, however I am new to managing an LDAP organization, and am unsure about some of the configuration settings I have. As a quick side note - despite the descriptions and wording in the configuration, this LDAP server is only for personal use and not for business purposes.

This is currently my running configuration:

listen on lo0 secure
listen on 10.42.19.5 ldaps certificate "/etc/ssl/hypnos/cert"

schema "/etc/ldap/core.schema"
schema "/etc/ldap/inetorgperson.schema"
schema "/etc/ldap/nis.schema"
schema "/etc/ldap/bsd.schema"

namespace "dc=spookyinternet,dc=com" {
  rootdn "dc=spookyinternet,dc=com"
  rootpw "{SSHA}3zOLoePUtznUxOMAqMCngEIw4o9FeS9KNXA5Wg=="
  index "uid"
  index "cn"
}

allow read access to subtree "dc=spookyinternet,dc=com" by self
deny read access to subtree "ou=personnel,dc=spookyinternet,dc=com" attribute "userPassword"
allow read,write access to subtree "ou=personnel,dc=spookyinternet,dc=com" attribute "userPassword" by self
allow read,write access to subtree "ou=personnel,dc=spookyinternet,dc=com" attribute "description" by self

I have created an initial structure out of this LDIF (/tmp/org.ldif):

dn: dc=spookyinternet,dc=com
objectclass: dcObject
objectclass: organization
dc: spookyinternet
o: spookyinternet.com LDAP Server
description: Root entry for spookyinternet.com

dn: ou=personnel,dc=spookyinternet,dc=com
objectclass: organizationalUnit
ou: personnel
description: All employees of Spooky Internet

dn: ou=services,dc=spookyinternet,dc=com
objectclass: organizationalUnit
ou: services
description: All sevices provided by Spooky Internet

dn: ou=domains,dc=spookyinternet,dc=com
objectclass: organizationalUnit
ou: domains
description: All domains managed by Spooky Internet

dn: dc=spookyinternet.com,ou=domains,dc=spookyinternet,dc=com
objectclass: domain
dc: spookyinternet.com
description: Primary domain

And was able to successfully import it with the following command:

ldapadd -vv -w 'correct horse battery staple' -H ldap://localhost/ -D dc=spookyinternet,dc=com -f /tmp/org.ldif

After completing the above, my questions are:

  • Some of the guides I looked at (specifically this) use a rootdn along the lines of cn=admin,dc=spookyinternet,dc=com. What is the difference between that and just dc=spookyinternet,dc=com for a rootdn?
  • If cn=admin should be used for the rootdn, is this a user that I need to create afterwards?
  • What is the difference between the rootdn in the configuration and the binddn I passed to ldapadd via the -D flag?
  • If the cn=admin rootdn should be used, is that what I should use for the binddn as well?
uplime
  • 25
  • 4

1 Answers1

3

Most LDAP servers simply use DNs as account names. The "bind DN" parameter in clients is your username for accessing the LDAP database, and the "root DN" parameter in ldapd.conf specifies which account will be granted root privileges to the database.

(The account specified in "rootdn" is allowed to bypass the 'allow/deny' restrictions defined in your ldapd.conf – it can read or write any attributes of any entry.)

Some of the guides I looked at (specifically this) use a rootdn along the lines of cn=admin,dc=spookyinternet,dc=com. What is the difference between that and just dc=spookyinternet,dc=com for a rootdn?

If cn=admin should be used for the rootdn, is this a user that I need to create afterwards?

The rootdn can be used in two ways:

  1. If rootpw is also defined, then the DN is completely arbitrary and doesn't have any correspondence to a real entry – all binds (logins) are simply verified against the configured 'rootpw'. It's up to you whether you add a "cn=admin" or not.

  2. If rootpw is not defined, then the specified DN must indeed exist in your LDAP database, and it must have a userPassword attribute which will be used to verify authentication.

    In this case, it's simply more logical to use a user account entry (whether it's named "cn=admin, dc=foo" or something else) than to put the userPassword attribute on your toplevel organization entry.

    (Though the schema does permit 'organization' object class to have a userPassword, so you can still do that if you wish, but it's weird.)

(Note: I'm more familiar with OpenLDAP, but as far as I've checked, OpenBSD's ldapd behaves the same way here.)

What is the difference between the rootdn in the configuration and the binddn I passed to ldapadd via the -D flag?

They're two ends of the same thing. Ldapadd's -D specifies the account name to be used for the operation, ldapd.conf's rootdn specifies whether that account has root privileges or not.

If the cn=admin rootdn should be used, is that what I should use for the binddn as well?

Yes if you want to connect with 'root' database privileges.

If you want to connect as a normal unprivileged user, then specify that user's DN as the "bind DN".

Any LDAP entry that has a userPassword attribute, regardless of its objectClass, can be bound to (i.e. used as an account for LDAP operations).

user1686
  • 10,162
  • 1
  • 26
  • 42