Adam Megacz wrote:
"Douglas E. Engert" <[EMAIL PROTECTED]> writes:
Looks like they let you register the principal gssklog/[EMAIL PROTECTED]
Correct; I requested that a few days ago and imported the secret key
they generated for me into /etc/krb5.keytab.
-s gssklog/[EMAIL PROTECTED] \
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/[EMAIL PROTECTED]
... it's using the "home" realm for the "@<realm>" part. It ought to
be using the foriegn realm. If I use "-s [EMAIL PROTECTED]", 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/[EMAIL PROTECTED]
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/[EMAIL PROTECTED]
or
gssklog/[EMAIL PROTECTED]
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/[EMAIL PROTECTED]
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:
[EMAIL PROTECTED] hostname
reconfigurable.cs.berkeley.edu
[EMAIL PROTECTED] dig reconfigurable.cs.berkeley.edu
reconfigurable.cs.berkeley.edu. 86400 IN A 128.32.37.206
[EMAIL PROTECTED] 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
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Douglas E. Engert <[EMAIL PROTECTED]>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
--- ,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);
