Internal MIT Kerberos functions used by Samba

Andreas Schneider asn at
Mon Mar 20 11:35:45 EDT 2017

On Monday, 20 March 2017 15:54:42 CET Greg Hudson wrote:
> Thanks again for writing this up.
> On 03/20/2017 05:45 AM, Andreas Schneider wrote:
> > The MIT Kerberos library has several symbols which are public but do not
> > offer a prototype in a header file.
> Just to be clear, we don't consider functions exported by libkrb5 to be
> part of the public API unless they have a prototype.  In most cases
> those symbols are exported for ease of testing or by use in other parts
> of the tree.
> [for the Samba kpasswd server]
> > decode_krb5_setpw_req
> The krb5_setpw_req structure is also not public.

krb5_error_code decode_krb5_setpw_req(const krb5_data *code,
                                      krb5_data **password_out,
                                      krb5_principal *target_out);

This is the function prototype. It doesn't use any internal structures. So I 
do not see how someone would need to use the structure you're talking about.

> If the only reason Samba needs its own kpasswd server is access control,
> I would hope that is a temporary need, although we've been very slow to
> create a pluggable access control interface for kadmind's password server.

I would say yes, but I haven't looked into RODC (Read Only Domain Controller) 
details yet.

> [for the Samba test suite]
> > decode_krb5_error
> > decode_krb5_as_req
> > decode_krb5_as_rep
> > decode_krb5_padata_sequence
> > krb5_free_kdc_req
> > krb5_free_kdc_rep
> > krb5_free_pa_data
> We have krb5_rd_error() which wraps decode_krb5_error().  This and
> krb5_mk_error() exist for applications which use KRB_ERROR messages in
> their protocols, such as kprop.
> One option would be to add similar krb5_rd_kdc_req(), krb5_rd_kdc_rep(),
> and krb5_rd_padata() wrappers, or some variation along those lines.  The
> argument against doing this is that libkrb5 isn't designed to be a
> nuts-and-bolts encoding library for test suites.  I've done some
> preliminary work on a Python library for this purpose, but I stalled out
> after implementing the crypto layer.

I would be happy to be able to do all of this in python :) I do not think we 
need new functions here.
> A more conservative option, in the sense of not making a long-term API
> commitment, would be to create a new public header marked as unstable
> across releases, containing prototypes for a set of encoding and
> decoding functions, and perhaps some formerly private structures such as
> krb5_setpw_req.

Just having a header which states that it will not have a stable API would be 
fine with me.

> I would welcome opinions from other Kerberos developers.

Thanks for considering,


Andreas Schneider                   GPG-ID: CC014E3D
Samba Team                             asn at

More information about the krbdev mailing list