Fwd: SASL LDAP authentication
Dan White
dwhite at olp.net
Thu Sep 24 17:43:10 EDT 2009
Very nice.
This would be great to put up on the Wiki.
On 24/09/09 21:17 +0200, Martin Schweizer wrote:
>Hello
>
>Sorry for the delay but I was out the country and need some time for
>the translation, Below you find my smal tutorial. Good luck!
>
>(Be careful the lines are probably wrapped).
>
>FreeBSD 7.2: Authentication against Windows 2003 Domain controller
>over Kerberos5
>=================================================================================
>
>
>The following setup I use to authenticate users on a mail server
>(Cyrus Imapd) againts Active Directory (but you can use any
>other services too). In this case FreeBSD works as a Kerberos5 client.
>Afterwoods I'm able to authenticate with Kerberos5,
>PAM and Cyrus SASL (over saslauthd -a PAM or -a Kerberos5).
>
>
>/etc/krb5.keytab
>================
>
>The first step is to create a user in Active Directory (see Windows
>domain controller) for the Unix host. krb5.keytab you need normaly
>only for services requests (for example from saslauthd -a kerberos5)
>
>acsvfbsd06# ktutil -v list
>FILE:/etc/krb5.keytab:
>
>Vno Type Principal Date
> 4 arcfour-hmac-md5 host/acsvfbsd06.acutronic.ch at ACUTRONIC.CH 2009-09-08
>
>ktutil: krb5_kt_start_seq_get krb4:/etc/srvtab: open(/etc/srvtab): No
>such file or directory
>
>Hint: The entries in /etc/srvtab will not be used in this case and can
>be ignored. This only for KerberosIV.
>
>To create a /etc/krb5.keytab file you have first to export it from a
>domain controller and bind it to the above user name:
>
>C:\Programme\Support Tools>ktpass princ
>host/acsvfbsd06.domain.tld at DOMAIN.TLD -crypto RC4-HMAC-NT -ptype
>KRB5_NT_SRV_INST -mapuser acsvfbsd06 -pass password out 21.keytab
>Targeting domain controller: acsv3k04.domain.tld
>Using legacy password setting method
>Successfully mapped host/acsvfbsd06.domain.tld to acsvfbsd06.
>WARNING: pType and account type do not match. This might cause problems.
>Key created.
>Output keytab to 21.keytab:
>Keytab version: 0x502
>keysize 76 host/acsvfbsd06.domain.tld at DOMAIN.TLD ptype 2 (KRB5_NT_SRV_INST)
>vno 4 etype 0x17 (RC4-HMAC) keylength 16 (0x5f92140f96a5ffbfa9fdf8fbae1ed02b)
>
>
>Important: pytype should be KRB5_NT_SRV_INST! In any other case it
>will not work. This is because Kerberos5 looks in this
>file and search this type of key. If the type is wrong you get under
>different cirscumstance different error messages in
>
>/var/log/auth.log:
>
>- saslauthd -a pam
>Sep 2 08:42:22 acsvfbsd06 saslauthd[772]: pam_krb5:
>verify_krb_v5_tgt(): krb5_kt_read_service_key(): Key table entry not
>found
>
>- saslauthd -a kerberos5
>Sep 2 08:42:22 acsvfbsd06 saslauthd[42062]: do_auth : auth
>failure: [user=user][service=imap] [realm=] [mech=kerberos5]
>[reason=krb5_verify_user_optfailed]
>
>
>After you create the keytab file you have to securly transfer the file
>to the FreeBSD host. If there exists one you can import the new key in
>/etc/krb5.keytab as following:
>
>ktutil copy /usr/home/martin/21.keytab /etc/krb5.keytab
>
>The file /etc/krb5.keytab has (after the creation) the following rights:
>
>-rw------- 1 root wheel 86B 8 Sep 08:20 krb5.keytab
>
>
>kinit
>=====
>- The settings from /etc/krb5.conf will be used.
>- kinit creates user owned Kerberos tickes. It's located under
>/tmp/krb5cc_<uid>, (for example kinit root => /tmp/krb5cc_0)
>
>You can use kinit to test the basic Kerberos mechanism on FreeBSD
>(without parameters). Then /etc/krb5.keytab will not be used.
>
>
>acsvfbsd06# klist -v
>Credentials cache: FILE:/tmp/krb5cc_0
> Principal: martin at DOMAIN.TLD
> Cache version: 4
>
>Server: krbtgt/DOMAIN.TLD at DOMAIN.TLD
>Ticket etype: arcfour-hmac-md5, kvno 2
>Auth time: Sep 8 07:40:45 2009
>End time: Sep 8 17:40:25 2009
>Renew till: Sep 15 07:40:45 2009
>Ticket flags: renewable, initial, pre-authenticated
>Addresses: IPv4:192.168.x.y
>
>Server: ldap/acsv3k04.domain.tld at DOMAIN.TLD
>Ticket etype: arcfour-hmac-md5, kvno 22
>Auth time: Sep 8 07:40:45 2009
>Start time: Sep 8 07:40:50 2009
>End time: Sep 8 17:40:25 2009
>Ticket flags: pre-authenticated, ok-as-delegate
>Addresses: IPv4:192.168.x.y
>
>kinit -k <username> can be used to test the keytab file. If you get no
>message then the authentication is ok and the tickets will deleted
>imediatly. If you get init: krb5_get_init_creds: Additional
>pre-authentication required, then only the pre-authentication is
>failed (see under Windows domain controller).
>
>ldapsearch
>==========
>
>Important: kinit should be executed before!
>
>With ldapsearch you can test the ldap functionality against the domain
>controller:
>
>acsvfbsd06# ldapsearch -v -LLL -b
>"OU=Mitgliedsserver,OU=ACH,DC=domain,DC=tld" -h acsv3k04.domain.tld
>description
>ldap_initialize( ldap://acsv3k04.domain.tld )
>SASL/GSSAPI authentication started
>SASL username: martin at DOMAIN.TLD
>SASL SSF: 56
>SASL data security layer installed.
>filter: (objectclass=*)
>requesting: description
>dn: OU=Mitgliedsserver,OU=ACH,DC=domain,DC=tld
>[snip]
>
>Important: If you use default_etypes_des in your etc/krb5.conf,
>ldapsearch will fail.
>
>After the first ldapsearch query you get an additional Kerberos ticket
>(see under kinit).
>
>
>
>/etc/krb5.conf
>==============
>[libdefaults]
> default_realm = DOMAIN.TLD
>
>[realms]
> DOMAIN.TLD= {
> kdc = acsv3k04.domain.tld:88
> }
>
>[domain_realm]
> domain.tld = DOMAIN.TLD
> .domain.tld = DOMAIN.TLD
> .acsv3k04.domain.tld = DOMAIN.TLD
> acsv3k04.domain.tld = DOMAIN.TLD
> .acsvfbsd06.domain.tld = DOMAIN.TLD
> acsvfbsd06.domain.tld = DOMAIN.TLD
> acsvfbsd06 = DOMAIN.TLD
>
>
>/etc/resolv.conf
>================
>
>domain domain.tld
>nameserver 192.168.x.y
>
>
>
>/etc/hosts
>==========
>
>
>With the settings below you get no DNS overhead.
>
>192.168.10.2 acsv3k04.domain.tld
>
>
>Cyrus SASL
>==========
>
>
>First you need to compile Cyrus SASL with all authentication mechanisms:
>
>acsvfbsd06# saslauthd -h
>usage: saslauthd [options]
>
>option information:
> -a <authmech> Selects the authentication mechanism to use.
> -c Enable credential caching.
> -d Debugging (don't detach from tty, implies -V)
> -r Combine the realm with the login before passing to
>authentication mechanism
> Ex. login: "foo" realm: "bar" will get passed as
>login: "foo at bar"
> The realm name is passed untouched.
> -O <option> Optional argument to pass to the authentication
> mechanism.
> -l Disable accept() locking. Increases performance, but
> may not be compatible with some operating systems.
> -m <path> Alternate path for the saslauthd working directory,
> must be absolute.
> -n <procs> Number of worker processes to create.
> -s <kilobytes> Size of the credential cache (in kilobytes)
> -t <seconds> Timeout for items in the credential cache (in seconds)
> -v Display version information and available mechs
> -V Enable verbose logging
> -h Display this message.
>
>saslauthd 2.1.23
>authentication mechanisms: sasldb getpwent kerberos5 pam rimap ldap
>
>saslauthd you start in /etc/rc.conf with -a pam or -a kerberos5
>
>
>PAM
>===
>
>In my setup I use PAM for central authentication. If you use Cyrus
>SASL/Imapd you need the service name "imap". So the
>correspondend file in /etc/pam.d should have the name imap.
>
>/etc/pam.d/imap:
>auth required pam_krb5.so try_first_pass no_user_check
>account required pam_krb5.so
>password required pam_krb5.so
>session required pam_krb5.so
>
>
>pam_krb5.so:
>Hint: pam_krb5.so do not check the fields Vno and encryption
>(arcfour-hmac-md5) from the keytab file (see the source code in
>/usr/src/lib/libpam/modules/pam_krb5).
>
>pam_krb5.so looks for a principal
>host/acsvfbsd06.domain.tld at DOMAIN.TLD with the type KRB5_NT_SRV_INST
>(see krb5.keytab/ktpass)
>
>In the actual version of /usr/src/lib/libpam/modules/pam_krb5 there is
>a long outstanding bug (see PR
>http://www.freebsd.org/cgi/query-pr.cgi?pr=76678&cat=). The problem is
>the authentication is only successfully if the authenticated user is
>also in the local FreeBSD passwd file. To change this you have to
>apply the patch below an set the option no_user_check in
>/etc/pam.d/imap (see PAM).
>
>Patch:
>--- pam_krb5.c.orig Tue Feb 10 10:13:20 2004
>+++ pam_krb5.c Sun Jan 9 23:58:36 2005
>@@ -89,6 +89,7 @@
> #define PAM_OPT_FORWARDABLE "forwardable"
> #define PAM_OPT_NO_CCACHE "no_ccache"
> #define PAM_OPT_REUSE_CCACHE "reuse_ccache"
>+#define PAM_OPT_NO_USER_CHECK "no_user_check"
> /*
> * authentication management
>@@ -213,11 +214,13 @@
> PAM_LOG("PAM_USER Redone");
> }
>- pwd = getpwnam(user);
>- if (pwd == NULL) {
>- retval = PAM_USER_UNKNOWN;
>- goto cleanup2;
>- }
>+ if (!openpam_get_option(pamh, PAM_OPT_NO_USER_CHECK)) {
>+ pwd = getpwnam(user);
>+ if (pwd == NULL) {
>+ retval = PAM_USER_UNKNOWN;
>+ goto cleanup2;
>+ }
>+ }
> PAM_LOG("Done getpwnam()");
>
>
>
>
>
>Windows domain controller
>=========================
>
>As a directory you can use the following article:
>- http://technet.microsoft.com/en-us/library/bb742433.aspx
>(Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability )
>- Windows Security and Directory Services for UNIX v1.0 (onlsy
>available on download.microsoft.com).
>
>As a first step you should create a user which has the same name as
>your FreeBSD host. This user name you need in combination with ktpass
>(see krb5.keytab). Additional your FreeBSD host should be resolvable
>by DNS with PTR and A record.
>
>Do not use the Support tools from Windows 2000, because ktpass has not
>the same options (for example encryption).
>
>If you see error messages in the Eventlog (Security) on your domain
>controller like:
>
>(sorry only in german available)
>
>Ereignistyp: Fehlerüberw.
>Ereignisquelle: Security
>Ereigniskategorie: Kontoanmeldung
>Ereigniskennung: 675
>Datum: 08.09.2009
>Zeit: 08:22:00
>Benutzer: NT-AUTORITÄT\SYSTEM
>Computer: ACSV3K04
>Beschreibung:
>Fehlgeschlagene Vorbestätigung:
> Benutzername: martin
> Benutzerkennung: ACH\martin
> Dienstname: krbtgt/DOMAIN.TLD
> Vorauthentifizierungstyp: 0x0
> Fehlercode: 0x19
> Clientadresse: 192.168.20.5
>
>... then the user name is successfully authenticated. The error shows
>only the pre-authentication is failed see:
>
>http://support.microsoft.com/kb/230476/en-us:
>
>0x19 (KDC_ERR_PREAUTH_REQUIRED) "Additional pre-authentication"
>The client did not send pre-authorization, or did not send the
>appropriate type of pre-authorization, to receive a ticket.
>The client will retry with the appropriate kind of pre-authorization
>(the KDC returns the pre-authentication type in the
>error). Many Kerberos implementations will start off without
>preauthenticated data and only add it in a subsequent request
>when it sees this error. In this case, this error can safely be ignored.
>
>
>
>Firewall
>========
>You need the following ports: 88 (for Kerberos), 53 (for DNS) and 389
>(for ldap).
>
>
>DNS
>===
>Therewith you have no DNS resolve problems it is a good idea to use a
>domain DNS server in /etc/resolv.conf.
>
>You need also this DNS record:
>_kerberos IN TXT DOMAINT.TLD
>
>
>Links
>=====
>
>- Kerberos: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kerberos5.html
>- PAM: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam/index.html
>- Principal/ktpass: http://www.grolmsnet.de/kerbtut/
>
>
>2009/9/21 Thomas Vogt <tv at solnet.ch>:
>> Hi
>>
>> Martin Schweizer schrieb:
>>>
>>> Hello Jack
>>>
>>> I was in the same situation as you in the past two months. My goal was
>>> to authenticate between my FreeBSD mail servers (Cyrus imapd /
>>> sendmail) and Active Directory. I find that the best way was to
>>> authenticate by KerberosV (by saslauthd -a kerberos5 or -a pam). Now
>>> all is workig as expected (after really hard work...). After the work
>>> was done I've written a small tutorial (until now only in
>>> german...:-))). Do you are interessted?
>>
>> Can you send me this tutorial too? I can read german :)
>>
>> Regards,
>> Thomas
>>
>>>
>>> Regards,
>>>
>>>
>>>
>>> 2009/9/14 Jackie Hunt <jackie at yuma.colostate.edu>:
>>>>
>>>> Hi all,
>>>>
>>>> I am trying to get authenticated SMTP running here on campus, and we are
>>>> wanting to authenticate against Active Directory. We are running
>>>> sendmail,
>>>> and I've been able to get it to work using the UNIX password file.
>>>> However,
>>>> I'm having trouble when I try to use ldap to authenticate.
>>>>
>>>> I'm working on RedHat ES rel4 with cyrus-sasl 2.1.19. My first question
>>>> is
>>>> whether or not cyrus-sasl-lib is required for this to work? It's not
>>>> installed on my test box. However, I tried another Linux system we have
>>>> that does have cyrus-sasl-lib installed, and things still don't work. I
>>>> know I'm missing something crucial, so any help would be greatly
>>>> appreciated.
>>>>
>>>> When I run saslauthd -v I see:
>>>>
>>>> saslauthd 2.1.19
>>>> authentication mechanisms: getpwent kerberos5 pam rimap shadow ldap
>>>>
>>>> So, I'm assuming it has everything it needs compiled in to do ldap
>>>> authentication.
>>>>
>>>> I then edited the /etc/sysconfig/saslauthd file, and changed the MECH=pam
>>>> line to MECH=ldap.
>>>>
>>>> Then I created a /etc/saslauthd.conf file with the contents:
>>>>
>>>> ldap_servers: ldap://129.82.xxx.xxx/
>>>> ldap_bind_dn: cn=xxxxx,ou=xxxxxxxxxxx,dc=ColoState,dc=edu
>>>> ldap_password: xxxxxxxx
>>>> ldap_filter: (sAMAccountName=%u)
>>>> ldap_search_base: dc=colostate,dc=edu
>>>> ldap_auth_method: bind
>>>>
>>>> Then I start saslauthd the following command:
>>>>
>>>> /usr/sbin/saslauthd -a ldap -d -O /etc/saslauthd.conf
>>>>
>>>> Then I run a command to test it:
>>>>
>>>> /usr/sbin/testsaslauthd -u jackie -p xxxxx
>>>>
>>>> And the output I see is:
>>>>
>>>> saslauthd[8045] :main : num_procs : 5
>>>> saslauthd[8045] :main : mech_option: /etc/saslauthd.conf
>>>> saslauthd[8045] :main : run_path : /var/run/saslauthd
>>>> saslauthd[8045] :main : auth_mech : ldap
>>>> saslauthd[8045] :ipc_init : using accept lock file:
>>>> /var/run/saslauthd/mux.accept
>>>> saslauthd[8045] :detach_tty : master pid is: 0
>>>> saslauthd[8045] :ipc_init : listening on socket:
>>>> /var/run/saslauthd/mux
>>>> saslauthd[8045] :main : using process model
>>>> saslauthd[8046] :get_accept_lock : acquired accept lock
>>>> saslauthd[8045] :have_baby : forked child: 8046
>>>> saslauthd[8045] :have_baby : forked child: 8047
>>>> saslauthd[8045] :have_baby : forked child: 8048
>>>> saslauthd[8045] :have_baby : forked child: 8049
>>>> saslauthd[8046] :rel_accept_lock : released accept lock
>>>> saslauthd[8047] :get_accept_lock : acquired accept lock
>>>> saslauthd[8046] :do_auth : auth failure: [user=jackie]
>>>> [service=imap] [realm=] [mech=ldap] [reason=Unknown]
>>>> saslauthd[8046] :do_request : response: NO
>>>> saslauthd[8047] :rel_accept_lock : released accept lock
>>>>
>>>> I don't see where it is trying to authenticate as the ldap_bind I
>>>> specified
>>>> in the configuration file. Should it do that first?
>>>>
>>>> I would really appreciate any help. I've been struggling with this for
>>>> several days.
>>>>
>>>> Thanks so much!
>>>>
>>>> Jackie Hunt
>>>> Colorado State University
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
>--
>Martin Schweizer
>schweizer.martin at gmail.com
>Tel.: +41 32 512 48 54 (VoIP)
>Fax: +1 619 3300587
--
Dan White
BTC Broadband
Ph 918.366.0248 (direct) main: (918)366-8000
Fax 918.366.6610 email: dwhite at olp.net
http://www.btcbroadband.com
More information about the Cyrus-sasl
mailing list