On Mon, 10 Jun 2024 13:38:21 +0100
Rowland Penny via samba <samba at lists.samba.org> wrote:
> On Mon, 10 Jun 2024 08:33:13 +0100
> Rowland Penny via samba <samba at lists.samba.org> wrote:
>
> > On Sun, 9 Jun 2024 18:52:39 +0100
> > Luis Peromarta via samba <samba at lists.samba.org> wrote:
> >
> > > Update:
> > >
> > > I have revoked the privilege to BUILIN\Administratos. As before,
> > > no root mapping.
> > >
> > > root at member:/# net rpc rights revoke
"BUILTIN\Administrators"
> > > SeDiskOperatorPrivilege -U "MAD\luis" Password for
[MAD\luis]:
> > > Successfully revoked rights.
> > >
> > > root at member:/# net rpc rights list privileges
> > > SeDiskOperatorPrivilege -Uluis Password for [MAD\luis]:
> > > SeDiskOperatorPrivilege:
> > >
> > > Reboot. Or else 'net cache flush &&
/etc/init.d/winbind restart &&
> > > /etc/init.d/smbd restart'
> > >
> > > I have delete and re-created the folder for there share (/test),
> > > chown luis:?unix admins?, and chmod 0770
> > >
> > > I still can set up the share from Windows no problem.
> > >
> > > LP
> >
> > That means one of two things, either once the group has inherited
> > the privilege it retains it, even if the parent group loses it. Or
> > the privileges are not actually required by AD.
> >
> > More investigation to follow.
> >
> > Rowland
> >
> >
>
> OK, where did the SeDiskOperatorPrivilege come from ? I cannot find
> any Windows documentation for it, I did find this:
>
>
https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/appendix-b--privileged-accounts-and-groups-in-active-directory
>
> Which lists the privileges, but there is no SeDiskOperatorPrivilege
>
> Anyway, I created a new Unix domain member using Debian 12 with Samba
> from backports.
> Once Samba was installed and running, the first thing I did was to
> revoke SeDiskOperatorPrivilege from Administrators:
>
> sudo net rpc rights list SeDiskOperatorPrivilege -U
> "SAMDOM\administrator" Password for [SAMDOM\administrator]:
> adminuser at debpriv:~$ # <-- nothing
>
> I the setup a share basically following this:
>
> https://wiki.samba.org/index.php/Setting_up_a_Share_Using_Windows_ACLs
>
> ignoring SeDiskOperatorPrivilege.
>
> It works, I added Domain Users with full control to the share as a
> member of Domain Admins.
>
> Do we really need the SeDiskOperatorPrivilege ? Did we ever need the
> SeDiskOperatorPrivilege in AD ?
>
> Rowland
>
OK, so I did some more testing this morning. I created a new share,
exactly the same as last time, apart from ownership, I used 'root:root'
instead of 'root:Domain Admins'.
I then connected to the share as a member of Domain Admins on Windows
and attempted to change the permissions and when I clicked the Security
tab, I got this:
Object name: \\DEBPRIV.SAMDOM.EXAMPLE.COM\Test
You must have read permissions to view the properties of this
object
Click Advanced to continue.
Clicking 'Advanced' didn't get me anywhere.
I then granted the SeDiskOperatorPrivilege to BUILTIN\Administrators,
this didn't help.
I then granted the SeDiskOperatorPrivilege to SAMDOM\Domain Admins,
again this didn't help.
So I revoked both the SeDiskOperatorPrivilege privileges I had granted
and tried the share I created yesterday, which was owned by
'root:Domain Admins' with 0770 permissions, this still works.
I now feel that having the 'SeDiskOperatorPrivilege' is of no use, what
does count is that the user you use to connect to the share from
Windows must have read/write permissions on the share, either as the
owner or by being a member of the group.
I still cannot find any Windows documentation for
'SeDiskOperatorPrivilege', but I think (if I understand git history
correctly) that it is a Samba thing. It appears to have been added in
2010 and the commitdif contains this:
+/* we have to define the LUID here due to a horrible check by printmig.exe
+ that requires the SeBackupPrivilege match what is in Windows. So match
+ those that we implement and start Samba privileges at 0x1001 */
+
................
+ SEC_PRIV_DISK_OPERATOR = 0x1003,
2010 was before Samba 4 was released, so was this only really required
for NT4-style domains ?
Was having the 'SeDiskOperatorPrivilege' privilege meant to make you
'root' when working from Windows ?
Who knows, all I can say is that it doesn't seem to do anything now,
but would like someone else to test it out before I remove it from the
wiki.
Rowland