[OpenAFS] one afs/cell.domain princs per realm
Chris McClimans
openafs-info@mcclimans.net
Wed, 27 Aug 2003 06:52:47 -0500
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)
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. 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?
# 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
#asetkey list
kvno 7: key is: fe4cfd26f873ba73
kvno 1: key is: 52ad80573240f25b
All done.
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
#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.
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.
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
>