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

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

Hi Davor,

If I've well understood you want some AD users to be local administrators
of some UNIX machines, not necessary all your UNIX machines.

I would give these users uidNumber=0 and/or gidNumber=0. In UNIX systems
you can rename "root" as long as you keep for him UID=0. You can also
have
several users sharing same UID and/or GID.

So, let's say now you have 10 users with uidNumber=0. They are valid users
in AD and valid users in UNIX context. So you have 10 new root accounts
able to connect on every UNIX boxes.

I don't know much SSSD but I expect you can define restriction about who
can connect on a given system. Playing with local sssd.conf to refuse login
for users in some group or accepting only connection if user is in some
other group. It seems "ad_access_filter" option is the one to do that,
this
option is described in sssd-ad man page.

Doing that you will nominative root accounts in AD and filters to avoid all
your admins can log on all UNIX machines.

Now perhaps I haven't understand your need.

2015-10-29 10:47 GMT+01:00 Davor Vusir <davortvusir at gmail.com>:
> 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
>
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba
>

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

On 2015-10-29 12:05, mathias dufresne wrote:
> Hi Davor,
>
> If I've well understood you want some AD users to be local
administrators
> of some UNIX machines, not necessary all your UNIX machines.
>
> I would give these users uidNumber=0 and/or gidNumber=0. In UNIX systems
> you can rename "root" as long as you keep for him UID=0. You can
also have
> several users sharing same UID and/or GID.
>
> So, let's say now you have 10 users with uidNumber=0. They are valid
users
> in AD and valid users in UNIX context. So you have 10 new root accounts
> able to connect on every UNIX boxes.
>
> I don't know much SSSD but I expect you can define restriction about
who
> can connect on a given system. Playing with local sssd.conf to refuse login
> for users in some group or accepting only connection if user is in some
> other group. It seems "ad_access_filter" option is the one to do
that, this
> option is described in sssd-ad man page.
>
> Doing that you will nominative root accounts in AD and filters to avoid all
> your admins can log on all UNIX machines.
>
> Now perhaps I haven't understand your need.
Hi Mathias!

I think you misunderstood. And I wasn't quite clear either. I like to 
look at Samba from a different angle; Samba is a Server Service which 
provides (mainly) file- and printerservices to Windows clients. To 
accomplish that it also uses/utilizes Linux and all the OS's different 
libraries and programs (Kerberos, PAM, network stuff and other things). 
Linux becomes a vessel for Samba. With that in mind you could look upon 
Samba as quite self contained.

If you want to delegate only the "Windows stuff", you don't have
to be
root to edit ACLs (both Share and DACL). It is enough to be a member of 
the _Sambaservers_ equivalent too Linux's root-group, Administrators.

What I'm trying to accomplish is to delegate Samba (Server Service) to 
given (delegated) administrators in a more elegant way than presented.

Regards
Davor
> 2015-10-29 10:47 GMT+01:00 Davor Vusir <davortvusir at gmail.com>:
>
>> 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
>>
>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions:  https://lists.samba.org/mailman/options/samba
>>

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