Am 24.01.15 um 18:04 schrieb Michael Ströder:

Leander Schäfer wrote:

...

I'm trying to construct a ldap filter for my Dovecot/Postfix setup which acts as the example pseudo code & result below:

|return uidNumber OF objectClass=posixAccount IF they have a ou=mail AND the mailAddress in this ou=mail IS EQUAL to test@Mydomain.TLD || # User-1, people, Mydomain.TLD dn: uid=||User-1,ou=people,dc=MyDomain,dc=TLD uidNumber: 2110

|

More specific like this while %s holds e.g.: test@Mydomain.TLD:

|search_base = dc=Mydomain,dc=TLD query_filter = ( &(objectClass=posixAccount)(ou=mail)(mailAddress=%s) ) result_attribute = uidNumber |

But obviously uidNumber is being hold by the posixAccount container one level above - and therewith it won't display what I want. Unfortunately I couldn't figure out how to get it work. My LDAP structure looks like this:

=> dc=MyDomain,dc=TLD ==> ou=People ===> uid=User-1 ====> uidNumber=4035 ====> ou=mail =====> mailAddress=test@Mydomain.TLD ===> uid=User-2

Any help would be greatly apprecitated

This won't work.

Can you please explain why your data is so complicated? What's the rationale of having even a separate tree if mail address entries?

Ciao, Michael.

Hi Michael

the structure is everything else then complex - the query/filter is the one which is :) The entire idea is, that each user can have several mail addresses. Yes, therefore I could use the mail attribute within the user itself BUT if I would set an alias in the user, then it would also affect ALL related mail=* addresses of the user. This is not good, since the user may only want to have an alias for certain addresses while others not. So in order to control each email address on its own, I decided to create a sub container named ou=mail under each user in where I put email hosting related information.

To prevent my current problem, I could simply provide uidNumber and gidNumber a second time. But since the posixAccount above ou=mail is holding this information, why should I provide it redundant?!

So I have decided that the mail attribute within the user account is used for general contact information about this person. Meanwhile the mailAddress attribute of my own mail.schema is there to represent one or more mailaccounts of this person.

I attached an example of how I would add users and their mail accounts below:

# ========================================================== #

# Adding posix User Account

This is how I would add a regular user to the LDAP DB:

cat << EOF > ./add_user.ldif dn: uid=User-1,ou=people,dc=MyDomain,dc=TLD objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount uidNumber: 2001 gidNumber: 2001 homeDirectory: /home/User-1 loginShell: /usr/local/bin/bash uid: User-1 userPassword: TopSecretPassword displayName: User-1 givenName: User-1 mail: SomeMail@SomeDomain.TLD telephoneNumber: 0123456 cn: User-1 sn: Surname o: Some Corporation jpegPhoto:< file://Picture.jpg EOF

# Adding ou=mail

Then I would add the User-1's mail container which holds all mail hosting relevant information.

cat << EOF > ./add_users_mail_container.ldif dn: ou=mail,uid=User-1,ou=people,dc=MyDomain,dc=TLD objectclass: top objectclass: organizationalUnit ou: mail EOF

# Adding Mail Accounts

And now I add mail accounts into the ou=mail container. The idea is, that this could be repeated several times with different mailAddress:

cat << EOF > /add_users_mail_account.ldif dn: mailAddress=test@Mydomain.TLD,ou=mail,uid=User-1,ou=people,dc=MyDomain,dc=TLD objectclass: mailAccount mailAddress: test@Mydomain.TLD MailPassword: {SSHA}TopSecretPasswordHash MailAccountStatus: active mailStorageDirectory: /home/User-1/mail #mailAlias: NONE mailDelivery: dovecot mailSizeMax: 10240 mailReplyText: Nothing to reply here mailQuotaSize: 10240 mailQuotaCount: 0 mailservice: smtp mailservice: pop3 mailservice: imap mailservice: managesieve EOF

# ========================================================== #

Best Regards, Leander

Am 24.01.15 um 19:03 schrieb Michael Ströder:

Leander Schäfer wrote:

...

the structure is everything else then complex

It is overly complex.

...

The entire idea is, that each user can have several mail addresses.

I have such a setup with dovecot.

For each *mailbox* (not system user) I have a separate LDAP entry with its own password and multiple aliases.

In my case I'm not using the uidNumber attribute because my dovecot installation simply uses vmail:vmail for user/group ownership of the mailbox files.

But of course you could also add the 'posixAccount' object class to your mailbox entries.

Ciao, Michael.

