[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Kerberos Feature Request
I agree with what all the other responses I have seen so far, but would
like to put a different spin on this too. i.e. seperate authentication
from authorization, and don't use the PAC.
"Henry B. Hotz" wrote:
>
> I probably should send this to the IETF group, but I'm not on their
> mailing lists.
Then please join the list!
> (Apologies if the cross-posting causes problems.) It
> would be *nice* if all Kerberos distributions added this feature the
> same way.
>
> One of the famous things that Microsoft did in their AD Kerberos
> implementation is added authorization data to the (supposedly
> optional) PAC field that is necessary when using certain other
> Microsoft functionality. AFAIK all of the information added is also
> contained in the LDAP directory that AD also provides.
Yes I believe it is. This brings up a good point. Authorization data
can be added to the tickets, BUT it does not have to be.
DCE and Microsoft tied the authentication and authorizations services
together and placed the information in the tickets. It did not have to
be that way. Kerberos does authentication, and uses tickets.
Authorization data can be obtained by the application, using other
means, such as contacting an LDAP server. This then allows
for multiple authorization services, which may not be run by the
same people that run the authentication services.
(There are issues of performance, and up to date authorization
data, but that is another discussion.)
>
> I do not think it makes any sense for a (non-Microsoft) Kerberos
> server to directly maintain this data. Rather it should have a
> mechanism for acquiring the data from an external source, such as an
> LDAP directory.
>
As others have said the "PAC" is Microsoft specific, and they can change
its definition at any time. If you really want to use the "PAC" use a
AD as the KDC.
But there is nothing to stop you application from acquiring authorization
data from LDAP today, even from using LDAP to the AD.
> My request is that the Kerberos community agree on a standard
> external interface to get that data. If the interface itself were
> standardized then the work of connecting that interface to the
> appropriate AD attributes could be done independently of any Kerberos
> server, and could be updated as Microsoft updates their schema
> independent of Kerberos versions. It would also make the use of PAC
> data in non-Microsoft environments much easier to consider.
It sounds like you want the PAC from Microsoft, which means you
will most likely have to have an AD around or you want a completely
independent implementation of AD that can build a Microsoft
compatible PAC. As other have pointed out this will be very hard,
as Microsoft can change this at any time, and there may be other
subtle changes needed.
If its the Microsoft KDC you don't like, i.e. it does not do
some PRE-AUTH you want, you could register the user's
in a non MS realm, and tell the AD to accept cross realm
authentication from that realm. Tickets created by the AD will
then have a PAC included so the PAC can be used by Microsoft
aplicaitons.(I have not tried this, but they say it works.) All of your
non-MS applicaitons/servers could be registed in the non-MS realm, yet
they could still use LDAP to access AD.
> --
> The opinions expressed in this message are mine,
> not those of Caltech, JPL, NASA, or the US Government.
> Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
> _______________________________________________
> krbdev mailing list krbdev@mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444