From klmitch@MIT.EDU Fri Sep 27 15:32:49 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 PAA08993 for <bugs@RT-11.MIT.EDU>; Fri, 27 Sep 1996 15:32:48 -0400
Received: from STARKILLER.MIT.EDU by MIT.EDU with SMTP
id AA09931; Fri, 27 Sep 96 15:32:42 EDT
Received: by starkiller.MIT.EDU (5.x/4.7) id AA04409; Fri, 27 Sep 1996 15:32:30 -0400
Message-Id: <9609271932.AA04409@starkiller.MIT.EDU>
Date: Fri, 27 Sep 1996 15:32:30 -0400
From: klmitch@MIT.EDU
Reply-To: klmitch@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: kprop is expecting authentication to wrong principle
X-Send-Pr-Version: 3.99
System: SunOS starkiller 5.4 Generic_101945-37 sun4m sparc
as specified in [domain_realms], even when given the -r option to specify
another realm. This might be a problem if a site, which has one realm, also
maintains a Kerberos realm for another site on a separate KDC from their
internal one. kprop does authenticate to the "expected" principle.
propagate to another machine, again in the Athena realm. I was at first
confused by the error message and thought kprop was at fault, but it was
kpropd, which was expecting authentication to itself in the Athena realm,
whereas kprop was attempting for the Zone realm.
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: klmitch@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/39: kprop is expecting authentication to wrong principle
Date: Fri, 18 Oct 1996 17:39:08 -0400
Ted and I did some poking and discovered that the source of the
problem is that krb5_sname_to_principal does not take a realm
argument. rlogin and kprop both munge the realm of the principal
returned by that function to have the realm specified by the -k or -r
command line argument (respectively), but kpropd doesn't; that is the
source of this bug report.
The larger questin is whether krb5_sname_to_principal should take a
realm argument. If so, we could either create a new function to do
it, or this could be the first test case for krb5 api versioning.
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Tue Oct 22 17:01:20 1996
State-Changed-Why:
Fixed. Files:
slave/ChangeLog
slave/kpropd.c
Note that another PR, [krb5-libs/129], has been submitted discussing
the limitation in krb5_sname_to_principal.
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 PAA08993 for <bugs@RT-11.MIT.EDU>; Fri, 27 Sep 1996 15:32:48 -0400
Received: from STARKILLER.MIT.EDU by MIT.EDU with SMTP
id AA09931; Fri, 27 Sep 96 15:32:42 EDT
Received: by starkiller.MIT.EDU (5.x/4.7) id AA04409; Fri, 27 Sep 1996 15:32:30 -0400
Message-Id: <9609271932.AA04409@starkiller.MIT.EDU>
Date: Fri, 27 Sep 1996 15:32:30 -0400
From: klmitch@MIT.EDU
Reply-To: klmitch@MIT.EDU
To: krb5-bugs@MIT.EDU
Subject: kprop is expecting authentication to wrong principle
X-Send-Pr-Version: 3.99
Show quoted text
>Number: 39
>Category: krb5-admin
>Synopsis: kprop is expecting authentication to wrong principle
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bjaspan
>State: closed
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Fri Sep e 15:33:00 EDT 1996
>Last-Modified: Tue Oct e 17:02:20 EDT 1996
>Originator: Kevin L Mitchell
>Organization:
mit>Category: krb5-admin
>Synopsis: kprop is expecting authentication to wrong principle
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: bjaspan
>State: closed
>Class: change-request
>Submitter-Id: unknown
>Arrival-Date: Fri Sep e 15:33:00 EDT 1996
>Last-Modified: Tue Oct e 17:02:20 EDT 1996
>Originator: Kevin L Mitchell
>Organization:
Show quoted text
>Release: 1.0-development
>Environment:
>Environment:
System: SunOS starkiller 5.4 Generic_101945-37 sun4m sparc
Show quoted text
>Description:
kpropd always expects authentication to the machine's default realmas specified in [domain_realms], even when given the -r option to specify
another realm. This might be a problem if a site, which has one realm, also
maintains a Kerberos realm for another site on a separate KDC from their
internal one. kprop does authenticate to the "expected" principle.
Show quoted text
>How-To-Repeat:
I set up a V5 server inside the Athena realm and attempted topropagate to another machine, again in the Athena realm. I was at first
confused by the error message and thought kprop was at fault, but it was
kpropd, which was expecting authentication to itself in the Athena realm,
whereas kprop was attempting for the Zone realm.
Show quoted text
>Fix:
>Audit-Trail:
>Audit-Trail:
From: "Barry Jaspan" <bjaspan@MIT.EDU>
To: klmitch@MIT.EDU
Cc: krb5-bugs@MIT.EDU
Subject: Re: krb5-admin/39: kprop is expecting authentication to wrong principle
Date: Fri, 18 Oct 1996 17:39:08 -0400
Ted and I did some poking and discovered that the source of the
problem is that krb5_sname_to_principal does not take a realm
argument. rlogin and kprop both munge the realm of the principal
returned by that function to have the realm specified by the -k or -r
command line argument (respectively), but kpropd doesn't; that is the
source of this bug report.
The larger questin is whether krb5_sname_to_principal should take a
realm argument. If so, we could either create a new function to do
it, or this could be the first test case for krb5 api versioning.
State-Changed-From-To: open-closed
State-Changed-By: bjaspan
State-Changed-When: Tue Oct 22 17:01:20 1996
State-Changed-Why:
Fixed. Files:
slave/ChangeLog
slave/kpropd.c
Note that another PR, [krb5-libs/129], has been submitted discussing
the limitation in krb5_sname_to_principal.
Show quoted text
>Unformatted: