[Samba] Local Administrators (group) and delegation in AD

Thu Oct 29 13:34:57 UTC 2015

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
>>
>
>