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

Davor Vusir davortvusir at gmail.com
Tue Nov 3 08:10:55 UTC 2015 

On 2015-10-30 09:07, Davor Vusir wrote:
> 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.
>

No, Davor. That won't work. The delegated user account is not member of 
'AD\Domain Admins' which is member of the group 'SERVER\Administrators'. 
You have to use the username map to be able to add the first AD-group or 
account to 'SERVER\Administrators'.

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