From bjaspan@MIT.EDU Tue Oct 22 18:10:24 1996
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id SAA14434 for <bugs@RT-11.MIT.EDU>; Tue, 22 Oct 1996 18:10:24 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA04058; Tue, 22 Oct 96 18:10:23 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA29241; Tue, 22 Oct 1996 18:10:21 -0400
Message-Id: <9610222210.AA29241@DUN-DUN-NOODLES.MIT.EDU>
Date: Tue, 22 Oct 1996 18:10:21 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: add this to kadm5/api-funcspec.tesx
X-Send-Pr-Version: 3.99
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
Date: Tue, 22 Oct 1996 14:24:44 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: kerberos@MIT.EDU
Subject: Explanation of a certain KADM5 behavior
Someone recently asked me question about a particular KADM5 behavior,
and I decided the question was good enough and the answer
non-intuitive enough to warrant forwarding the answer here.
In the KADM5 api specification, kadm5_get_principal is specified to
require the following authorization:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Wed Oct 30 13:12:49 1996
State-Changed-Why:
Done. Most of the information was already contained in
api-funcspec.tex's Authentication and Authorization section, so I just
added some more detail. Files:
doc/kadm5/api-funcspec.tex
The question was "what does this mean, particularly the second
sentence, and why?"
Two KADM5 administrative service principals exist: kadmin/admin and
kadmin/changepw (well, actually three exist, but that's not
important...). A KADM5 client (like kpasswd or kadmin) acquires a
Kerberos ticket for one of the services in order to authenticate
itself to the kadmind server. A KADM5 client can choose to use either
service principal, but the choice matters.
The sentence "If the request is authenticated to the kadmin/changepw
service, the get privilege is disregarded" means that if the request
is authenticated to kadmin/changepw, then it is as if the caller does
not have the "get" permission the duration of this call (even if the
caller does have it acording to the acl file). So, in that case, only
the second part of the first sentence is operative: "the calling
principal being the same as the princ argument." This means that a
principal can *always* retrieve its own principal record, regardless
of whether it authenticated via kadmin/admin or kadmin/changepw. If
the caller has the get privilege, and if the caller authenticated via
kadmin/admin, then it can also retrieve any other principal record.
But if the caller has the get privilege and authenticated with
kadmin/changepw, then the get priv is ignord and it can only retrieve
its own principal record. Similar logic applies to chpass_principal
(change password), randkey_principal (randomize password), and
get_policy (when retrieving the policy assigned to the calling
principal).
To put it another way: Principals can always perform the essential
functions on themselves, via either kadmin/admin or kadmin/changepw.
But no principal authenticated with kadmin/changepw can ever operate
on any principal other than itself. If you want to use any of your
administrative permissions, you have to authenticate with
kadmin/admin. Luckily, humans never have to think about this
distinction, though, because the kadmin cli *always* authenticates via
kadmin/admin.
There is a good reason for the distinction between kadmin/admin and
kadmin/changepw. The kadmin/changepw principal has a special
attribute bit set that says "the KDC will issue tickets for this
principal even if the password of the client requesting the ticket has
expired." This is why you can run kpasswd (which performs an AS_REQ,
just like kinit) even when your password is expired. However, the
admin system does not want to allow an administrator with an expired
password to perform administration tasks. Thus, only kadmin/changepw
has the special bit set, not kadmin/admin, and kadmin/changepw does
not allow administrative actions to be performed on arbitrary
principals.
I think I'll add this explanation to the functional spec...
Barry
Received: from MIT.EDU (SOUTH-STATION-ANNEX.MIT.EDU [18.72.1.2]) by rt-11.MIT.EDU (8.7.5/8.7.3) with SMTP id SAA14434 for <bugs@RT-11.MIT.EDU>; Tue, 22 Oct 1996 18:10:24 -0400
Received: from DUN-DUN-NOODLES.MIT.EDU by MIT.EDU with SMTP
id AA04058; Tue, 22 Oct 96 18:10:23 EDT
Received: by DUN-DUN-NOODLES.MIT.EDU (5.x/4.7) id AA29241; Tue, 22 Oct 1996 18:10:21 -0400
Message-Id: <9610222210.AA29241@DUN-DUN-NOODLES.MIT.EDU>
Date: Tue, 22 Oct 1996 18:10:21 -0400
From: bjaspan@MIT.EDU
Reply-To: bjaspan@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: add this to kadm5/api-funcspec.tesx
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 130
>Category: krb5-doc
>Synopsis: add this to kadm5/api-funcspec.tesx
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 18:11:01 EDT 1996
>Last-Modified: Wed Oct e 13:13:59 EST 1996
>Originator: Barry Jaspan
>Organization:
mit>Category: krb5-doc
>Synopsis: add this to kadm5/api-funcspec.tesx
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: krb5-unassigned
>State: closed
>Class: sw-bug
>Submitter-Id: unknown
>Arrival-Date: Tue Oct e 18:11:01 EDT 1996
>Last-Modified: Wed Oct e 13:13:59 EST 1996
>Originator: Barry Jaspan
>Organization:
Show quoted text
>Release: 1.0-development
>Environment:
>Environment:
System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc
Show quoted text
>Description:
Date: Tue, 22 Oct 1996 14:24:44 -0400
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: kerberos@MIT.EDU
Subject: Explanation of a certain KADM5 behavior
Someone recently asked me question about a particular KADM5 behavior,
and I decided the question was good enough and the answer
non-intuitive enough to warrant forwarding the answer here.
In the KADM5 api specification, kadm5_get_principal is specified to
require the following authorization:
Show quoted text
>How-To-Repeat:
Show quoted text
>Fix:
Show quoted text
>Audit-Trail:
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Wed Oct 30 13:12:49 1996
State-Changed-Why:
Done. Most of the information was already contained in
api-funcspec.tex's Authentication and Authorization section, so I just
added some more detail. Files:
doc/kadm5/api-funcspec.tex
Show quoted text
>Unformatted:
>> AUTHORIZATION REQUIRED: get, or the calling principal being the same
>> as the princ argument. If the request is authenticated to the
>> kadmin/changepw service, the get privilege is disregarded.
>> as the princ argument. If the request is authenticated to the
>> kadmin/changepw service, the get privilege is disregarded.
The question was "what does this mean, particularly the second
sentence, and why?"
Two KADM5 administrative service principals exist: kadmin/admin and
kadmin/changepw (well, actually three exist, but that's not
important...). A KADM5 client (like kpasswd or kadmin) acquires a
Kerberos ticket for one of the services in order to authenticate
itself to the kadmind server. A KADM5 client can choose to use either
service principal, but the choice matters.
The sentence "If the request is authenticated to the kadmin/changepw
service, the get privilege is disregarded" means that if the request
is authenticated to kadmin/changepw, then it is as if the caller does
not have the "get" permission the duration of this call (even if the
caller does have it acording to the acl file). So, in that case, only
the second part of the first sentence is operative: "the calling
principal being the same as the princ argument." This means that a
principal can *always* retrieve its own principal record, regardless
of whether it authenticated via kadmin/admin or kadmin/changepw. If
the caller has the get privilege, and if the caller authenticated via
kadmin/admin, then it can also retrieve any other principal record.
But if the caller has the get privilege and authenticated with
kadmin/changepw, then the get priv is ignord and it can only retrieve
its own principal record. Similar logic applies to chpass_principal
(change password), randkey_principal (randomize password), and
get_policy (when retrieving the policy assigned to the calling
principal).
To put it another way: Principals can always perform the essential
functions on themselves, via either kadmin/admin or kadmin/changepw.
But no principal authenticated with kadmin/changepw can ever operate
on any principal other than itself. If you want to use any of your
administrative permissions, you have to authenticate with
kadmin/admin. Luckily, humans never have to think about this
distinction, though, because the kadmin cli *always* authenticates via
kadmin/admin.
There is a good reason for the distinction between kadmin/admin and
kadmin/changepw. The kadmin/changepw principal has a special
attribute bit set that says "the KDC will issue tickets for this
principal even if the password of the client requesting the ticket has
expired." This is why you can run kpasswd (which performs an AS_REQ,
just like kinit) even when your password is expired. However, the
admin system does not want to allow an administrator with an expired
password to perform administration tasks. Thus, only kadmin/changepw
has the special bit set, not kadmin/admin, and kadmin/changepw does
not allow administrative actions to be performed on arbitrary
principals.
I think I'll add this explanation to the functional spec...
Barry