Question: want different default_realm for service and user principles

[Douglas E. Engert]

Dirk Pape wrote:

> Hello,
> 
> I want to do the following with two kerberos realms which trust each 
> other:
> 
> first realm "FOO.ORG" holds only user principles, it is based on a 
> Windows 2003 Server AD.
> 
> second realm "BAR.FOO.ORG" hold service principles for unix services, 
> such as "host/domain at BAR.FOO.ORG" for all unix hosts running ssh.
> We want to hold these principals in a MIT-kerb. based KDC, because we 
> like to use the well known and well documented kadmin tool to remotely 
> create service principles in that domain.
> 
> As I understand it will be possible to authenticate as "user at FOO.ORG" to 
> a service running with a keytab for a service principle 
> "service/domain at BAR.FOO.ORG" if both realms trust each other.
> 
> First question: is this correct and a reasonable scenario? (we could not 
> yet test it because we did not yet set up the BAR.FOO.ORG domain).

Yes, this is what we do. A few thousand users and Windows PCs in AD, and
a few hundred UNIX servers and workstations registered in a MIT based realm.

> 
> If this works and is a reasonable approach, then we see the following 
> problem from our tests.
> 
> let the [libdefaults] section in /etc/krb5.conf on the unix host running 
> the kerberized ssh service contain "default_realm = BAR.FOO.ORG", then 
> obtaining user tgts on login (via pam) or by "kinit user" on this host 
> will fail, because it will try to get it from realm BAR.FOO.ORG.

No, use default_realm=FOO.BAR

For example, I can ssh form my Windows PC to my Solaris 9 workstation,
or login at the console via PAM using my Window AD principal.

> 
> on the other hand, if "default_realm = FOO.ORG" the ssh service and 
> other service would not find the correct keytab entry because they look 
> for "service/domain at FOO.ORG" instead of "service/domain at BAR.FOO.ORG".
> 

Then in src/lib/gssapi/krb5/accept_sec_context.c we added this:

                            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_getauthenticator(context, auth_context, &authdat);

(I will submit this as a mod to MIT today.)

> For what I see, I need to specify somehow that SPNs and user PNs come 
> from different realms in default.

As Jeff pointed out, another approach is to start sshd with
KRB5_CONFIG=/etc/krb5.server.conf already set.

But if you also allow ssh login via Krb user and password, this
would set the deafult realm for these user to the wrong realm.

> 
> Is this doable with some configuraton options on the unix host? (I 
> already tried many things with the sections [domain_realm] and 
> [appdefaults] but I could ot find a way)

In inetd.conf, use something like with wrapper (all on one line):
kftp stream tcp nowait root /usr/sbin/in.tcpd
/bin/env KRB5_CONFIG=/etc/krb5.server.conf /krb5/sbin/ftpd -l -a

> 
> I would appreciate every hint.
> 
> The other approach for our problem would be to find or implement an RPC 
> on the windows server running AD, which like kadmin/kadmind enables 
> admins to create SPNs remotely and transfer keytab securely to the 
> service host.
> 
> last question: does anybody know such a daemon for windows 2003 server?
> 
> Thanks,
> Dirk.
> 

-- 

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