samba - Oct 2015 - Local Administrators (group) and delegation in AD

On 2015-10-29 12:23, Rowland Penny wrote:
> On 29/10/15 09:47, Davor Vusir wrote:
>> On 2015-10-29 09:52, Rowland Penny wrote:
>>> On 29/10/15 08:34, Davor Vusir wrote:
>>>> Hi all!
>>>>
>>>> We have got many delegations in our AD. To add a certain 
>>>> administrator group to the local Administrators group you can
use
>>>> GPO for Windowsservers. As Samba does not understand GPO I have
>>>> initially used the "username map" feature to add a
domain account
>>>> to become root. After the appropriate group is added via
Computer
>>>> Management MMC by the delegated administrator, the line
"username
>>>> map" is commented and Samba is restarted. After this
procedure the
>>>> delegated administrators have got proper access to the server.
Not
>>>> using this feature of course renders access denied error when 
>>>> attempting to add an AD-group to the local Administrators
group.
>>>>
>>>> If Winbind is disabled you get the well known SID in members
list
>>>> in the properties dialog for the local Administrators group
instead
>>>> of the human readable names (AD\Domain Admins...).
>>>>
>>>> We are using SSSD to retrieve user- and groupinfo from AD, 
>>>> therefore is the AD-backend commented in smb.conf.
>>>>
>>>> Do you know of another way of doing this?
>>>>
>>>> Regards
>>>> Davor vusir
>>>>
>>>> Relevant part of smb.conf:
>>>> #  username map = /etc/samba/usermap
>>>>
>>>> idmap config *:backend = tdb
>>>>   idmap config *:range = 2200000001-2200100000
>>>> #  idmap config AD:backend = ad
>>>> #  idmap config AD:schema_mode = rfc2307
>>>> #  idmap config AD:range = 1000-2200000000
>>>> #  winbind nss info = rfc2307
>>>>
>>>>
>>>> Relevant part of nsswitch.conf:
>>>> passwd:     files sss winbind
>>>> shadow:     files
>>>> group:      files sss winbind
>>>>
>>>>
>>>>
>>>
>>> So, you are having problems by not using winbind and you are asking
>>> for help with sssd on a samba mailing list, I can think of ways 
>>> around this, but they involve not using sssd. You may get help with
>>> this on the sssd mailing list.
>>>
>>> Rowland
>>>
>>>
>> No, Rowland. I'm not asking for help with SSSD. It's working
quite
>> fine. And so is winbind. And both are running fine together. I'm 
>> asking if there is another way of delegating administrator access to 
>> a Sambaserver. A more elegant way than what I have described.
>>
>> I would be grateful if you could share your thoughts.
>>
>> /Davor
>>
>
> How about this:
>
> ssh into the DC, either as root or as a user that can use sudo (you 
> can use kerberos, but I am not going into that here)
>
> Create the group:
> samba-tool group add unixadmins --gid-number=GID_NUMBER 
> --nis-domain=NIS_DOMAIN
>
> Add the group to Administrators:
> samba-tool group addmembers Administrators unixadmins
>
> Add the required users to unixadmins, they should get the same rights 
> as if they were directly members of Administrators.
> samba-tool group addmembers unixadmins anADuser
>
> Now with setfacl, give the group unixadmins the required permissions 
> on the share
>
> Rowland
>
>
It looks to me that members of unixadmins become domain administrators 
if you do it like that. And then in turn get administrative privileges 
on _all_ member servers and clients. That's not delegation.

Domain Admins delegate, for instance, an OU, to a select group, 
unixadmins. The group members of unixadmins can not, and should not, do 
Domain Admin-stuff. It's okay if unixadmins only could do admin stuff on 
the Samba server. And nowhere else.

Regards
Davor

I'm thick :D
I don't really understand more :(

Samba can share file, printers and when samba hosts a domain samba is also
acting as a users database.

All that can be managed from Windows side or Linux side.

Delegation on Windows is quiet well documented I expect by Microsoft itself
and in the Samba Wiki.
According to that I expect your question is about how to delegate Samba
management from Linux side. Am I right or should I go back home and take a
nap? (I would love the nap!)

If you look for a way to manage Samba on Linux side with users which are
not in Domain Admins group, you can. A Linux with Samba is a Linux anyway.
The way I propose in my first you get users with UID=0 so they are root.
They are root so they can be root everywhere.

Then using SSSD you can filter on which servers/workstations these groups
of users can connect or not. There you start to have delegation, using
UID=0 accounts. Delegation to play as sysadmins on Linux boxes but not all
Linux boxes.

