[OpenAFS] Mapping btw. AFS tokens and Kerberos tickets (Heimdal)

Education Center mailbox030403@mail.ru
Wed, 9 Nov 2005 13:26:44 +0300


This is the second post since pervious one has been stopped due size =
limit
So now the same info with plain text format
Since we found it extremely useful we would like to share it with others


Iljya

******

Installing Kerberos & AFS=20

Installing Kerberos & AFS=20
Basics=20
OpenAFS=20
Starting the Install=20
Create AFS Keys and Administrators=20
KerberosVMIT=20
HeimdalKTH=20
KTH Kerberos4=20
Finishing OpenAFS installation=20
Setting up Transparent Login=20
AFS includes its own implementation of Kerberos, the KAServer. However, =
new installs of KAServer are not recommended as it is based on a draft =
version of the obsolete Kerberos 4 protocol. Even though AFS doesn't =
support KerberosV directly, it is highly recommended that you set up a =
KerberosV realm for your AFS cell and not install the KAServer. See =
KerberosV for the many advantages of using the latest Kerberos for your =
network authentication.=20

Note that this document is under development. Also, I don't try to =
explain the OpenAFS specific parts of the install -- This document =
describes only the changes that have to be made to create a new OpenAFS =
cell with KerberosV authentication. If you have followed these =
instructions and are still having problems please email the openafs-info =
mailing list.=20

Derrick wrote nice pages at: =
http://www.cs.cmu.edu/afs/andrew.cmu.edu/usr/shadow/www/afs/afs-with-kerb=
eros.html =
http://www.contrib.andrew.cmu.edu/~shadow/afs/afs-with-kerberos.html=20

DenizKanca? posted her notes at =
http://www.arayan.com/da/yazi/OpenAFS_Kerberos_5.html.=20

JeffreyHutzelman posted a good summary of all these component to =
OpenAFS-info on 25-Jul-2003. Be sure to check to follow-ups for some =
minor clarifications.=20


Basics=20
To continue, you need a working Kerberos realm. See =
SettingUpAuthentication? for the implementation options, and refer to =
the documentation that comes with your particular version of Kerberos to =
establish your realm. It is easiest if your realm name is the caps =
version of your cell name, which in turn is the same as your site's =
domain name. For example if your site's domain is 'greekmythology.com', =
your Kerberos realm name should be 'GREEKMYTHOLOGY.COM' and your AFS =
cell name should be 'greekmythology.com'. See KerberosTerms if you are =
confused on what a "realm" is.=20

Once you have a working Kerberos realm, ie. you can "kinit" as yourself =
and receive valid Kerberos tickets, you are ready to continue on =
installing OpenAFS. (NOTE: If you are working on the Red Hat Linux =
platform, there is an RPM available that may ease your pain =
considerably. See LinuxAFSInstall.)=20


OpenAFS=20

Starting the Install=20
Now we will begin the OpenAFS installation. The relevant part of the =
OpenAFS documentation can be found at OpenAFS installation =
documentation. Follow the instructions in Creating AFS Directories and =
begin the Platform Specific Procedures as appropriate for your operating =
system. SKIP the "Enabling AFS Login" section of your operating system's =
instructions. Also note that you may need to reboot during this =
procedure (particularly on Solaris).=20

Now you are ready to continue on to Starting the BOS Server (... someone =
want to chime in here and explain how one can use pt_util etc to do this =
part without running in -noauth??). Proceed to Defining Cell Name. =
During the Starting Database Servers section, do not issue the bos =
create command to add the kaserver.=20


Create AFS Keys and Administrators=20
First you will need to create a principal "afs" or =
"afs/greekmythology.com" in your KerberosV database. The latter is the =
preferred alternative, especially if you will support more than one =
AFSCell? with a single KerberosRealm?. In case you have KerberosIV?, =
create afs or afs.greekmythology.com respectively.=20

