[OpenAFS] Re: one afs/cell.domain princs per realm
Douglas E. Engert
deengert@anl.gov
Wed, 27 Aug 2003 11:13:21 -0500
Chris McClimans wrote:
>
> I'm in the end just trying to manipulate the ptserver database to have
> specific uid's for a particular kerberos principle. (ie to match the
> campus wide integer/UID per student)
The username to UID mappings are stored in the PTS. But UIDs are also
on every ACL for every directory. So if you are changing UIDs, you also
need to change the ACLs for many directories.
You can live with the UIDs not matching the campus wide, (ls -l uses the
uid to look in /etc/passwd to get the username, but this is only for
looks. It has nothing to do with security.
But for security the UIDs in the ACLs better match the UIDs in the PTS.
>
> Current setup:
>
> krbtgt/CS.TTU.EDU@TTU.EDU exists in both realms with a shared password.
> krbtgt/TTU.EDE@CS.TTU.EDU does not exist anywhere.
>
> So afs administrative princs in CS.TTU.EDU would need to use the
> afs/cs.ttu.edu@CS.TTU.EDU because they cannot access services in the
> TTU.EDU realm. username@TTU.EDU princs are currently using
> afs/cs.ttu.edu@CS.TTU.EDU as a cross realm ticket but they map to
> dynamically created pts entries in the form of username@ttu.edu.
Dynamiclly created entries? How are you doing this?
> These
> accounts are difficult to control/create and I need to be able to
> specify the UID in order to sync with my unix UID.
>
> In order to make the TTU.EDU princs appear local I had the
> administrators of TTU.EDU create an afs/cs.ttu.edu@TTU.EDU in the
> windows AD/Kerberos realm. It's not a v4 ticket obviously, but it was
> created as DES-CBC-CRC. They don't run krb524 so I've tried to run one
> locally using a keytab file containing afs/cs.ttu.edu for both realm
> and point my clients to it. Things were running fine when I was only
> using the afs/cs.ttu.edu@CS.TTU.EDU and the normal krb524 with -X
> (crossrealm).
>
> Things in my afs appear to be pretty broken due to knvo's and the
> multiple afs/cs.ttu.edu entries in the KeyFile (one from each realm).
> What is the logic for the use of entries in the KeyFile?
The ticket contains the kvno of the key used to encrypt the encrypted part
of the ticket. The Kerberos V5 keytab code will lookup the principal and
kvno in the keytab file. (The intent is that the keytab file could have
multiple entries so a key could be changed on the server and the kvno
incremented. The server could then still respond to old or new tickets.
But Microsoft does not use kvno in the KDC, and will issue a ticket
with the kvno set to 0. Most of the MIT code will spot this and try
multiple keys.
The standard krb524d will decrypt the K5 ticket copy whats needed to a
V4 ticket, and encrypt it using the same key. This means that the
/usr/afs/KeyFile must also have the key and kvno.
But the AFS KeyFile only has keys and kvnos, so when a request
comes in, only the kvno is used to find the keyand it does not try
mltiple keys. So if you have multiuple realms, make sure the kvno are
differet for each realm. This may be a problem with multiple MS
ADs, and they don't use kvno's like they should.
The version of krb524d we are running, uses two seperate keys,
the one from the K5 keytab file to decrypt, and a copy of the
/usr/afs/KeyFile to encrypt the K4 ticket. Thus we don't have
all these sync problems and the K5 ticket is not limited to
des (The gssklogd does something similiar, letting GSSAPI handle the
incoming request, and encrypting the outgoing ticket using the /usr/afs/KeyFile.)
>
> # ktutil
> ktutil: rkt afs_cs.ttu.edu.krb524.keytab
> ktutil: l
> slot KVNO Principal
> ---- ----
> ---------------------------------------------------------------------
> 1 7 afs/cs.ttu.edu@CS.TTU.EDU
> 2 7 afs/cs.ttu.edu@CS.TTU.EDU
> 3 1 afs/cs.ttu.edu@TTU.EDU
>
Since the MS isnot using a KVNO, Iwould bet that if you added
the key for afs/cs.ttu.edu@TTU.EDU wiht kvno 0 it might work.
> Pts doesn't seem to like my keys at all anymore, even for the
> afs/cs.ttu.edu@CS.TTU.EDU ticket.
>
> # kinit mccliman/admin@CS.TTU.EDU
> Password for mccliman/admin@CS.TTU.EDU:
> # aklog -d
> Authenticating to cell cs.ttu.edu (server oak.cs.ttu.edu).
> We've deduced that we need to authenticate to realm CS.TTU.EDU.
> Getting tickets: afs/cs.ttu.edu@CS.TTU.EDU
> About to resolve name mccliman.admin to id in cell cs.ttu.edu.
> Id 1
> Set username to AFS ID 1
> Setting tokens. AFS ID 1 / @ CS.TTU.EDU
> # pts mem system:administators
> pts: ticket contained unknown key version number so couldn't look up
> names
This looks like the client is trying to do an authenticatd connection
to the PTS, and the AFS token is encryted in a key that is not in the
/usr/afs/KeyFile.
>
> #klist -e -f
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: mccliman/admin@CS.TTU.EDU
>
> Valid starting Expires Service principal
> 08/27/03 06:47:58 08/27/03 16:47:56 krbtgt/CS.TTU.EDU@CS.TTU.EDU
> Flags: FPIA, Etype (skey, tkt): Triple DES cbc mode with
> HMAC/sha1, Triple DES cbc mode with HMAC/sha1
> 08/27/03 06:48:01 08/27/03 16:47:56 afs/cs.ttu.edu@CS.TTU.EDU
> Flags: FPAT, Etype (skey, tkt): DES cbc mode with CRC-32,
> Triple DES cbc mode with HMAC/sha1
>
> I read in the thread Douglas referred me to that there is an etc/Realms
> functionality to allow users in a remote Realm to appear to be local.
That was not me, but there is some something about "realm of cell".
> Would that work in this context? That would probably be the best
> solution, and give me time to setup a better gssapi based system over
> time.
>
And just to reiterate, the view I want to take of an AFS cell is that
it is an authorization domain, willing to accept authentication from
multiple authentication domains. The authentication might be via Kerberos
tickets or using the Globus GSI, via certificates. Once authenticated,
an AFS token is issued, which is then use internally by AFS.
(It just so happens that the token is using a Kerberos ticket, and can
even use a K5 kerberos ticket.) It also means in the simple case where the
K5 realm and AFS cell names match it can use the K5 tickets directly,
but is not required to.
> On Tuesday, August 26, 2003, at 09:54 AM, Douglas E. Engert wrote:
>
> >
> >
> > Wyllys Ingersoll wrote:
> >>
> >> Douglas E. Engert wrote:
> >>> These would be in the gss libraries supplied by MIT, Hiemdal or the
> >>> Sun SEAM.
> >>>
> >>> You will need to add when you run configure:
> >>>
> >>> --with-gss-lib-dir=/usr/lib
> >>> --with-gss-lib-name=gss
> >>>
> >>> I don't have SEAM setup on any systems but this compiles and links
> >>> on a 5.8 system:
> >>>
> >>> ../src/configure \
> >>> --with-gss-lib-dir=/usr/lib \
> >>> --with-gss-lib-name=gss \
> >>> --with-tcp-wrappers=/afs/anl.gov/appl/wrapper-7.6/@sys \
> >>> --enable-server \
> >>> --enable-pam \
> >>> --with-server-extra-ldflags=/usr/afsws/lib/libdes.a
> >>>
> >>> This will use the /etc/gss configuration files to select which mech
> >>> to try.
> >>> There maybe a way to use the Kerberos only version.
> >>> See "man mech"
> >>
> >> Correct. Put the Kerberos_V5 entry first in the list (/etc/gss/mech)
> >> and it will be used by default.
> >>
> >>>
> >>> Maybe someone who has imlemented SEAM could say something here.
> >>>
> >>>
> >>>
> >>> Chris McClimans wrote:
> >>>
> >>>> I'm trying to get the gssklog to compile and I appear to be missing
> >>>> a
> >>>> library... linking against sasl2 doesn't seem to help.
> >>>> Where are the gss_*status/buffer functions defined?
> >>>> -chris
> >>>>
> >>>> gcc -o gssklog gssklog.o gssklog_afs.o \
> >>>> gssklog_gss.o gssklog_comm.o \
> >>>> -Wl,--noinhibit-exec,-rpath,:/usr/lib:/lib -L/usr/afsws/lib
> >>>> -L/usr/afsws/lib/afs -lprot -lubik -lauth -lcmd -lsys -lrxkad -lrx
> >>>> -llwp /usr/afsws/lib/libdes.a /usr/afsws/lib/afs/util.a
> >>>> /usr/afsws/lib/afs/libcom_err.a \
> >>>> \
> >>>> -L -l -lresolv -lnsl
> >>
> >> The link command (above) does not include "-lgss". Thats why you are
> >> getting all of the unresolved symbol errors below. Tweak the makefile
> >> so it adds "-lgss" to the list of libraries.
> >
> > The configure --with-gss-lib-name should take cake of this. There
> > should be no need
> > to change the Makefile.
> >
> >
> >>
> >> If using Solaris 8, also be sure to download the Solaris Encryption
> >> Pack
> >> for Solaris 8 (free download from
> >> http://www.sun.com/software/solaris/encryption)
> >> in order to get the correct encryption algorithms for Kerberos and
> >> GSSAPI.
> >> By default, the SEAM package for Solaris 8 includes a "neutered"
> >> kerberos
> >> implementation because at the time that the packages were created, we
> >> were bound by much stricter export control laws. Also get the latest
> >> patches from sunsolve.sun.com.
> >>
> >> In Solaris 9, the Kerberos crypto is installed by default.
> >>
> >> -Wyllys
> >>
> >>>> gssklog_gss.o: In function `gssklog_gss_acquire_cred':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:96: undefined
> >>>> reference
> >>>> to `gss_acquire_cred'
> >>>> gssklog_gss.o: In function `gssklog_gss_doit':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:200: undefined
> >>>> reference
> >>>> to `gss_import_name'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:205: undefined
> >>>> reference
> >>>> to `gss_release_buffer'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:226: undefined
> >>>> reference
> >>>> to `gss_init_sec_context'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:279: undefined
> >>>> reference
> >>>> to `gss_release_buffer'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:368: undefined
> >>>> reference
> >>>> to `gss_release_name'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:372: undefined
> >>>> reference
> >>>> to `gss_delete_sec_context'
> >>>> gssklog_gss.o: In function `gssklog_gss_wrap':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:396: undefined
> >>>> reference
> >>>> to `gss_wrap'
> >>>> gssklog_gss.o: In function `gssklog_gss_unwrap':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:420: undefined
> >>>> reference
> >>>> to `gss_unwrap'
> >>>> gssklog_gss.o: In function `gssklog_gss_display_status':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:447: undefined
> >>>> reference
> >>>> to `gss_display_status'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:456: undefined
> >>>> reference
> >>>> to `gss_release_buffer'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:467: undefined
> >>>> reference
> >>>> to `gss_display_status'
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:476: undefined
> >>>> reference
> >>>> to `gss_release_buffer'
> >>>> gssklog_gss.o: In function `gssklog_gss_release_buffer':
> >>>> /home/mccliman/src/gssklog-0.8/./gssklog_gss.c:490: undefined
> >>>> reference
> >>>> to `gss_release_buffer'
> >>>>
> >>>> _______________________________________________
> >>>> OpenAFS-info mailing list
> >>>> OpenAFS-info@openafs.org
> >>>> https://lists.openafs.org/mailman/listinfo/openafs-info
> >>>
> >>>
> >>
> >> --
> >>
> >> Wyllys Ingersoll
> >> Sun Microsystems, Inc
> >> PGP Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF353913
> >> Fingerprint: 92CD E875 59A0 798E ED9A D75B 303A 57F0 AF35 3913
> >
> > --
> >
> > Douglas E. Engert <DEEngert@anl.gov>
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois 60439
> > (630) 252-5444
> > _______________________________________________
> > OpenAFS-info mailing list
> > OpenAFS-info@openafs.org
> > https://lists.openafs.org/mailman/listinfo/openafs-info
> >
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444