Now to be able to manage only one OU from Linux side, I can't see how to
proceed. Samba is a bunch of files as any software on Linux. This means you
can play with Samba tools to manage Samba on Linux side if your user is
allowed to modify the file which are would be modified by the command you
run.
And as Samba database is not splitted in small files, if you give that
non-root user the ability to modify Samba database files, or just one file,
this user can modify all objects contained in that DB file. So the
granularity of that kind of fake-delegation is awfully bad and ceertainly
not what you want.

Another way would be to reinvent the wheel installing products to access
Samba's LDAP and place ACL on the LDAP tree (no idea if Samba's LDAP
tree
can do that) to simulate Windows delegation.

But as I said, I need a nap right now :)


2015-10-29 14:10 GMT+01:00 Davor Vusir <davortvusir at gmail.com>:
> On 2015-10-29 12:23, Rowland Penny wrote:
>
>> On 29/10/15 09:47, Davor Vusir wrote:
>>
>>> On 2015-10-29 09:52, Rowland Penny wrote:
>>>
>>>> On 29/10/15 08:34, Davor Vusir wrote:
>>>>
>>>>> Hi all!
>>>>>
>>>>> We have got many delegations in our AD. To add a certain
administrator
>>>>> group to the local Administrators group you can use GPO for
Windowsservers.
>>>>> As Samba does not understand GPO I have initially used the
"username map"
>>>>> feature to add a domain account to become root. After the
appropriate group
>>>>> is added via Computer Management MMC by the delegated
administrator, the
>>>>> line "username map" is commented and Samba is
restarted. After this
>>>>> procedure the delegated administrators have got proper
access to the
>>>>> server. Not using this feature of course renders access
denied error when
>>>>> attempting to add an AD-group to the local Administrators
group.
>>>>>
>>>>> If Winbind is disabled you get the well known SID in
members list in
>>>>> the properties dialog for the local Administrators group
instead of the
>>>>> human readable names (AD\Domain Admins...).
>>>>>
>>>>> We are using SSSD to retrieve user- and groupinfo from AD,
therefore
>>>>> is the AD-backend commented in smb.conf.
>>>>>
>>>>> Do you know of another way of doing this?
>>>>>
>>>>> Regards
>>>>> Davor vusir
>>>>>
>>>>> Relevant part of smb.conf:
>>>>> #  username map = /etc/samba/usermap
>>>>>
>>>>> idmap config *:backend = tdb
>>>>>   idmap config *:range = 2200000001-2200100000
>>>>> #  idmap config AD:backend = ad
>>>>> #  idmap config AD:schema_mode = rfc2307
>>>>> #  idmap config AD:range = 1000-2200000000
>>>>> #  winbind nss info = rfc2307
>>>>>
>>>>>
>>>>> Relevant part of nsswitch.conf:
>>>>> passwd:     files sss winbind
>>>>> shadow:     files
>>>>> group:      files sss winbind
>>>>>
>>>>>
>>>>>
>>>>>
>>>> So, you are having problems by not using winbind and you are
asking for
>>>> help with sssd on a samba mailing list, I can think of ways
around this,
>>>> but they involve not using sssd. You may get help with this on
the sssd
>>>> mailing list.
>>>>
>>>> Rowland
>>>>
>>>>
>>>> No, Rowland. I'm not asking for help with SSSD. It's
working quite
>>> fine. And so is winbind. And both are running fine together.
I'm asking if
>>> there is another way of delegating administrator access to a
Sambaserver. A
>>> more elegant way than what I have described.
>>>
>>> I would be grateful if you could share your thoughts.
>>>
>>> /Davor
>>>
>>>
>> How about this:
>>
>> ssh into the DC, either as root or as a user that can use sudo (you can
>> use kerberos, but I am not going into that here)
>>
>> Create the group:
>> samba-tool group add unixadmins --gid-number=GID_NUMBER
>> --nis-domain=NIS_DOMAIN
>>
>> Add the group to Administrators:
>> samba-tool group addmembers Administrators unixadmins
>>
>> Add the required users to unixadmins, they should get the same rights
as
>> if they were directly members of Administrators.
>> samba-tool group addmembers unixadmins anADuser
>>
>> Now with setfacl, give the group unixadmins the required permissions on
>> the share
>>
>> Rowland
>>
>>
>>
> It looks to me that members of unixadmins become domain administrators if
> you do it like that. And then in turn get administrative privileges on
> _all_ member servers and clients. That's not delegation.
>
> Domain Admins delegate, for instance, an OU, to a select group,
> unixadmins. The group members of unixadmins can not, and should not, do
> Domain Admin-stuff. It's okay if unixadmins only could do admin stuff
on
> the Samba server. And nowhere else.
>
> Regards
> Davor
>
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

