[Dovecot] Dovecot authenticating---> Active Directory Win2003

[Romer Ventura]

The only problem with that is that then all of the AD users will have a
virtual account. This includes built-in accounts in AD.

I would take the take to  do LDAP queries against AD and do it so that it
searches the "mail" attribute for the objectClass person. Then in order to
(lets call it activate) activate the user for pop3/imap authentication you
need to fill up the mail field in the user properties in your AD.

I agree with that LDAP is insecure, but using pam_krb5/pam_winbind will make
every single account accessible from pop3/imap


On 12/8/08 5:12 PM, "Jason Gunthorpe" <jgunthorpe at obsidianresearch.com>
wrote:

> On Mon, Dec 08, 2008 at 02:43:53PM +0100, Thomas Siebert wrote:
>> You have to use LDAP as Authentication Backend with Port 3268.
>> 
>> http://wiki.dovecot.org/AuthDatabase/LDAP
> 
> That works but has 3 main drawbacks:
>  1) It is a pain to setup SSL LDAP on both windows and linux. If you
>     don't do this then it is massively insecure
>  2) Passwords must be exchanged in plain text over IMAP. Also no
>     single sign on capabilities.
>  3) There is no redundancy or load balancing if you have
>     multiple ADS servers
> 
> The *best* answer is to use a combination of samba's winbind and
> kerberos. This gives you encryption and mutual authentication between
> dovecot and the ADS server and various non-plaintext options between
> the client and dovecot - plus single sign on capabilities for SSPI or
> kerberdized clients.
> 
> Use dovecot's pam support to call out to pam_winbind/pam_krb5, and the
> native support to call out to winbind for ntlm and spnego. Dovecot's
> native gssapi kerberos rounds things out.
> 
> The basic steps are
>  1) Get samba, winbind, dovecot, kerberos installed
>  1a) Setup smb.conf with the proper ADS options
>    Note you do not need to run nmbd or smbd, just winbind.
>  2) Use samba to join the machine to the domain with
>     'net ads join -U Administrator'
>     Verify in ADS you have a computer with the proper name
>  3) Create an imap keytab entry 'net ads keytab imap/host at REALM'
>     Also tell windows imap is allowed for this host via the gui or
>     adsiedit/ldapedit/etc
>  4) Start winbind
>  5) Setup dovecot
>  5a) Setup pma_winbind for dovecot
>  6) Test on the dovecot machine:
>    net ads testjoin
>    wbinfo -n mywinuser
>    klist -k
>    kinit mywinuser at REALM
>    kvno imap/host at REALM
>    # check DNS that host has proper forward and reverse entries
>    telnet localhost imap
>      1 CAPABILITIY
>      * CAPABILITY [..] AUTH=PLAIN AUTH=GSSAPI AUTH=GSS-SPNEGO AUTH=LOGIN
> AUTH=NTLM
> 
> I also have exim setup to use dovecot SASL and so it also does
> NTLM, GSSAPI and SPNEGO.
> 
> There is alot of information about this scattered on various web
> sites. The method I've outlined above is the lastest scheme using the
> newer software. Some reference material uses older techniques...
> 
> In my experience pretty much every client supports some version of
> NTLM, so passwords will be exchanged non-plaintext in most cases
> (though weak flavors of NTLM might be negotiated). Many clients like
> thunderbird support kerberos, and so on windows you get single sign on
> too. Most linux clients also support kerberos so can gen single sign
> on for them too with some setup.
> 
> Here are some config fragments you might find helpful
> 
> smb.conf:
> [global]
>    netbios name = host
>    workgroup = FOO
>    realm = ADS.FOO
>    security = ads
>    use kerberos keytab = true
>    encrypt passwords = true
>    winbind use default domain = yes
> 
> Dovecot:
> 
> auth_ntlm_use_winbind = yes
> auth_username_format = %n
> auth_winbind_helper_path = /usr/bin/ntlm_auth
>   mechanisms = plain gssapi gss-spnego login ntlm
>   passdb pam {}

------ 
Romer Ventura
Network Administrator
Houston-Sigma Technologies, L.P.
1333 Industrial Blvd. Sugar Land Tx. 77478
Voice 281-295-5017
rventura at h-st.com