failed to create kerberos key: 5

Lara Adianto m1r4cle_26 at yahoo.com
Fri Jul 30 02:33:39 EDT 2004


But I had it working before !
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" <pbh at 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-bounces at MIT.EDU [mailto:kerberos-bounces at MIT.EDU] On Behalf
Of Lara Adianto
Sent: Thursday, July 29, 2004 9:54 PM
To: Douglas E. Engert
Cc: kerberos at mit.edu
Subject: Re: failed to create kerberos key: 5

--- "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.
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 ? 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
________________________________________________
Kerberos mailing list Kerberos at 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!!From greg at server1.hurderos.com Fri Jul 30 16:10:20 2004
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU
	[18.7.21.83])
	by pch.mit.edu (8.12.8p2/8.12.8) with ESMTP id i6UKAIl1005307
	for <kerberos at PCH.mit.edu>; Fri, 30 Jul 2004 16:10:20 -0400 (EDT)
Received: from server1.hurderos.com ([216.239.30.246])i6UKA9uq001463
	for <kerberos at mit.edu>; Fri, 30 Jul 2004 16:10:15 -0400 (EDT)
Received: from server1.hurderos.com (localhost [127.0.0.1])
	by server1.hurderos.com (8.12.11/8.12.11) with ESMTP id i6UKA6Lr019021
	for <kerberos at mit.edu>; Fri, 30 Jul 2004 15:10:06 -0500
Received: (from greg at localhost)
	by server1.hurderos.com (8.12.11/8.12.11/Submit) id i6UKA6qb019020
	for kerberos at mit.edu; Fri, 30 Jul 2004 15:10:06 -0500
Message-Id: <200407302010.i6UKA6qb019020 at server1.hurderos.com>
From: g.w at hurderos.org
Date: Fri, 30 Jul 2004 15:10:06 -0500
X-Mailer: Mail User's Shell (7.2.5 10/14/92)
To: kerberos at mit.edu
Subject: Hurderos 0.1.1 released.
X-BeenThere: kerberos at mit.edu
X-Mailman-Version: 2.1
Precedence: list
Reply-To: g.w at hurderos.org
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: Fri, 30 Jul 2004 20:10:23 -0000

Good afternoon to everyone, I hope the end of the week is going well.

Hurderos 0.1.1 a GPL/OSS identity and services authorization
management solution was released on Friday, July 30th.  Source and
patches are at the following location:

        ftp://ftp.hurderos.org/pub/Hurderos/src

With this release binary distributions in RPM and tar format are
available as well at the following location:

        ftp://ftp.hurderos.org/pub/Hurderos/binaries

There have been a series of updates to the web-site as well.  Of most
interest may be screenshots of the graphical user interface.  This can
be found at:

        http://www.hurderos.org

The most significant changes have been to the build and install
process.  The most notable change being with respect to the Kerberos
internal headers needed by the service provisioning plug-in.

Sam and the boys at MIT are cogitating on the best way to deal with
this problem.  Until that solution comes forth we have implemented an
abstraction tool which will grovel through a compiled MIT source
distribution and abstract the necessary headers into the Hurderos
source tree.

This has been integrated into the build process so the only
requirement is to plop a 1.2.8 MIT source distribution alongside the
Hurderos source distribution and type ./configure and make in the
Kerberos source tree.  Followed by make in the Hurderos tree of
course.

The goal of the Hurderos Project is to provide a GPL'ed identity
management, SSO and service provisioning solution which is a superset
of the functionality provided by products such as Active Directory and
NDS.  It features a novel authorization scheme predicated on the
genetic identity generation model which Hurderos is based.

Please contact us if you are interested in being added to the
low-volume 'Friends of Hurderos' announcement list.

I'm off to the lake, best wishes to everyone else for an equally
enjoyable weekend.

As always,
GW
------------------------------------------------------------------------------
                         The Hurderos Project
         Open Identity, Service and Authorization Management
                       http://www.hurderos.org


More information about the Kerberos mailing list