Please note that on Samba servers a root account can do almost all stuffs a
Domain admin can do, more perhaps: a domain admin would face complaints
from Windows ADUC tools if he tries to remove the whole AD database. A root
user on Samba server can remove the whole database using "rm" command,
without complaint in no time.

2015-10-29 14:31 GMT+01:00 mathias dufresne <infractory at gmail.com>:
> I'm thick :D
> I don't really understand more :(
>
> Samba can share file, printers and when samba hosts a domain samba is also
> acting as a users database.
>
> All that can be managed from Windows side or Linux side.
>
> Delegation on Windows is quiet well documented I expect by Microsoft
> itself and in the Samba Wiki.
> According to that I expect your question is about how to delegate Samba
> management from Linux side. Am I right or should I go back home and take a
> nap? (I would love the nap!)
>
> If you look for a way to manage Samba on Linux side with users which are
> not in Domain Admins group, you can. A Linux with Samba is a Linux anyway.
> The way I propose in my first you get users with UID=0 so they are root.
> They are root so they can be root everywhere.
>
> Then using SSSD you can filter on which servers/workstations these groups
> of users can connect or not. There you start to have delegation, using
> UID=0 accounts. Delegation to play as sysadmins on Linux boxes but not all
> Linux boxes.
>
> Now to be able to manage only one OU from Linux side, I can't see how
to
> proceed. Samba is a bunch of files as any software on Linux. This means you
> can play with Samba tools to manage Samba on Linux side if your user is
> allowed to modify the file which are would be modified by the command you
> run.
> And as Samba database is not splitted in small files, if you give that
> non-root user the ability to modify Samba database files, or just one file,
> this user can modify all objects contained in that DB file. So the
> granularity of that kind of fake-delegation is awfully bad and ceertainly
> not what you want.
>
> Another way would be to reinvent the wheel installing products to access
> Samba's LDAP and place ACL on the LDAP tree (no idea if Samba's
LDAP tree
> can do that) to simulate Windows delegation.
>
> But as I said, I need a nap right now :)
>
>
> 2015-10-29 14:10 GMT+01:00 Davor Vusir <davortvusir at gmail.com>:
>
>> On 2015-10-29 12:23, Rowland Penny wrote:
>>
>>> On 29/10/15 09:47, Davor Vusir wrote:
>>>
>>>> On 2015-10-29 09:52, Rowland Penny wrote:
>>>>
>>>>> On 29/10/15 08:34, Davor Vusir wrote:
>>>>>
>>>>>> Hi all!
>>>>>>
>>>>>> We have got many delegations in our AD. To add a
certain
>>>>>> administrator group to the local Administrators group
you can use GPO for
>>>>>> Windowsservers. As Samba does not understand GPO I have
initially used the
>>>>>> "username map" feature to add a domain
account to become root. After the
>>>>>> appropriate group is added via Computer Management MMC
by the delegated
>>>>>> administrator, the line "username map" is
commented and Samba is restarted.
>>>>>> After this procedure the delegated administrators have
got proper access to
>>>>>> the server. Not using this feature of course renders
access denied error
>>>>>> when attempting to add an AD-group to the local
Administrators group.
>>>>>>
>>>>>> If Winbind is disabled you get the well known SID in
members list in
>>>>>> the properties dialog for the local Administrators
group instead of the
>>>>>> human readable names (AD\Domain Admins...).
>>>>>>
>>>>>> We are using SSSD to retrieve user- and groupinfo from
AD, therefore
>>>>>> is the AD-backend commented in smb.conf.
>>>>>>
>>>>>> Do you know of another way of doing this?
>>>>>>
>>>>>> Regards
>>>>>> Davor vusir
>>>>>>
>>>>>> Relevant part of smb.conf:
>>>>>> #  username map = /etc/samba/usermap
>>>>>>
>>>>>> idmap config *:backend = tdb
>>>>>>   idmap config *:range = 2200000001-2200100000
>>>>>> #  idmap config AD:backend = ad
>>>>>> #  idmap config AD:schema_mode = rfc2307
>>>>>> #  idmap config AD:range = 1000-2200000000
>>>>>> #  winbind nss info = rfc2307
>>>>>>
>>>>>>
>>>>>> Relevant part of nsswitch.conf:
>>>>>> passwd:     files sss winbind
>>>>>> shadow:     files
>>>>>> group:      files sss winbind
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> So, you are having problems by not using winbind and you
are asking
>>>>> for help with sssd on a samba mailing list, I can think of
ways around
>>>>> this, but they involve not using sssd. You may get help
with this on the
>>>>> sssd mailing list.
>>>>>
>>>>> Rowland
>>>>>
>>>>>
>>>>> No, Rowland. I'm not asking for help with SSSD.
It's working quite
>>>> fine. And so is winbind. And both are running fine together.
I'm asking if
>>>> there is another way of delegating administrator access to a
Sambaserver. A
>>>> more elegant way than what I have described.
>>>>
>>>> I would be grateful if you could share your thoughts.
>>>>
>>>> /Davor
>>>>
>>>>
>>> How about this:
>>>
>>> ssh into the DC, either as root or as a user that can use sudo (you
can
>>> use kerberos, but I am not going into that here)
>>>
>>> Create the group:
>>> samba-tool group add unixadmins --gid-number=GID_NUMBER
>>> --nis-domain=NIS_DOMAIN
>>>
>>> Add the group to Administrators:
>>> samba-tool group addmembers Administrators unixadmins
>>>
>>> Add the required users to unixadmins, they should get the same
rights as
>>> if they were directly members of Administrators.
>>> samba-tool group addmembers unixadmins anADuser
>>>
>>> Now with setfacl, give the group unixadmins the required
permissions on
>>> the share
>>>
>>> Rowland
>>>
>>>
>>>
>> It looks to me that members of unixadmins become domain administrators
if
>> you do it like that. And then in turn get administrative privileges on
>> _all_ member servers and clients. That's not delegation.
>>
>> Domain Admins delegate, for instance, an OU, to a select group,
>> unixadmins. The group members of unixadmins can not, and should not, do
>> Domain Admin-stuff. It's okay if unixadmins only could do admin
stuff on
>> the Samba server. And nowhere else.
>>
>> Regards
>> Davor
>>
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>
>
>

