There is a philosophical issue with whether pam_krb5 should be optional (as Sun and I set it up) or required ("sufficient", so it really controls login). The former is clearly correct for a laptop, while the latter is probably correct for a multi-user lab machine.
I absolutely agree that all the pam interactions are unfortunately complex for such a critical configuration. We just discovered a few months ago that one of the standard pam configurations we had been using allowed console login as root without a password! It was crazy how hard it was to figure out how to do the other things we needed without exposing the hole. (Thankfully it did not allow network access, and the machines were in locked rooms!)
On Jul 29, 2004, at 6:51 PM, Eliot Lebsack wrote:
------------------------------------------------------------------------ ----Henry,
I just managed to get it working. It turns out that you can't just uncomment the krb5 entries in the /etc/pam.conf file. You also need to make sure that krb5 is "sufficient" for the "auth" rule for the service, in this case "login". You may need to play with the relationship with pam_unix.so as well, since pam_unix.so may fail the authentication without getting to the krb5 stage to let it do its magic.
Sun really needs to do a better job in explaining the interplay between the pam_unix and pam_krb5 modules in /etc/pam.conf. RedHat's authconfig tool sets this up automagically, and I've never had to muck with any of my pam.d files until now.
As far as I can tell, the tickets are being issued at login, and destroyed at logout correctly. This is awfully nice. Now, I think the next step is to install the full SEAM packages to get the kerberized telnet server and client.
Thanks again for your attention on this issue.
Regards,
Eliot
-----Original Message----- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 5:55 PM To: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
You still haven't told me what happens when you try a kinit as a non-root user on your Solaris 8 machine. That was step one of the debugging procedure I gave you.
On your Sol8 machine, while logged in as an ordinaray user please show me: 1) klist before 2) kinit 3) klist after
and show me the corresponding entries in the kdc log file from the kerberos server.
If you show me this information I can probably help you.
On Jul 28, 2004, at 12:48 PM, Eliot Lebsack wrote:
----------------------------------------------------------------------- -Henry,
I just went back and tried the following, as the non-root user on another set of machines: command result 1. kinit (successfully) 2. klist (get the initial krbtgt/<REALM>@<REALM>) 3. telnet -f <somehost> (log in) 4. <somehost>: exit (log out) 5. klist (have two tickets: krbtgt, and host/<somehost>)
As the root user on the solaris 8 machine, I did the following, with NO tickets in the root cache:
1. kinit -k (no answer) 2. klist (get the initial krbtgt/<REALM>@<REALM>)
When I telnet to the solaris machine from my linux box as non-root user, with a valid initial ticket, the failure occurs as shown in my debug output:
sol8test = my solaris 8 machine.
Jul 28 15:47:19 sol8test login: [ID 427203 auth.debug]
pam_authenticate:
error Authentication failed
Jul 28 15:47:19 sol8test login: [ID 705685 auth.debug] PAM-KRB5:
pam_sm_authenticate
Jul 28 15:47:25 sol8test PAM: [ID 599088 auth.debug] pam_close_session:
error Authentication token manipulation error
Eliot
-----Original Message----- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 28, 2004 1:16 PM To: Eliot Lebsack Cc: [EMAIL PROTECTED] Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
On Jul 28, 2004, at 5:34 AM, Eliot Lebsack wrote:
Henry,
Thanks for going through this with me. In response to your questions:
1) Can the user (once logged in) do a kinit? (If not check krb5.confpermissions, and contents.)
When I "su - <username>" from root, and do a kinit, the ticket is granted by the KDC correctly.
Like I said, if kinit works from root, but not from a user account then
it's most likely a permissions problem. kinit should work even if the
host principal/keytab is messed up. If you have more than one version
of kerberos (and kinit) then that could also be a source of problems.
This is your basic problem. Worry about it before spending much time on the others. See comments on pam debugging below.
Permissions problems on Solaris may not get reported intelligibly, unfortunately. If I try step 3 as user instead of root I get "Unknown code 13" for instance.
2) Can the user (once kinit'ed) get a host service ticket? (Trytelnet'ing to yourself at the external network address. I think that will do it. If not you need a second machine.)
After doing "su - <username>" from root, and a kinit as <username>, I'm unable to telnet to my solaris 8 machine at the external address. I then went to a Linux client on the same KDC/Realm, logged in as <username>, kinit, then used the kerberized telnet to try to log onto the solaris 8 machine, but was unsuccessful.
I didn't expect the login to be successful, but did the Linux client
(with klist) show a host/[EMAIL PROTECTED] ticket after the
failure? (That would be a success for this test.) Make sure you use
the right options on Telnet to try Kerberos authentication. (It should
print messages about the attempt.)
[lap:~] hotz% klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default Principal: [EMAIL PROTECTED] Valid Starting Expires Service Principal 07/28/04 09:45:23 07/28/04 19:45:22 krbtgt/[EMAIL PROTECTED] renew until 07/28/04 09:46:23
[lap:~] hotz% telnet -f mac Trying 137.78.61.41... Connected to mac.jpl.nasa.gov. Escape character is '^]'. [ Kerberos V5 accepts you as [EMAIL PROTECTED]'' ] [ Kerberos V5 accepted forwarded credentials ] Last login: Mon Jun 21 18:14:49 2004 from lap on ttyp0 . . . . Welcome to NetBSD!
mac: {1} exit mac: {2} logout Connection closed by foreign host. [lap:~] hotz% klist Kerberos 5 ticket cache: 'API:Initial default ccache' Default Principal: [EMAIL PROTECTED] Valid Starting Expires Service Principal 07/28/04 09:45:23 07/28/04 19:45:22 krbtgt/[EMAIL PROTECTED] renew until 07/28/04 09:46:23 07/28/04 09:45:39 07/28/04 09:46:22 host/[EMAIL PROTECTED]
[lap:~] hotz%
3) Does the local keytab work? (Try kinit -k as root. klist shouldshow you are kinit'ed as host/[EMAIL PROTECTED])
kinit -k shows nothing.
No, it shouldn't. What does klist show after doing the kinit?
My /etc/krb5/krb5.keytab file has the following entries:
slot KVNO Principal ---- ---- ------------------------------------------- 1 3 root/<fqdn of solaris 8 machine>@<REALM> 2 3 host/<fqdn of solaris 8 machine>@<REALM>
They were added at the KDC with the following arguments:
addprinc -randkey -e des-cbc-crc:normal {host,root}/<fqdn of solaris 8
machine>
and added to the keytab with the following arguments
ktadd -k /etc/sol8.krb5.keytab -e des-cbc-crc:normal {host,root}/<fqdn
of
solaris 8 machine>
I use Heimdal more than MIT or Solaris, but those commands look right to me. You have checked the name resolution, right? There's a FAQ on that subject.
The file /etc/sol8.krb5.keytab was copied to /etc/krb5/krb5.keytab on the solaris 8 machine, with permissions 0600.
. . . and owner root, I presume. I also presume that the permissions/ownership on /etc/krb5/ are normal.
I've enabled pam debugging as follows:
a) add "auth.debug /etc/pam_debug" to /etc/syslog.conf b) touch /etc/pam_debug c) /etc/init.d/syslog stop; /etc/init.d/syslog start
I have a line:
other auth optional pam_krb5.so.1 try_first_pass debug
in my Solaris 9 pam.conf. That was the debug option I was talking about. "man pam_krb5" to check if it's available on Sol8, too. You are using the Sun pam_krb5, right? Make sure which man page you read matches the version installed/used, of course.
You should also look at the kdc logs at the time when you try to log in
to the Solaris 8 machine. This is generally useful, but you *may* get
more info from the pam debug in this case.
Regards,
Eliot
====================================================== Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE Corporation Bedford, MA
2) Can the user (once kinit'ed) get a host service ticket? (Try telnet'ing to yourself at the external network address. I think that will do it. If not you need a second machine.)
3) Does the local keytab work? (Try kinit -k as root. klist should show you are kinit'ed as host/[EMAIL PROTECTED])
4) Does the host service ticket agree with the one in the local /etc/krb5/krb5.keytab? (Not sure exactly how to check this. The Solaris ktutil doesn't show much info. Presumably if both 2 and 3 work it should be OK, but they might be different kvno's.)
Don't know if Sol 8 is completely like Sol 9, but the pam modules need
the host principal to work for full functionality on 9.
Isn't there a debug option for the pam modules?
On Jul 27, 2004, at 6:29 AM, Eliot Lebsack wrote:
Henry,
I checked all of the permissions, and they check out. However, this does not fix the problem.
Regards,
Eliot
====================================================== Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE Corporation Bedford, MA
-----Original Message-----
From: Henry B. Hotz [mailto:[EMAIL PROTECTED]
Sent: Monday, July 26, 2004 6:20 PM
To: Eliot Lebsack
Cc: [EMAIL PROTECTED]
Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot
Lebsack)
Right, that's the problem. You need to set -rw-r--r-- (644) for krb5.conf.
Those permissions are correct for krb5.keytab.
Both should be root owned.
On Jul 26, 2004, at 1:05 PM, Eliot Lebsack wrote:
Henry,
Just checked - the permissions are -rw------- (0600). Still have the same problem. The /etc/krb5/krb5.keytab file is also set with the same permissions.
Regards,
Eliot
====================================================== Eliot Lebsack (781) 271-5830 Lead Communications Engineer [EMAIL PROTECTED] The MITRE Corporation Bedford, MA
-----Original Message----- From: Henry B. Hotz [mailto:[EMAIL PROTECTED] Sent: Monday, July 26, 2004 3:17 PM To: [EMAIL PROTECTED] Cc: Eliot Lebsack Subject: Re: Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
If it works as root, but not as a user, then it sounds like a permissions problem. Is /etc/krb5/krb5.conf world-readable?
On Jul 26, 2004, at 9:00 AM, [EMAIL PROTECTED] wrote:
Date: Mon, 26 Jul 2004 09:55:02 -0400 From: "Eliot Lebsack" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux Message-ID: <[EMAIL PROTECTED]> Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: list Message: 1
Good morning.
I've set up a KDC on a RHEL 3 box with NIS as the name service. All of my Linux boxes have no problem authenticating against this configuration.
When I attempted to migrate my Solaris 8 (2/02) Ultra 80 to this authentication/name service combination, using the on-board (non-SEAM) kerberos authentication tools which are run when reconfiguring a system (running sys-unconfig, then rebooting), I entered the fields for Kerberos as those used by my Linux machines.
I went ahead and synced up my /etc/krb5/krb5.conf file with that used by the Linux clients. I uncommented the pam.conf lines for the pam_krb5.so.1 module as directed by the documention I could find on the web. I've even generated a keytab for the host principle, and moved it into /etc/krb5/krb5.keytab.
I've checked my DNS setup as well as NTP. Everything looks good.
When I attempt to log onto the Solaris 8 machine as a regular user, forcing the machine to refer to NIS/Kerberos for more information, the pam_krb5 authentication module refuses to allow access.
When I "su -" to the user from root, and do a kinit as the user, it successfully gets the Kerberos ticket.
It appears that pam_krb5 is not entering the authentication process correctly, or that it is not negotiating with the KDC correctly.
Has anyone else tried a similar configuration? I'm trying to do something real basic here; no kerberized NFS or anything like that.
I also tried installing SEAM for Solaris 8, and still had the same problem.
Regards,
Eliot
====================================================== Eliot Lebsack Lead Communications Engineer [EMAIL PROTECTED] The MITRE Corporation Bedford, MA
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
[EMAIL PROTECTED], or [EMAIL PROTECTED]
________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
