Solaris pam-krb5 client and MIT krb5 KDC on Linux (Eliot Lebsack)
Eliot Lebsack
elebsack at mitre.org
Thu Jul 29 21:51:28 EDT 2004
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:hotz at jpl.nasa.gov]
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:hotz at jpl.nasa.gov]
> Sent: Wednesday, July 28, 2004 1:16 PM
> To: Eliot Lebsack
> Cc: kerberos at mit.edu
> 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.conf
>> permissions, 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? (Try
>> telnet'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/your.machine at YOUR.REALM 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: hotz at HOTZ.JPL.NASA.GOV
>> Valid Starting Expires Service Principal
>> 07/28/04 09:45:23 07/28/04 19:45:22
>> krbtgt/HOTZ.JPL.NASA.GOV at HOTZ.JPL.NASA.GOV
>> 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 ``hotz at HOTZ.JPL.NASA.GOV'' ]
>> [ 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: hotz at HOTZ.JPL.NASA.GOV
>> Valid Starting Expires Service Principal
>> 07/28/04 09:45:23 07/28/04 19:45:22
>> krbtgt/HOTZ.JPL.NASA.GOV at HOTZ.JPL.NASA.GOV
>> renew until 07/28/04 09:46:23
>> 07/28/04 09:45:39 07/28/04 09:46:22
>> host/mac.jpl.nasa.gov at HOTZ.JPL.NASA.GOV
>>
>> [lap:~] hotz%
>
>
>>>> 3) Does the local keytab work? (Try kinit -k as root. klist should
>> show you are kinit'ed as host/your.machine at YOUR.REALM.)
>>
>> 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 elebsack at mitre.org
>> 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/your.machine at YOUR.REALM.)
>>
>> 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 elebsack at mitre.org
>>> The MITRE Corporation Bedford, MA
>>>
>>> -----Original Message-----
>>> From: Henry B. Hotz [mailto:hotz at jpl.nasa.gov]
>>> Sent: Monday, July 26, 2004 6:20 PM
>>> To: Eliot Lebsack
>>> Cc: kerberos at mit.edu
>>> 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 elebsack at mitre.org
>>>> The MITRE Corporation Bedford, MA
>>>>
>>>> -----Original Message-----
>>>> From: Henry B. Hotz [mailto:hotz at jpl.nasa.gov]
>>>> Sent: Monday, July 26, 2004 3:17 PM
>>>> To: kerberos at mit.edu
>>>> 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, kerberos-request at mit.edu wrote:
>>>>
>>>>> Date: Mon, 26 Jul 2004 09:55:02 -0400
>>>>> From: "Eliot Lebsack" <elebsack at mitre.org>
>>>>> To: <kerberos at mit.edu>
>>>>> Subject: Solaris pam-krb5 client and MIT krb5 KDC on Linux
>>>>> Message-ID: <000901c47318$25c78aa0$1b515381 at MITRE.ORG>
>>>>> 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 elebsack at mitre.org
> The MITRE Corporation Bedford, MA
>
>
>
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu
More information about the Kerberos
mailing list