How to extend kadmin

Greg Hudson ghudson at MIT.EDU
Tue Oct 27 11:36:24 EDT 2009

Summary response:

* Nico, Ken, and (in previous off-list conversation) Tom have expressed
displeasure at an approach which requires more hand-editing of XDR code.
So the way we've extended kadmin for lockout support on the trunk (the
api 2->3 bump and conditionalization of xdr_kadm5_policy_ent_rec) is

* However, Nico notes that the way we marshal krb5_principal is
problematic for using rpcgen.  I looked into this myself: we call
krb5_unparse_name on encode and krb5_parse_name on decode.  Does rpcgen
support app-defined encoding functions for particular fields?  If not, I
am doubtful that we will ever be in the position of being able to use
a .x file to define the kadmin protocol without starting over.

* Personally, I don't think hand-editing XDR code is a big deal, as long
as it wasn't my fault that we got into this position in the first place.
For better or for worse, rpcgen generates pretty readable and hackable

* There've been some ideas for the future of kadmin that don't involve
ONC RPC, such as LDAP.  Lacking specific plans and resources allocated
to such a reboot, I have to assume that we'll be making evolutionary
changes to the current kadmin architecture for an indefinite period.

* I'm going to resist the temptation to get into a wide-ranging
discussion of network protocol architecture at this juncture.  Just
pretend I didn't say anthing about my personal like or dislike of
RPC-style network protocols.

More information about the krbdev mailing list