[OpenAFS-devel] 1.5.1 - multiple Kerberos realm support

[Christopher D. Clausen]

Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
> Derrick J Brashear wrote:
>> On Tue, 2 May 2006, Christopher D. Clausen wrote:
>>> Jeffrey Altman <jaltman@secure-endpoints.com> wrote:
>>>> The OpenAFS Gatekeepers announce the availability of OpenAFS
>>>> Development version 1.5.1 .
>>>> [snip]
>>>>
>>>> (3) partial support for multiple Kerberos realms mapping to a
>>>> single cell has been added to servers.
>>>
>>> Are there more details on this multiple Kerberos realm support
>>> somewhere?
>>
>> List them in /usr/afs/etc/krb.conf, one per line
>
> Correction.  The realms are white space separated on the first line
> of the /usr/afs/etc/krb.conf file.   The format of the file is
> compatible with the Kerberos IV krb.conf file.  This file format
> has one or more realms on the first line and subsequent lines in
> the file contain kdc listings.  OpenAFS ignores the kdc listings
> and only pays attention to the first realms listed on the first line.
>
> Each realm listed in the krb.conf file is considered a local realm.
> Authenticated principals belonging to a local realm are treated as
> local cell usernames.  For example, if the krb.conf file contains
> the realm names:
>
>  EXAMPLE.COM  AD.EXAMPLE.COM
>
> then the principal names user@EXAMPLE.COM and user@AD.EXAMPLE.COM will
> both be treated as the AFSID whose name is "user".  Whereas the
> principal name user@FOREIGN.COM will be treated as a foreign identity.

Let me see if I understand this...

Currently, ACM.UIUC.EDU (MIT realm) trusts AD.UIUC.EDU (MS Active 
Directory.)  Our afs cell keyfile is only in ACM.UIUC.EDU.  Users in the 
AD realm can either use gssklog to obtain tokens for acm.uiuc.edu 
directly, or use aklog and show up as foreign.  Upgrading to 1.5.1 (or 
newer) on the servers would allow user@AD principals to be treated as 
local users in the acm cell?  I would not need to add  the 
afs/acm.uiuc.edu princial in the AD realm?  Would the clients also need 
to be upgraded to 1.5.1, or would client accesses be transparently 
handled from older clients through the newer servers?

>> Usernames must map directly e.g. be the same in all realms, though.
>
> In addition to the krb.conf file there is also an exclusion file.
>
>  /usr/afs/etc/krb.excl
>
> This file contains a list of principal names that should not be
> treated as a local AFS identity.  This file contains one principal
> name per line.
>
>  user@AD.EXAMPLE.COM
>  admin@AD.EXAMPLE.COM

Would principals with instances be written using Kerberos 5 syntax or 
Kerberos IV? i.e. would I use cclausen/admin@AD.UIUC.EDU or 
cclausen.admin@AD.UIUC.EDU to prevent an AD admin from creating a 
principal to map to my system:administrator account?

Is the exclusion file functionality in the 1.5.1 code?

>>> And what exactly does "partial support" mean?
>>
>> It means later you'll be able to also say
>> userA@realm1 maps to userB@realm2
>
> To elaborate on this statement.  Work is being performed to extend the
> AFS Protection database to allow multiple names to be associated with
> the same AFSID.  Currently, I have multiple Kerberos principals from
> realms that have exchanged cross-realm keys.  When accessing a volume
> in cell 'a' I want to be able to access the volume with a single AFSID
> regardless of which of the Kerberos principals I control that I am
> using at a given time.
>
> When the Protection Server extensions are complete, it will be
> possible to associate not only short names "user" with an AFSID but a
> Kerberos 5 principal name or other name types that may be registered
> in the future.

Ah, Excellent!

Realm trusts (in at least one direction) must exist between these realms 
though, correct?

<<CDC