Issues while integrating with Microsoft Active Directory

[Dan White]

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 at 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 at example.com
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