...making Linux just a little more fun!
[ In reference to "Migrating a Mail Server to Postfix/Cyrus/OpenLDAP" in LG#124 ]
René Pfeiffer [lynx at luchs.at]
On Nov 28, 2007 at 1526 -0600, Peter Clark appeared and said:
> [...] > I hope this is not an improper venue for seeking out information. If it is 20 > I apologize and will bugger off. If not, I am writing to you to ask a few > questions about your Postfix/Cyrus/OpenLDAP article.
The Linuxgazette articles are meant to be useful, and if not then the authors usually answer any open questions or at least try to do that. We try to publish any useful answers, so this is why I sent my reply as copy to The Answer Gang list. This helps all people who have similar questions to find possible answers.
> I am not very experienced at all with OpenLDAP so that is where the thrust > of my questions lay. I am trying to use your article and supplied > configurations as a template and modifying as needed.
OpenLDAP isn't easy to set up, so you are in good company. This is not due to the software but to the concepts used in LDAP.
> In your tree design you show > cn=webmail,ou=system,ou=accounts,dc=example,dc=net as a webmail account to > do lookups but it is not referenced at all in the slapd.conf. How is that > portion used.
slapd.conf only configures the basics of the OpenLDAP server process. You can define the directory where the LDAP tree is stored, the root account for the whole tree, the object class definitions to be used, SSL/TLS keys/certificates, indices and access rules. All this information is only used to start the server and then initialise the LDAP backend storage.
An entry such as "cn=webmail,ou=system,ou=accounts,dc=example,dc=net" is really a branch of the LDAP tree. This branch can either be a container for more branches or be an object of its own. The notation alone doesn't tell you what it is. You have to look for the object class of this entry. In my case I used "cn=webmail,ou=system,ou=accounts,dc=example,dc=net" as an example for an account object holding the password for access to the OpenLDAP server. The subsystem could connect to the OpenLDAP server, provide "cn=webmail,ou=system,ou=accounts,dc=example,dc=net" as a kind of login und authenticate with the password contained in the object referenced by "cn=webmail,ou=system,ou=accounts,dc=example,dc=net" in the tree.
That's what I meant by LDAP being a bit difficult to understand. You have branches which can be objects of classes and which can hold a variety of data. If the OpenLDAP servers sees that an object has a password attribute, it will allow a login with this password.
> I am trying to set this (your configuration) up in harmony with Daniel > Marczisovszky's SquirrelMail plugins (ldap_abook_backend and > ldap_prefs_backend). The ACL's and the how it fits with the tree structure > is something I am having a hard time understanding. When I see in your ACL > section you have: > > # Subtrees can be manages by tree admins > access to dn.regex="^cn=[^,]+,ou=marketing,dc=example,dc=net$" > attrs=children > by dn.exact="cn=admin,ou=marketing,dc=example,dc=net" write > > As the article is written this doesn't seem to have a place or be > necessary. Is this some legacy piece from your own configuration? Can it be > removed or does something else depend on it?
This entry is an example configuration. I wanted to show how access lists can be used. This line says that the administrator using the object "cn=admin,ou=marketing,dc=example,dc=net" as login (and providing the correct password contained in its attribute) has write access to any child objects of the branch described by the regular expression "^cn=[^,]+,ou=marketing,dc=example,dc=net$". You can safely remove that 6rom your configuration. However you may add access lists for accounts that need to write to your LDAP tree. SquirrelMail will probably want to store things in the LDAP tree and thus need to have write access somewhere.
> I believe I need to add a ou=addresses for his ldap_abook_backend to > function properly and I do not want to confuse my self with your ACL's > and his suggested ones.
Yes, this is a good strategy. Try to have as few access lists as possible and sparingly add new ones. Too much ACLs (and RegExps) do cause confusion and misconfiguration.
Building ACLs in OpenLDAP basically boils down to the following configuration.
access to DESCRIPTION ATTRIBUTES by USER PERMISSIONSYou grant access to any branch matched by DESCRIPTION. The access is granted to ATTRIBUTES which may be only single attributes or all available. The access is granted to USER (which is most probably a reference to an account object inside your LDAP tree). The kind of access is give by PERMISSIONS. You find all the gory details in section 5.3 of the OpenLDAP manual.
Don't despair when you have no clue after the first readings. I read this section a lot, believe me.
Best wishes, René.