On Mon, Feb 04, 2002 at 07:01:43PM -0500, Marc Horowitz wrote:
It requires no changes to the protocol or KDC to use the local TGT to
get forwardable service tickets for the short list of specific
services you care about, and forward those.
As long as the list is short... :)
On Tue, 22 Jan 2002, Nicolas Williams wrote:
It probably calls krb5_kuserok(), which, if (~/.k5login does not exist
AND username == krb5_aname_to_lname(client_principal)) returns true.
OTOH, if ~/.k5login exists and the client principal name is not listed
in it, access is denied, even if
On Mon, Feb 04, 2002 at 02:21:43PM -0800, Booker C. Bense wrote:
On Mon, 4 Feb 2002, Nicolas Williams wrote:
On Mon, Feb 04, 2002 at 08:12:20PM +, Paul Jakma wrote:
and thanks everyone for setting straight re: the idea of ticket ACL's.
:)
Actually, I think that it would be a
Nicolas == Nicolas Williams [EMAIL PROTECTED] writes:
Nicolas On Mon, Feb 04, 2002 at 02:21:43PM -0800, Booker C. Bense
Nicolas wrote:
On Mon, 4 Feb 2002, Nicolas Williams wrote:
On Mon, Feb 04, 2002 at 08:12:20PM +, Paul Jakma wrote:
and thanks everyone for
[EMAIL PROTECTED] (Nicolas Williams) writes:
Actually, I think that it would be a good thing if there were an
authorization data type for packing ticket ACLs (i.e., princ name
patterns) into forwarded TGTs. The idea being that you could forward a
TGT that is crippled and allows the receiver
Paul == Paul Jakma [EMAIL PROTECTED] writes:
Paul On 21 Jan 2002, Sam Hartman wrote:
No, at worst a principal is granted access because a service
assuming the KDC does authorization is deployed in a realm
where this is not the case. The interop problem happens when
On Tue, Jan 22, 2002 at 12:27:14PM -0500, Sam Hartman wrote:
Paul == Paul Jakma [EMAIL PROTECTED] writes:
I am aware of no widely deployed Kerberos applications without
authorization support.
Paul pam_krb5?
The pam_krb5 I use certainly checks .k5login in the account step.
Paul == Paul Jakma [EMAIL PROTECTED] writes:
Paul hi, i'm wondering whether it would be possible to implement
Paul ACLs for service ticket requests?
Yes, unfortunately it might be possible to do this. This means
someone might do it. Depending on how they did it they would either
hi,
i'm wondering whether it would be possible to implement ACLs for
service ticket requests?
eg, something like a way to specify on the KDC which principals are
allowed to request service tickets for whatever service principals.
perhaps something as simple as:
host/* *
On 21 Jan 2002, Sam Hartman wrote:
Yes, unfortunately it might be possible to do this. This means
someone might do it. Depending on how they did it they would
either create a security problem or an interoperability problem.
shouldnt be an interoperability problem should it? it would be
Paul == Paul Jakma [EMAIL PROTECTED] writes:
Paul On 21 Jan 2002, Sam Hartman wrote:
Yes, unfortunately it might be possible to do this. This means
someone might do it. Depending on how they did it they would
either create a security problem or an interoperability
On 21 Jan 2002, Sam Hartman wrote:
No, at worst a principal is granted access because a service
assuming the KDC does authorization is deployed in a realm where
this is not the case. The interop problem happens when someone
wants to deploy a service but realizes they cannot do so because
No, at worst a principal is granted access because a service
assuming the KDC does authorization is deployed in a realm where
this is not the case. The interop problem happens when someone
wants to deploy a service but realizes they cannot do so because
it requires authorization features their
I am aware of no widely deployed Kerberos applications without
authorization support.
pam_krb5?
You have to be in the Unix password file for pam_krb5 to give you access
to a machine. At least, any pam_krb5 implementation I've ever seen works
that way. And assuming you could login as
14 matches
Mail list logo
