Presence/absence of the keytab
Scott Lowe
able to find a satisfactory answer, so I thought I'd go to the experts.
:)
I'm testing/verifying integration between Linux and Linux-based systems
and Active Directory on Windows Server 2003 R2 via Kerberos and PAM.
All of the documentation I've ever seen for integrating
Linux/Linux-based systems into AD via Kerberos call for the use of
ktpass.exe on the Windows domain controller (KDC) to generate the
keytab, which is then securely transferred to the Linux/Linux-based
system in question.
Yesterday, however, I was able to successfully authenticate via
Kerberos from VMware ESX Server 2.5.3 (the console operating system is
Linux-based) *without* generating a keytab. This seems to fly in the
face of all the information and instructions I've seen.
So, I'm curious...any thoughts as to why this worked?
BTW, here are the instructions I followed:
<http://www.vmware.com/pdf/esx_authentication_AD.pdf>
TIA.
--
Regards,
Scott Lowe
ePlus Technology, Inc.
Richard E. Silverman
SL> Yesterday, however, I was able to successfully authenticate via
SL> Kerberos from VMware ESX Server 2.5.3 (the console operating
SL> system is Linux-based) *without* generating a keytab. This seems
SL> to fly in the face of all the information and instructions I've
SL> seen.
SL> So, I'm curious...any thoughts as to why this worked?
A keytab is needed for a host on which a kerberized service runs; it holds
the service princpal's secret key, which the service software needs.
You don't need anything special on a host to allow someone to "kinit" on
it. The only secret needed is your password.
--
Richard Silverman
r...@qoxp.net
Donn Cave
True, though there is a sort of grey area inhabited by services
that use Kerberos to perform password authentication. This is
functionally like "kinit", but semantically quite different, and
without a service principal to validate the authentication results,
they're vulnerable.
So depending on what `successfully authenticate' actually means here,
the information and instructions that say to get a service principal
and a keytab may be worth listening to, even if the service appears
to work without it.
Donn Cave, do...@u.washington.edu
Scott Lowe
OK, that makes sense, since in this instance the "server" (let's say, a
non-Kerberized SSH daemon) is strictly a Kerberos client talking
through pam_krb5. In that instance, since it is not the one talking
Kerberos directly to all other systems involved (I'm hesitant to keep
using the terms "client" and "server" here), then a keytab would
typically not be necessary.
Scott Lowe
I suppose if I were seeking to use a fully Kerberized server
application that accept Kerberos tickets from Kerberos clients, then a
keytab would be necessary. In this instance, the service does not
accept Kerberos authentication from connecting systems, but acts a
Kerberos client on the back-end to perform authentication (using PAM).
It seems to make sense, then, that a keytab would not be necessary. At
least, not in this situation.
Thanks for your response.
Donn Cave
Scott Lowe <sl...@eplus.com> wrote:
> On 2006-05-04 12:29:53 -0400, Donn Cave <do...@u.washington.edu> said:
> > True, though there is a sort of grey area inhabited by services
> > that use Kerberos to perform password authentication. This is
> > functionally like "kinit", but semantically quite different, and
> > without a service principal to validate the authentication results,
> > they're vulnerable.
> >
> > So depending on what `successfully authenticate' actually means here,
> > the information and instructions that say to get a service principal
> > and a keytab may be worth listening to, even if the service appears
> > to work without it.
> I suppose if I were seeking to use a fully Kerberized server
> application that accept Kerberos tickets from Kerberos clients, then a
> keytab would be necessary. In this instance, the service does not
> accept Kerberos authentication from connecting systems, but acts a
> Kerberos client on the back-end to perform authentication (using PAM).
> It seems to make sense, then, that a keytab would not be necessary. At
> least, not in this situation.
I guess it depends on what you mean by "necessary", but if there's
any reasonable possibility that you could create a host service
principal and install that keytab, I would do it. If you have
reason to believe that the PAM authentication isn't actually using
the keytab, I would find out why and try to get it fixed. Without
it, you're vulnerable. Of course everything's relative, and the
authorization you're providing with this authentication may not
warrant the concern, but that's different than thinking it isn't
necessary in the sense that there is no use for it, which would be
an error.
Donn Cave, do...@u.washington.edu
Markus Moeller
and updates it regularly as part of the system trust key update.
Markus
"Donn Cave" <do...@u.washington.edu> wrote in message
news:donn-7FA334.1...@gnus01.u.washington.edu...
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Luke Howard
>BTW. You don't really need a keytab. Windows uses for example its own store
>and updates it regularly as part of the system trust key update.
Right, but for all intents and purposes it's effectively the same thing.
The only difference is that Windows stores a string from which the keys
can be derived rather than the keys themselves.
-- Luke
--
Scott Lowe
It's certainly not a problem to create the host service principal in
Active Directory (using ktpass.exe) and installing the keytab on the
Linux system. I was just a bit caught off-guard by the fact that the
authentication (again, via pam_krb5) worked even when the keytab was
not installed. Given the explanation that you and others have provided
regarding the purpose of the keytab, I think that I understand why.
However, just for the sake of completeness, it makes sense and is not a
great deal of work to continue to generate the host service principal
and its associated keytab for the Linux hosts.
Thanks for your time and the time of others to explain this situation.
Richard E. Silverman
SL> I was just a bit caught off-guard by the fact that the
SL> authentication (again, via pam_krb5) worked even when the keytab
SL> was not installed.
pam_krb5 verifies your password against Kerberos, right? In that case,
there *should* be a keytab, due to the issue alluded to earlier in this
thread: the module should obtain a host ticket to defend against a KDC
spoofing attack. If it let you in without that, perhaps there's a "verify
KDC" option that's turned off (and ideally, should be turned on).
--
Richard Silverman
r...@qoxp.net
Russ Allbery
The pam_krb5 modules that I've used either don't do this or only do this
when the keytab is available, presumably doing a security vs. ease of
deployment tradeoff. One difficulty is that if the authentication is not
being done as root, the PAM module needs something other than the host
keytab to use for verification, and I don't know of any PAM module that is
configurable enough to be pointed at any keytab and use that keytab for
verification. It would be a good thing to add, though.
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Marcus Watts
> Subject: Re: Presence/absence of the keytab
> References: <4bpb78F...@individual.net>
> <m2psiuq...@darwin.oankali.net>
> <donn-516701.0...@gnus01.u.washington.edu>
> <4buuu2F...@individual.net>
> <donn-7FA334.1...@gnus01.u.washington.edu>
> <4c117cF...@individual.net>
> From: "Richard E. Silverman" <r...@qoxp.net>
> Date: 06 May 2006 00:14:58 -0400
> Message-ID: <m2k68z4...@darwin.oankali.net>
> To: kerb...@mit.edu
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
There's 2 easy ways pam_krb5 could use a host ticket to defend
against a host spoof attack. It could contain logic to explicitly
get a host ticket. Typically there will be calls to routines like
krb5_kt_read_service_key
krb5_mk_req
krb5_rd_req
Or it could be using the kerberos 5 library call krb5_verify_init_creds()
to do the same thing. In the latter case there is in fact an option to
control what happens when the keytab is missing. There are two ways to
invoke this:
/1/ compile-time configuration: add logic:
add variable, type: krb5_verify_init_creds_opt
initialize with
krb5_verify_init_creds_opt_init
use krb5_verify_init_creds_opt_set_ap_req_nofail
to set KRB5_VERIFY_INIT_CREDS_OPT_AP_REQ_NOFAIL.
pass as last parm to krb5_verify_init_creds
/2/ run-time configuration:
add [libdefaults]
verify_ap_req_nofail = TRUE
to krb5.conf
At a quick glance, the "libpam-krb5 1.2.0" that comes with debian linux
does the former - hardcoded logic. Doesn't seem to be any way to
make it give up if no keytab is present, but there is a debug option
that will cause it to log helpful text when various errors occur,
including no keytab.
-Marcus Watts
Russ Allbery
> Or it could be using the kerberos 5 library call
> krb5_verify_init_creds() to do the same thing. In the latter case there
> is in fact an option to control what happens when the keytab is missing.
> There are two ways to invoke this:
> /1/ compile-time configuration: add logic:
> add variable, type: krb5_verify_init_creds_opt
> initialize with
> krb5_verify_init_creds_opt_init
> use krb5_verify_init_creds_opt_set_ap_req_nofail
> to set KRB5_VERIFY_INIT_CREDS_OPT_AP_REQ_NOFAIL.
> pass as last parm to krb5_verify_init_creds
> /2/ run-time configuration:
> add [libdefaults]
> verify_ap_req_nofail = TRUE
> to krb5.conf
> At a quick glance, the "libpam-krb5 1.2.0" that comes with debian linux
> does the former - hardcoded logic. Doesn't seem to be any way to make
> it give up if no keytab is present, but there is a debug option that
> will cause it to log helpful text when various errors occur, including
> no keytab.
Is this run-time configuration supported with both MIT Kerberos and
Heimdal? If so, I can modify Debian's libpam-krb5 to use that approach
instead (since it looks like I'm going to end up being the upstream
maintainer of that fork of the code anyway since we need it at Stanford
and I need to add and fix a bunch of bits in it anyway).
Marcus Watts
> Subject: Re: Presence/absence of the keytab
> Organization: The Eyrie
> Message-ID: <87odybe...@windlord.stanford.edu>
> References: <m2k68z4...@darwin.oankali.net>
> To: kerb...@MIT.EDU
Looks to me like heimdal has supported both krb5_verify_init_creds&friends,
and "verify_ap_req_nofail" since at least 0.6.4.
-Marcus
Scott Lowe
It looks as if there is a parameter for pam_krb5 (the parameter is
"validate") that requires validation of the TGT (see
<http://www.die.net/doc/linux/man/man5/pam_krb5.5.html>). The default
value is false, which is why I assume that the absence of the keytab
didn't matter. I would guess that setting this parameter to true would
cause authentication via pam_krb5 to fail if the keytab is not present.
I intend to test this and will post back any results as soon as I have
them.
Thanks again for everyone's time and responses.
--
Regards,
Scott Lowe
ePlus Technology Inc.
Donn Cave
Russ Allbery <r...@stanford.edu> wrote:
...
> The pam_krb5 modules that I've used either don't do this or only do this
> when the keytab is available, presumably doing a security vs. ease of
> deployment tradeoff. One difficulty is that if the authentication is not
> being done as root, the PAM module needs something other than the host
> keytab to use for verification, and I don't know of any PAM module that is
> configurable enough to be pointed at any keytab and use that keytab for
> verification. It would be a good thing to add, though.
Wonder if this situation is common enough to warrant library support
for some default file convention, like /etc/krb5.keytab if root,
otherwise ~/krb5.keytab.
Not to say a configurable parameter isn't a good thing, too.
Donn Cave, do...@u.washington.edu
Jeffrey Hutzelman
On Friday, May 05, 2006 09:17:34 PM -0700 Russ Allbery <r...@stanford.edu>
wrote:
> One difficulty is that if the authentication is not
> being done as root, the PAM module needs something other than the host
> keytab to use for verification
... or a setuid-0 helper program.
Scott Lowe
I performed some additional testing (using CentOS 4.3 and pam_krb5--not
sure which version, but it was the version included with the
distribution) and the "validate" parameter has no effect on the
module's operation. Authentication via pam_krb5 occurred successfully
(either via console login or via ssh) whether the keytab was present or
not.
This supports Russ' earlier statement that the pam_krb5 modules he's
worked with just don't do this or only do this when the keytab is
available.