Ticket History #4435: Vista x86 client cross-realm interop with MIT KDCs

[Note: The Feedback ID (bug ID) on Connect is 224492. The engineer
appears to be "yizeng" or "lzhu@microsoft.com" according to the Connect
messages. --Karl]

Hello MIT developers,

Microsoft has identified what they believe to be an interop issue
between the Vista x86 client and recent MIT KDCs when operating as part
of an AD-MIT cross-realm scenario. Our CAMPUS.BERKELEY.EDU AD realm
trusts our BERKELEY.EDU MIT realm and has worked fine for years with
WinXP hosts joined to the CAMPUS domain where users are defined as
@BERKELEY.EDU principals and mapped to shadow AD user accounts via
altSecurityIdentities. See Microsoft's analysis of the issue near the
end of the appended excerpt of the report I opened with the Vista Beta team.

--Karl

Karl Grose
UC Berkeley

=======
Feedback ID 224492 Blocking Issue No
Feedback Type Bug Access Restriction Public
Status Active Submission Language English
Opened Date 10/11/2006 11:25:47 PM
Opened By karlgrose

--------------------------------------------------------------------------------

Description Logons to a domain-joined computer where the user account
exists in an external MIT Kerberos realm fail.
...

Entered by Microsoft on 10/12/2006 at 2:52 PM
first, we just had a report that the build you have does not work well
with older MIT kDCs (older than 1.2xx I think),
can you try the latest fix in mit2.zip.txt?
...

Entered by karlgrose on 10/12/2006 at 6:34 PM
The newer kerberos.dll did not seem to make any difference. the kerb.etl
file has been uploaded to here.
--Karl
...
Entered by karlgrose on 10/13/2006 at 10:09 AM
OK, restored the original kerberos.dll and reran the tracelog command
using a newer version of tracelog. The file is uploaded here as "kerb1.etl".
My understanding is that our KDC is running MIT Kerberos v. 1.4.3 plus
the UMich patches.
...

Entered by Microsoft on 10/13/2006 at 11:43 AM
below is TEXT log decoded from the ETL. it seems that your client at
first sends no preauth (this is expected), then the KDC says preauth is
required, then the client sends the encrypted timestamp as preauth (the
encryption type used is des-cbc-crc), but then the KDC reply is
encrypted using des-cbc-md5.
based on your log, we actually replicated the exact protocol sequence,
but our clients worked fine.

at this point, we would need the sniff/traffic capture to compare the
difference in your setup and ours. thx.

Setting log file to: E:\temp\berkeley\kerb1.etl

Getting guids from E:\temp\berkeley\default.tmf

[0]0280.0E88::10/13/2006-09:56:23.963 [winnt5]LogonUser returned c000010b, 0

[1]0280.0E88::10/13/2006-09:56:23.969 [winnt5]LsaApLogonTerminated
called: 0x0:0x178344

[1]0280.0E88::10/13/2006-09:56:23.969 [winnt5]KerbCreateLogonSession
creating logon session for 0:0x178347

[1]0280.0E88::10/13/2006-09:56:23.970 [winnt5]INSERT logonsess 002CAB40
for 0:0x178347

[1]0280.0E88::10/13/2006-09:56:23.970
[winnt5]KerbGetAuthenticationTicket sending NO preauth

[0]0280.0E88::10/13/2006-09:56:24.191 [winnt5]Failed to unpack KDC reply
as AS: 0x3c

[0]0280.0E88::10/13/2006-09:56:24.191 [winnt5]KerbCallKdc failed: error
0x19, extendedStatus 0,
d:\rtm_edw\ds\security\protocols\kerberos\client2\logonapi.cxx, line 2428

[0]0280.0E88::10/13/2006-09:56:24.231 [winnt5]KerbFindCommonPaEtype
using current password of xxxxxxx@BERKELEY.EDU@(null)

[0]0280.0E88::10/13/2006-09:56:24.232
[winnt5]KerbGetAuthenticationTicket sending preauth enctype 1, length 8,
PrimaryCredentials->PublicKeyCreds 00000000

[0]0280.0E88::10/13/2006-09:56:24.257
[winnt5]KerbGetAuthenticationTicket rekeying 1 -> 3 (preauth not required)

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]Kdc returned reply with
encryption type we don't support: 3.
d:\rtm_edw\ds\security\protocols\kerberos\client2\logonapi.cxx, line 3042

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]KerbCacheLogonInformation
updating NLP Cache entry of (null)\xxxxxxx@BERKELEY.EDU, flags 0x21
disabling optimized logon...

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]KerbCacheLogonInformation
failed to cache credentials: 0x0, 0xc000006d.
d:\rtm_edw\ds\security\protocols\kerberos\client2\krbtoken.cxx, line 3259

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]LogonUser: Failed to get
TGT for (null)\xxxxxxx@BERKELEY.EDU : 0xc000006d

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]REMOVE logonsess 002CAB40
for 0:0x178347

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]LogonUser returned c000006d, 0

