From windows client it's not possible to change the owner of directories in Samba share, even if the user has the SeRestorePrivilege (Samba is a Domain Member). In the Samba logs I can see the following error message: [2023/02/06 13:23:31.624803, 3] ../../source3/modules/nfs4_acls.c:1042(smb_set_nt_acl_nfs4) chown New folder, 11150, 4294967295 failed. Error = NT_STATUS_INVALID_OWNER. This points to the try_chown() in samba code, which should become root and allow the chown, if the user has the SeRestorePrivilege: if (lp_enable_privileges()) { bool has_take_ownership_priv = security_token_has_privilege( get_current_nttok(fsp->conn), SEC_PRIV_TAKE_OWNERSHIP); bool has_restore_priv = security_token_has_privilege( get_current_nttok(fsp->conn), SEC_PRIV_RESTORE); if (has_restore_priv) { ; /* Case (2) */ } else if (has_take_ownership_priv) { /* Case (3) */ if (uid == get_current_uid(fsp->conn)) { gid = (gid_t)-1; } else { has_take_ownership_priv = false; } } if (has_take_ownership_priv || has_restore_priv) { status = NT_STATUS_OK; become_root(); ret = SMB_VFS_FCHOWN(fsp, uid, gid); if (ret != 0) { status = map_nt_error_from_unix(errno); } unbecome_root(); return status; } } From windows I have added the SeRestorePrivilege to that user, and actually samba can see that privileges for the user: # net rpc rights list 'DOMAIN\user' -S X.X.X.X -U Administrator SeBackupPrivilege SeRestorePrivilege So it seems cause of a bug the privileges are not in the security token. Actually the debug logs shows that in the security token for that user the Privileges are missing [2023/02/08 10:06:05.624154, 5] ../../libcli/security/security_token.c:57(security_token_debug) Security token SIDs (13): <SNIP> Privileges (0x 0): Rights (0x 0): If I use the "Administrator" user the Privileges are present in the security token: [2023/02/08 10:49:21.253173, 5] ../../libcli/security/security_token.c:57(security_token_debug) Security token SIDs (25): <SNIP> Privileges (0x 1FFFFFF0): Privilege[ 0]: SeMachineAccountPrivilege Privilege[ 1]: SeTakeOwnershipPrivilege Privilege[ 2]: SeBackupPrivilege Privilege[ 3]: SeRestorePrivilege Privilege[ 4]: SeRemoteShutdownPrivilege Privilege[ 5]: SePrintOperatorPrivilege Privilege[ 6]: SeAddUsersPrivilege Privilege[ 7]: SeDiskOperatorPrivilege Privilege[ 8]: SeSecurityPrivilege Privilege[ 9]: SeSystemtimePrivilege Privilege[ 10]: SeShutdownPrivilege Privilege[ 11]: SeDebugPrivilege Privilege[ 12]: SeSystemEnvironmentPrivilege Privilege[ 13]: SeSystemProfilePrivilege Privilege[ 14]: SeProfileSingleProcessPrivilege Privilege[ 15]: SeIncreaseBasePriorityPrivilege Privilege[ 16]: SeLoadDriverPrivilege Privilege[ 17]: SeCreatePagefilePrivilege Privilege[ 18]: SeIncreaseQuotaPrivilege Privilege[ 19]: SeChangeNotifyPrivilege Privilege[ 20]: SeUndockPrivilege
Can you get me a debug level 10 trace of the user first connecting ? It's when the token is created for that logging in user that the privileges should be associated with the account, so it'd be good to see all debugs around that.
The key should be in the debug inside get_privileges_for_sids(). There is a DEBUG info here (debug level 5). DBG_INFO("sid = %s\nPrivilege set: 0x%"PRIx64"\n", dom_sid_str_buf(&slist[i], &buf), which should print out the hex value of any privilege set for each specific SID in the user token for the logged on user. This is called from finalize_local_nt_token() which is called as the last act when creating a token for the logging on user.
Created attachment 17755 [details] debug logs
I have attached debug logs (level) for the client user "andrea" that open the share "test" and try to change the owner of directory "New folder" from "andrea" to "betty"
I don't see in the log the message "Privilege set:" for the SID of "andrea" user, which is S-1-5-21-2736888305-896212807-1561745698-1142, but I do see the message: [2023/02/09 02:20:21.493651, 4, pid=51512, effective(0, 0), real(0, 0)] ../../source3/lib/privileges.c:99(get_privileges) get_privileges: No privileges assigned to SID [S-1-5-21-2736888305-896212807-1561745698-1142]
the "tdbdump /var/lib/samba/account_policy.tdb" output doesn't show the SID S-1-5-21-2736888305-896212807-1561745698-1142
Also the privileges for "BUILTIN\Backup operators" are not set in the db # net rpc rights list 'BUILTIN\Backup operators' -S 10.50.50.85 -U administrator SeBackupPrivilege SeRestorePrivilege SeShutdownPrivilege SeInteractiveLogonRight SeBatchLogonRight # wbinfo -n 'BUILTIN\Backup operators' S-1-5-32-551 SID_ALIAS (4) # tdbdump /var/lib/samba/account_policy.tdb | grep -A1 S-1-5-32-551 key(18) = "PRIV_S-1-5-32-551\00" data(8) = "\00\00\00\00\00\00\00\00"
Well that explains it. Now the problem is why net rpc rights set isn't setting the bit in the tdb.
As far as I can see "net rpc rights set" command just connect to Windows DC and set the privileges, it doesn't touch Samba account_policy.tdb. Moreover, the privileges may be set directly from the windows DC, and Samba should load it even in this case. The issue doesn't affect the Administrator user because when smbd start we have the following calls flow: main() make_new_session_info_guest() create_local_token() create_local_nt_token_from_info3() inalize_local_nt_token() get_privileges_for_sids() get_privileges() get_account_pol_db() init_account_policy() /* BUILTIN\Administrators get everything -- *always* */ grant_all_privileges( &global_sid_Builtin_Administrators )
Ah that explains it completely :-). You need to set the rights/privilages ON THE SAMBA SERVER serving the files. The account_policy.tdb is local to a server. Use -S <samba_server> to connect to the correct machine.
(In reply to Jeremy Allison from comment #10) Interesting, that way I can see the privileges for that user in account_policy.tdb. Does that mean Samba can't load the privileges from DC (when the user open the session) and you have to add the privileges manually in the Samba server?
Yes, privileges are local to a server, not global via a DC. What people usually do is create a group, "restore_operators" or whatever, assign users into that group in AD, then add the privilege SeRestore to that group and replicate the account_policy db to all servers that need it.