Christopher D. Clausen wrote: > Jeffrey Altman <[EMAIL PROTECTED]> wrote: >> 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?
Correct > I would not need to add the > afs/acm.uiuc.edu princial in the AD realm? Correct > 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? This is a server only change. >>> 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? Kerberos 5 > Is the exclusion file functionality in the 1.5.1 code? Yes >>>> 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? If a cross-realm key exchange has not been performed then you can create afs/[EMAIL PROTECTED] service principals in multiple realms and install all of the keys. As long as the kvno values are different the multiple keys can co-exist. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
