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.
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.