> On 17. Feb 2025, at 19:23, NoSense via illumos-discuss > <discuss@lists.illumos.org> wrote: > > Thomas, thanks for the ideas. > > Yes, sync and npt are running and all systems in the network are using the > same local ntp server which is sync'd externally. > > Yes, NTLM is blocked on the DC only but not on the workstation that was > accessing the SMB server in the network trace above. This is to force the SMB > server to use Kerberos for authentication since I can't seem to disable NTLM > on the SMB server. This in turn forces the workstation to ramp up to Kerberos > from NTLM as seen in the negotiation with the SMB server. That all seems to > go well and they both agree to use Kerberos. > > As for the login @REALM issue, this is a login on windows machine (not > Android) with a domain account. no matter which syntax you login with the > SAMAccountName is always what is presented to the SMB server. > > Right now, I think the issue might be that none of the AD users have > individually defined rights to the file shares. They are all defined by AD > Groups the user belongs to. Howerver, idmap dump -n shows the GIDs for all > the wingroups and works perfectly when using NTLMv2. Is the Kerberos lookup > failing the group lookup and denying access to the resource? > > Under Kerberos is it not able to figure that out? How do I get more detailed > logs on the SMB server side? >
Well, the error code itself is suggesting that the server knows about the policy, but as I noted, on very quick check I was not able to find the relevant bit in code. log is in /var/svc/log/network-smb-server:default.log and smbd also does syslog as daemon.level, so you want to set up syslog with daemon.debug or like… rgds, toomas ------------------------------------------ illumos: illumos-discuss Permalink: https://illumos.topicbox.com/groups/discuss/Tef371e0d901b265f-M4ca2e4ce7ddb02af3f5ba852 Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
