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

Davor Vusir davortvusir at gmail.com
Thu Oct 29 19:38:48 UTC 2015



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



More information about the samba mailing list