Your KerberosV realm must support krb524 for aklog to work, typically. =
In other words, it has to be able to respond to your version 4 requests =
(as AFS is based on KerberosIV? protocol).=20

Next we will create an AFS KeyFile and an administrator principal in the =
Kerberos database. The procedure for creating an AFS KeyFile depends on =
which Kerberos implementation you have chosen to use, but the logic is =
the same.=20

Things to remember about AFS KeyFile: they must contain a key using the =
des-cbc-crc encryption type and the key must have exactly same kvno as =
the afs/greekmythology.com@GREEKMYTHOLOGY.COM in the Kerberos database. =
If cell is same as lowercased COM name, you can create =
afs@GREEKMYTHOLOGY.COM instead of afs/cell@GREEKMYTHOLOGY.COM.=20


KerberosVMIT=20

set up krb524d. You will need to make sure your krb524d server host =
includes something like this in krb5.conf. Only one of the 2 entries =
should be needed for a realm, depending on how you did the setup in your =
KerberosV database.=20

[appdefaults]
afs_krb5 =3D {
      REALM.NAME =3D {
                afs =3D false
                afs/cell.name =3D false
      }
}

use kadmin get command and ktutil copy similarly as described in section =
Heimdal to create afs key in a database or use for the last step instead =
of ktutil asetkey as below=20

The AFS-Kerberos5 migration kit includes a program asetkey=20
Save the AFS key from kerberos KDC to a file, possibly using kadmin(see =
KTH KerberosIV? section above), and the use either asetkey or use ktutil =
(see HeimdalKTH section below) to convert the format and save into =
KeyFile.=20


       asetkey add 0 /etc/srvtab.afskey afs.cell@REALM
