Re: kerberos AD: keytab and service principal not needed?
- From: rossdruker@xxxxxxxxx
- Date: 30 Aug 2006 14:44:32 -0700
I did reply to your latest post, but it doesn't seem to indicate that
on google. I posted details about the kerberos udp/tcp packets.
Ross
Christopher D. Clausen wrote:
rossdruker@xxxxxxxxx wrote:
Christopher D. Clausen wrote:
rossdruker@xxxxxxxxx wrote:
Thanks for your response. Some questions. With regard to:
So, what is the point of the Windows-side setup?
The point is to prevent someone from setting up a fake KDC and
sending bogus data, possibly allowing an attacker to logon to your
otherwise secure machine.
By creating the keytab, you have a "shared secret" between the KDC
and your machine that you can use to see if the KDC is legit or
not. This is similar to how SSH host key verification works.
If they keytab is the shared secret, then how come I can delete it
with no effect? Clearly it's not being used. Which means that it
wouldn't be used in the case of a fake KDC.
Your logic isn't necessarily valid. If there is a mechanism to
simply bypass the additional security check in the case of a failure
it may just warn or no-op and not error out on failure. I haven't
debugged LAM for a few years and don't recall the needed debug steps
of hand.
I suppose it could be "working around" the problem, but it seems like
it's missing the whole point of keytabs and "shared secrets".
Perhaps. I'm pretty sure it did not work at without a keytab when I
tried to set this up on AIX 5.1.
Is AIX perhaps not implementing this properly?
Which side do you delete it from? The AIX side? Or the KDC side?
Also, its possible that the verfication step just ignores errors if
the verification can't be completed. Unfortunately I don't know
enough about AIX's Kerberos implementation to tell you what happens.
I deleted the keytab on the AIX side. There was no AD account (our
KDC) to delete since it doesn't exist.
What? How did you get a keytab without mapping it to some AD account?
I'd say to watch the KDC logs (which might be hard with MS AD) and
see if the principal in the keytab is requested when users
authenticate to the AIX machine. Or run a network sniffer and
watch. Its also possible that the principal in the keytab isn't the
one that AIX wants and the check is still failing with a keytab b/c
something isn't correct (usually problems with the host/fqdn and
/etc/hosts file or incorrect krb5.conf.)
I have asked one of the Windows admins here to see if he can get me
the logs.
I did run tcpdump on two hosts, looking for kerberos protocol packets.
One host with a keytab and AD computer account and one host with
neither. The conversations appear almost identical -- there's some
slight difference in the TCP packets at the end, but I don't think
that's relevant. Below is the packet summary (doesn't paste well into
the textbox, hope it displays better), for the host *with* the keytab
and AD account.
I can't really say I understand the details yet. I don't know what a
"correct" conversation should look like. I did search on the net for
KRB5KDC_ERR_PREAUTH_REQUIRED and found this page,
http://mailman.mit.edu/pipermail/kerberos/2006-May/009750.html, which
talks about MS AD and ktpass issues. But again, I'm not yet sure if
it applies to my situation.
No. Time Source Destination
Protocol Info
1 0.000000 136.141.230.45 136.141.3.41 KRB5
AS-REQ
2 0.108226 136.141.3.41 136.141.230.45 KRB5
KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED
3 0.128793 136.141.230.45 136.141.171.74 KRB5
AS-REQ
4 0.133382 136.141.171.74 136.141.230.45 KRB5
KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG
That might be your problem. If you are in a large number of AD groups
the returned Kerberos ticket might be larger than what AIX's Kerberos
supports and it'll bail out.
See http://support.microsoft.com/kb/832572 for information on setting
NO_AUTH_REQUIRED which will not append PAC data (group list) to the
Kerberos tickets.
5 0.143178 136.141.230.45 136.141.3.41 TCP
37290 > kerberos [SYN] Seq=0 Len=0 MSS=1460
6 0.251388 136.141.3.41 136.141.230.45 TCP
kerberos > 37290 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460
7 0.251411 136.141.230.45 136.141.3.41 TCP
37290 > kerberos [ACK] Seq=1 Ack=1 Win=65535 Len=0
8 0.251442 136.141.230.45 136.141.3.41 KRB5
AS-REQ
9 0.368198 136.141.3.41 136.141.230.45 TCP
[TCP segment of a reassembled PDU]
10 0.371591 136.141.3.41 136.141.230.45 KRB5
AS-REP
11 0.371620 136.141.230.45 136.141.3.41 TCP
37290 > kerberos [FIN, ACK] Seq=251 Ack=2100 Win=65535 Len=0
12 0.465437 136.141.3.41 136.141.230.45 TCP
kerberos > 37290 [ACK] Seq=2100 Ack=252 Win=65285 Len=0
13 0.465640 136.141.3.41 136.141.230.45 TCP
kerberos > 37290 [FIN, ACK] Seq=2100 Ack=252 Win=65285 Len=0
14 0.465659 136.141.230.45 136.141.3.41 TCP
37290 > kerberos [ACK] Seq=252 Ack=2101 Win=65535 Len=0
You might need to actually look inside the packets. And in fact,
Kerberos traffic is usually UDP (port 88), not TCP, although there are
methods to force TCP only traffic.
<<CDC
.
- References:
- kerberos AD: keytab and service principal not needed?
- From: rossdruker
- Re: kerberos AD: keytab and service principal not needed?
- From: Christopher D. Clausen
- Re: kerberos AD: keytab and service principal not needed?
- From: rossdruker
- Re: kerberos AD: keytab and service principal not needed?
- From: Christopher D. Clausen
- Re: kerberos AD: keytab and service principal not needed?
- From: rossdruker
- Re: kerberos AD: keytab and service principal not needed?
- From: Christopher D. Clausen
- kerberos AD: keytab and service principal not needed?
- Prev by Date: Re: AIX 5.3 authenticating against Former Sun One Directory server (Now Fedora)
- Next by Date: n00b question
- Previous by thread: Re: kerberos AD: keytab and service principal not needed?
- Next by thread: TPC 3.1.2
- Index(es):
Relevant Pages
|
