There's a bug in pam_krb5afs where its supposed to lookup the fileserver
that /afs/ lives and find its realm (from the domain_realm
mapping in krb5.conf) and then try afs/[EMAIL PROTECTED] Under 1.3.x when
it calls the PFindVolume pioctl it only passes in a 4 byte long iob.out in
minikafs_real
Hello Christopher,
do you have any patches for rhel4's pam_krb5 available?
Thanks,
Grant.
Christopher Allen Wing wrote:
On Tue, 26 Apr 2005, Dj Merrill wrote:
Hi Chris,
Thanks for all the work in maintaining the
pam_krb5 program
Thanks, but I haven't contributed anything to pam_krb5 mys
Christopher Allen Wing wrote:
Thanks, but I haven't contributed anything to pam_krb5 myself. I just
noticed like you that it didn't work properly in RHEL4.
Fair enough.. *grin*
You should be fine with the afs/econ.duke.edu key. At some point I'll try
to get the necessary fixes to Red Hat so pa
On Tue, 26 Apr 2005, Dj Merrill wrote:
> Hi Chris,
> Thanks for all the work in maintaining the
> pam_krb5 program
Thanks, but I haven't contributed anything to pam_krb5 myself. I just
noticed like you that it didn't work properly in RHEL4.
> If I leave things as they are (using th
Christopher Allen Wing wrote:
pam_krb5 in RHEL4 no longer uses the Kerberos ticket file directly to
obtain AFS tokens; this is why it does not show up in klist.
(It obtains the necessary Kerberos ticket and stores it in memory only)
Makes sense - thanks!
The reason why using the new principal
> One interesting note is that "klist" under
> 3.4 gives an entry for "[EMAIL PROTECTED]"
> whereas for 4 it does not. However, it seems to work - I can
> access files in AFS, etc.
pam_krb5 in RHEL4 no longer uses the Kerberos ticket file directly to
obtain AFS tokens; this is why it does
Dj Merrill wrote:
Douglas E. Engert wrote:
You have not said anything about the krb5 realm, or having added
a principal to the realm's database.
Hi Douglas,
I have a completely working system using all RHEL 3.4 machines.
Krb5 is setup and working, corresponding principals are in the database,
Dj Merrill wrote:
Hi Chris,
Will this break my existing and working RHEL 3.4 systems?
To answer my own query, no, it does not break the
RHEL 3.4 machines. I basically did:
"asetkey list" to get the highest KVNO listed (in my case, 1).
I then created the afs/econ.duke.edu principal and
Christopher Allen Wing wrote:
As Douglas suggests, adding the principal to your realm:
afs/[EMAIL PROTECTED]
would also likely solve your problem. pam_krb5 only tries the instanceless
principal:
[EMAIL PROTECTED]
when it can reverse map the IP address of the AFS server, and use that
domai
Christopher Allen Wing wrote:
It looks like it tries '[EMAIL PROTECTED]' instead of '[EMAIL PROTECTED]':
Hi Chris,
I'm sorry, that was a typo on my part.
It tries:
Apr 25 13:39:35 galactica sshd[28332]: pam_krb5[28332]: attempting to
obtain tokens for "econ.duke.edu" ("afs/[EMAIL PROTECTED]")
Apr
Douglas E. Engert wrote:
You have not said anything about the krb5 realm, or having added
a principal to the realm's database.
Hi Douglas,
I have a completely working system using all RHEL 3.4 machines.
Krb5 is setup and working, corresponding principals are in the database,
and RHEL 3.4 clients
Christopher Allen Wing wrote:
Frode:
The pam_krb5 module that comes with Red Hat should be able to obtain
tokens. Note that it may have some bugs:
- it may not work with dynroot enabled
- it may not work when you have more than 1 AFS database server
At some point I will try to get p
> As per the K5 migration info, I have an afs principal:
> [EMAIL PROTECTED]
> however, I note that the pam_krb5afs tries several other
> combinations, but not this one exactly. For example, it tries
> [EMAIL PROTECTED], afs/[EMAIL PROTECTED], and
> afs/[EMAIL PROTECTED]
As Douglas suggests
You have not said anything about the krb5 realm, or having added
a principal to the realm's database.
Dj Merrill wrote:
Christopher Allen Wing wrote:
Frode:
The pam_krb5 module that comes with Red Hat should be able to obtain
tokens. Note that it may have some bugs:
- it may not work with dynro
> As per the K5 migration info, I have an afs principal:
> [EMAIL PROTECTED] however, I note that the pam_krb5afs tries several other
> combinations, but not this one exactly. For example, it tries
> [EMAIL PROTECTED], afs/[EMAIL PROTECTED], and
> afs/[EMAIL PROTECTED]
It looks like it tr
On Thu, Apr 07, 2005 at 11:41:59AM -0400, Dj Merrill wrote:
> However, I can issue the "afslog" command after login
> and it obtains an AFS token just fine with no errors.
>
> In the logs I get:
>
> Apr 7 11:14:08 galactica sshd[9019]: pam_krb5[9019]: got error -1
> (Unknown code __
Nalin Dahyabhai wrote:
Can you add "debug" to the end of this line, configure /etc/syslog.conf
to save debug-level messages (for example by adding "*.* /var/log/debug"
somewhere near the top) and look for the messages which are logged
between "obtaining tokens for mytest.dartmouth.edu" and the erro
Craig Cook wrote:
Can you replace your "standard" pam_krb5afs.so with the version that comes with
1.3.81?
Keep a copy in case it doesn't work ;)
Hi Craig,
I don't see a pam_krb5afs.so in 1.3.81.
I see a pam_afs, but it is only good for Krb 4, not 5
according to the man page included with i
Can you replace your "standard" pam_krb5afs.so with the version that comes with
1.3.81?
Keep a copy in case it doesn't work ;)
Craig Cook
--
Systems Monitoring Consulting and Support Services
http://www.cookitservices.com
___
OpenAFS-info mailing list
Craig Cook wrote:
Where did you get the afs (and krbafs) packages from? (Also noted they are different versions you are playing with).
I should have been more clear in my last reply.
The krbafs comes with the distributions.
OpenAFS I'm compiling from the source code.
The reason for different v
Craig Cook wrote:
> These lines imply that afs support is compiled into your standard >
pam_krb5.so file...
> lrwxrwxrwx 1 root root11 Mar 9 04:00 pam_krb5afs.so -> pam_krb5.so
> -rwxr-xr-x 1 root root 57724 Aug 31 2004 pam_krb5.so
That is correct - it does have AFS support includ
>session optional /lib/security/$ISA/pam_krb5afs.so
On Solaris $ISA resolves to different dirs, depending on 32-bit or 64-bit of
the OS.
These lines imply that afs support is compiled into your standard pam_krb5.so
file...
lrwxrwxrwx 1 root root11 Mar 9 04:00 pam_krb5afs.so -> p
Craig Cook wrote:
Seems Solaris is fussy about group ownership on the pam_afs.so.1 file. If it is set to
"other" the AFS pam thing will not work.
You also need to set "UsePAM yes" in your sshd_config file.
Hi Craig,
I checked UsePAM, and it is set to yes.
I get the same behaviour whether
On a similar issue, I have just solved the same thing on Solaris 8 & 9.
Could login using ssh but not automatically get tokens (using OpenSSH 4.0p1 on
the destination AFS solaris server)
Once logged in, could use klog and get tokens.
(Not using Kerberos though)
Seems Solaris is fussy about group
Hi all,
I'm banging my head on a problem and thought one of
you might have a hint that will help me solve this.
I have a CentOS 3.4 server (basically RHEL 3.4)
running Krb5 and OpenAFS 1.2.13. I am able to login
to the machine with my test account against Krb5 and
obtain an AFS tok
25 matches
Mail list logo
