[OpenAFS] Re: gssklog[d] works with berkeley.edu kerberos realm, but needed a hack -- why?

Douglas E. Engert deengert@anl.gov
Thu, 28 Apr 2005 10:26:49 -0500


This is a multi-part message in MIME format.
--------------090503070002000504070400
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit



Adam Megacz wrote:

> "Douglas E. Engert" <deengert@anl.gov> writes:
> 
>>Looks like they let you register the principal gssklog/...@BERKLEY.EDU
> 
> 
> Correct; I requested that a few days ago and imported the secret key
> they generated for me into /etc/krb5.keytab.
> 
> 
>>>           -s gssklog/reconfigurable.cs.berkeley.edu@BERKELEY.EDU \
> 
> 
>>The -s option is for the GSSAPI import name, which is not the same as
>>a krb5 principal name, as the gss is expecting <service>@<host>
>>If the krb5 gss is being used, you should not need the -s option,
>>as the defaults for creating a principal will be gssklog/<host>@<realm>
> 
> 
> Right, but if I don't specify the "-s" option, it tries:
> 
>   len=69, name=gssklog/reconfigurable.cs.berkeley.edu@RECONFIGURABLE.CS.BERKELEY.EDU
> 
> ... it's using the "home" realm for the "@<realm>" part.  It ought to
> be using the foriegn realm.  If I use "-s gssklog@BERKELEY.EDU", it's


But the -s option is passed to gssapi, and it should have <service>@<host>
not <servide>@<realm> So even though it is close, it should not work like that.

> *almost* right:
> 
>   len=41, name=gssklog/arachne.berkeley.edu@BERKELEY.EDU


> 
> Again, I have no clue what arachne is.  

Me neither, but it sure looks like some DNS, /etc/host or krb5.conf
problem on your end.

> How do I forcibly override this?

There is a GSSAPI limitation in that it only accepts <service>@<host>
which for Kerberos is not enough information to allow the application
to supply the full principal name. (The IETF Kitten group is looking
at this.)

There are two ways around this:

  (1) have an extra krb5.conf file with the default realm of BERKLEY.EDU
      or the [domain_realm]   reconfigurable.cs.berkeley.edu = BERKELEY.EDU
      The have enviroment variable KRB5_CONFIG set in the environment before
      the gssklogd is run.

  (2) Use a modified gss that will allow the server to use any entry
      in the keytab  where the service and host match. Thus the same
      gssklogd could respond to:
       gssklog/reconfigurable.cs.berkeley.edu@BERKELEY.EDU
       or
       gssklog/reconfigurable.cs.berkeley.edu@RECONFIGURABLE.CS.BERKELEY.EDU

Option (2) is probably what you will want in the long run anyway, as you are
running two realms, and are not using cross realm (or are you?). See the attached
patch for accept_sec_context.c

> 
> 
>>Its not gssklog/<afscell>@<realm>
>>but     gssklog/<host of gssklogd server>@<realm>
> 
> 
> Ok, in my case, these happen to be the same thing.  But I'll keep that
> in mind.
> 
> 
>>You will need a principal in the realm and the keytab for
>>gssklog/arachne.berkely.edu@BERKELEY.EDU
>>I assume that the host name of the afs/gssklogd server is arachne.berkley.edu?
>>Or was you IP once asigned to arachne, and DNS needs to be updated?
> 
> 
> No:
> 
>   root@reconfigurable# hostname
>   reconfigurable.cs.berkeley.edu
> 
>   root@reconfigurable# dig reconfigurable.cs.berkeley.edu
>   reconfigurable.cs.berkeley.edu. 86400 IN A      128.32.37.206
> 
>   root@reconfigurable# dig -x 128.32.37.206
>   206.37.32.128.in-addr.arpa. 3600 IN     PTR     reconfigurable.CS.Berkeley.EDU.
> 
> 
> 
>>In any case the principal has the hostname.
> 
> 
> Um, I don't understand.
never mind, you host matches the cell name.
> 
> 
>>Note for AFS with gssklog, you don't need your own realm. But if
>>you do have users in your realm and don't use cross realm
>>You may also want to add a principal to  your own realm,
> 
> 
> Right, I will need to add users who don't have @BERKELEY.EDU
> principals (and are not able to get them).
> 
> 
>>Answer:Mis-understanding of the -s option and the principals used by default.
> 
> 
> Okay, but we still haven't figured out why gssklogd thinks my machine
> is arachne.  Or even where that name came from.  Polling /dev/random,
> perhaps?
> 

The arachne is still a mystery. But does your krb5.conf have a line with:
   berkeley.edu = archane.berkeley.edu


>   - a
> 
> 
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
> 
> 
> 

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

--------------090503070002000504070400
Content-Type: text/plain;
 name="acdept_sec_context.c.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="acdept_sec_context.c.patch"

--- ,accept_sec_context.c	Wed Jul 28 21:26:43 2004
+++ accept_sec_context.c	Fri Mar  4 09:54:52 2005
@@ -402,11 +402,39 @@
        goto fail;
    }
 
-   if ((code = krb5_rd_req(context, &auth_context, &ap_req, cred->princ,
+   if ((code = krb5_rd_req(context, &auth_context, &ap_req, NULL,
 			   cred->keytab, NULL, &ticket))) {
        major_status = GSS_S_FAILURE;
        goto fail;
    }
+/*
+ * Allow for lax checking of the princ name. This will allow
+ * us to have ssh and ftp use any of the tickets in the 
+ * keytab, as we change from dce.anl.gov to KRB5.ANL.GOV
+ * rlogin already allows this. We will check all but realm.
+ */
+   if ( cred->princ && ticket->server) {
+               int i;
+               int nelem; 
+               nelem = krb5_princ_size(context, cred->princ);
+               if (nelem == krb5_princ_size(context,ticket->server)) {
+                       for (i = 0; i < nelem; i++) {
+                               register const krb5_data *p1 = 
+                                       krb5_princ_component(context, cred->princ ,i);
+                               register const krb5_data *p2 = 
+                                       krb5_princ_component(context, ticket->server, i);
+                               if (p1->length != p2->length ||
+                                               memcmp(p1->data, p2->data, p1->length)) {
+                                       major_status = GSS_S_FAILURE;
+                                       goto fail;
+                               }
+                       }
+               } else {
+                       major_status = GSS_S_FAILURE;
+                       goto fail;
+               }
+   }
+
    krb5_auth_con_setflags(context, auth_context,
 			  KRB5_AUTH_CONTEXT_DO_SEQUENCE);
 

--------------090503070002000504070400--