Am 25.02.20 um 15:16 schrieb Rowland penny via samba:> On 25/02/2020 14:01, Stefan G. Weichinger via samba wrote: >> Am 25.02.20 um 14:54 schrieb Rowland penny via samba: >>> You do not need it, it is only required if using the winbind 'ad' >>> backend and only then if you don't want possible problems with sysvol. >> What? Now I *don't* need it? > > Bad choice of words there, you do not need 'Unix Admins', you can use > 'Domain Admins' instead. You only need to use 'Unix Admins' if you use > the winbind 'ad' backend and do not care if you mess up sysvol. > > If you add GPOs, then they can be owned by Domain Admins (something that > normally cannot happen on Unix). This is because Domain Admins is mapped > to 'ID_TYPE_BOTH' in idmap.ldb. If you give Domain Admins a gidNumber, > it becomes just a group and cannot own anything in sysvol. On a Unix > domain member using the 'rid' backend, the mapping is done locally and > does not affect idmap.ldb.Hm, I understand that partially, it seems. Fact is that I can't edit the share from within Windows with the DOM\Administrator user right now. No read permissions .. That is bad ... That user is member of both DOM\IT and DOM\dom?nen-admins And should have the needed privilege: # net rpc rights list privileges SeDiskOperatorPrivilege -U "CUSTOMER\administrator" Enter CUSTOMER\administrator's password: SeDiskOperatorPrivilege: CUSTOMER\Administrator BUILTIN\Administrators CUSTOMER\IT
Am 25.02.20 um 15:29 schrieb Stefan G. Weichinger via samba:> Hm, I understand that partially, it seems. > > Fact is that I can't edit the share from within Windows with the > DOM\Administrator user right now. > > No read permissions ..fixed it partially but not satisfyingly or correct mixture of "chown root:10512" , setfacl ... root:rwx etc But it isn't working *right* And I still don't understand why ... I am afk now for some hours and will maybe start over doing all this with a specific test share.
Am 25.02.20 um 16:32 schrieb Stefan G. Weichinger via samba:> Am 25.02.20 um 15:29 schrieb Stefan G. Weichinger via samba: > >> Hm, I understand that partially, it seems. >> >> Fact is that I can't edit the share from within Windows with the >> DOM\Administrator user right now. >> >> No read permissions .. > > fixed it partially but not satisfyingly or correct > > mixture of "chown root:10512" , setfacl ... root:rwx etc > > But it isn't working *right* > > And I still don't understand why ... > > I am afk now for some hours and will maybe start over doing all this > with a specific test share.Had my share [acltest] working an hour ago, now again "access denied". Oh my. Anything wrong here related to Windows ACLs ? -> [global] dedicated keytab file = /etc/krb5.keytab domain master = No kerberos method = secrets and keytab load printers = No local master = No preferred master = No printcap name = /dev/null realm = customer.INTRA security = ADS template homedir = /mnt/MSA2040/smb/Homes/%D/%U unix charset = iso8859-15 unix extensions = No username map = /etc/samba/samba_usermapping winbind cache time = 10 winbind refresh tickets = Yes winbind use default domain = Yes workgroup = customer full_audit:priority = notice full_audit:facility = local5 full_audit:success = mkdir rmdir read pread write pwrite rename unlink full_audit:failure = connect full_audit:prefix = %u|%I|%m|%S idmap config customer : backend = rid idmap config customer : range = 10000-20000 idmap config * : range = 3000-7999 idmap config * : backend = tdb acl allow execute always = Yes inherit acls = Yes map acl inherit = Yes vfs objects = acl_xattr full_audit wide links = Yes