I would be really handy if FreeIPA would support a bit of separation between mail fields in LDAP to better integrate with e-mail solutions, e.g.
and support maybe even quota:
(source: http://iredmail.googlecode.com/svn/trunk/iRedMail/samples/iredmail.schema)
I know this is managable by running separate LDAP for e-mail specifics, or updating FreeIPA LDAP servers with this other schema, but that lacks integrity and ease-of-use without UI and CLI.
Particularly I ran into this while setting up postfix+freeipa where I map groups to 'distribution lists':
$ postconf virtual_alias_maps virtual_alias_maps = hash:/etc/postfix/virtual_aliases.cf, ldap:/etc/postfix/virtual_aliasgrps_idm.cf $ sudo cat /etc/postfix/virtual_aliasgrps_idm.cf server_host = ldap://ipa.example.com search_base = cn=groups,cn=accounts,dc=example,dc=com query_filter = (&(objectClass=ipausergroup)(cn=%u)) result_attribute = mail special_result_attribute = member bind = yes bind_dn = uid=ipabind,cn=users,cn=accounts,dc=example,dc=com bind_pw = <secret!> dereference = 0 start_tls = yes version = 3 tls_ca_cert_file = /etc/ipa/ca.crt tls_require_cert = yes
It works fine if user has only mail entry, but once 2 or more are specified, user gets same e-mail twice, thrice, etc...:
$ ipa user-show martin --raw | grep mail mail: martin@example.com # postmap -q admins ldap:/etc/postfix/virtual_aliasgrps_idm.cf martin@example.com $ ipa user-mod martin --addattr=mail=example@example.com $ ipa user-show martin --raw | grep mail mail: martin@example.com mail: example@example.com # postmap -q admins ldap:/etc/postfix/virtual_aliasgrps_idm.cf martin@example.com,example@example.com
Plus, I'm not sure how 'Realm Domains' are populated, but they might be used for additional 'Alias Domains', e.g. example.local -> example.com, or some other field like mailAlias would be helpful, too.
Well, seems this is partially manageable just by adding 'mailRecipient' objectClass to user's default attributes:
$ ipa config-mod --addattr=ipaUserObjectClasses=mailRecipient
And then just using CLI:
# this could get it's own plugin, where domain part would be verified against 'ipadefaultemaildomain' $ ipa user-mod --addattr=mailAlternateAddress=example@example.com # while this could get any 3rd party domain $ ipa user-mod --addattr=mailForwardingAddress=example@anotherexample.com # and for mailQuota $ ipa user-mod --addattr=mailQuota=4G
Although, I'm not sure if I get the LDAP attribs meanings correctly, as described e.g. in: https://docs.oracle.com/cd/E19566-01/819-4437/6n6jckqrg/index.html
WebUI needs plugin(s) anyway.
And there's still question of disallowing multiple mail fields, since that e.g. breaks reject_sender_login_mismatch/smtpd_sender_login_maps, or causes mentioned duplicates on delivery.
Mail as multivalued attribute is commonly used: http://www.zytrax.com/books/ldap/ape/core-schema.html#mail Limiting it to be a single value attribute is not a backwards compatible change.
Adding the other object classes/attributes is tight to a very specific, i.e. not general, use case/mail server. As such it should not be a part of core FreeIPA but it should be rather developed as a plugin.
Community contribution is welcome. FreeIPA core team can provide guidance if needed.
Acknowledged. I have resolved the e-mail address duplication by re-writing LDAP query, thanks to FreeIPA/LDAP's forward- and back-references it should play nicely. I just wonder if there won't be any performance implications.
As stated originally for '/etc/postfix/virtual_aliasgrps_idm.cf', the new query is:
$ sudo cat /etc/postfix/virtual_aliasgrps_idm.cf server_host = ldap://ipa.example.com search_base = cn=users,cn=accounts,dc=example,dc=com query_filter = (&(objectClass=posixaccount)(objectClass=inetorgperson)(memberof=cn=%u,cn=groups,cn=accounts,dc=example,dc=com)) result_attribute = uid bind = yes bind_dn = uid=ipabind,cn=users,cn=accounts,dc=example,dc=com bind_pw = <secret!> dereference = 0 start_tls = yes version = 3 tls_ca_cert_file = /etc/ipa/ca.crt tls_require_cert = yes
While NO ACTIONS from comment ticket:5521#comment:1 are necessary to do this. I will try to test this from all angles and post 'Postfix integration' to HOWTO Wikis.
Little things like mailQuota or Bcc maps are still nice features. I would like to develop a plugin for it, is this https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf set of slides good / valid place to start?
Replying to [comment:3 mstefany]:
I would like to develop a plugin for it, is this https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf set of slides good / valid place to start?
Yes. And this http://www.freeipa.org/page/Contribute.
This would be nice to have in the UI, is there being worked on ?
Nobody from FreeIPA core team is working on it. Comment 2 still reflects current state.
Replying to [comment:6 pvoborni]:
OK, I think this would be good to have it in as most people won't move over from *SQL to Ldap lookups now.
As this is not my type of thing to develop I will look what I can do when I tested out the manual attribute way.
I was looking @ some old ticket and found this:
https://github.com/pdf/freeipa-user-mailalternateaddress
It seems pretty up-to-date?
Replying to [comment:8 yamakasy]:
I was looking @ some old ticket and found this: https://github.com/pdf/freeipa-user-mailalternateaddress It seems pretty up-to-date?
It's not currently compatible with FreeIPA 4.4+, I will try and update it in the next week or so. It also doesn't use the built-in schema plugin update mechanism or have packaging data, but I'll likely not have the time to sort those out in the near future.
It also only supports mailAlternateAddress (per https://fedorahosted.org/freeipa/ticket/2863)
yes I came to your repo because of #2863
I will keep your GitHub repo checked, thanks!
Metadata Update from @mstefany: - Issue assigned to someone - Issue set to the milestone: Plugins
Thank you taking time to submit this request for FreeIPA. Unfortunately this bug was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfil this request I am closing the issue as wontfix. To request re-consideration of this decision please reopen this issue and provide additional technical details about its importance to you.
Metadata Update from @rcritten: - Issue close_status updated to: wontfix - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.