[16411] in Kerberos_V5_Development
Re: 2008 R2
daemon@ATHENA.MIT.EDU (Tom Yu)
Wed Sep 29 17:49:37 2010
To: Bill Fellows <wrfellows@yahoo.com>
From: Tom Yu <tlyu@mit.edu>
Date: Wed, 29 Sep 2010 17:49:33 -0400
In-Reply-To: <471772.15807.qm@web30408.mail.mud.yahoo.com> (Bill Fellows's
message of "Thu, 23 Sep 2010 10:51:44 -0700 (PDT)")
Message-ID: <ldviq1ousnm.fsf@cathode-dark-space.mit.edu>
MIME-Version: 1.0
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: krbdev-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Bill Fellows <wrfellows@yahoo.com> writes:
> We got this response from Microsoft technical support:>> "I have received an update from my SME on the data which has been> provided to us. The problem is the name-type used for the TGT> request is set to Unknown:>> 133 2010-08-26 17:15:17.284157 x.x.x.x> x.x.x.x KRB5 AS-REQ> Server Name (Unknown): krbtgt/EXAMPLE.COM> Name-type: Unknown (0)> Name: krbtgt> Name: EXAMPLE.COM>> The name-type needs to be Service and Instance. The reason why it> works against the Writable DCs is because those DCs dont need to> proxy the authentication, RODCs do. In W2K8R2 there were additional> checks in the Kerberos decryption code path which now exposes this> problem."
That statement implies that the difficulty is with the principalname-type of the TGS principal (krbtgt/EXAMPLE.COM). A reasonableinterpretation of RFC 4120 is that an implementation should notrequire that the name-type be a certain value when processing arequest, which matches historical behavior.
> I've attached a network capture displaying this problem.
The mailing list software strips out non-text attachments.
>> -----Original Message----->> From: krbdev-bounces@mit.edu>> [mailto:krbdev-bounces@mit.edu]>> On Behalf Of Bill Fellows>> Sent: Wednesday, September 22, 2010 2:13 PM>> To: krbdev@mit.edu>> Subject: 2008 R2 >> >> Hi,>> >> I'm unable to authenticate through Kerberos to a 2008 R2>> read only domain controller (RODC) with Samba 3.5.5. I>> changed the krb5_princ_type field in bld_pr_ext.c>> krb5_build_principal_ext() to KRB5_NT_SRV_INST from>> KRB5_NT_UNKNOWN and this solved the problem. Is there a>> better / safer fix for this bug?
I suspect that a safer solution would be to explicitly reset theprincipal type in the relevant places in the get_init_creds()implementation, but I still think it's wrong for Windows Server 2008R2 to be denying the request solely on the basis of the principaltype.
_______________________________________________krbdev mailing list krbdev@mit.eduhttps://mailman.mit.edu/mailman/listinfo/krbdev
