[29989] in Kerberos
Re: Proposal to change the meaning of -allow_tix +allow_svr aka
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Wed Jun 18 17:14:30 2008
Date: Wed, 18 Jun 2008 16:13:44 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Ken Raeburn <raeburn@mit.edu>
Message-ID: <20080618211343.GI2735@Sun.COM>
Mail-Followup-To: Ken Raeburn <raeburn@mit.edu>,
Kerberos mailing list list <kerberos@mit.edu>,
"krbdev@mit.edu List" <krbdev@mit.edu>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <BC4966C7-0FEC-4975-9AE0-CAD1161A06C7@mit.edu>
Cc: "krbdev@mit.edu List" <krbdev@mit.edu>,
Kerberos mailing list list <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Wed, Jun 18, 2008 at 04:54:04PM -0400, Ken Raeburn wrote:
> On Jun 18, 2008, at 16:33, Jeffrey Altman wrote:
> > I believe that the meaning of allow_tix should be altered such that
> > it only applies to the client
> > in a TGS or AS request. This would permit -allow_tix to be applied
> > to a service principal
> > and ensure that no client ticket requests can be satisfied for that
> > service principal while at
> > the same time permitting other principals to obtain service tickets.
> > Organizations that wish to disable the issuance of service tickets
> > for the service principal
> > would apply -allow_svr to the principal in addition to -allow_tix.
>
> I think it should be pointed out that such a change would allow
> tickets to start being issued where currently they would not when the
> KDC software gets updated -- even if the latter really was the intent
> of the realm administrator. Because of that, we might instead want to
> create a new flag with the semantics Jeff wants, and leave the
> existing flag with its current (suboptimal) behavior.
Or provide a migration script.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
