Possible bug : krb5_free_data_contents() segfault when Active Directory user is "disabled"

[Etienne Goyer]

Hi there,

I am not very familiar with Kerberos and less so about MIT Kerberos
developpement process, so please bear with me if I make no sense or
report a non-issue.

I am using saslauthd (part of cyrus-sasl) with the gssapi plugin built
against MIT Kerberos to authenticate user to a MS Active Directory KDC.
When I "disable" the user that represent the principal used on the AD,
saslauthd segfault.  When the user representing the principal is
enabled, it work correctly.  The plain Kerberos stuff (kinit, 
sclient/sserver, etc) work correctly all the time.

I am not a very good C programmer but I narrowed the problem to
krb5_free_data_contents() with careful use of syslog() in the saslauthd
code.  I check the argument passed to krb5_free_data_contents() and they
are both not NULL.  From there on, I really can't get further with my
troubleshooting.

If you are interested in looking at the code that triggered the bug for
me, it would in cyrus-sasl 2.1.13, in file saslauthd/auth_krb5.c at line
264.  I am using the Kerberos distribution from RedHat 7.3 version
1.2.4-11.

It should be trivial to write a test case that just get a TGT and call
krb5_free_data_contents().  That way, I could test with or without the
principal user disabled and make sure it is really
krb5_free_data_contents().  If somebody have the skill to write the test
case (sorry, I don't), I would be willing to try it.

Just to help those not familiar with Active Directory understand what I
mean by "principal user", let me explain.  AD does not use the notion of
principal.  When you want to have other Kerberos implantation
interoperate with AD, you need to create user (yes, regular user) that
represent the principal for which you want to emit a keytab.  The
utility that create the keytab also does "principal-to-name mapping".
Thus, you end up with a user representing a principal in the AD.  It's a
kludge, but apparently it work.  You can get the whole story at
http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp

Thanks for taking the time to consider my request.

-- 
Etienne Goyer                    Linux Québec Technologies Inc.
http://www.LinuxQuebec.com       etienne.goyer at linuxquebec.com
PGP Pub Key: http://www.LinuxQuebec.com/pubkeys/eg.key 
Fingerprint: F569 0394 098A FC70 B572  5D20 3129 3D86 8FD5 C853