>Login is a [EMAIL PROTECTED] which says use Kerberos
>if you just say lara it will use the local machine.
Yaa, of course I logged in as [EMAIL PROTECTED]
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 [EMAIL PROTECTED]
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/[EMAIL PROTECTED]
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/[EMAIL PROTECTED]
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/[EMAIL PROTECTED]
KerbTicket Encryption Type: Kerberos DES-CBC-CRC
End Time: 6/1/2004 7:07:00
Renew Time: 6/7/2004 21:07:00
Server: [EMAIL PROTECTED]
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/[EMAIL PROTECTED]
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" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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/[EMAIL PROTECTED] 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/[EMAIL PROTECTED]
> > > 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 [EMAIL PROTECTED]
> > > 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.
________________________________________________
Kerberos mailing list [EMAIL PROTECTED]
https://mailman.mit.edu/mailman/listinfo/kerberos
