Re: kerberos AD: keytab and service principal not needed?

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?

Sort of a long story. Short version: The AD computer account was
accidentally deleted by someone after it and the keytab were created.
Then I noticed logging in to that AIX host still worked. So I moved
the keytab file out of /etc/krb5, and noticed it still continued to
work, which led me to post here.

I have asked one of the Windows admins here to see if he can get me
the logs.

Here's what he sent me, in two versions. He said this was the only
entry. I'm not sure if it helps (replaced my actual logon id)

Authentication Ticket Request:
User Name: mylogonid
Supplied Realm Name: ROHMHAAS.NET
User ID: NAR\mylogonid
Service Name: krbtgt
Service ID: NAR\krbtgt
Ticket Options: 0x10
Result Code: -
Ticket Encryption Type: 0x17
Pre-Authentication Type: 2
Client Address: 136.141.230.45
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:

672,AUDIT SUCCESS,Security,Wed Aug 30 09:08:26 2006,NT
AUTHORITY\SYSTEM, mylogonid ROHMHAAS.NET
%{S-1-5-21-2059484695-1622420474-1353397897-5558} krbtgt
%{S-1-5-21-2059484695-1622420474-1353397897-502} 0x10 - 0x17 2
136.141.230.45

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.

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.

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.

I've been looking at the Wireshark packets and it appears that AIX is
frist trying with UDP, failing, then re-attempting with TCP
successfully. You can see the switchover. The first four packets go
out via UDP, the remaining conversation is via TCP.

No. Time Source Destination
Protocol Info
1 0.000000 136.141.252.48 136.141.171.73 KRB5
AS-REQ

User Datagram Protocol, Src Port: 44207 (44207), Dst Port: kerberos
(88)
Kerberos AS-REQ

No. Time Source Destination
Protocol Info
2 0.002258 136.141.171.73 136.141.252.48 KRB5
KRB Error: KRB5KDC_ERR_PREAUTH_REQUIRED

User Datagram Protocol, Src Port: kerberos (88), Dst Port: 44207
(44207)
Kerberos KRB-ERROR

No. Time Source Destination
Protocol Info
3 0.068771 136.141.252.48 136.141.228.74 KRB5
AS-REQ

User Datagram Protocol, Src Port: 44212 (44212), Dst Port: kerberos
(88)
Kerberos AS-REQ

No. Time Source Destination
Protocol Info
4 0.073837 136.141.228.74 136.141.252.48 KRB5
KRB Error: KRB5KRB_ERR_RESPONSE_TOO_BIG

User Datagram Protocol, Src Port: kerberos (88), Dst Port: 44212
(44212)
Kerberos KRB-ERROR

No. Time Source Destination
Protocol Info
5 0.085501 136.141.252.48 136.141.171.73 TCP
50314 > kerberos [SYN] Seq=0 Len=0 MSS=1460

Transmission Control Protocol, Src Port: 50314 (50314), Dst Port:
kerberos (88), Seq: 0, Len: 0

No. Time Source Destination
Protocol Info
6 0.085728 136.141.171.73 136.141.252.48 TCP
kerberos > 50314 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460

Transmission Control Protocol, Src Port: kerberos (88), Dst Port: 50314
(50314), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination
Protocol Info
7 0.085896 136.141.252.48 136.141.171.73 TCP
50314 > kerberos [ACK] Seq=1 Ack=1 Win=17520 Len=0

Transmission Control Protocol, Src Port: 50314 (50314), Dst Port:
kerberos (88), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination
Protocol Info
8 0.086489 136.141.252.48 136.141.171.73 KRB5
AS-REQ

Transmission Control Protocol, Src Port: 50314 (50314), Dst Port:
kerberos (88), Seq: 1, Ack: 1, Len: 251
Kerberos AS-REQ

No. Time Source Destination
Protocol Info
9 0.090023 136.141.171.73 136.141.252.48 TCP
[TCP segment of a reassembled PDU]

Transmission Control Protocol, Src Port: kerberos (88), Dst Port: 50314
(50314), Seq: 1, Ack: 252, Len: 1460

No. Time Source Destination
Protocol Info
10 0.090158 136.141.171.73 136.141.252.48 KRB5
AS-REP

