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 ; 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 >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 >Release: 1.0-development >Environment: System: SunOS DUN-DUN-NOODLES 5.4 Generic_101945-37 sun4m sparc >Description: Date: Tue, 22 Oct 1996 14:24:44 -0400 From: "Barry Jaspan" 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: >How-To-Repeat: >Fix: >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 >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. 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