Jeffrey Altman <[EMAIL PROTECTED]> wrote: > Derrick J Brashear wrote: >> On Tue, 2 May 2006, Christopher D. Clausen wrote: >>> Jeffrey Altman <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] and [EMAIL PROTECTED] will > both be treated as the AFSID whose name is "user". Whereas the > principal name [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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. > > [EMAIL PROTECTED] > [EMAIL PROTECTED] Would principals with instances be written using Kerberos 5 syntax or Kerberos IV? i.e. would I use cclausen/[EMAIL PROTECTED] or [EMAIL PROTECTED] 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 >> [EMAIL PROTECTED] maps to [EMAIL PROTECTED] > > 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
