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

Davor Vusir davortvusir at gmail.com
Fri Oct 30 08:07:30 UTC 2015 

On 2015-10-29 21:32, Rowland Penny wrote:
> On 29/10/15 19:38, Davor Vusir wrote:
>>
>>
>> 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.
>
> And that is where everything starts to go wrong, there is really no 
> such thing as a 'local Administrators' group on Linux.

No, it doesn't. You can put Linux aside. I've been talking about Samba 
only. And in Samba there is a "local Administrators" group.
[_davor at ct-srv001-t ~]$ klist
klist: Credentials cache file '/tmp/krb5cc_10051785' not found
[_davor at ct-srv001-t ~]$ net rpc group list -U _davor
Enter _davor's password:
Administrators
Users
[_davor at ct-srv001-t ~]$ net groupmap list
Failed to open group mapping database: Permission denied
Failed to initialise tdb mapping backend
failed to initialize group mapping
[_davor at ct-srv001-t ~]$ sudo net groupmap list -U davor
Administrators (S-1-5-32-544) -> BUILTIN\administrators
Users (S-1-5-32-545) -> BUILTIN\users
[_davor at ct-srv001-t ~]$ net rpc group members Administrators
Enter _davor's password:
USER\davor
USER\Domain Admins
[_davor at ct-srv001-t ~]$

And I found 'net rpc group addmem'. That might be a better solution.

[_davor at ct-srv001-t ~]$ net rpc group addmem Administrators _davor -U davor
Enter davor's password:
[_davor at ct-srv001-t ~]$ net rpc group members Administrators
Enter _davor's password:
USER\_davor
USER\davor
USER\Domain Admins
[_davor at ct-srv001-t ~]$

The users that's going to manage Samba file shares need to be members of 
Sambas "local Administrators" group only.

Regards
Davor

> Linux uses the user:usergroup mechanism and they have uid & gid 
> numbers not RIDS. As standard, the main admin on Linux is 'root' which 
> has its own group called 'root', though on distros like Ubuntu 'sudo' 
> is used instead,
>
> You cannot 'delegate' on Linux like you can on windows, you can use 
> 'sudo' to give you something like delegation and this can be setup 
> with the sudo rules in AD. Perhaps you should investigate this.
>
> Rowland
>
>
>>
>> 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