[0]0280.0E88::10/13/2006-09:56:24.270 [winnt5]FREE logonsess 002CAB40
for 0:0x178347

[1]0280.0E88::10/13/2006-09:56:50.068 [winnt5]LogonUser returned c000010b, 0

[1]0280.0E88::10/13/2006-09:56:50.121 [winnt5]LsaApLogonTerminated
called: 0x0:0x1787e7

[1]0280.0E88::10/13/2006-09:56:50.122 [winnt5]KerbCreateLogonSession
creating logon session for 0:0x1787eb

[1]0280.0E88::10/13/2006-09:56:50.122 [winnt5]INSERT logonsess 002CAB40
for 0:0x1787eb

[1]0280.0E88::10/13/2006-09:56:50.122 [winnt5]KerbFindCommonPaEtype
using current password of xxxxxxx@CAMPUS.BERKELEY.EDU@(null)

[1]0280.0E88::10/13/2006-09:56:50.122
[winnt5]KerbGetAuthenticationTicket sending preauth enctype 0, length 0,
PrimaryCredentials->PublicKeyCreds 00000000

[1]0280.0E88::10/13/2006-09:56:50.249 [winnt5]Failed to unpack KDC reply
as AS: 0x3c

[1]0280.0E88::10/13/2006-09:56:50.249 [winnt5]KerbCallKdc failed: error
0x19, extendedStatus 0,
d:\rtm_edw\ds\security\protocols\kerberos\client2\logonapi.cxx, line 2428

[1]0280.0E88::10/13/2006-09:56:50.301 [winnt5]KerbFindCommonPaEtype
using current password of xxxxxxx@CAMPUS.BERKELEY.EDU@(null)

[1]0280.0E88::10/13/2006-09:56:50.301
[winnt5]KerbGetAuthenticationTicket sending preauth enctype 23, length
16, PrimaryCredentials->PublicKeyCreds 00000000

[0]0280.0E88::10/13/2006-09:56:50.344 [winnt5]UserName different in
logon session & AS ticket: xxxxxxx@CAMPUS.BERKELEY.EDU vs xxxxxxx

[0]0280.0E88::10/13/2006-09:56:50.344 [winnt5]Domain name is different
in logon session & as ticket: (null) vs CAMPUS.BERKELEY.EDU

[0]0280.0E88::10/13/2006-09:56:50.359 [winnt5]KerbCacheLogonInformation
updating NLP Cache entry of (null)\xxxxxxx@CAMPUS.BERKELEY.EDU, flags 0
<NULL>...

[0]0280.0E88::10/13/2006-09:56:50.403 [winnt5]KerbCreateLogonSession
creating logon session for 0:0x17882c

[0]0280.0E88::10/13/2006-09:56:50.403 [winnt5]INSERT logonsess 002CA9F8
for 0:0x17882c

[1]0280.02E0::10/13/2006-09:56:51.137 [winnt5]KerbFindCommonPaEtype
using current password of xxxxxxx@CAMPUS.BERKELEY.EDU

[1]0280.02E0::10/13/2006-09:56:51.137
[winnt5]KerbGetAuthenticationTicket sending preauth enctype 0, length 0,
PrimaryCredentials->PublicKeyCreds 00000000

[0]0280.02E0::10/13/2006-09:56:51.142 [winnt5]Failed to unpack KDC reply
as AS: 0x3c

[0]0280.02E0::10/13/2006-09:56:51.142 [winnt5]KerbCallKdc failed: error
0x19, extendedStatus 0,
d:\rtm_edw\ds\security\protocols\kerberos\client2\logonapi.cxx, line 2428

[0]0280.02E0::10/13/2006-09:56:51.172 [winnt5]KerbFindCommonPaEtype
using current password of xxxxxxx@CAMPUS.BERKELEY.EDU

[0]0280.02E0::10/13/2006-09:56:51.172
[winnt5]KerbGetAuthenticationTicket sending preauth enctype 23, length
16, PrimaryCredentials->PublicKeyCreds 00000000

[0]0280.02E0::10/13/2006-09:56:51.215 [winnt5]KerbBuildGssChecksum asked
for delegation, but not granted

Event traces dumped to FmtFile.txt

Event Summary dumped to FmtSum.txt

Exit Status: 38


Entered by karlgrose on 10/13/2006 at 12:17 PM
I used Network Monitor on the host to capture traffic from the KDC
to/from the NATed VMware Vista x86 client. This is uploaded here as
"kerberos.cap". The registry settings active are in the BERKELEY.EDU.reg
file previously send with the original report.
--Karl
...
Entered by Microsoft on 10/13/2006 at 2:41 PM
excellent, with the sniff you provided, we have identified this issue:
in frame 4 of sniff, the kdc reply contains a preauth data of type
etype-info2, but the encryption type does not match with the encryption
type of the enc-part in the AS-REP.