Transmission Control Protocol, Src Port: kerberos (88), Dst Port: 50314
(50314), Seq: 1461, Ack: 252, Len: 490
[Reassembled TCP Segments (1950 bytes): #9(1460), #10(490)]
Kerberos AS-REP

I don't know if it helps, but here are the packet details for the
AS-REQ packet. The AS-REP has similar details (no KDCOptions, though).

KDC_REQ_BODY
Padding: 0
KDCOptions: 00000010 (Renewable OK)
.0.. .... .... .... .... .... .... .... = Forwardable: Do
NOT use forwardable tickets
..0. .... .... .... .... .... .... .... = Forwarded: This
is NOT a forwarded ticket
...0 .... .... .... .... .... .... .... = Proxyable: Do NOT
use proxiable tickets
.... 0... .... .... .... .... .... .... = Proxy: This
ticket has NOT been proxied
.... .0.. .... .... .... .... .... .... = Allow Postdate:
We do NOT allow the ticket to be postdated
.... ..0. .... .... .... .... .... .... = Postdated: This
ticket is NOT postdated
.... .... 0... .... .... .... .... .... = Renewable: This
ticket is NOT renewable
.... .... ...0 .... .... .... .... .... = Opt HW Auth:
False
.... .... .... ..0. .... .... .... .... = Constrained
Delegation: This is a normal request (no constrained delegation)
.... .... .... ...0 .... .... .... .... = Canonicalize:
This is NOT a canonicalized ticket request
.... .... .... .... .... .... ..0. .... = Disable Transited
Check: Transited checking is NOT disabled
.... .... .... .... .... .... ...1 .... = Renewable OK: We
accept RENEWED tickets
.... .... .... .... .... .... .... 0... = Enc-Tkt-in-Skey:
Do NOT encrypt the tkt inside the skey
.... .... .... .... .... .... .... ..0. = Renew: This is
NOT a request to renew a ticket
.... .... .... .... .... .... .... ...0 = Validate: This is
NOT a request to validate a postdated ticket
Client Name (Principal): mylogonid
Name-type: Principal (1)
Name: mdyadsi
Realm: ROHMHAAS.NET
Server Name (Unknown): krbtgt/ROHMHAAS.NET
Name-type: Unknown (0)
Name: krbtgt
Name: ROHMHAAS.NET
from: 2006-08-30 17:56:05 (Z)
till: 2006-08-31 17:56:05 (Z)
Nonce: 1156960565
Encryption Types: des3-cbc-sha1 rc4-hmac
aes256-cts-hmac-sha1-96 des-cbc-md5 des-cbc-crc
Encryption type: des3-cbc-sha1 (16)
Encryption type: rc4-hmac (23)
Encryption type: aes256-cts-hmac-sha1-96 (18)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-crc (1)



Christopher D. Clausen wrote:
I do know that if you are using GSSAPI authentication with SSH and
you remove the keytab that GSSAPI no longer works.

The /etc/ssh/sshd_config file on the target host is set like this:
GSSAPIAuthentication yes

Are you acutally using GSSAPI to login though?

I don't know the answer nor how to find out. I simply followed the AIX
instructions for the config file with regard to setting up ssh with
kerberos


If properly configured
you should NOT be prompted from a password and you should have a
host/fqdn.aix.machine in the klist output on the client that you used to
SSH in from.

If we use ssh keys and an authorized_keys file on the target host, then
there is no password prompt. If we don't use keys or hide the key file
(as I've done to test the AD password login), then we do get prompted.


Ross

.

Relevant Pages

  • Re: How to setup trust between 2003 SP1/R2 and MIT 1.4.3 ?
    ... Protocol: IP ... User Datagram Protocol, Src Port: 32885, Dst Port: kerberos ... NOT allow the ticket to be postdated ... Encryption type: des3-cbc-sha1 ...
    (comp.protocols.kerberos)
  • Re: How to setup trust between 2003 SP1/R2 and MIT 1.4.3 ?
    ... opensuse.suse.home (no port 88 traffic) ... Protocol: IP ... NOT allow the ticket to be postdated ... Encryption type: des3-cbc-sha1 ...
    (comp.protocols.kerberos)
  • Re: Cannot telnet some ports
    ... Some with remote administration feature I believe. ... >> From a Windows 2003 Server SP2 ... >> fromn the 2k3 serrver but can telnet into any other port. ... kerberos 750/udp kdc # Kerberos udp ...
    (microsoft.public.windows.server.general)
  • RE: Remote Assistance
    ... Best to use Notepad. ... you will probably have to have his router point that port to his ... IP" address of your relative's computer in your ticket. ... Norton Internet Protection software. ...
    (microsoft.public.windowsxp.help_and_support)
  • RE: Remote Assistance
    ... You may introduce formatting ... Best to use Notepad. ... you will probably have to have his router point that port to his ... IP" address of your relative's computer in your ticket. ...
    (microsoft.public.windowsxp.help_and_support)