reason=saslauthd internal error ????

Tomas Lindroos skitta at abo.fi
Wed Oct 11 15:01:57 EDT 2006


On Aug 2, 2006, at 8:46 PM, Vincent Fox wrote:

>
> So I'm setting up cyrus-sasl 2.1.22 on a Linux box, specifically  
> RHEL4.
>
> When testing it out with testsaslauthd I keep getting this:
> 0: NO "authentication failed"
>
> log shows this:
>
> saslauthd: do_auth : auth failure: [user=blah] [service=pop]
> [realm=OUR.REALM] [mech=kerberos5] [reason=saslauthd internal error]
>
> Yet my Kerberos server clearly shows it thinks everything is ok:
>
> auth1 [xxx] [ID 254627 user.info] $DLFDDFLJ, AS: ticket issued:  
> authtime
> 1154540343, host=IP (FQDN), client=blah at OUR.REALM,
> server=krbtgt/OUR.REALM at OUR.REALM

I have been struggling with this too. I'm by no means a kerberos5  
expert, but we needed to get authentication against Active Directory  
to work for a virtual domain on a cyrus mailserver.

If I understand things correctly the procedure goes like this:

- user logs in (with say PLAIN) and the username/password/realm is  
given to saslauthd
- saslauthd contacts the ticket granting service and gets a TGT  
(ticked assumed, in your example)
- then saslauthd checks that the ticket you got really is from the  
server that it claims to be from (i.e. not spoofed). If this doesn't  
work, you'll get a "saslauthd internal error".

To make it work you need to add a "keytab" that can be used for the  
service. This means that:

- you should generate a keytab on the kerberos server (in our case AD)
- move the keytab securely to the mail server
- add the keytab somewhere that the mailserver will find it and can  
read it, /etc/krb5.keytab is the default place. You can manage  
keytabs with "ktutil".

Now, I have found quite a lot of recipies on how to generate diffrent  
kinds of keytabs, both from a windows AD domain and otherwise, but I  
can't seem to figure out:

a) exactly how to generate the right kind of keytab (using ktpasswd  
on the PDC, but with what switches?)
b) a keytab for what principal (host/fqdn at domain, service/fqdn at DOMAIN  
or what?) is really needed?

I would appreciate if someone who uses saslauthd against AD could  
give me some tip on how you do it.

(The solution while testing has been patching saslauthd to not check  
the ticket for validity, but that's of course not the right thing to  
do...)

Regards,

	/skitta

-- 
Tomas 'Skitta' Lindroos.
Åbo Akademi University, Computing Centre
<skitta at abo.fi>



More information about the Cyrus-sasl mailing list