Hi,
I'm currently busy re-newing my mail server using LDAP instead of SQL based backend. Therwith I also want to implement LDAP based aliases. From my current point of understanding, it is a bad idea to provide aliases directly in the user object as e.g.:
Why? Because a user can have multiple mail[AlternateAddress] attributes - meaning the user has a couple of email addresses hosted. Setting up an alias within this object would then apply to all mail addresses of this user.
This was not an option for me neither did I feel comfortable puting sub containers under the user for each email address and potential aliases. The reason for this imply lies in password maintenance - or better said: user should have one master password. This is why I decided to have a separate alias OU in where I can store all aliases - more fine tuned - for each email address specifically on its own. So I was dreaming of something like this as alias leave:
I'm not too well oiled when it comes to know the potentials of LDAP's objectclasses. Now my question is what objectclasses to use best for each alias leave? Of course I could rape a regular fake user (top person inetOrgPerson) for this but I wouldn't want, because it provides so many attributes which wouldn't be required - and an alias is not a person
. For my virtual domains I found a simple suitable and bare minimum solution (dnsDomain domainrelatedobject) - and similar I want to do with the aliases.
Is there recommentable objectclasses? Or a better solution? Personally I would prefer not to add any additional LDAP schemata - except if there is good reason for.
Here is the most important LDIFs to understand my LDAP DB structure:
I'm currently busy re-newing my mail server using LDAP instead of SQL based backend. Therwith I also want to implement LDAP based aliases. From my current point of understanding, it is a bad idea to provide aliases directly in the user object as e.g.:
Code:
# Bad Example User
dn: uid=username,ou=people,${DCs,,}
cn: Username
gidnumber: 2112
[...]
mail: My-01-Mail-Address@MyDomain.TLD
mail: My-02-Mail-Address@MyDomain.TLD
mailAlternateAddress: My-03-Mail-Address@OtherDomain.TLD
mailAlternateAddress: My-04-Mail-Address@OtherDomain.TLD
mailForwardingAddress: allMail@MyDomain.TLD
mailForwardingAddress: allMail@OtherDomain.TLD
[...]
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: shadowAccount
uid: username
uidnumber: 2112
[...]
This was not an option for me neither did I feel comfortable puting sub containers under the user for each email address and potential aliases. The reason for this imply lies in password maintenance - or better said: user should have one master password. This is why I decided to have a separate alias OU in where I can store all aliases - more fine tuned - for each email address specifically on its own. So I was dreaming of something like this as alias leave:
Code:
dn: ou=My-02-Mail-Address@MyDomain.TLD,ou=aliases,ou=mail,${DCs,,}
mailDeliveryOption: forward
mailForwardingAddress: allMail@MyDomain.TLD
mailForwardingAddress: allMail@OtherDomain.TLD
I'm not too well oiled when it comes to know the potentials of LDAP's objectclasses. Now my question is what objectclasses to use best for each alias leave? Of course I could rape a regular fake user (top person inetOrgPerson) for this but I wouldn't want, because it provides so many attributes which wouldn't be required - and an alias is not a person
Is there recommentable objectclasses? Or a better solution? Personally I would prefer not to add any additional LDAP schemata - except if there is good reason for.
Here is the most important LDIFs to understand my LDAP DB structure:
Code:
# People Container
dn: ou=people,${DCs,,}
objectClass: top
objectClass: organizationalUnit
ou: people
# Example User
dn: uid=username,ou=people,${DCs,,}
cn: Username
displayname: Username
gidnumber: 2112
givenname: Username
homedirectory: /home/username
loginshell: /usr/local/bin/bash
mail: My-01-Mail-Address@MyDomain.TLD
o: MyCorporation
objectclass: top
objectclass: person
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: shadowAccount
sn: Surname
telephonenumber: +123456789
uid: username
uidnumber: 2112
userpassword: ${RANDOM}
# Mail Container
dn: ou=mail,${DCs,,}
objectClass: top
objectClass: organizationalUnit
ou: mail
# Aliases Container
dn: ou=aliases,ou=mail,${DCs,,}
objectClass: top
objectClass: organizationalUnit
ou: aliases
# Domains Container
dn: ou=domains,ou=mail,${DCs,,}
objectClass: top
objectClass: organizationalUnit
ou: domains
# Domain Example
dn: dc=Mydomain.TLD,ou=domains,ou=mail,${DCs,,}
objectClass: dnsDomain
objectClass: domainrelatedobject
dc: Mydomain.TLD
description: Xaver & Angelika
seeAlso: uid=User-01,ou=people,${DCs,,}
seeAlso: uid=User-02,ou=people,${DCs,,}
associateddomain: Mydomain.TLD