mathias dufresne skrev den 2015-10-29 14:31:
> I'm thick :D
> I don't really understand more :(
>
No. I'm having trouble explaining. Maybe these threads are more 
enlightning: 
https://lists.samba.org/archive/samba/2015-April/191020.html and 
http://www.spinics.net/lists/samba/msg123646.html.
> Samba can share file, printers and when samba hosts a domain samba is also
> acting as a users database.
>
> All that can be managed from Windows side or Linux side.
>
True. But it may not be of interest to an administrator that lacks 
knowledge about Linux and have a need and knowledge of Windows file sharing.
> Delegation on Windows is quiet well documented I expect by Microsoft itself
> and in the Samba Wiki.
> According to that I expect your question is about how to delegate Samba
> management from Linux side. Am I right or should I go back home and take a
> nap? (I would love the nap!)
>
My point is that what I have presented is the only way I have found to 
delegate "the Windows way". When looking at the net command I find
that
it's possible to map a AD-group to a local Linux-group. But not make a 
AD-group or -account member of the (Samba!) servers local Administrators 
group. If it the only way, then fine. If there is another more 
Windows-like approach, I'm all ears.
> If you look for a way to manage Samba on Linux side with users which are
> not in Domain Admins group, you can. A Linux with Samba is a Linux anyway.
> The way I propose in my first you get users with UID=0 so they are root.
> They are root so they can be root everywhere.
>
You needn't be root to manage Samba file shares. An AD-account or -group 
has to be member of Sambas equivalent of Windows local Administrators group.

