failed to create kerberos key: 5
Lara Adianto
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'm not sure whether the last line is fatal.
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:
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/Win2k...@WINDOMAIN.COM
Error Text:
File:
Line:
Error Data is in record data.
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 Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
Lara Adianto
- I used UMICH patch for cross realm auth, I can see from the log file that the cross-realm ticket is issued by MIT Realm
- The krbtgt/adian...@windomain.com and krbtgt/windom...@adianto.com key is des-cbc-crc32
- the TGT in win client:
Cached TGT:
ServiceName: krbtgt
TargetName: krbtgt
FullServiceName: lara
DomainName: ADIANTO.COM
TargetDomainName: ADIANTO.COM
AltTargetDomainName: ADIANTO.COM
TicketFlags: 0x40c00000
KeyExpirationTime: 1/1/1601 8:00:00
StartTime: 7/29/2004 19:32:15
EndTime: 7/30/2004 19:32:15
RenewUntil: 7/29/2004 19:32:15
TimeSkew: 1/1/1601 8:00:00
- the tickets:
Cached Tickets: (2)
Server: krbtgt/ADIAN...@ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-MD5
End Time: 7/30/2004 19:32:15
Renew Time: 7/29/2004 19:32:15
Server: host/test.adi...@ADIANTO.COM
KerbTicket Encryption Type: Kerberos DES-CBC-MD5
End Time: 7/30/2004 19:32:15
Renew Time: 7/29/2004 19:32:15
regards,
lara
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Douglas E. Engert
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'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.adi...@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?
> 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/Win2k...@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.
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?
>
> 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 Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Lara Adianto
>
>
> 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 la...@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.
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.adi...@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 ? 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)
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...
=====
------------------------------------------------------------------------------------
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
Login is a la...@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.adi...@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.
Lara Adianto
Windows 2000 joining a workgroup: ADIANTO.COM (which is an MIT Realm)...
It can single sign on to access resources in windows domain
Anyway, as you suggested, I've tried using XP as client. No "failed to create kerberos key: 5" message this time, but it's still unable to access resources in windows domain with the same error code: KRB5KRB_AP_ERR_MODIFIED. Something wrong with the key or encryption type maybe...
I included the packets captured by ethereal (TGS_REQ to windows KDC and the reply which is a KRB_ERR with error code: KRB5KRB_AP_ERR_MODIFIED):
---- TGS REQ ----
Frame 63 (637 bytes on wire, 637 bytes captured) Arrival Time: Jul 30, 2004 13:36:06.423544000
Time delta from previous packet: 0.015687000 seconds
Time since reference or first frame: 24.654556000 seconds
Frame Number: 63
Packet Length: 637 bytes
Capture Length: 637 bytes
Ethernet II, Src: 00:06:22:00:aa:37, Dst: 00:01:02:c8:42:01
Destination: 00:01:02:c8:42:01 (3com_c8:42:01)
Source: 00:06:22:00:aa:37 (ChungFuC_00:aa:37)
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: 623
Identification: 0x096b (2411)
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: 0x5cea (correct)
Source: 192.168.168.105 (192.168.168.105)
Destination: 192.168.168.110 (192.168.168.110)
User Datagram Protocol, Src Port: 1200 (1200), Dst Port: kerberos (88)
Source port: 1200 (1200)
Destination port: kerberos (88)
Length: 603
Checksum: 0xb03f (correct)
Kerberos
Pvno: 5
MSG Type: TGS-REQ (12)
padata PA-TGS-REQ
Type: PA-TGS-REQ (1)
Value: 6E8201AF308201ABA003020105A10302...
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 WINDOMAIN.COM
Name-type: Unknown (0)
Name: krbtgt
Name: WINDOMAIN.COM
enc-part des-cbc-md5
Encryption type: des-cbc-md5 (3)
Kvno: 1
enc-part: E28434D900C5457FBB8801551BD43818...
Authenticator des-cbc-crc
Encryption type: des-cbc-crc (1)
Authenticator data:
37996424C41754A991A2213E98D9E785...
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: WINDOMAIN.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: 505654961
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)
---- KRB-ERR ----
Frame 64 (138 bytes on wire, 138 bytes captured)
Arrival Time: Jul 30, 2004 13:36:06.425367000
Time delta from previous packet: 0.001823000 seconds
Time since reference or first frame: 24.656379000 seconds
Frame Number: 64
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 (ChungFuC_00:aa:37)
Source: 00:01:02:c8:42:01 (3com_c8:42:01)
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: 0x2716 (10006)
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: 0x0000 (incorrect, should be 0x4132)
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: 1200 (1200)
Source port: kerberos (88)
Destination port: 1200 (1200)
Length: 104
Checksum: 0xf570 (correct)
Kerberos
Pvno: 5
MSG Type: KRB-ERROR (30)
stime: 2004-07-30 05:36:06 (Z)
susec: 365182
error_code: KRB5KRB_AP_ERR_MODIFIED (41)
Realm: WINDOMAIN.COM
Server Name (Service and Instance): krbtgt WINDOMAIN.COM
Name-type: Service and Instance (2)
Name: krbtgt
Name: WINDOMAIN.COM
Thanks,
lara
"Paul B. Hill" <p...@MIT.EDU> wrote:
A Windows 2000 machine in a workgroup will not do what you are attempting.
An XP machine in a workgroup will, assuming that the MIT KDC is running the
referrals patch available from UMich.
-----Original Message-----
From: kerberos...@MIT.EDU [mailto:kerberos...@MIT.EDU] On Behalf
Of Lara Adianto
Sent: Thursday, July 29, 2004 9:54 PM
To: Douglas E. Engert
Cc: kerb...@mit.edu
Subject: Re: failed to create kerberos key: 5
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.adi...@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 ? But instead, it
> 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
________________________________________________
Kerberos mailing list Kerb...@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
------------------------------------------------------------------------------------
La vie, voyez-vous, ca n'est jamais si bon ni si mauvais qu'on croit
- Guy de Maupassant -
------------------------------------------------------------------------------------
---------------------------------
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
Lara Adianto
>if you just say lara it will use the local machine.
Yaa, of course I logged in as la...@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 la...@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/ADIAN...@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/LARASA...@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/ADIAN...@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.a...@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" <deen...@anl.gov> wrote:
Lara Adianto wrote:
> > 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.
Douglas E. Engert
Lara Adianto wrote:
>
> I have set that up before. Using name mapping in AD and registering la...@ADIANTO.COM as the kerberos name for lara. I also setup the cross-realm trust between windows AD and MIT KDC.
>
> It worked before !
If it worked before, and you setup your domain controller again, and does not work now,
it sounds like the cross realm keys don't match.
There are really two principals and keys, one for each direction. krbtgt/<realm1>@<realm2>
and krbtgt/<realm2>@<realm1>
The KDCs of each realm have to have the key. The user's realm, <realm1>, uses the key just
like any other key, to issue a ticket for the service, i.e. krbtgt/<realm2>@<realm1>
The other KDC uses its copy like a server would use a key in a keytab, but it looks in
its database instead, (which is what it does for its own krbtgt).
So you need to make sure you have the keys kvnos and enctypes in sync between the two
realms. I suspect that you need to add the keys again to the Kerberos realm. You may
have to delete the krbtgt/<realm1>@<realm2> and krbtgt/<realm2>@<realm1> principals
and then add again.
> 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).
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444