[cifs-protocol] [EXTERNAL] ServerAuthenticateKerberos() not usable for - TrackingID#2412180040010640

[Kristian Smith]

[Mike to Bcc]

Hi Metze,

Thanks for reaching out with your question. I'll be looking into this issue and will be in touch as soon as I have information to share.

Regards,
Kristian Smith
Support Escalation Engineer | Microsoft® Corporation
Email: kristian.smith at microsoft.com

-----Original Message-----
From: Michael Bowen <Mike.Bowen at microsoft.com> 
Sent: Wednesday, December 18, 2024 9:14 AM
To: Stefan Metzmacher <metze at samba.org>
Cc: cifs-protocol at lists.samba.org; Microsoft Support <supportmail at microsoft.com>
Subject: RE: [EXTERNAL] ServerAuthenticateKerberos() not usable for - TrackingID#2412180040010640

[DocHelp to bcc]

Hi Stefan,

Thanks for your question about Kerberos authentication. I have created case number 2412180040010640 to track this issue, please leave the number in the subject line when communicating with our team. One of our engineers will contact you soon.

Best regards,
Michael Bowen
Sr. Escalation Engineer - Microsoft® Corporation
 
-----Original Message-----
From: Stefan Metzmacher <metze at samba.org> 
Sent: Wednesday, December 18, 2024 7:00 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: [EXTERNAL] ServerAuthenticateKerberos() not usable for

Hi DocHelp,

while implementing ServerAuthenticateKerberos() in Samba, I found a strange behavior when using it for TrustedDnsDomainSecureChannel.

When I'm using it as a client the following LogonGetCapabilities() gets ACCESS_DENIED.

For all other network visible NETLOGON_SECURE_CHANNEL_TYPE values:
WorkstationSecureChannel, ServerSecureChannel, CdcServerSecureChannel and even TrustedDomainSecureChannel (used for downlevel NT4 trusts) it works as expected.

I'm testing with a Windows 2025 preview build, but I guess there are no related changes compared to the final version...

I also noticed that the Windows DC doesn't try to use ServerAuthenticateKerberos() when connecting to a DC of a trusted domain.

Is this behavior intended?
Is there a flag on the TDO object to allow it to work?

I've attached a network capture that shows the problem.

The problem happens in frames 1528-1531.
All others are just there to show it's working...

With a nightly build of wireshark you should be able to decrypt all kerberos and netlogon secure channel traffic.

Thanks for any help you can provide!
metze