Regards
Davor
> Then using SSSD you can filter on which servers/workstations these groups
> of users can connect or not. There you start to have delegation, using
> UID=0 accounts. Delegation to play as sysadmins on Linux boxes but not all
> Linux boxes.
>
> Now to be able to manage only one OU from Linux side, I can't see how
to
> proceed. Samba is a bunch of files as any software on Linux. This means you
> can play with Samba tools to manage Samba on Linux side if your user is
> allowed to modify the file which are would be modified by the command you
> run.
> And as Samba database is not splitted in small files, if you give that
> non-root user the ability to modify Samba database files, or just one file,
> this user can modify all objects contained in that DB file. So the
> granularity of that kind of fake-delegation is awfully bad and ceertainly
> not what you want.
>
> Another way would be to reinvent the wheel installing products to access
> Samba's LDAP and place ACL on the LDAP tree (no idea if Samba's
LDAP tree
> can do that) to simulate Windows delegation.
>
> But as I said, I need a nap right now :)
>
>
> 2015-10-29 14:10 GMT+01:00 Davor Vusir <davortvusir at gmail.com>:
>
>> On 2015-10-29 12:23, Rowland Penny wrote:
>>
>>> On 29/10/15 09:47, Davor Vusir wrote:
>>>
>>>> On 2015-10-29 09:52, Rowland Penny wrote:
>>>>
>>>>> On 29/10/15 08:34, Davor Vusir wrote:
>>>>>
>>>>>> Hi all!
>>>>>>
>>>>>> We have got many delegations in our AD. To add a
certain administrator
>>>>>> group to the local Administrators group you can use GPO
for Windowsservers.
>>>>>> As Samba does not understand GPO I have initially used
the "username map"
>>>>>> feature to add a domain account to become root. After
the appropriate group
>>>>>> is added via Computer Management MMC by the delegated
administrator, the
>>>>>> line "username map" is commented and Samba is
restarted. After this
>>>>>> procedure the delegated administrators have got proper
access to the
>>>>>> server. Not using this feature of course renders access
denied error when
>>>>>> attempting to add an AD-group to the local
Administrators group.
>>>>>>
>>>>>> If Winbind is disabled you get the well known SID in
members list in
>>>>>> the properties dialog for the local Administrators
group instead of the
>>>>>> human readable names (AD\Domain Admins...).
>>>>>>
>>>>>> We are using SSSD to retrieve user- and groupinfo from
AD, therefore
>>>>>> is the AD-backend commented in smb.conf.
>>>>>>
>>>>>> Do you know of another way of doing this?
>>>>>>
>>>>>> Regards
>>>>>> Davor vusir
>>>>>>
>>>>>> Relevant part of smb.conf:
>>>>>> #  username map = /etc/samba/usermap
>>>>>>
>>>>>> idmap config *:backend = tdb
>>>>>>    idmap config *:range = 2200000001-2200100000
>>>>>> #  idmap config AD:backend = ad
>>>>>> #  idmap config AD:schema_mode = rfc2307
>>>>>> #  idmap config AD:range = 1000-2200000000
>>>>>> #  winbind nss info = rfc2307
>>>>>>
>>>>>>
>>>>>> Relevant part of nsswitch.conf:
>>>>>> passwd:     files sss winbind
>>>>>> shadow:     files
>>>>>> group:      files sss winbind
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> So, you are having problems by not using winbind and you
are asking for
>>>>> help with sssd on a samba mailing list, I can think of ways
around this,
>>>>> but they involve not using sssd. You may get help with this
on the sssd
>>>>> mailing list.
>>>>>
>>>>> Rowland
>>>>>
>>>>>
>>>>> No, Rowland. I'm not asking for help with SSSD.
It's working quite
>>>> fine. And so is winbind. And both are running fine together.
I'm asking if
>>>> there is another way of delegating administrator access to a
Sambaserver. A
>>>> more elegant way than what I have described.
>>>>
>>>> I would be grateful if you could share your thoughts.
>>>>
>>>> /Davor
>>>>
>>>>
>>> How about this:
>>>
>>> ssh into the DC, either as root or as a user that can use sudo (you
can
>>> use kerberos, but I am not going into that here)
>>>
>>> Create the group:
>>> samba-tool group add unixadmins --gid-number=GID_NUMBER
>>> --nis-domain=NIS_DOMAIN
>>>
>>> Add the group to Administrators:
>>> samba-tool group addmembers Administrators unixadmins
>>>
>>> Add the required users to unixadmins, they should get the same
rights as
>>> if they were directly members of Administrators.
>>> samba-tool group addmembers unixadmins anADuser
>>>
>>> Now with setfacl, give the group unixadmins the required
permissions on
>>> the share
>>>
>>> Rowland
>>>
>>>
>>>
>> It looks to me that members of unixadmins become domain administrators
if
>> you do it like that. And then in turn get administrative privileges on
>> _all_ member servers and clients. That's not delegation.
>>
>> Domain Admins delegate, for instance, an OU, to a select group,
>> unixadmins. The group members of unixadmins can not, and should not, do
>> Domain Admin-stuff. It's okay if unixadmins only could do admin
stuff on
>> the Samba server. And nowhere else.
>>
>> Regards
>> Davor
>>
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>