Skip Menu |
 

Date: Thu, 19 May 2005 13:17:33 -0600
From: "Shawn M. Emery" <Shawn.Emery@Sun.COM>
To: krb5-bugs@mit.edu
Subject: Solaris client and 1.4 kadmind
Download (untitled) / with headers
text/plain 1.9KiB

For rpcsec-gss kadm5, Solaris has always used the changepw/<master_fqhn>
principal. Starting with MIT 1.4's kadmind, it now supports a
rpcsec-gss kadmind. However, it expects and it's clients to only use
the kadmin/changepw service principal. The problem is that MIT is
restricting the authorization to kadmin/changepw and this subsequently
causes a Solaris kpasswd interop issue:

client% kpasswd
kpasswd: Changing password for user1.
Old password:
kpasswd: Cannot establish a session with the Kerberos administrative
server for realm EXAMPLE.COM. Communication failure with server.

The server yields:
May 18 21:22:22 kdc1 krb5kdc[15301](info): AS_REQ (5 etypes {17 16 23 3
1}) 1.2.3.4: ISSUE: authtime 1116476542, etypes {rep=16 tkt=16 ses=16},
user1@EXAMPLE.COM for changepw/kdc1.example.com@EXAMPLE.COM
May 18 21:22:24 kdc1 kadmind[15407](Error): bad service principal
changepw/kdc1.example.com@EXAMPLE.COM
May 18 21:22:24 kdc1 kadmind[15407](Error): Authentication attempt
failed: 1.2.3.4, RPC authentication flavor 6

The solution is to have MIT open up the check to include the
changepw/<master_fqhn> service principal for the rpcsec-gss protocol
(see below). It would also be helpful if MIT's kdb5_util create command
create the changepw/<master_fqhn> along with the default principal set.

Shawn.
--
Sun Microsystems, Inc. Software Security Group (Kerberos)

Diffs for 1.4.1 source
----------------------
src/kadmin/server/kadm_rpc_svc.c:
@@ -283,11 +283,12 @@

c1 = krb5_princ_component(kctx, princ, 0);
c2 = krb5_princ_component(kctx, princ, 1);
realm = krb5_princ_realm(kctx, princ);
if (strncmp(handle->params.realm, realm->data, realm->length) == 0
- && strncmp("kadmin", c1->data, c1->length) == 0) {
+ && (strncmp("kadmin", c1->data, c1->length) == 0
+ || strncmp("changepw", c1->data, c1->length) == 0)) {

if (strncmp("history", c2->data, c2->length) == 0)
goto fail_princ;
else
success = 1;
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #3064] Solaris client and 1.4 kadmind
From: Sam Hartman <hartmans@mit.edu>
Date: Fri, 20 May 2005 11:26:44 -0400
RT-Send-Cc:
I'd like to confirm that we don't have an interop problem if we use
the non-rpc change password approach?

If we do open up support for this principal, we would need to make
sure that it was an AS request. Typically we do that with KDC flags;
I would feel uncomfortable for that with a new principal and so we
would need a check in kadmind.
Date: Fri, 20 May 2005 14:22:50 -0600
From: Shawn M Emery <Shawn.Emery@Sun.COM>
Subject: Re: [krbdev.mit.edu #3064] Solaris client and 1.4 kadmind
To: rt-comment@krbdev.mit.edu
RT-Send-Cc:
Sam Hartman via RT wrote:

Show quoted text
>I'd like to confirm that we don't have an interop problem if we use
>the non-rpc change password approach?
>
>
Yes, the horowitz implementation uses the kadmin/changepw service
principal on a Solaris client, so this works fine as is.

Show quoted text
>If we do open up support for this principal, we would need to make
>sure that it was an AS request. Typically we do that with KDC flags;
>I would feel uncomfortable for that with a new principal and so we
>would need a check in kadmind.
>
>
Wouldn't that be helpful regardless if the server is changepw or kadmin?

Thanks,

Shawn.
--
Date: Fri, 20 May 2005 17:30:31 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: rt@krbdev.mit.edu, Sam Hartman <hartmans@mit.edu>
Subject: Re: [krbdev.mit.edu #3064] Solaris client and 1.4 kadmind
RT-Send-Cc:
On Fri, May 20, 2005 at 03:59:27PM -0400, Sam Hartman via RT wrote:
Show quoted text
> I'd like to confirm that we don't have an interop problem if we use
> the non-rpc change password approach?

We don't have such an interop problem, no.

Show quoted text
> If we do open up support for this principal, we would need to make
> sure that it was an AS request. Typically we do that with KDC flags;
> I would feel uncomfortable for that with a new principal and so we
> would need a check in kadmind.

The rpcsec_gss APIs in Solaris don't work that way, so you have to rely
on KDC flags.

Even if the rpcsec_gss APIs were better designed, since we're talking
GSS we'd need extensions in order to be able to observe the INITIAL
flag. Can we do that with name attributes?

Nico
--