[OpenAFS-devel] pts examine

[Neulinger, Nathan]

> Would someone believe that I'm so stupid to put into UserList=20
> usernames in
> a syntax of kerberos5 and NOT kerberos4? Thanks to Johan Danielson who
> pointed me to this problem.

From changelog:

        * src/auth/userok.c: DELTA
        afs-superuser-foreign-realm-checks-20010514 AUTHOR nneul@umr.edu
       =20
        This rewrite cleans up the code a bit, removes any athena =
specific
        references (not needed anymore in this version), and adds =
support
        for multi realm management of afs servers (you can now specify
        "admin@OTHERREALM" in your userlist).
       =20
        Code now checks as follows:
       =20
        tname tinst  - remote user info from conn tcell lcell - local =
cell
        lrealm - local realm (defaults to lcell if not avail)
       =20
        if no remote cell or instance         allow localauth if the =
cell
        of the remote connection matches local cell or local realm       =
=20
        if not tinst                 allow if tname in UserList         =
if
        tinst                 allow if tname.tinst in UserList if cell
        doesn't match local cell or realm         if not tinst           =
 =20
           allow if tname@cell in UserList                 allow if
        tname@CELL in UserList         if tinst                 allow if
        tname.tinst@cell in UserList                 allow if
        tname.tinst@CELL in UserList
       =20
        modified per openafs-devel discussion such that krb5 versions
        (/tinst rather than .tinst) code path disabled for now DELTA
        some-name-yyyymmdd AUTHOR contributor@some.site



Sounds like we just have the krb5 style syntax disabled at the moment... =
I don't remember the discussion, so I'm not sure why that is the case.

Seems to me that enabling the krb5 syntax is a step in the right =
direction.


> Yes, having mokrejs/admin@GSF.DE there was my problem and that was the
> reason why my AFS authentication did not work (kerberos KDC worked and
> issued tickes for me, also AFS tokens), but ptserver/fs and=20
> others said
> always "Permission denied".
>=20
> Would be nice if bosserver and ptserver would check that=20
> users specified
> are entered in the mokrejs.admin@GSF.DE way. Probably syntax=20
> checking of
> the whole UserList file during startup would be the best and when
> inserting new users into the list. :)
>=20
>=20
> > > # pts examine -nameorid 3 -force -noauth
> > > Name: mokrejs/admin, id: 3, owner: system:administrators,=20
> creator: anonymous,
> > >   membership: 1, flags: S----, group quota: unlimited.
> > > # pts examine -nameorid 4 -force -noauth
> > > Name: mokrejs, id: 4, owner: system:administrators,=20
> creator: anonymous,
> > >   membership: 0, flags: S----, group quota: 20.
> > > # pts examine mokrejs/admin -noauth
> > > Name: mokrejs/admin, id: 3, owner: system:administrators,=20
> creator: anonymous,
> > >   membership: 1, flags: S----, group quota: unlimited.
> > > #
> > >
> > > I think mokrejs/admin@GSF.DE might not be converted to=20
> mokrejs/admin@gsf.de at least,
> > > at the best the "@GSF.DE" could be removed from the=20
> string, if it's really
> > > causing lookup failure. Any opinions?
>=20
> --=20
> Martin Mokrejs <mmokrejs@natur.cuni.cz>, <m.mokrejs@gsf.de>
> PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
> MIPS / Institute for Bioinformatics <http://mips.gsf.de>
> GSF - National Research Center for Environment and Health
> Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
> tel.: +49-89-3187 3683 , fax:=A0+49-89-3187 3585
>=20
> _______________________________________________
> OpenAFS-devel mailing list
> OpenAFS-devel@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-devel
>=20