failed to create kerberos key: 5 (KRB5KDC_AP_ERR_MODIFIED)
Lara Adianto
m1r4cle_26 at yahoo.com
Mon Aug 2 04:32:06 EDT 2004
>Login is a lara at ADIANTO.COM which says use Kerberos
>if you just say lara it will use the local machine.
Yaa, of course I logged in as lara at ADIANTO.COM....
In the logon box, I chose the username as lara and the domain ADIANTO.COM not LOCAL MACHINE....
>NO! standard Kerberos does authentication. AD uses Kerberos
>for authentication, then adds in its authorization data,
>the "PAC", into the ticket.
>But there is a way to tell AD that it should add a PAC.
>You wold have to setup the user account in AD and tell it
>that it can accept external Kerberos authentication for
>the user. We don't use this, so you wil have to look around
>for the instrustions.
I have set that up before. Using name mapping in AD and registering lara at ADIANTO.COM as the kerberos name for lara. I also setup the cross-realm trust between windows AD and MIT KDC.
It worked before ! See belw for the tickets cached in the windows client, using klist.exe. In this scenario user lara logged in to MIT REALM ADIANTO.COM using a win2000 machine (testw2k8.adianto.com) then accesses resource in test_w2kserver which is a member of windows domain LARASARI.COM (as opposed to ADIANTO.COM which is a workgroup). This is possible with cross realm setup (hence lara is not asked for password anymore to access test_w2kserver).
Here are the tickets after the cross-realm negotiation:
Cached Tickets: (5)
Server: krbtgt/ADIANTO.COM at ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
Server: krbtgt/LARASARI.COM at ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
Server: krbtgt/ADIANTO.COM at ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
Server: TEST_W2KSERVER$@LARASARI.COM
KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
Server: host/testw2k8.adianto.com at ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
However, after reinstalling test_w2kserver and hence re-setup the domain controller in LARASARI.COM, it didn't work anymore. when lara contacts krbtgt/LARASARI.COM, it failed with KRB5KDC_AP_ERR_MODIFIED.
Requests to krbtgt/LARASARI.COM:
-----------------------------------------------------
Frame 92 (628 bytes on wire, 628 bytes captured)
Arrival Time: Aug 2, 2004 11:47:52.819555000
Time delta from previous packet: 0.000915000 seconds
Time since reference or first frame: 22.781995000 seconds
Frame Number: 92
Packet Length: 628 bytes
Capture Length: 628 bytes
Ethernet II, Src: 00:06:22:00:aa:37, Dst: 00:01:02:c8:42:01
Destination: 00:01:02:c8:42:01 (192.168.168.110)
Source: 00:06:22:00:aa:37 (192.168.168.105)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.168.105 (192.168.168.105), Dst Addr: 192.168.168.110 (192.168.168.110)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 614
Identification: 0x0669 (1641)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x5ff5 (correct)
Source: 192.168.168.105 (192.168.168.105)
Destination: 192.168.168.110 (192.168.168.110)
User Datagram Protocol, Src Port: 1104 (1104), Dst Port: kerberos (88)
Source port: 1104 (1104)
Destination port: kerberos (88)
Length: 594
Checksum: 0x9826 (correct)
Kerberos
Pvno: 5
MSG Type: TGS-REQ (12)
padata PA-TGS-REQ
Type: PA-TGS-REQ (1)
Value: 6E8201A6308201A2A003020105A10302...
Pvno: 5
MSG Type: AP-REQ (14)
Padding: 0
APOptions: 00000000
.0.. .... .... .... .... .... .... .... = Use Session Key: Do NOT use the session key to encrypt the ticket
..0. .... .... .... .... .... .... .... = Mutual required: Mutual authentication is NOT required
Ticket
Tkt-vno: 5
Realm: ADIANTO.COM
Server Name (Unknown): krbtgt LARASARI.COM
Name-type: Unknown (0)
Name: krbtgt
Name: LARASARI.COM
enc-part des-cbc-crc
Encryption type: des-cbc-crc (1)
Kvno: 1
enc-part: 0958DB85841224F4BCDAAEB1B020FA76...
Authenticator des-cbc-crc
Encryption type: des-cbc-crc (1)
Authenticator data: BC32419B702A6D1DBD6366F698C7598D...
KDC_REQ_BODY
Padding: 0
KDCOptions: 40810000 Forwardable Renewable
.1.. .... .... .... .... .... .... .... = Forwardable: FORWARDABLE tickets are allowed/requested
..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
.... .... 1... .... .... .... .... .... = Renewable: This ticket is RENEWABLE
.... .... ...0 .... .... .... .... .... = Opt HW Auth: False
.... .... .... .... .... .... ..0. .... = Disable Transited Check: Transited checking is NOT disabled
.... .... .... .... .... .... ...0 .... = Renewable OK: We do NOT 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
Realm: LARASARI.COM
Server Name (Service and Instance): cifs Testw2kserver
Name-type: Service and Instance (2)
Name: cifs
Name: Testw2kserver
till: 2037-09-13 02:48:05 (Z)
Nonce: 2100943361
Encryption Types rc4-hmac 0xffffff7b 0xffffff80 des-cbc-md5 des-cbc-crc rc4-hmac-exp 0xffffff79
Encryption type: rc4-hmac (23)
Encryption type: Unknown (65403)
Encryption type: Unknown (128)
Encryption type: des-cbc-md5 (3)
Encryption type: des-cbc-crc (1)
Encryption type: rc4-hmac-exp (24)
Encryption type: Unknown (65401)
REPLY from LARASARI.COM
--------------------------------------------
Frame 96 (138 bytes on wire, 138 bytes captured)
Arrival Time: Aug 2, 2004 11:47:52.822420000
Time delta from previous packet: 0.001100000 seconds
Time since reference or first frame: 22.784860000 seconds
Frame Number: 96
Packet Length: 138 bytes
Capture Length: 138 bytes
Ethernet II, Src: 00:01:02:c8:42:01, Dst: 00:06:22:00:aa:37
Destination: 00:06:22:00:aa:37 (192.168.168.105)
Source: 00:01:02:c8:42:01 (192.168.168.110)
Type: IP (0x0800)
Internet Protocol, Src Addr: 192.168.168.110 (192.168.168.110), Dst Addr: 192.168.168.105 (192.168.168.105)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 124
Identification: 0x08c2 (2242)
Flags: 0x00
0... = Reserved bit: Not set
.0.. = Don't fragment: Not set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 128
Protocol: UDP (0x11)
Header checksum: 0x5f86 (correct)
Source: 192.168.168.110 (192.168.168.110)
Destination: 192.168.168.105 (192.168.168.105)
User Datagram Protocol, Src Port: kerberos (88), Dst Port: 1104 (1104)
Source port: kerberos (88)
Destination port: 1104 (1104)
Length: 104
Checksum: 0xa625 (correct)
Kerberos
Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2004-08-02 03:47:10 (Z)
susec: 844582
error_code: KRB5KRB_AP_ERR_MODIFIED (41)
Realm: LARASARI.COM
Server Name (Service and Instance): krbtgt LARASARI.COM
Name-type: Service and Instance (2)
Name: krbtgt
Name: LARASARI.COM
thanks,
lara
"Douglas E. Engert" <deengert at anl.gov> wrote:
Lara Adianto wrote:
>
> --- "Douglas E. Engert" wrote:
>
> >
> >
> > Lara Adianto wrote:
> > >
> > > Hi,
> > >
> > > I have a strange problem with cross-realm
> > authentication.
> > > It's a windows 2000 machine authenticating to an
> > MIT KDC, then it accesses a computer in a windows
> > domain. This should be possible theoritically with
> > ksetup, and all the necessary steps described in the
> > step by step kerberos interoperability document.
> > >
> > > However, this is what happen in my environment:
> > > 1. The user is able to login into windows 2000
> > machine with his credential in MT KDC. The windows
> > 2000 is configured to be a member of workgroup.
> > However, when I examine the setting setup using
> > ksetup, this is what I got:
> > > ksetup:
> > > default realm = ADIANTO.COM (external)
> > > ADIANTO.COM:
> > > kdc = kerberos.adianto.com
> > > Failed to create Kerberos key: 5 (0x5)
> >
> > I don't see the Failed message on my machine which
> > is setup similiarly, but I do
> > have some Mappings of principals to local accounts.
> >
>
> I should have made it clearer.
> I did a name mappings with ksetup as well
> ksetup:
> default realm = ADIANTO.COM (external)
> ADIANTO.COM:
> kdc = kerberos.adianto.com
> Mapping lara at ADIANTO.COM to lara
>
> Besides the above info, I also added RealmFlags set to
> 8, LogLevel set to 1 in the registry.
>
> But, when I logged in as lara, and checked ksetup.
Login is a lara at ADIANTO.COM which says use Kerberos
if you just say lara it will use the local machine.
> It shows this:
> default realm = ADIANTO.COM (external)
> ADIANTO.COM:
> kdc = kerberos.adianto.com
> Failed to create Kerberos key: 5 (0x5)
>
> > > I'm not sure whether the last line is fatal.
> >
> > Since you where able to login, and you next note
> > show you got
> > a host/test.adianto.com at ADIANTO.COM ticket during
> > login,
> > the kerberos on the w2000 box looks good.
> >
> > >
> > > 2. When the user tried to access a computer in a
> > windows domain (should be possible due to the cross
> > realm setup), the following error occured:
> >
> > What do you mean "tried to access a computer in a
> > windows domain"?
> >
> > What applicaiton are you using?
>
> What I mean is opening the network neighborhood,
> opening a windows domain to access one of its
> computer.
> It should be a single sign-on right ?
NO! standard Kerberos does authentication. AD uses Kerberos
for authentication, then adds in its authorization data,
the "PAC", into the ticket.
But there is a way to tell AD that it should add a PAC.
You wold have to setup the user account in AD and tell it
that it can accept external Kerberos authentication for
the user. We don't use this, so you wil have to look around
for the instrustions.
In our enviroment we do just to opposite. The users are
in a AD domain, so if ther get tickets they have the PAC.
But they can get tickets for cross realm to a standard kerberos
realm that uas a number of unix servers. In this case the PAC
is just ignored.
> But instead, it
> prompts me with user logon and password !
> This is because the cross-realm auth failed with
> KRB_AP_ERR_MODIFIED (I checked it through ethereal)
>
> > > Event Type: Error
> > > Event Source: Kerberos
> > > Event Category: None
> > > Event ID: 594
> > > Date: 7/29/2004
> > > Time: 7:37:30 PM
> > > User: N/A
> > > Computer: TEST
> > > Description:
> > > A Kerberos Error Message was received:
> > > on logon session
> > InitializeSecurityContext
> > > Client Time:
> > > Server Time:
> > > Error Code: 11:36:30.0000 7/29/2004 (null) 0x29
> > > Extended Error: KRB_AP_ERR_MODIFIED
> > > Client Realm:
> > > Client Name:
> > > Server Realm: WINDOMAIN.COM
> > > Server Name: krbtgt/WINDOMAIN.COM
> > > Target Name: HOST/Win2kServer at WINDOMAIN.COM
> > > Error Text:
> > > File:
> > > Line:
> > > Error Data is in record data.
> >
> >
> > Doing a google search for KRB_AP_ERR_MODIFIED shows
> > this in one of the messages:
> >
> > The kerberos client received a KRB_AP_ERR_MODIFIED
> > error from the server
> > COMPANY$. This indicates that the password used
> > to encrypt the kerberos
> > service ticket is different than that on the
> > target server. Commonly,
> > this is due to identically named machine accounts
> > in the target realm
> > (COMPANY.NET), and the client realm. Please
> > contact your system
> > administrator.
>
> I know what the error code means :-)
> I did a search in google as well. But I dont' have
> identically named machine account...
>
> > This might also mean the cross realm keys don't
> > match, i.e. the user's realm
> > issued a tgt for the service realm, but the service
> > realm can not decrypt it.
> > Did you ever get any cross realm to work with the
> > user in the MIT realm, and the
> > service in the AD?
> > Did the UMich modification make any changes in this
> > area?
>
> This is more possible for me. I noticed (with
> ethereal) that the checksum is wrong. Not sure why
> though...
> No, I don't try Windows KDC and MIT client...
> In fact, I got my setup working before. User can login
> to windows machine using MIT credentials, then access
> resources in win domain and even does a password
> change ! But yesterday, it suddenly failed...:-(
> Not sure why...maybe bec I just reinstalled my the
> win2k server that serves as win KDC...
> maybe bec I modified the ksetup in win client...
> sigh...
>
> >
> > >
> > > Win2kServer is the computer that Test tried to
> > access, belonged to WINDOMAIN, which is a windows
> > domain.
> > >
> > > My guess is that the Failed to generate key caused
> > the KRB_AP_ERR_MODIFIED...
> > > but I can't confirm it...
> > > I'm not sure what caused it to fail to generate
> > the key...
> > >
> > > I've followed the steps in the step by step
> > kerberos interoperability document carefully...
> > >
> > > Any clue ?
> > >
> > > regards,
> > > lara
> > >
> > >
> >
> ------------------------------------------------------------------------------------
> > > La vie, voyez-vous, ca n'est jamais si bon ni si
> > mauvais qu'on croit
> > >
> > - Guy de Maupassant -
> > >
> >
> ------------------------------------------------------------------------------------
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > > http://mail.yahoo.com
> > > ________________________________________________
> > > Kerberos mailing list Kerberos at mit.edu
> > > https://mailman.mit.edu/mailman/listinfo/kerberos
> >
> > --
> >
> > Douglas E. Engert
> > Argonne National Laboratory
> > 9700 South Cass Avenue
> > Argonne, Illinois 60439
> > (630) 252-5444
> >
>
> =====
> ------------------------------------------------------------------------------------
> La vie, voyez-vous, ca n'est jamais si bon ni si mauvais qu'on croit
> - Guy de Maupassant -
> ------------------------------------------------------------------------------------
>
>
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
------------------------------------------------------------------------------------
La vie, voyez-vous, ca n'est jamais si bon ni si mauvais qu'on croit
- Guy de Maupassant -
------------------------------------------------------------------------------------
---------------------------------
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone..From raeburn at MIT.EDU Mon Aug 2 14:57:21 2004
Received: from biscayne-one-station.mit.edu (BISCAYNE-ONE-STATION.MIT.EDU
[18.7.7.80])
by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i72IvKl1020840
for <kerberos at PCH.mit.edu>; Mon, 2 Aug 2004 14:57:20 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU
[18.7.21.86])i72IvBWv015785; Mon, 2 Aug 2004 14:57:11 -0400 (EDT)
Received: from [12.105.246.232] (0127ahost232.starwoodbroadband.com
[12.105.246.232]) (authenticated bits=0)
(User authenticated as raeburn at ATHENA.MIT.EDU)i72Iv9Om020855
(version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT);
Mon, 2 Aug 2004 14:57:11 -0400 (EDT)
In-Reply-To: <200408012250.08652.dlucio at okay.com.mx>
References: <200408012250.08652.dlucio at okay.com.mx>
Mime-Version: 1.0 (Apple Message framework v618)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <C0DE76E2-E4B5-11D8-861D-000A95909EE2 at mit.edu>
Content-Transfer-Encoding: 7bit
From: Ken Raeburn <raeburn at MIT.EDU>
Date: Mon, 2 Aug 2004 11:57:08 -0700
To: Luis Daniel Lucio Quiroz <dlucio at okay.com.mx>
X-Mailer: Apple Mail (2.618)
cc: kerberos at mit.edu
cc: Ken Raeburn <raeburn at mit.edu>
Subject: Re: Kereros and Linux 2.6
X-BeenThere: kerberos at mit.edu
X-Mailman-Version: 2.1
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Help: <mailto:kerberos-request at mit.edu?subject=help>
List-Post: <mailto:kerberos at mit.edu>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=subscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request at mit.edu?subject=unsubscribe>
X-List-Received-Date: Mon, 02 Aug 2004 18:57:21 -0000
Ah, here we are... for some reason, this message had "may be forged" in
the Received: line added by your ISP (I think it's usually caused by
your system's "HELO" name not matching the DNS name found by looking up
your address), which is one of the things that triggers message
moderation on this mailing list, whereas your earlier message did not
have that header. Anyways...
On Aug 1, 2004, at 20:50, Luis Daniel Lucio Quiroz wrote:
> Helo,
>
> I new on kerberos and whilel I was setting it up I realize that
> kerberso 5
> does not support IPv6 when trying to bind port 88.
>
> ug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): setting up
> network...
> Aug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): skipping
> unrecognized local address family 17
> Aug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): skipping
> unrecognized local address family 17
Address family 17 is "packet family" according to the comments on my
Linux system. So this is nothing to worry about.
> Aug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): listening on
> fd 6:
> udp 192.168.3.1.88
> Aug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): listening on
> fd 7:
> udp 201.129.237.114.88
> Aug 02 00:57:22 tao.linuxchange.com krb5kdc[10409](info): listening on
> fd 8:
> udp 192.168.3.6.88
That part looks good...
> krb5kdc: No such device - Cannot bind server socket to port 88 address
> fe80::5054:5ff:fef3:34fe%253
This, I haven't seen before. "No such device" from bind() is a new one
on me. I'll have to look into it a little. The "Cannot bind server
socket" message is generated in only one place, where bind() fails on a
socket already created. Obviously your system supports IPv6 sockets.
What does "ifconfig" show? Is there anything weird going on, like the
IPv6 address is on an interface that is down at the time?
Ken
More information about the Kerberos
mailing list