On 30/04/10 18:08 +0530, Goutam Baul wrote:
We are trying to configure a mail server on RHEL 4.4 using Postfix
2.2.10-1.RHEL4.2,Courier-imap-4.1.3-1.3ES,courier-authlib-0.59.3-10.rh3ES,
maildrop2.0.3, cyrus-sasl-2.1.19-5.EL4.
So far we have been able to push mail using telnet and that mail is also
getting delivered to the respective mailbox whose information is present in
the active directory. This indicates that we can successfully query active
directory using openldap client. We have also tested a mail account using
outlook express and that successfully fetches mails from the server. The
only issue is with the SASL authentication. We have searched in the internet
and found few articles where kerberos has been advised to use for
encryption. We have followed the directions there to configure the Linux
box. The command
We are not trying to implement SSL to communicate with the AD for SASL
authentication. Is it a must?
No.
But when are checking the sasl authentication using the following command:-
testsaslauthd -u bonhi.sengupta -p cescnet_123
0: NO "authentication failed"
Apr 30 20:46:27 mail saslauthd[15653]: do_auth : auth failure:
[user=bonhi.sengupta] [service=imap] [realm=] [mech=ldap] [reason=Unknown]
the /etc/saslauthd file reads as follows:
[root@mail ~]# cat /etc/saslauthd.conf
# /etc/saslauthd.conf
#servers: ldap://127.0.0.1/
servers: ldap://10.50.81.250/
ldap_auth_method: fastbind
ldap_search_base: cn:users,dc=tibs,dc=edu,dc=in
This line looks like a type (cn:users)
#ldap_filter: (|(uid=%u)(uid=%U))
ldap_filter: uid=%u
ldap_timeout: 20
ldap_ssl: no
ldap_start_tls: no
ldap_debug: 255
Reference the saslauthd/LDAP_SASLAUTHD (in the source tarball) file for
documentation on saslauthd ldap configuration.
By default, 'ldap_use_sasl' is off, which means that if you configure
ldap_auth_method for fastbind, the following applies:
The fastbind method (when 'ldap_use_sasl: no') does away with the
search and an extra anonymous bind in auth_bind, but makes two
assumptions:
1. Expanding the ldap_filter expression gives the user's
fully-qualified DN
2. There is no cost to staying bound as a named user
Which means that ldap_filter would need to be something like:
ldap_filter: cn=%u,dc=tibs,dc=edu,dc=in
And that assumes that your usernames appear in the user DN entries within
Active Directory. That is not true of an Active Directory server we use
where I work (which uses actual names instead of usernames).
If that scenario does not work for you, you can try something like this,
which I've verified works with our Active Directory server:
ldap_servers: ldap://192.0.2.1/
ldap_search_base: OU=Users,OU=BTC,DC=example,DC=com
ldap_bind_dn: Administrator@xxxxxxxxxxx
ldap_bind_pw: secret
ldap_use_sasl: no
ldap_auth_method: bind
ldap_filter: (sAMAccountName=%u)
Or you can try:
ldap_servers: ldap://192.168.2.1/
ldap_use_sasl: yes
ldap_mech: DIGEST-MD5
Assuming you can figure out how to do an LDAP sasl bind against Active
Directory, which I haven't been able to do with a non GSSAPI sasl mech.
--
Dan White