The `0' above means kvno (key version number 0). Use ktutils list or =
similar like kadmin get command to see, what kvno has the afs key in =
Kerberos database. Use exactly same number when running asetkey. There's =





HeimdalKTH=20

http://www.pdc.kth.se/heimdal=20
kdc will service krb524 requests=20
edit /etc/krb5.conf similar to the example below=20

[logging]
default =3D FILE:/var/log/krb5libs.log
kdc =3D FILE:/var/log/krb5kdc.log
admin_server =3D FILE:/var/log/kadmind.log

[ktutil]
        dns_lookup_realm =3D false
        dns_lookup_kdc =3D false


[libdefaults]
        dns_lookup_realm =3D false
        dns_lookup_kdc =3D false
        ktype_is_etype =3D true
        encrypt =3D yes
        forward =3D yes
        srv_lookup =3D no
        srv_try_txt =3D no
        srv_try_rfc2052 =3D no
        default_realm =3D GREEKMYTHOLOGY.COM
        clockskew =3D 300
        kdc =3D 127.0.0.1
        v4_instance_resolve =3D true
        krb4_get_tickets =3D yes
        forwardable =3D true
        v4_name_convert =3D {
                host =3D {
                        rcmd =3D host
                        ftp =3D ftp
                }
                plain =3D {
                        something =3D something-else
                }
        }

[realms]
        GSF.DE =3D {
                kdc =3D 127.0.0.1
                admin_server =3D 127.0.0.1
                krb525_server =3D 127.0.0.1
                v4_name_convert =3D {
                        ftp =3D ftp
                        pop =3D pop
                        rcmd =3D host
                }
                v4_instance_convert =3D true
                default_domain =3D greekmythology.com
        }

[domain_realm]
        .greekmythology.com =3D GREEKMYTHOLOGY.COM
        greekmythology.com =3D GREEKMYTHOLOGY.COM

[kadmin]
kdc =3D=20
# you can disable fallback DNS queries, if don't have registered name =
like kerberos.yourdomain
dns_lookup_realm =3D false
dns_lookup_kdc =3D false
default_keys =3D v4 v5 afs3
afs-cell =3D greekmythology.com
v4-realm =3D GREEKMYTHOLOGY.COM


[kdc]
        enable-kerberos4 =3D true
        afs-cell =3D=20
        enable-524 =3D true
        v4-realm =3D GREEKMYTHOLOGY.COM


The HeimdalKTH distribution's ktutil can copy directly into an AFS =
KeyFile and removes salt from keys=20


       kadmin --admin-server=3Dmy_kdc_server
       kadmin> add --random-key afs/cell
       kadmin> del_enctype afs/cell@REALM des3-cbc-sha1
       kadmin> get afs/cell@REALM
       kadmin> list *
       kadmin> ext -k /etc/afskeytabfile.krb5
       kadmin> quit
       ktutil -k /etc/afskeytabfile.krb5 list
       ktutil copy FILE:/etc/afskeytabfile.krb5 =
AFSKEYFILE:/usr/afs/etc/KeyFile

After you have a working KeyFile installed in the appropriate directory =
(/usr/afs/etc/KeyFile for transarc-paths, ???? otherwise) and with the =
appropriate permissions (0600, owner root), we can create administrative =
users for AFS. This is a two step process as we first create an =
authentication principal in the Kerberos database then add the admin =
user in the authorization ("protection") database in the AFS server.=20

Create a user ("joe/admin" in this example) using the appropriate kadmin =
utility with your KerberosV distribution. Set a secure password, and =
note that setting Kerberos admin rights for this user does not affect =
his AFS rights. Please note, that "joe/admin@REALM" is KerberosV =
notation and that KerberosIV? is using "joe.admin@REALM". As AFS is =
based on KerberosIV?, you should specify "joe.admin@REALM" or just =
"joe.admin". (I did this mistake recently and for days was hunting for =
an explanation, why while having valid tickets, valid AFS tokens with =
proper kvno (key version number as the one in Kerberos KDC) fileserver, =
ptserver and bosserver complain about my AFS token being invalid. Yes, I =
had in the /usr/(afs|vice)/etc/UserList file "joe/admin@REALM"). In =
OpenAFS-1.2.8, you can possibly enable Kerbero5 syntax for usernames =
(See this message to openafs-devel)=20



KTH Kerberos4=20

http://www.pdc.kth.se/kth-krb :=20
You can create afs key using "kadmin add", you had to specify password =
on interactively. That's quite weak password. Much better is to do =
kadmin get. kadmin will try to download the key from KDC, and if it's =
not present, it will create one, using random key. That's what we want.=20

ksrvutil(1) does similar and doesn't require from you to have kadmind(1) =
running on your machine. The "get" command does same: downloads or (in =
our case) creates new afs principal using random password. The next =
example expects that joe.admin is you and you know the proper password =
to get full access to you kerberos database:=20


    mv /etc/srvtab /etc/srvtab.orig
    /usr/athena/sbin/ksrvutil -p joe.admin get
    Name [rcmd]: afs
    Instance [hostname]: greekmythology.com
    Realm [GREEKMYTHOLOGY.COM]: GREEKMYTHOLOGY.COM
    Is this correct? (y,n) [y]
    Add more keys? (y,n) [n]
    Password for joe.admin@GREEKMYTHOLOGY.COM
    # list keys in /etc/srvtab, look for the AFS key and it's kvno
    ksrvutil list
    mv /etc/srvtab /etc/srvtab.afskey
    mv /etc/srvtab.orig /etc/srvtab
If you want to make the above more complicated, you will need =
/usr/athena/sbin/ext_srvtab utility to extract already existing key from =
Kerberos KDC and save it into /etc/srvtab. It will ask you for your =
master kerberos password (but if you installed kerberos in the "proper" =
way, you've used random password which you don't know at all), so better =
use ksrvutil as described above and forget ext_srvtab.=20

Now you should have the afs key in /etc/srvtab.afskey.=20

Import this AFS key from Kerberos keyfile (/etc/srvtab format) into AFS =
/usr/afs/etc/KeyFile using asetkey utility, which is I think from =
/afs/transarc.com/public/afs-contrib=20


    asetkey add 0 /etc/srvtab.afskey =
afs.greekmythology\.com@GREEKMYTHOLOGY.COM
This KeyFile with the AFS-key you can just always re-copy to new AFS =
machines. Be sure that the key version number KVNO is always same in =
this KeyFile and in Kerberos database. On all these machines you of =
course need afs.hostname.REALM key loaded into their /etc/srvtab (create =
them with '/ust/athena/bin/ksrvutil get').=20

You can test if you have same keys in kerberos and AFS like this:=20


    kauth username
    tokens
If you have some tokens now, then it works and you can now shutdown =
kaserver. Users, which you have created under kaserver are stored in =
/usr/afs/db/kaserver.*, but you can just forget them. Create these users =
again in Kerberos. With KerberosIV? from KTH they get stored under =
/var/kerberos, when using Heimdal under /var/heimdal/.=20



Finishing OpenAFS installation=20
Now we will use the pts command in OpenAFS to add this joe.admin user to =
the AFS administrators group named system:administrators. The username =
could be just "joe" or "admin", but it's a good habit to have .admin =
appended to it (it is called instance). Please note the notation =
"joe.admin", not "joe/admin" as would be typical in Kerberos5 style:=20


    pts createuser -name joe.admin -cell greekmythology.com -noauth
    pts adduser joe.admin system:administrators -cell  -noauth
where greekmythology.com is the name of your local cell. After your =
complete this step, you can continue on to...=20

Activate the new AFS KeyFile by executing:=20


    bos restart <machine name> -all -cell <cell name> -noauth
After this restart, try using kinit to get Kerberos tickets for admin =
then (if necessary) use aklog to get an AFS token or use afslog if afsd =
client cache is already running. Basically ensure that the AFS KeyFile =
is valid:=20


    /usr/heimdal/sbin/ktutil copy AFSKEYFILE:/usr/afs/etc/KeyFile =
FILE:/etc/afskeytabfile.krb5
    /usr/heimdal/bin/kinit -k -t /etc/afskeytabfile.krb5 =
afs/greekmythology.com
    # you should be able to autenticate against KDC using the =
/etc/afskeytabfile.krb5
    #    where is saved your afs key in keytab form recognizable by =
Kerberos5
    /usr/heimdal/klist
    # you should see you have afs/greekmythology.com ticket having some =
expiration time etc.



Proceed to the Starting File Server section of the OpenAFS =
documentation. The rest of the documentation can be completed without =
any changes. (What about replacing NTP with something recent, though...? =
See FAQ 3.22 and [NTP])=20


Setting up Transparent Login=20
In its current state, you have to manually log into your AFS cell =
through kinit and possibly aklog (explain aklog..., debugging using =
"tokens" etc). There are several methods to enable transparent login to =
both local resources (the machine itself) and AFS through a single =
password. See KerberosV and SettingUpAuthentication? for some =
information. The best option if you are using pam is probably the =
pam_krb5 project on sourceforge.=20

-- JasonGarman - 05 Feb 2002 -- DerrickBrashear - 26 Nov 2002=20

****************************=20


-----Original Message-----
From: Florian Daniel Otel [mailto:florian.otel@gmail.com]
Sent: Tuesday, November 08, 2005 8:03 PM
To: openafs-info@openafs.org
Subject: [OpenAFS] Mapping btw. AFS tokens and Kerberos tickets =
(Heimdal)


All,


Disclaimer: Since this is my first posting to this list (hello all!) I
might be missing smth obvious. Thanks in advace for the patience
and/or pointers to appropriate resources (even though I google quite a
bit before posting...)


My problem: I am trying to setup a Heimdal Kerberos5 / OpenAFS setup
and apparently I am not able to get right the mapping between AFS
users and Kerberos principals: While I can get tickets from the KDC,
"bos" and "ptserver" are not able to authenticate the user based on
those certificates i.e. translate btw. Kerberos tickets and AFS tokens
(??). I am also a bit confused about the output of "aklog" and
"afslog" and when do I need which and for what (TIA for any
explanation):

Two examples (see detailed command output below):

1)  The principal for administering "bos" is "florian/admin". Even
though this principal exists, can get tickets and is listed as such in
"bos listusers" (i.e. "/etc/openafs/UserList",
"/etc/openafs/server/UserList"), any "bos restart" or commands
requiring administrative priviledges fail. Some other times when
performing "bos status" or similar, the "bos" returns "bos: no such
entry (getting tickets)" (?!?!?!).

2) Ditto for the same principal with "ptserver" and ACLs. While that
principal is "pts create"d, is added to "system:administrators" group,
it is not allowed to do anything, e.g. getting/setting ACLs. The only
thing that worked was creating a Kerberos principal called "admin" (is
this a built-in administrator in "pts" ??) and using that one to issue
"pts" commands and getting/setting ACLs commands


My questions:

1) Are there any special settings needed in "/etc/krb5.conf" and/or
"/var/lib/heimdal/kdc.conf" to get this mapping working ?

2) When and how does one use "aklog" and "afslog" and how can one
check the mapping btw. Kerberos tickets and AFS tokens ?


Thanks in advance for any help in clearing up the confusion


Florian


P.S. In both  examples below the system is  Debian/Sarge 3.1r0a,
running stock Heimdal 0.6.3, openafs 1.3.81 and openafs-krb5 1.3.10-1

"DOMAIN.COM" (my Kerberos realm)  and "domain.com" (my DNS domain) are
identical.


Example 1) bos commands

kdc-hostname:~# kinit florian/admin
florian/admin@DOMAIN.COM's Password:
kinit: NOTICE: ticket renewable lifetime is 1 week

kdc-hostname:~# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: florian/admin@DOMAIN.COM

  Issued           Expires          Principal
Nov  8 17:58:33  Nov  9 03:58:33  krbtgt/DOMAIN.COM@DOMAIN.COM
Nov  8 17:58:33  Nov  9 03:58:33  krbtgt/DOMAIN.COM@DOMAIN.COM
Nov  8 17:58:33  Nov  9 03:58:33  afs@DOMAIN.COM

   V4-ticket file: /tmp/tkt0
        Principal: florian.admin@DOMAIN.COM

  Issued           Expires          Principal
Nov  8 17:58:33  Nov  9 03:58:33  krbtgt.DOMAIN.COM@DOMAIN.COM



kdc-hostname:~# aklog -d
Authenticating to cell domain.com (server kdc-hostname.domain.com).
We've deduced that we need to authenticate to realm DOMAIN.COM.
Getting tickets: afs/domain.com@DOMAIN.COM
Identical tokens already exist; skipping.


kdc-hostname:~# tokens

Tokens held by the Cache Manager:

Tokens for afs@domain.com [Expires Nov  8 08:46]
   --End of list--


kdc-hostname:~# bos listusers localhost -localauth
SUsers are: florian/admin

kdc-hostname:~# bos restart localhost vlserver
bos: failed to restart instance vlserver (you are not authorized for
this operation)

Relelvant parts of "strace"ing the above command:
[...]sendmsg(3, {msg_name(16)=3D{sa_family=3DAF_INET,
sin_port=3Dhtons(7007), sin_addr=3Dinet_addr("127.0.0.1")},
msg_iov(2)=3D[{"\211{Q\6\373G7\264\0\0\0\1\0\0\0\1\0\0\0\1\1\5\0\2&\t\0".=
..,
28}, {"\0\0\0h\0\0\0\10vlserver", 16}], msg_controllen=3D0,
msg_flags=3D0}, 0) =3D 44
getitimer(ITIMER_REAL, {it_interval=3D{0, 0}, it_value=3D{3599, =
985718}}) =3D 0
getitimer(ITIMER_REAL, {it_interval=3D{0, 0}, it_value=3D{3599, =
985718}}) =3D 0
gettimeofday({1131400433, 740910}, NULL) =3D 0
gettimeofday({1131400433, 741060}, NULL) =3D 0
select(4, [3], NULL, NULL, {1, 998850}) =3D 1 (in [3], left {1, 999000})
recvmsg(3, {msg_name(16)=3D{sa_family=3DAF_INET, sin_port=3Dhtons(7007),
sin_addr=3Dinet_addr("127.0.0.1")},
msg_iov(7)=3D[{"\211{Q\6\373G7\264\0\0\0\0\0\0\0\0\0\0\0\1\6\0\0\2\0\0"..=
.,
28}, {"\0\0\0\2\25\376\234B\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1416}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1416}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1416}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1416}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1416}, {"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
1420}], msg_controllen=3D0, msg_flags=3D0}, 0) =3D 44
sendmsg(3, {msg_name(16)=3D{sa_family=3DAF_INET, sin_port=3Dhtons(7007),
sin_addr=3Dinet_addr("127.0.0.1")},
msg_iov(2)=3D[{"\211{Q\6\373G7\264\0\0\0\0\0\0\0\0\0\0\0\2\7\1\0\2\0\0"..=
.,
28}, {"\0\0\0\2\0\0\0\0\f\241\206\271\252\320\203-s\377m\311\273"...,
275}], msg_controllen=3D0, msg_flags=3D0}, 0) =3D 303
getitimer(ITIMER_REAL, {it_interval=3D{0, 0}, it_value=3D{3599, =
984719}}) =3D 0
gettimeofday({1131400433, 742303}, NULL) =3D 0
select(4, [3], NULL, NULL, {1, 996758}) =3D 1 (in [3], left {1, 997000})
recvmsg(3, {msg_name(16)=3D{sa_family=3DAF_INET, sin_port=3Dhtons(7007),
sin_addr=3Dinet_addr("127.0.0.1")},
msg_iov(7)=3D[{"\211{Q\6\373G7\264\0\0\0\1\0\0\0\0\0\0\0\2\4\0\0\2\0\0"..=
.,
28}, {"\0\0
\232\6\0\0\0\0\f\241\206\271\252\320\203-s\377m\311"..., 1416},
{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1416},
{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\
0\0"..., 1416},
{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1416},
{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 1416},
{"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0
\0\0\0\0\0\0\0\0\0\0\0\0"..., 1420}], msg_controllen=3D0, =
msg_flags=3D0}, 0) =3D 32
getitimer(ITIMER_REAL, {it_interval=3D{0, 0}, it_value=3D{3599, =
982719}}) =3D 0
getitimer(ITIMER_REAL, {it_interval=3D{0, 0}, it_value=3D{3599, =
982719}}) =3D 0
fstat64(1, {st_mode=3DS_IFIFO|0600, st_size=3D0, ...}) =3D 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) =3D 0xb7e15000
write(1, "bos: failed to restart instance "..., 85bos: failed to
restart instance vlserver (you are not authorized for this operation)
[...]


The only "suspicious" entry in the logs per se is from "fileserver" =
process:

kdc-hostname:/var/log/openafs# cat FileLog
Mon Nov  7 22:45:25 2005 File server starting
Mon Nov  7 22:45:25 2005 afs_krb_get_lrealm failed, using domain.com.
Mon Nov  7 22:45:25 2005 VL_RegisterAddrs rpc failed; will retry
periodically (code=3D5376, err=3D2)
Mon Nov  7 22:45:26 2005 Set thread id 14 for FSYNC_sync
.....


Example 2) ptserver problem

As above, even though "florian/admin@DOMAIN.COM" was the intented
principal to be member of the "system:administrators" group, the only
one that works (of a fashion) is the "admin@DOMAIN.COM" principal that
I added only afterwards.


- With "admin@DOMAIN.COM":

[...]
florian@kdc-hostname:~$ kinit admin
admin@DOMAIN.COM's Password:
kinit: NOTICE: ticket renewable lifetime is 1 week

florian@kdc-hostname:~$ aklog -d
Authenticating to cell domain.com (server kdc-hostname.domain.com).
We've deduced that we need to authenticate to realm DOMAIN.COM.
Getting tickets: afs/domain.com@DOMAIN.COM
Identical tokens already exist; skipping.
florian@kdc-hostname:~$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 1000) tokens for afs@domain.com [Expires Nov  8 09:00]
   --End of list--

florian@kdc-hostname:~$ pts membership system:administrators
Members of system:administrators (id: -204) are:
  florian/admin
  admin

florian@kdc-hostname:~$ pts examine florian/admin
Name: florian/admin, id: 1, owner: system:administrators, creator: =
anonymous,
  membership: 1, flags: S----, group quota: unlimited.


florian@kdc-hostname:~$ pts examine admin
Name: admin, id: 3, owner: system:administrators, creator: anonymous,
  membership: 1, flags: S----, group quota: unlimited.

florian@kdc-hostname:~$ pts listentries -users
Name                          ID  Owner Creator
anonymous                  32766   -204    -204
florian/admin                  1   -204   32766
florian                        2   -204   32766
admin                          3   -204   32766


florian@kdc-hostname:~$ fs listacl /afs/domain.com/
Access list for /afs/domain.com/ is
Normal rights:
  system:administrators rlidwka
  system:anyuser rl
[...]


   However, trying to use "florian/admin" instead doesn't work. Note
also that the output of the "tokens" command does not output any "AFS
ID" as the one for "admin" above (!?!?!).

[...]
kdc-hostname:~# kinit florian/admin
florian/admin@DOMAIN.COM's Password:
kinit: NOTICE: ticket renewable lifetime is 1 week

kdc-hostname:~# tokens

Tokens held by the Cache Manager:

Tokens for afs@domain.com [Expires Nov  8 09:04]
   --End of list--

kdc-hostname:~# pts membership "system:administrators"
pts: Permission denied ; unable to get membership of
system:administrators (id: -204)

kdc-hostname:~# pts examine florian/admin
pts: Permission denied ; unable to find entry for (id: 1)


kdc-hostname:~# fs setacl /afs/domain.com/ system:anyuser rl
fs: You don't have the required access rights on '/afs/domain.com/'
[...]



=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D /etc/krb5.conf =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
[libdefaults]
        default_realm =3D DOMAIN.COM
# The following krb5.conf variables are only for MIT Kerberos.
        krb4_config =3D /etc/krb.conf
        krb4_realms =3D /etc/krb.realms
        kdc_timesync =3D 1
        ccache_type =3D 4
        forwardable =3D true
        proxiable =3D true
# Get Kerberos 4 tickets
        krb4_get_tickets =3D true

        v4_instance_resolve =3D true
        v4_name_convert =3D {
                host =3D {
                        rcmd =3D host
                        ftp =3D ftp
                }
        }

[realms]
DOMAIN.COM =3D {
         kdc =3D kdc-hostname.domain.com.
         admin_server =3D kdc-hostname.domain.com.
}

[kdc]
        use_2b=3D{
                afs@DOMAIN.COM =3D true
                afs/DOMAIN.COM@DOMAIN.COM =3D true
        }

[domain_realm]
        .domain.com =3D DOMAIN.COM

# This below is for kerberos-enabled login.
[login]
        krb4_convert =3D true
        krb4_get_tickets =3D true


=3D=3D=3D=3D=3D=3D=3D=3D=3D /var/lib/heimdal-kdc/kdc.conf =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

[kdc]
logging =3D FILE:/var/log/heimdal-kdc.log

# respond to Kerberos 4 requests
enable-kerberos4 =3D true

# respond to 524 requests
enable-524 =3D true

v4-realm =3D DOMAIN.COM

# Enable kaserver emulation (in case it's compiled in).
enable-kaserver =3D true


# [kadmin]
# default_keys =3D list of strings
# Maybe this will help ?
  default_keys =3D v4 v5 afs3-salt:domain.com
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info