[OpenAFS] Kerberos 5, AFS, and no krb524d

[Neulinger, Nathan]

Perhaps we should just make a simple new pioctl that knows how to deal
with a k5 ticket, but internally strips out all but the encrypted part?
That would allow for doing the "aklog-like" activity, without having to
really dig into full k5 support? =20

(I'm just commenting, I haven't looked to see if the above has some
blatantly rediculous caveat.)

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: Derrick J Brashear [mailto:shadow@dementia.org]=20
> Sent: Friday, June 06, 2003 2:02 PM
> To: openafs-info@openafs.org
> Subject: Re: [OpenAFS] Kerberos 5, AFS, and no krb524d=20
>=20
>=20
> On Fri, 6 Jun 2003, Ken Hornstein wrote:
>=20
> > >I agree. Releasing a magic aklog that understands how to=20
> do something that
> > >isn't a krb5 ticket doesn't seem to fill the bill.
> >
> > Hm?  I'm not sure I understand.  This _is_ a V5 ticket=20
> we're putting in
> > the kernel for the cache manager.  I know about the=20
> backwards compatability
> > issues with older cells, and I don't have a good answer on=20
> how to deal
> > with that yet.  But if we consider aklog part of the client=20
> program, that's
> > easy for non-KDC admins to deal with.
>=20
> No, it's part of a krb5 ticket: the encrypted part. If it were a krb5
> ticket you could krb5_get_credentials something and stuff it into the
> kernel (probably with a header) and be done.
>=20
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
>=20