Extending Kerberos

[g.w@hurderos.org]

>> Hello,

Good afternoon Anderson and to everyone else on the list.

Replies to both pieces of mail rolled into one since they encapsulate
a common issue.

>> I'm required to extend the MIT Kerberos implementation so that the KDC
>> can fill the authorization data field with some authorization
>> information for the authenticating user.  I thought I'd already found
>> it by myself where I'd to add the authorization data extension
>> code. Just changed the process_as_req() function in do_as_req.c to add
>> the authorization information, insted of setting that field to NULL.
>> But, sometimes, the KDC crashes, so maybe I missed something, and that
>> is not enough.  Can anyone tell me where can I find some documentation
>> about the kerberos source?

For what you are attempting to do the Kerberos source code is about as
much documentation as there is.  The code is reasonably well organized
and easy to follow once you get the hang of it.

You have correctly identified one of the places where authorization
information gets injected.  Sticking tokens in at that point will
yield TGT's with imbedded authorization information.  That may or may
not be what you want.

The other spot that you may want to look at is in the do_tgs_req file
in the kdc sub-directory.  There is an opportunity to stick service
specific authorization tokens into a service ticket there as well.  If
memory serves me correctly any authorization information supplied at
that point gets concantenated onto the authorization information in
the TGT.

As to why the KDC crashes it would be a little difficult to determine
that without greater knowledge of your code and what you are
attempting to do.  Based on the information from your second note
(text included below) it would seem that you are trying to stuff some
type of information from an SQL database into the authorization field
of the TGT.  There may be any number of things that might be going
wrong.

Some suggestions below on things that might help you proceed forward.

> I'm trying to extend kerberos, and now I'm having problems while
> trying to edit makefiles.  I have already done some C porgramming, but
> I'm new to editting makefiles.
>
> I'm currently using Kerberos V5 1.3.5.
>
> I have added two files to src/kdc:
> src/kdc/kerb_ext.c
> src/kdc/kerb_ext.h

> But, as I need to compile the whole system, then I tryed to change the
> file src/kdc/Makefile.in, like it's in the end of the message. These
> changes are kind of a guess, based on other Makefile.in files.

> When I try to compile, by executing 'make', I get the following error:

> making all in kdc...
> make[1]: Entering directory `/home/sam_sm/krb5-src_dev/krb5-1.3.5/compiled/kdc'
> Makefile:531: *** commands commence before first target.  Stop.
> make[1]: Leaving directory `/home/sam_sm/krb5-src_dev/krb5-1.3.5/compiled/kdc'
> make: *** [all-recurse] Error 1

Our Hurderos project is focused on providing an open-architecture
Active Directory work-alike with an authorization strategy which is a
superset of what Active Directory (or most other people) are currently
pursueing.  In addition to enhanced functionality our interest in an
alternate architecture stems from a concern over the potential for
legal difficulties secondary to 'cloning' AD.  We will leave that
whole affair to the Samba folks who are probably well on their way
toward that goal.

About two months ago we were faced with the prospect of wading into
the MIT KRB5 sources to begin the process of supporting the KRB5
imbedded portion of our authorization strategy.  I chatted with Sam
Hartman via e-mail about 'acceptable' strategies for adding enhanced
functionality to krb5kdc/kadmind.  Sam noted that they had a vision
for a 'plug-in' architecture to do that kind of thing but had nothing
on the drawing board to offer.

As long as we were going in anyway it seemed to make sense to do this
the 'right' way so that other people might be able to leverage our
efforts.  To that end we have developed a basic plug-in infrastructure
against V1.3.5 of MIT's Kerberos which allows basic functionality to
be extended through the use of shared libraries 'plug-ins'.

The architecture allows the functionality of both the KDC and KADMIND
to be modified with a single plug-in.  We currently have implemented
interception points for the following functionality:

	1.) Password changes.
	2.) AS_REQ
	3.) AS_REQ authorization token insertion.
	4.) TGS_REQ
	5.) TGS_REQ authorization token insertion.

The advantage to this system from your problem perspective is that you
don't need to know how to modify or edit the build infra-structure of
Kerberos itself.  Plug-ins do need to have have access to various KRB5
headers but can be built and debugged outside of the source tree.
This pretty much eliminates the need to mess with the KRB5 build
process itself.

We were hoping to get a new Hurderos release out this week but a
couple of presentation deadlines conspired with the holiday to slip
our schedule.  I'm hoping that we will have 0.1.3 out next week which
will automatically build a plugin-enhanced 1.3.5.

In addition to providing a plug-in to provide the Hurderos specific
functionality there is a 'template' plug-in included which simply
hooks all the interception points and logs messages to syslog.  That
should provide a pretty good foundation for people, like yourself, who
want to start building customized extensions.

You may want to look at the Hurderos plug-in as well.  In addition to
doing identity translation for the AS_REQ the plug-in loads the
authorization field of the TGT with the intrinsic user identity.  The
TGS_REQ interception checks to see whether a Hurderos service
principal (svc/SVCNAME) is being requested.  If it is a service
instance identity is created and stuffed into the authorization field
of the service ticket.  The general formula for what we are doing may
help you get your stuff going.

If MIT is interested I plan to yank down the current CVS trunk and
will build a patchset against that for their evaluation.  In the
meantime we will be tracking the current releases from MIT.

Hope this information is helpful.

Best wishes for a productive week and/or holiday to everyone.

As always,
GW
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org