this is incorrect according to RFC4120. On page 63, section 5.2.7.5 of
RFC4120, it says:
If ETYPE-INFO2 is sent in an AS-REP, there shall be exactly one
ETYPE-INFO2-ENTRY, and its etype shall match that of the enc-part in
the AS-REP.

Because MIT KDCs do not behave according to the above TEXT of RFC4120,
vista clients bail out.

The question then is why WinXP works with MIT KDCs. this is because
according RFc4120, ETYPE-info2 is sent by the KDC only when the AS
request etype list contains at least one "newer" enctype. As such, the
incorrect etype-info2 is only sent to vista clients because vista has
AES enctypes in the AS request etype list, winXP does not have any newer
entype in the request etype list.

Please report this issue to MIT Kerberos team, we would also like to
request this issue to MIT Kerberos dev in parallel, but we would need
your permission to release the netmon sniffs to MIT kerberos devs to
help them identify the issues.

The workaround is to configure the MIT principal to prefer des-cbc-md5,
right now the MIT KDC is sending des-cbc-crc first.


Entered by karlgrose on 10/13/2006 at 3:12 PM
I will send a report to the MIT Kerberos team and hereby give you
permission to release any information I've provided on this case
including the network capture info uploaded here.
Thanks,

--Karl

Karl Grose
UC Berkeley


How often does this happen?
always happens

Have you seen this problem before in this product?
I don't know if this issue existed previously.

Reproduction Steps
Create a cross-realm trust between an AD realm
(CAMPUS.BERKELEY.EDU) and an external MIT Kerberos realm (BERKELEY.EDU).
Define altSecurityIdentities mapping the external principals to local AD
accounts. Create GPOs to create the registry entries in newly joined
computers to define the external realm for the local computer. All of
this works in production for years with XP clients. Join a Vista host to
the CAMPUS.BERKELEY.EDU domain and attempt to logon as either
"user@BERKELEY.EDU" or "BERKELEY.EDU\user" and receive the wrong
username or password error. Logons to "user@CAMPUS.BERKELEY.EDU" or
CAMPUS\user" work as expected.

Expected Results

Logons using the BERKELEY.EDU principals succeed as for
CAMPUS.BERKELEY.EDU principals.


Language ID
9
What product are you filling this report on?
Longhorn
This install?
is not an upgrade (a clean install)
Area
Security
Sub-area
Winlogon
Build
5744.16384
Platform
Microsoft(R) Windows(R) Vista Ultimate
Processor Architecture
x86 Family 15 Model 2 Stepping 8, GenuineIntel
...
=======

The user principal contains the following keys:

Key: vno 11, DES cbc mode with CRC-32, no salt
Key: vno 11, DES cbc mode with RSA-MD5, Version 4
Key: vno 11, DES cbc mode with RSA-MD5, Version 5 - No Realm
Key: vno 11, DES cbc mode with RSA-MD5, Version 5 - Realm Only
Key: vno 11, DES cbc mode with RSA-MD5, AFS version 3

On 10/25/06, Sam Hartman via RT <rt-comment@krbdev.mit.edu> wrote:

AFAIK, the des-cbc-md5 change was never part of the replication or
referral patches, but I'm not 100% it was never included somewhere
back in time. I was wondering if this problem might somehow be
related to residue from starting with an earlier version and
upgrading.

K.C.

[kwc@citi.umich.edu - Wed Oct 25 11:04:59 2006]:

KDC

I should clarify that at UC Berkeley we're running 1.4.2. Is it
possible that a change made between 1.4.2 and 1.4.3 could be involved?

Mike Friedman
mikef@ack.berkeley.edu

Hi.

I just looked at the changes between 1.4.2 and 1.4.3. The Vista
Interop problem you are seeing is fixed in MIT Kerberos 1.4.3.


I suggest upgrading or applying the patches in MIT RT tickets 3207 and
3205.

mikef@ack> Sam,

mikef@ack> I see a patch in ticket #3205:

mikef@ack> ===========================================================================
mikef@ack> In kdc_preauth.c:return_etype_info2()

mikef@ack> + /* using encrypting_key->enctype as this is
mikef@ack> specified in rfc4120 */ retval =
mikef@ack> _make_etype_info_entry(context, request, - client_key,
mikef@ack> client_key->key_data_type[0], + client_key,
mikef@ack> encrypting_key->enctype,
mikef@ack> ===========================================================================

mikef@ack> But I don't see any patch code in #3207. Is there just
mikef@ack> one patch?

No, it points to a Subversion revision in our repository. The patch
is not directly included.