[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: afslog behaviour in a cross realm configuration

To: Love =?utf-8?q?H=C3=B6rnquist_=C3=85strand?= <lha@it.su.se>
Subject: Re: afslog behaviour in a cross realm configuration
From: Ulrich Schwickerath <Ulrich.Schwickerath@iwr.fzk.de>
Date: Mon, 29 Aug 2005 09:49:49 +0200
Cc: heimdal-discuss@sics.se
In-Reply-To: <054A8344-E110-4907-9876-6314B62191BA@it.su.se>
Organization: Forschungszentrum Karlsruhe, HIK
References: <m2wtmbg34c.fsf@dhcp-wavelan-v-206.publik.su.se> <54831B5E-34F7-4200-8FA1-77422BC1765B@it.su.se> <054A8344-E110-4907-9876-6314B62191BA@it.su.se>
Reply-To: ulrich.schwickerath@iwr.fzk.de
Sender: owner-heimdal-discuss@sics.se
User-Agent: KMail/1.8

Hello, Love,

I just had a look into the code of afslog, and I found the explanation why 
what you suggest did not work. The -k option is meaningless, it is not used 
at all. krb5_afslog is always called with a NULL argument for the REALM. I 
have hacked to afslog to see what happens if I force it to use CG.FZK.DE as 
the REALM. Starting with the KRB5 principals:

$ klist
Credentials cache: FILE:/tmp/krb5cc_fN5560
        Principal: schwicke@A.FZK.DE

  Issued           Expires          Principal
Aug 29 09:41:30  Aug 29 19:22:18  krbtgt/A.FZK.DE@A.FZK.DE
Aug 29 09:41:31  Aug 29 19:22:18  krbtgt/CG.FZK.DE@A.FZK.DE

and then running the hacked version of afslog I get:

$ /usr/src/redhat/BUILD/heimdal-0.6.4/appl/afsutil/.libs/afslog -v
krb5 tried afs/cg.fzk.de@CG.FZK.DE -> -1765328377
krb5 tried afs@CG.FZK.DE -> 0

$ tokens

Tokens held by the Cache Manager:

User's (AFS ID 7597) tokens for afs@cg.fzk.de [Expires Aug 29 19:22]
   --End of list--

/afs/cg.fzk.de/home/schwicke]$ touch blafasel
$ ls -l blafasel
-rw-r--r--    1 393009   iwr             0 Aug 29 09:45 blafasel

So, that works. It would be great if the -k option could be made working with 
afslog in a future version of heimdal. Usually, I get my afs tokens already 
at login with PAM (making use of krb5_afslog), I guess there it is the same 
problem, but now that I know what I have to look for I think I can extend it 
to our needs.

Thank's a lot,
Ulrich

P.S.: I'm sorry we lost the CC to the list, I add it again, history see below.


