1

Topic: Features disabled due to AD integration

Hello,

Could someone tell me what are the features getting disabled after an AD integration ?

Same question with iredadmin pro, is it useful to buy it ? What features will be disabled ?

Thanks

2

Re: Features disabled due to AD integration

*) iRedMail (OpenLDAP edition) has its own LDAP schema, many features depend on this LDAP schema. For example, per-user/per-domain transport setting, mail service restrictions, bcc/catch-all, etc.

*) iRedAdmin-Pro doesn't work with AD, so don't purchase it if you're going to integrate AD with iRedMail.

3 (edited by nicolasfo 2014-06-16 16:32:02)

Re: Features disabled due to AD integration

Hello,

Is there a way to split what you store in a LDAP (or MYSQL) database for all goodies iRedMail offers and the authentication of users ?

AD database handles only users authentication and all the rest of data (catchall, quota etc) will be handle by a MySQL database (for example).

Do you think it's possible (I don't ask you to do it, just to know if you consider it could be done ?)

I think it's possible to do it, but i'll have to create the user in the AD database and in the Mysql database with the same email adress (it looks like obvious...). I don't care to create each users 2 times if they can use the same password later and be responsible of their account.

Thanks

Nicolas

4 (edited by nicolasfo 2014-06-16 19:37:12)

Re: Features disabled due to AD integration

I just tested my solution, it seems to work, here's how I did for those interested :
I start with a iRedadmin MySQL backend server.

First, install iRedMail with MySQL backend. When install is complete, install postfix-ldap, dovecot-ldap and ldap-utils packages.

I used this page to help me.

Configure postfix :

Create those files (touch) :

# touch /etc/postfix/ldap/ad_virtual_mailbox_maps.cf 
# touch /etc/postfix/ldap/ad_virtual_group_maps.cf 
# touch /etc/postfix/ldap/ad_sender_login_maps.cf

Don't disable iRedmail special settings as said in the howto.

Edit "smtpd_sasl_local_domain" and "transport_maps" like said in the howto.

Enable AD query :

Verify SMTP senders :

# postconf -e smtpd_sender_login_maps='proxy:ldap:/etc/postfix/ldap/ad_sender_login_maps.cf'

Used to verify local mail users :

# postconf -e virtual_mailbox_maps='proxy:ldap:/etc/postfix/ldap/ad_virtual_mailbox_maps.cf'

Used to verify local mail lists/groups :

# postconf -e virtual_alias_maps='proxy:ldap:/etc/postfix/ldap/ad_virtual_group_maps.cf \
proxy:mysql:/etc/postfix/mysql/virtual_alias_maps.cf, \
proxy:mysql:/etc/postfix/mysql/domain_alias_maps.cf, \
proxy:mysql:/etc/postfix/mysql/catchall_maps.cf, \
proxy:mysql:/etc/postfix/mysql/domain_alias_catchall_maps.cf'

As you can see, just add the LDAP entry to the existent line.


Don't create /etc/postfix/transport (still stored in MySQL database)


Edit /etc/postfix/ldap/ad_sender_login_maps.cf :

server_host     = ad.example.com
server_port     = 389
version         = 3
bind            = yes
start_tls       = no
bind_dn         = vmail
bind_pw         = password_of_vmail
search_base     = cn=users,dc=example,dc=com
scope           = sub
query_filter    = (&(userPrincipalName=%s)(objectClass=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
result_attribute= userPrincipalName
debuglevel      = 0

Edit /etc/postfix/ldap/ad_virtual_mailbox_maps.cf :

server_host     = ad.example.com
server_port     = 389
version         = 3
bind            = yes
start_tls       = no
bind_dn         = vmail
bind_pw         = passwd_of_vmail
search_base     = cn=users,dc=example,dc=com
scope           = sub
query_filter    = (&(objectclass=person)(userPrincipalName=%s))
result_attribute= userPrincipalName
result_format   = %d/%u/Maildir/
debuglevel      = 0

/etc/postfix/ldap/ad_virtual_group_maps.cf : (but still not configured in main.cf)

server_host     = ad.example.com
server_port     = 389
version         = 3
bind            = yes
start_tls       = no
bind_dn         = vmail
bind_pw         = password_of_vmail
search_base     = cn=users,dc=example,dc=com
scope           = sub
query_filter    = (&(objectClass=group)(mail=%s))
special_result_attribute = member
leaf_result_attribute = mail
result_attribute= userPrincipalName
debuglevel      = 0

In the "query filter" and "result_attribute" for each files, I set "mail" in place of "userPrincipalName".
This allows me to only enable users who have an email adress specified in their AD profile. As a result, the default user "administrator" don't have access to the mail server, for example.
I repeat that you cannot set a "search_base" with only "dc=exemple,dc=com". I must create an OU where I store my users. it results : OU=mycompany,dc=example,dc=com".

Verify LDAP queries as mentionned in the howto. Groups you'll create in you AD database must have their "mail" field completed to make the query working.


Configure Dovecot :

Create /etc/dovecot/dovecot-ldap.conf :

hosts           = ad.example.com:389
ldap_version    = 3
auth_bind       = yes
dn              = vmail
dnpass          = passwd_of_vmail
base            = cn=users,dc=example,dc=com
scope           = subtree
deref           = never
user_filter     = (&(userPrincipalName=%u)(objectClass=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
pass_filter     = (&(userPrincipalName=%u)(objectClass=person)(!(userAccountControl:1.2.840.113556.1.4.803:=2)))
pass_attrs      = userPassword=password
default_pass_scheme = CRYPT
user_attrs      = =home=/var/vmail/vmail1/%Ld/%Ln/Maildir/,=mail=maildir:/var/vmail/vmail1/%Ld/%Ln/Maildir/

The same as above, I remplaced "userPrincipalName=%u" by "mail=%u" for the same reasons.


I'm testing if advanced features are working. In a first time, authentications are working well based on the AD database.

To be continued...

5

Re: Features disabled due to AD integration

nicolasfo wrote:

I think it's possible to do it, but i'll have to create the user in the AD database and in the Mysql database with the same email adress (it looks like obvious...). I don't care to create each users 2 times if they can use the same password later and be responsible of their account.

You're right. but i don't plan to make iRedMail + iRedAdmin-Pro work with this architecture.