I agree that / accounts are very useful. My organization assigns me one
(and only one) username.
My regular account has a strong password.
My /wireless account has a different password, and I let my PC 'remember'
it so I don't have to type it just to connect to the wireless network using
802.1x.
My problem is that I don't like a multiplicity of names for a single
user entity.
Instead I'd like much more in the way of attributes being passed in
ancillary data like, e.g., authorization-data.
I.e., I prefer the Windows/AD model. I get that in general that's a
difficult model to apply
Nico Williams n...@cryptonector.com writes:
I.e., I prefer the Windows/AD model. I get that in general that's a
difficult model to apply outside Windows, but still, I prefer it.
We use separate user principals in Windows/AD for privileged actions for
exactly the same reason.
--
Russ Allbery
On Fri, Jan 18, 2013 at 1:35 PM, Russ Allbery r...@stanford.edu wrote:
Nico Williams n...@cryptonector.com writes:
There's really no point to the /admin thing: since the server requires
INITIAL tickets there's no risk of use of stolen TGTs for accessing
kadmin, and if you were to have
Nico Williams n...@cryptonector.com writes:
On Fri, Jan 18, 2013 at 1:35 PM, Russ Allbery r...@stanford.edu wrote:
Er, it's still a good security practice to use a separate set of
credentials that you don't type into everything all the time to do your
daily work. Particularly given that we
Can anyone explain away the reasoning behind the decision
to make user principals need the form:
specific_part/contextual_part
e.g. jennifer/admin
and service principals the OPPOSITE - of the form
contextual_part/specific_part
e.g. host/daffodil.mit.edu
What happened? Who
On Fri, Jan 18, 2013 at 11:25 AM, Jeff Blaine jbla...@kickflop.net wrote:
Can anyone explain away the reasoning behind the decision
to make user principals need the form:
specific_part/contextual_part
e.g. jennifer/admin
and service principals the OPPOSITE - of the form
also have an additional principal, with an instance called
admin.
You might want to check out kadm5.acl to see how /instance is being used.
Date: Fri, 18 Jan 2013 11:44:31 -0600
Subject: Re: Principal naming
From: n...@cryptonector.com
To: jbla...@kickflop.net
CC: kerberos@mit.edu
On Fri
Jeff Blaine jbla...@kickflop.net writes:
Can anyone explain away the reasoning behind the decision
to make user principals need the form:
specific_part/contextual_part
e.g. jennifer/admin
and service principals the OPPOSITE - of the form
contextual_part/specific_part
On 1/18/2013 2:13 PM, Bob Liu wrote:
You should look at it this way... |primary/instance@REALM
|In the case of a user, it's the same as your username. For a host, the
primary is the word |host|.
The instance is an optional string that qualifies the primary. In the
case of a user, the
Nico Williams n...@cryptonector.com writes:
There's really no point to the /admin thing: since the server requires
INITIAL tickets there's no risk of use of stolen TGTs for accessing
kadmin, and if you were to have different pre-authentication
requirements for kadmin than for initial TGTs the
11 matches
Mail list logo