On Sunday 28 August 2005 15:58, Love Hörnquist Åstrand wrote:
> Hello Ulrich,
>
> You have had a chance to test this ?
>
> Love
>
> 25 aug 2005 kl. 19.12 skrev Love Hörnquist Åstrand:
> > Hello Ulrich
> >
> > The user id that is presented is just for presentation and
> > confusion of the user,
> > its only the client that care about it, and only for presentation.
> > It is never sent to the server.
> >
> > The key version number is the same that is shown in "klist -v" kvno
> > field, with the exception below.
> >
> > There is a hack in the afs protocol that allows the service to
> > support kerberos 5 ticket
> > even though AFS is a keberos 4 service. KVNO (key version number)
> > 256 is used
> > tell the server its a kerberos 5 ticket, and 213 its a trimmed down
> > kerberos ticket
> > (known as 2b token after the proposal). When this type of ticket is
> > used, the real kvno
> > is stored inside the Kerberos 5 ticket.
> >
> > If you run afslog -v you see what principal is used, from your
> > previous mail:
> >
> >     $afslog -v
> >     krb5 tried afs/cg.fzk.de@A.FZK.DE -> 0
> >
> > If you compare with with the aklog output
> >
> >> We've deduced that we need to authenticate to realm CG.FZK.DE.
> >> Getting tickets: afs/cg.fzk.de@CG.FZK.DE
> >> Principal not found, trying alternate service name: afs/@CG.FZK.DE
> >> Using Kerberos V5 ticket natively
> >
> > I think your problem is that the A.FZK.DE has a afs/
> > cg.fzk.de@A.FZK.DE entry
> > in their data case, while you really want to use afs@CG.FZK.DE.
> >
> > It might be so that you can work around this problem by running
> >
> > afslog -k CG.FZK.DE -c cg.fzk.de -v
> >
> > Not sure if this works though.
> >
> > If the output  you have given me, that is the problem.
> >
> > Love
> >
> > 25 aug 2005 kl. 15.03 skrev Ulrich Schwickerath:
> >> Hello, Love,
> >>
> >> maybe, as an additional piece of information, I think it may be
> >> useful to add
> >> a bit of verbose output of what aklog really does:
> >>
> >> $aklog -d
> >> Authenticating to cell cg.fzk.de (server iwrafs0.fzk.de).
> >> We've deduced that we need to authenticate to realm CG.FZK.DE.
> >> Getting tickets: afs/cg.fzk.de@CG.FZK.DE
> >> Principal not found, trying alternate service name: afs/@CG.FZK.DE
> >> Using Kerberos V5 ticket natively
> >> About to resolve name schwicke@A.FZK.DE to id in cell cg.fzk.de.
> >> Id 393009
> >> Set username to AFS ID 393009
> >> Setting tokens. AFS ID 393009 /  @ A.FZK.DE
> >>
> >> in the pts database, there is a user that has been allocated
> >> before named
> >> schwicke@ka.fzk.de  with AFS ID   393009. Am I right that afslog/
> >> libkafs
> >> instead tries to create a token for schwicke (the one with PTS ddb
> >> entry
> >> schwicke 7597, and uses a different key ? If so, which key would
> >> that be, and
> >> how can I find out the correct key version number to allocate it
> >> AFS with
> >> bos_util adddes ? Making afs accept the token would be the most
> >> elegant
> >> solution for our  "problem" :-)
> >>
> >> Thank's a lot,
> >> Ulrich
> >>
> >> On Wednesday 24 August 2005 13:19, Ulrich Schwickerath wrote:
> >>> Hello, Love,
> >>>
> >>>> The "AFS ID" is just the result of getuid(), so that is nothing to
> >>>> care about. You should try run afslog -v to see what errors you get
> >>>
> >>> no error, everything seems to work fine, and it happily creates a
> >>> token for
> >>> me:
> >>> $ afslog -v
> >>> krb5 tried afs/cg.fzk.de@A.FZK.DE -> 0
> >>>
> >>>> You  should also see that error codes you get back from the
> >>>> fileserver, check output in dmesg or use tcpdump/ethereal to check
> >>>> what errors the fileserver returns in the message.
> >>>
> >>> The tokens is immediately discarded (seen by syslog/dmesg):
> >>> afs: Tokens for user of AFS id 7597 for cell cg.fzk.de are
> >>> discarded (rxkad
> >>> error=19270408)
> >>> This error translates into an "unknown key version number", which
> >>> makes me
> >>> suspicious that something is going really wrong here... I should
> >>> not have
> >>> to import another key, should I ?
> >>>
> >>> There is another strange thing: each time I do an afslog, I get
> >>> another new
> >>> cross realm ticket granting ticket (right?)
> >>> krbtgt/CG.FZK.DE@A.FZK.DE
> >>> eg.
> >>> $klistredentials cache: FILE:/tmp/krb5cc_fW9797
> >>>         Principal: schwicke@A.FZK.DE
> >>>
> >>>   Issued           Expires          Principal
> >>> Aug 24 13:14:54  Aug 24 21:14:44  krbtgt/A.FZK.DE@A.FZK.DE
> >>> Aug 24 13:14:54  Aug 24 21:14:44  krbtgt/CG.FZK.DE@A.FZK.DE
> >>>
> >>> $afslog -v
> >>> krb5 tried afs/cg.fzk.de@A.FZK.DE -> 0
> >>>
> >>> $klist
> >>> Credentials cache: FILE:/tmp/krb5cc_fW9797
> >>>         Principal: schwicke@A.FZK.DE
> >>>
> >>>   Issued           Expires          Principal
> >>> Aug 24 13:14:54  Aug 24 21:14:44  krbtgt/A.FZK.DE@A.FZK.DE
> >>> Aug 24 13:14:54  Aug 24 21:14:44  krbtgt/CG.FZK.DE@A.FZK.DE
> >>> Aug 24 13:15:45  Aug 24 21:14:44  krbtgt/CG.FZK.DE@A.FZK.DE
> >>>
> >>> aklog, on the other hand, works fine (as I said).
> >>>
> >>> Cheers,
> >>> Ulrich
> >>
> >> --
> >> __________________________________________
> >> Dr. Ulrich Schwickerath
> >> Forschungszentrum Karlsruhe
> >> GRID-Computing and e-Science
> >> Institut for Scientific Computing (IWR)
> >> P.O. Box 36 40
> >> 76021 Karlsruhe, Germany
> >>
> >> Tel: +49(7247)82-8607
> >> Fax: +49(7247)82-4972
> >>
> >> e-mail: ulrich.schwickerath@iwr.fzk.de
> >> PGP DH/DSS Key: ID 0xCEB9826F
> >> Fingerprint: 5537 8473 CD26 507E 8EE2  BAAF 98E2 FD16 CEB9 826F
> >> __________________________________________

-- 
__________________________________________
Dr. Ulrich Schwickerath
Forschungszentrum Karlsruhe
GRID-Computing and e-Science
Institut for Scientific Computing (IWR)
P.O. Box 36 40
76021 Karlsruhe, Germany

Tel: +49(7247)82-8607
Fax: +49(7247)82-4972 

e-mail: ulrich.schwickerath@iwr.fzk.de
PGP DH/DSS Key: ID 0xCEB9826F
Fingerprint: 5537 8473 CD26 507E 8EE2  BAAF 98E2 FD16 CEB9 826F
__________________________________________

Prev by Date: your teeths are disquat
Next by Date: Very long pam_acct_mgmt times on Suse SLES9 with heimdal 0.6.1rc3,w2k3 kdc and Openssh-3.8p1
Prev by thread: Re: afslog behaviour in a cross realm configuration
Next by thread: Server not found in database
Index(es):
- Date
- Thread