I'm aware of the vmail:vmail setup. Unfortunately this is not an option for this mail server implementation. Also I don't want to add 'posixAccount' to my mailbox entries - it would overload it, since it also requires lots of additional unused attributes. I would rather add mailUid and mailGid to my schema to keep it as low weight as possible. But it would still not make me happy since this mailUid and mailGid would be exactly the very same as in uidNumber of the user the ou=mail container with the accounts belongs to. Is there maybe a way of implementing a symbloic link? Something like

mailUid === Internal Symbolic Link to ===> uidNumber,userid=User-1,ou=people,dc=netocean,dc=local

Thanks

Am 24.01.15 um 19:31 schrieb Michael Ströder:

Leander Schäfer wrote:

...

I would rather add mailUid and mailGid to my schema to keep it as low weight as possible. But it would still not make me happy since this mailUid and mailGid would be exactly the very same as in uidNumber of the user the ou=mail container with the accounts belongs to. Is there maybe a way of implementing a symbloic link? Something like

Anyway you have to maintain sort of a connection from your mailbox to your system user entry. When having a DN reference (e.g. 'seeAlso') a LDAP client could use the deref control to retrieve attributes from referenced entries. But you would need to convince the dovecot developers to make use of it.

IMO it does not make sense to have separate real mailbox entries for a single system user. Oh well, it's your choice.

Ciao, Michael.

Well, one of the main reasons to get rid of my current SQL based mailserver implementation is that I don't want to maintain account information redundant. Such as UID, GID, etc. This is why grouped mail account related information below the user whom it belongs to. The hope was to keep the relation between "account info" and "account owner" in order to prevent redunant GID und UID.

Thanks, I'm aware of seeAlso, but it only replies the path, not the value to what it points - otherwhise this would be it ;)

I remember, that SQL offered a way of having multiple queries in one ... so the one query could store a result which the second query was using to filter for the final result like this pseudo code

( (SELECT col ==stor to var==> VAR_ONE ) (SELECT col WHERE value = VAR_ONE ) ) If this would be possible with a LDAP filter then this would be the solution to my problem. But I couldn't find any examples like this for an LDAP filter.

Ok, thanks for your support anyway

Best Regards, Leander

Am 24.01.15 um 19:49 schrieb Michael Ströder:

Leander Schäfer wrote:

...

Well, one of the main reasons to get rid of my current SQL based mailserver implementation is that I don't want to maintain account information redundant.

SQL has joins (depending on your SQL DB) but LDAP does not.

...

Thanks, I'm aware of seeAlso, but it only replies the path, not the value to what it points - otherwhise this would be it ;)

I did not only mention attribute 'seeAlso' but also the deref extended control. But this would have to be implemented at the client side (here: dovecot).

Ciao, Michael.

Leander Schäfer wrote:

I have one more question. Which minimal objectclass can I add in order to be able to use "seeAlso"?

Use a decent schema browser to find out. ;-)

Example: https://demo.web2ldap.de:1760/web2ldap/oid?ldap://ldap.uninett.no/dc=uninett...

Enter "seealso" in the input field and hit [Search].

Watch out what's listed under "Usable in these object classes".

Of course you should point web2ldap to your own LDAP server to see what's in your local subschema.

Ciao, Michael.

Am Sat, 24 Jan 2015 19:31:44 +0100 schrieb Michael Ströder michael@stroeder.com:

Leander Schäfer wrote:

...

I would rather add mailUid and mailGid to my schema to keep it as low weight as possible. But it would still not make me happy since this mailUid and mailGid would be exactly the very same as in uidNumber of the user the ou=mail container with the accounts belongs to. Is there maybe a way of implementing a symbloic link? Something like

Anyway you have to maintain sort of a connection from your mailbox to your system user entry. When having a DN reference (e.g. 'seeAlso') a LDAP client could use the deref control to retrieve attributes from referenced entries. But you would need to convince the dovecot developers to make use of it.

[...] For documentation of deref control see https://tools.ietf.org/html/draft-masarati-ldap-deref-00 This document provides some simple examples.

-Dieter

Dieter Klünter wrote:

schrieb Dieter Klünter dieter@dkluenter.de:

...

[...] For documentation of deref control see https://tools.ietf.org/html/draft-masarati-ldap-deref-00 This document provides some simple examples.

Hmm, have OID and control been removed from the code? slapd[5365]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16

Did you load slapo-deref?

With my openSUSE package it's in package openldap2-contrib.

Ciao, Michael.

On 24/01/15 23:06, Dieter Klünter wrote:

Hmm, have OID and control been removed from the code? slapd[5365]: slap_global_control: unrecognized control: 1.3.6.1.4.1.4203.666.5.16

No, it's there. Is the deref overlay enabled for the database in question? Does this show the control? ldapsearch -xLLL -b "" -s base supportedControl