[22225] in Kerberos
windows 2000 and 2003 compatibility issue on MIT Kerberos
daemon@ATHENA.MIT.EDU (peter_yen@trendmicro.com)
Wed Aug 18 15:32:55 2004
content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 16 Aug 2004 15:49:21 -0700
Message-ID: <24340ABC3CDA1743BA3E3247CB2B18A850766C@usexmail02.us.trendnet.org>
From: <peter_yen@trendmicro.com>
To: <kerberos@mit.edu>
Content-Type: text/plain;
charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
-----Original Message-----
From: Jeffrey Altman [mailto:jaltman@mit.edu]
Sent: Monday, August 16, 2004 3:44 PM
To: Peter Yen (RD-US)
Subject: Re: export private interface "krb5_set_default_tgs_ktypes" defined in krb5.h
Send this report to kerberos@mit.edu
Windows 2003 is doing the right thing. Your client and server must support RC4-HMAC or
you need to mark the server principal to be DES only.
peter_yen@trendmicro.com wrote:
Hi Jeff,
Sorry for my late response. Here I provide two configurations for windows 2000 and windows 2003 respectively. The windows 2000 case works fine but 2003 failed with
"Server not found in Kerberos Database". And I also noticed that the TGT ticket returned from windows 2003 server using "DES cbc mode with CRC-
32, ArcFour with HMAC/md5" which is not specified on client's configuration enctypes list. My packet trace of Windows 2003 gives me the following stream trace.
Am I missing something here? seems like I have to add a keytab both on server and clietn sides? I'd appreciate your great help a lot. Thanks for taking your time.
Peter
+++++++++++++++++++++++++++++
Packet Trace for Windows 2003 Failure
+++++++++++++++++++++++++++++
Client: a LDAP client wanting to use Kerberos to authentication itself to windows 2003 AD
Server:a Active Directory(LDAP) server with Kerberos daemon running
C -----> S :KRB5 AS-REQ
S -----> C :KRB5 KDC_ERR_PREAUTH_REQUIRED
C -----> S :KRB5 AS-REQ
S ------> C :KRB5 REP
C ------> S :KRB5 TGS-REQ
S ------->C : KRB5 KDC_ERR_PRINCIPAL_UNKNOWN [ERROR]
+++++++++++++++++++++++++
Windows 2000 Klist
+++++++++++++++++++++++++
Ticket cache: API:krb5cc
Default principal: ADMINISTRATOR@IWSSAD.TRENDMICRO.COM
Valid starting Expires Service principal
08/16/04 15:15:53 08/17/04 01:16:29 krbtgt/IWSSAD.TRENDMICRO.COM@IWSSAD.TRENDM
ICRO.COM
renew until 08/17/04 15:15:53, Etype (skey, tkt): DES cbc mode with CRC-
32, DES cbc mode with CRC-32
08/16/04 15:16:29 08/17/04 01:16:29 ldap/US-IWSS-PROXY.IWSSAD.TRENDMICRO.COM@I
WSSAD.TRENDMICRO.COM
renew until 08/17/04 15:15:53, Etype (skey, tkt): DES cbc mode with CRC-
32, DES cbc mode with CRC-32
Kerberos 4 ticket cache: API:krb4cc
klist: No ticket file (tf_util)1
-----------------------------------------------------
krb5.conf
-----------------------------------------------------
[libdefaults]
ticket_lifetime = 900
default_realm = IWSSAD.TRENDMICRO.COM
default_tgs_enctypes = DES-CBC-CRC
default_tkt_enctypes = DES-CBC-CRC
default_etypes = DES-CBC-CRC
default_etypes_des = DES-CBC-CRC
clockskew = 300
[realms]
IWSSAD.TRENDMICRO.COM = {
kdc = US-IWSS-PROXY.IWSSAD.TRENDMICRO.COM:88
admin_server = US-IWSS-PROXY.IWSSAD.TRENDMICRO.COM
default_domain = trendmicro.com
}
[domain_realm]
..trendmicro.com = IWSSAD.TRENDMICRO.COM
trendmicro.com = IWSSAD.TRENDMICRO.COM
+++++++++++++++++++++++++++
Windows 2003 Klist
+++++++++++++++++++++++++++
Ticket cache: API:krb5cc
Default principal: ADMINISTRATOR@INCOMING.COM
Valid starting Expires Service principal
08/16/04 15:09:55 08/17/04 01:09:29 krbtgt/INCOMING.COM@INCOMING.COM
renew until 08/17/04 15:09:55, Etype (skey, tkt): DES cbc mode with CRC-
32, ArcFour with HMAC/md5
Kerberos 4 ticket cache: API:krb4cc
klist: No ticket file (tf_util)
Errors:
service_name: <mailto:ldap/US-ANDSON-W2K3.QALAB.US.TRENDNET.ORG@INCOMING.CO> ldap/US-ANDSON-W2K3.QALAB.US.TRENDNET.ORG@INCOMING.CO
GSS-API error initializing context: Server not found in Kerberos database
--------------------------------------------------------
krb5.conf
--------------------------------------------------------
[libdefaults]
ticket_lifetime = 900
default_realm = INCOMING.COM
default_tgs_enctypes = DES-CBC-CRC
default_tkt_enctypes = DES-CBC-CRC
clockskew = 1000
[realms]
INCOMING.COM = {
kdc = us-andson-w2k3.qalab.us.trendnet.org:88
admin_server = us-andson-w2k3.qalab.us.trendnet.org
default_domain = incoming.com
}
[domain_realm]
..incoming.com = INCOMING.COM
incoming.com = INCOMING.COM
-----Original Message-----
From: Jeffrey Altman [ mailto:jaltman@mit.edu]
Sent: Monday, August 16, 2004 12:31 PM
To: Peter Yen (RD-US)
Cc: Ken Raeburn
Subject: Re: export private interface "krb5_set_default_tgs_ktypes" defined in krb5.h
What does klist report for the enctypes associated with the tickets?
Why is there any reason for you to be restricting the enctypes on the client?
Who controls the service? If it is you, what keys do you have in the keytab
file?
peter_yen@trendmicro.com wrote:
Hi Jeff,
Thanks for your insights. I am adopting the Samba ads_sasl_gssapi_bind() implementation to do GSSAPI auth to a windows 2003 Active Directory. ( http://samba.org/doxygen/appliance-head/sasl_8c.html#a6)
I have included the supported enctypes, both des-cbc-crc and des-cbc-md5 in the krb5.conf file. My packet trace shows that the code proceeds to line 00375 rc = ldap_sasl_bind_s(ads->ld, NULL, "GSSAPI", &cred, NULL, NULL, &scred) and return error of "invalid credential". I suspect that erros comes from inconsisteny of enctypes while obtaing tickets from KDC. Am I missing something here? I'd highly appreciate your help a lot. Thanks .
Peter
-----Original Message-----
From: Jeffrey Altman [ mailto:jaltman@mit.edu]
Sent: Monday, August 16, 2004 10:59 AM
To: Ken Raeburn
Cc: Peter Yen (RD-US)
Subject: Re: export private interface "krb5_set_default_tgs_ktypes"
defined in krb5.h
The issue with Windows 2000 vs Windows 2003 is this:
Windows 2000 has a security weakness in it because it will always
provide a response using the first enctype in the list of supported
enctypes provided by the client instead of the strongest enctype
supported by the client. The client should be prepared to accept
tickets in all enctypes the client says it will support.
This usually shows itself when the service principal is set for
DES only. In this case, Windows 2000 will respond with a
DES-CBC-CRC ticket enctype; whereas Windows 2003 will respond
with a DES-CBC-MD5 ticket enctype.
What is it that you are doing that results in your client not being
able to handle the tickets obtained from the KDC?
Ken Raeburn wrote:
(Oops. On the previous message I cc'ed the account Jeff uses for
posting to newsgroups, which was the one he replied to you from before.
According to his auto-responder, though, he doesn't actually read mail
there, so his Columbia address is preferred.)
On Aug 16, 2004, at 13:46, Ken Raeburn wrote:
On Aug 16, 2004, at 13:00, <mailto:peter_yen@trendmicro.com> <peter_yen@trendmicro.com> wrote:
Hi Ken,
Thanks for your kind response. Acutally, I am having some
compatibility issues using Kerberos/GSSAPI authentication with
Windows 2003 Active Directory. I adopted the way how Samba
authenticates itself using GSSAPI mechanism but it works well on
Windows 2000 but not Windows 2003 Active Directory. I traced my
packets and found that the encryption scheme used at Active Directory
is different as the one requested by client which cause the
server/client unable to recognize/decrypt the authenticating
credentails. I have been looking up on the internet for a while but
still cannot get it work. That's why I wanted to export the private
interface to see if I could manipulate the encryption schemes during
GSSAPI context exchanges. Is there a known issue for Windows 2003
compatibility. I'd appreciate your help a lot. Thanks you in advance.
Jeff Altman (who also replied on the Kerberos list) would be a lot
more familiar with the Windows compatibility issues than I am.
Does setting default_tgs_enctypes in the config file not do the job?
I note that in the current sources, krb5_set_default_tgs_ktypes just
calls krb5_set_default_tgs_enctypes, which appears to be exported.
I'm not sure offhand if that was the case in the KfW release, I don't
have a tree checked out.
Peter Yen
-----Original Message-----
From: Ken Raeburn [ mailto:raeburn@MIT.EDU]
Sent: Monday, August 16, 2004 9:48 AM
To: Peter Yen (RD-US)
Cc: <mailto:krbdev@mit.edu> <krbdev@mit.edu>; ' kerberos@mit.edu'
Subject: Re: export private interface "krb5_set_default_tgs_ktypes"
defined in krb5.h
On Aug 12, 2004, at 18:48, <mailto:peter_yen@trendmicro.com> <peter_yen@trendmicro.com> wrote:
I have tried to build up the MIT Krb-1.3.4 on Windows to export the
private interface "krb5_set_default_tgs_ktypes" declared in
First of all, why do you need it exported? As you note, it is marked
"private", and you shouldn't be surprised if such declarations or even
the functions disappear or have different signatures in some future
version.
added the compiled libraries into my VC6.0 project linker settings.
Unfortunately, it still gives me error such as "error LNK2001:
unresolved external symbol _krb5_set_default_tgs_ktypes". I am pretty
sure that I have included the libraries(comerr32.lib, gssapi32.lib,
krb532.lib, xpprof32.lib) in my linker settings but it still cannot
work. Is there anything I missed out? I'd appreciate your kind help a
lot. Thanks.
The library would need to be rebuilt after you update krb5_32.def,
which lists all the symbols to be exported. And your rebuilt library
would have to be used by anyone using your application, because it
wouldn't be compatible with the standard KfW DLLs.
Ken
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is
confidential and may be subject to copyright or other intellectual
property protection. If you are not the intended recipient, you are
not authorized to use or disclose this information, and we request
that you notify us by reply mail or telephone and delete the original
message from your mail system.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
