1

I am writing a system which performs user login and provides single-sign-on access to SMB shares within the network.

User login is done with Kerberos 5 to verify the user's identity and get a TGT ticket. When accessing an SMB share, the TGT ticket is used to get the TGS ticket for the server where the share is hosted and the session setup is performed with that TGS (by that achieving SSO).

All works fine until the user tries to access an SMB share on the DC. In that case, the DC will return a STATUS_ACCESS_DENIED to the Tree Connect Request as shown in the link included below.

Wireshark capture

The user is a member of the Domain Admins group. As such, should have access to IPC$ share

The interesting thing is that if instead of performing the Session Setup with the TGS, I perform it with NTLMSSP (using the same user's credentials), the DC allows connecting to the share.

Why are different permissions assigned to the SMB session depending on the authentication performed (NTLMSSP vs. Kerberos 5)?

This smells like a GPO/GPP configuration but my knowledge on that is very limited.

Are further steps needed in a Session Setup against a DC when using Kerberos 5? Or is it safe to assume that I am doing it correctly if the server returns STATUS_SUCCESS?

A couple of notes:

  • The SMB client always tries to connect to IPC$ share to perform some IOCTLs before connecting to the required share.
  • I have verified that the date and time of my system is synchronized with the DC's
  • This system is developed on Linux,. I am using heimdal's libkrb5 and a proprietary SMB client (I have the ability to modify both libraries)

Update: Even when skipping connecting to the IPC$ share, and I connect to the required share directly, the behavior is the same. The DC will return a STATUS_ACCESS_DENIED to the Tree Connect Request.

Nadim Z
  • 21
  • 1
  • 6
  • Of course, only a member of the Domain Admins group is going to have permission to access admin shares on a DC. If it is policy related, you should review the settings at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. Some policy settings and how they affect IPC$ are explained here: https://support.microsoft.com/en-us/help/3034016/ipc-share-and-null-session-behavior-in-windows – twconnell Jul 26 '19 at 21:49
  • @twconnell, the user trying to connect to the share is in fact a member of Domain Admins. I updated the question to reflect that. I am starting to think this is not related to the IPC$ share. I modified the SMB client's behavior to connect directly to the network share without trying the IPC$ first, and ran into the same problem. Tried to play around with the settings at Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options, but no luck their neither. I might be missing something though. – Nadim Z Jul 30 '19 at 06:55

1 Answers1

1

Windows DC by default requires SMB message signing. This is advertised by the DC in the Security Mode part of Negotiate Protocol Response.

The (proprietary) SMB client in question was ignoring this security flag when using Kerberos and performing unsigned Tree Connect Requests. This caused the server (DC) to deny access to the share.

After modifying the SMB client, and insuring it respects the Signing requred flag when Kerberos credentials are used, connecting to DC's SMB shares became possible.

Nadim Z
  • 21
  • 1
  • 6