Bug 506717 - saslauthd seems to ignore kerberos realm
saslauthd seems to ignore kerberos realm
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: cyrus-sasl (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Jan F. Chadima
Depends On:
  Show dependency treegraph
Reported: 2009-06-18 09:10 EDT by Karel Volný
Modified: 2011-08-18 11:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-08-18 11:00:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2009-06-18 09:10:31 EDT
Description of problem:
When trying to test kerberos configuration for cyrus-imap, I have found that saslauthd seems to ignore kerberos realm and use empty value instead.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. reset kerberos configuration
rm -f /var/kerberos/krb5kdc/*
rm -f /etc/krb5.keytab

2. create testing kerberos configuration
echo "[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 default_realm = EXAMPLE.COM
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes

  kdc = `hostname -f`:88
  admin_server = `hostname -f`:749
  default_domain = redhat.com

 .redhat.com = EXAMPLE.COM
 redhat.com = EXAMPLE.COM

 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false
 }" > /etc/krb5.conf
kdb5_util create -s EXAMPLE.COM
service krb5kdc start
service kadmin start
kadmin.local -q "ank -randkey imap/`hostname -f`"
kadmin.local -q "ktadd imap/`hostname -f`"

3. make the keytab readable
chmod +r /etc/krb5.keytab

4. set saslauthd to use kerberos
# cat /etc/sysconfig/saslauthd
# Directory in which to place saslauthd's listening socket, pid file, and so
# on.  This directory must already exist.

# Mechanism to use when checking passwords.  Run "saslauthd -v" to get a list
# of which mechanism your installation was compiled with the ablity to use.

# Additional flags to pass to saslauthd on the command line.  See saslauthd(8)
# for the list of accepted flags.

5. set mechanism to pam
# cat /etc/imapd.conf
configdirectory: /var/lib/imap
partition-default: /var/spool/imap
admins: cyrus
sievedir: /var/lib/imap/sieve
sendmail: /usr/sbin/sendmail
hashimapspool: true
sasl_pwcheck_method: saslauthd
sasl_mech_list: plain pam
tls_cert_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem
tls_key_file: /etc/pki/cyrus-imapd/cyrus-imapd.pem
tls_ca_file: /etc/pki/tls/certs/ca-bundle.crt

6. (re)start the services
service saslauthd start
service cyrus-imapd start

7. imtest -r EXAMPLE.COM

8. see /var/log/messages

Actual results:
Jun 18 09:04:08 i386-5s-m1 saslauthd[30905]: auth_krb5: krb5_get_init_creds_password: -1765328378
Jun 18 09:04:08 i386-5s-m1 saslauthd[30905]: do_auth         : auth failure: [user=root] [service=imap] [realm=] [mech=kerberos5] [reason=saslauthd internal error]

Expected results:
... [realm=EXAMPLE.COM] ...

Additional info:
Comment 1 fous 2010-05-03 03:59:34 EDT

what's in your



Comment 2 Jan F. Chadima 2010-06-14 05:42:16 EDT
Reporter, could you please reply to the previous question?
Comment 3 James Yale 2010-09-07 11:59:39 EDT

I'm getting a very similar symptoms with saslauthd (realm is also empty), I don't believe it's simply ignoring the realm but having larger issues with the kerberos5 method in general. 

I've been trying to get saslauthd to authenticate against kerberos running on AD, should be a case of setting the method to kerberos5, create an appropriate krb5.conf and host keytab and it's good to go. This is the case on Debian which I used as a test case when it didn't work on:

CentOS 5.5 (i386 and x64)
CentOS 5.2 (i386 and x64)
RHEL 5.5 (x64)
CentOS 4.8 (i386 and x64)

Infact, the only system I have got this going on is a historic RHEL 4 update 7 system which I can't touch as it's in production. I intend to try and reproduce the success/failure there though. 

Interestingly for me the realm being unpopulated doesn't make any difference to the success of the request in my case, perhaps because it simply uses the default domain.

If this helps and you'd like more information let me know, if it's OT let me know, but this is the only existing reference I can find to the problem that isn't fixed by supplying a working keytab. 



Copious debugging output included below (I've obscured the name of the test request to xxxxx.hirst in each case):

RHEL box (working):

jim@latestar:~$ cat /etc/redhat-release 
Red Hat Enterprise Linux AS release 4 (Nahant Update 7)
jim@latestar:~$ rpm -qa | grep sasl

jim@latestar:~$ sudo /usr/sbin/saslauthd -d -a kerberos5
saslauthd[31176] :main            : num_procs  : 5
saslauthd[31176] :main            : mech_option: NULL
saslauthd[31176] :main            : run_path   : /var/run/saslauthd
saslauthd[31176] :main            : auth_mech  : kerberos5
saslauthd[31176] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[31176] :detach_tty      : master pid is: 0
saslauthd[31176] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[31176] :main            : using process model
saslauthd[31177] :get_accept_lock : acquired accept lock
saslauthd[31176] :have_baby       : forked child: 31177
saslauthd[31176] :have_baby       : forked child: 31178
saslauthd[31176] :have_baby       : forked child: 31179
saslauthd[31176] :have_baby       : forked child: 31180
saslauthd[31177] :rel_accept_lock : released accept lock
saslauthd[31176] :get_accept_lock : acquired accept lock
saslauthd[31214] :do_auth         : auth success: [user=xxxx.hirst] [service=imap] [realm=] [mech=kerberos5]
saslauthd[31177] :do_request      : response: OK
saslauthd[31176] :rel_accept_lock : released accept lock
saslauthd[31178] :get_accept_lock : acquired accept lock
saslauthd[31176] :do_auth         : auth success: [user=elizabeth.clark] [service=ldap] [realm=CURRICULUM.WILDERN.HANTS.SCH.UK] [mech=kerberos5]
saslauthd[31176] :do_request      : response: OK

Debian 5 box (working):

ldap05:~# cat /etc/debian_version 
ldap05:~# dpkg --list | grep sasl2-bin
ii  sasl2-bin                         2.1.22.dfsg1-23+lenny1   Cyrus SASL - administration programs for SASL users database

ldap05:~# /usr/sbin/saslauthd -d -a kerberos5
saslauthd[2258] :main            : num_procs  : 5
saslauthd[2258] :main            : mech_option: NULL
saslauthd[2258] :main            : run_path   : /var/run/saslauthd
saslauthd[2258] :main            : auth_mech  : kerberos5
saslauthd[2258] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[2258] :detach_tty      : master pid is: 0
saslauthd[2258] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[2258] :main            : using process model
saslauthd[2259] :get_accept_lock : acquired accept lock
saslauthd[2258] :have_baby       : forked child: 2259
saslauthd[2258] :have_baby       : forked child: 2260
saslauthd[2258] :have_baby       : forked child: 2261
saslauthd[2258] :have_baby       : forked child: 2262
saslauthd[2259] :rel_accept_lock : released accept lock
saslauthd[2260] :get_accept_lock : acquired accept lock
saslauthd[2259] :do_auth         : auth success: [user=xxxxx.hirst] [service=imap] [realm=] [mech=kerberos5]
saslauthd[2259] :do_request      : response: OK

RHEL 5.5 (broken):

[root@ldap03 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
[root@ldap03 ~]# rpm -qa | grep sasl

[root@ldap03 ~]# /usr/sbin/saslauthd -a kerberos5 -d
saslauthd[3394] :main            : num_procs  : 5
saslauthd[3394] :main            : mech_option: NULL
saslauthd[3394] :main            : run_path   : /var/run/saslauthd
saslauthd[3394] :main            : auth_mech  : kerberos5
saslauthd[3394] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[3394] :detach_tty      : master pid is: 0
saslauthd[3394] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[3394] :main            : using process model
saslauthd[3395] :get_accept_lock : acquired accept lock
saslauthd[3394] :have_baby       : forked child: 3395
saslauthd[3394] :have_baby       : forked child: 3396
saslauthd[3394] :have_baby       : forked child: 3397
saslauthd[3394] :have_baby       : forked child: 3398
saslauthd[3395] :rel_accept_lock : released accept lock
saslauthd[3396] :get_accept_lock : acquired accept lock
saslauthd[3395] :do_auth         : auth failure: [user=xxxxx.hirst] [service=imap] [realm=] [mech=kerberos5] [reason=saslauthd internal error]
Comment 4 Jan F. Chadima 2010-09-08 03:26:57 EDT
Have you test to add allow_weak_crypto=true into libdefaults section in krb5.conf in the "broken" RHEL 5.5. If no, please test it again with it added.
Comment 5 James Yale 2010-09-08 06:55:01 EDT
Thanks for the suggestion, and sorry - perhaps broken was the wrong term. I tried adding the line to /etc/krb5.conf (also attached) with no change on the non-working RHEL 5.5 box:

[root@ldap03 ~]# cat /etc/redhat-release 
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
[root@ldap03 ~]# kdestroy 
kdestroy: No credentials cache found while destroying cache
[root@ldap03 ~]# kinit -k -t /etc/krb5.keytab host/ldap03.wildern.hants.sch.uk
[root@ldap03 ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: host/ldap03.wildern.hants.sch.uk@CURRICULUM.WILDERN.HANTS.SCH.UK

Valid starting     Expires            Service principal
09/08/10 11:48:24  09/08/10 21:48:44  krbtgt/CURRICULUM.WILDERN.HANTS.SCH.UK@CURRICULUM.WILDERN.HANTS.SCH.UK
        renew until 09/09/10 11:48:24

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached
[root@ldap03 ~]# /usr/sbin/saslauthd -a kerberos5 -d
saslauthd[2342] :main            : num_procs  : 5
saslauthd[2342] :main            : mech_option: NULL
saslauthd[2342] :main            : run_path   : /var/run/saslauthd
saslauthd[2342] :main            : auth_mech  : kerberos5
saslauthd[2342] :ipc_init        : using accept lock file: /var/run/saslauthd/mux.accept
saslauthd[2342] :detach_tty      : master pid is: 0
saslauthd[2342] :ipc_init        : listening on socket: /var/run/saslauthd/mux
saslauthd[2342] :main            : using process model
saslauthd[2343] :get_accept_lock : acquired accept lock
saslauthd[2342] :have_baby       : forked child: 2343
saslauthd[2342] :have_baby       : forked child: 2344
saslauthd[2342] :have_baby       : forked child: 2345
saslauthd[2342] :have_baby       : forked child: 2346
saslauthd[2343] :rel_accept_lock : released accept lock
saslauthd[2344] :get_accept_lock : acquired accept lock
saslauthd[2343] :do_auth         : auth failure: [user=xxxxx.hirst] [service=imap] [realm=] [mech=kerberos5] [reason=saslauthd internal error]


[root@ldap03 ~]# cat /etc/krb5.conf 
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

 dns_lookup_realm = true
 dns_lookup_kdc = true
 ticket_lifetime = 24h
 forwardable = yes


#  kdc = kerberos.example.com:88
#  admin_server = kerberos.example.com:749
#  default_domain = example.com
# }

 .curriculum.wildern.hants.sch.uk = CURRICULUM.WILDERN.HANTS.SCH.UK
 curriculum.wildern.hants.sch.uk = CURRICULUM.WILDERN.HANTS.SCH.UK

 pam = {
   debug = false
   ticket_lifetime = 36000
   renew_lifetime = 36000
   forwardable = true
   krb4_convert = false


Comment 6 Karel Volný 2010-10-12 10:25:58 EDT
(In reply to comment #1)
> hi
> what's in your
> /var/kerberos/krb5kdc/kdc.conf
> ???
> f.

[root@ibm-l4b-lp4 ~]# cat /var/kerberos/krb5kdc/kdc.conf
cat: /var/kerberos/krb5kdc/kdc.conf: No such file or directory

... and yes, I've repeated the complete reproducer to the point where I got:

Oct 12 10:23:07 ibm-l4b-lp4 saslauthd[28250]: do_auth         : auth failure: [user=root] [service=imap] [realm=] [mech=kerberos5] [reason=saslauthd internal error]

Note You need to log in before you can comment on or make changes to this bug.