[Samba] Samba4: "MYDOM\Administrator" quite useless on a member server?
Davor Vusir
davortvusir at gmail.com
Mon Oct 27 02:07:39 MDT 2014
2014-10-24 11:27 GMT+02:00 Rowland Penny <rowlandpenny at googlemail.com>:
> On 23/10/14 21:16, Davor Vusir wrote:
>>
>> 2014-10-23 14:04 GMT+02:00 Rowland Penny <rowlandpenny at googlemail.com>:
>>>
>>> On 23/10/14 12:22, ?icro MEGAS wrote:
>>>>
>>>> Hello list,
>>>>
>>>> my DC and member server is running Samba 4.1.12. The DC was provisioned
>>>> with rfc2307 and NIS extensions. Through ADUC tool and the [UNIX
>>>> Attribute]
>>>> tab I assigned a uid to the AD user "testuser1" and I also assigned a
>>>> gid to
>>>> the AD group "Domain Users". The member server was configured according
>>>> the
>>>> official wiki of samba.org. Winbind was configured on the member server
>>>> and
>>>> /etc/nsswitch.conf was modified, too like that:
>>>>
>>>> passwd: compat winbind
>>>> group: compat winbind
>>>>
>>>> My questions are:
>>>>
>>>> (1.) "wbinfo -p", "wbinfo -u" and "wbinfo -g" executed on the member
>>>> server all are returning correct and expected results. From "wbinfo -u"
>>>> and
>>>> "wbinfo -g" I get all the available AD users+groups. From "getent
>>>> passwd" I
>>>> get only the AD users, for which a uid on the UNIX attribute exist, in
>>>> that
>>>> case "testuser1" is displayed correctly. But when I run "getent group" I
>>>> don't get the group "Domain Users" although this group also has a gid
>>>> assigned. The strange thing is that "getent group 'Domain Users'" or
>>>> "getent
>>>> group 10000" works fine though:
>>>>
>>>> [root at membersrv1:~$ getent group 'Domain Users'
>>>> domain users:x:10000:
>>>> [root at membersrv1:~$ getent group 10000
>>>> domain users:x:10000:
>>>>
>>>> Why does "getent group" *NOT* returning the AD domain groups, that
>>>> certainly have a GID assigned as UNIX attribute? I installed a new
>>>> member
>>>> server with samba 4.1.11/wheezy-backports and joined it to my DC. The
>>>> same
>>>> problem exists on that new member server. I don't get the AD groups
>>>> displayed by command "getent group" but with " getent group 'Domain
>>>> Users' "
>>>> or " getent group 10000 " they are displayed correctly.
>>>>
>>>> Where is that issue related to?
>>>
>>> It is related to a known problem, if indeed it is a problem, you will
>>> have
>>> to give **every** group a gidNumber to get 'getent group' to work like
>>> 'getent paswd'. If I was you, I wouldn't worry about it, everything else
>>> seems to work.
>>>
>> Perhaps not anything to worry about. But isn't uid- and gidNumber to
>> be considered the "bridge", in some sense, between the Windows-world
>> and Linux-world? And winbind is the interpretator? Wouldn't it be
>> better to advice to assign both uid- and gidNumbers to user accounts
>> and gidNumbers to groups? For compatability sake?
>
>
> What you are saying is indeed true, but you only need to add uidNumber's &
> gidNumber's to users & groups that you want/need to be visible to Unix and
> you would also have to use the winbind 'ad' backend (other similar programs
> are available)
>
>>
>>>> (2.) For my understanding please anyone explain to me. Every user or
>>>> group
>>>> I want to make usable on a member server *needs* to have a uid or gid
>>>> assigned on the [UNIX attribute] tab, correct? On the other side, I was
>>>> told
>>>> *NEVER* ever assign a UNIX attribute UID to the "MYDOM\Administrator"
>>>> account on the [UNIX attribute] tab in ADUC tool. So how should that
>>>> special
>>>> user "MYDOM\Administrator" be available for my member server? He cannot
>>>> in
>>>> my opinion, and so winbind never will be able to use him.
>>>
>>>
>>> Look. ignore what ever dev it was that told you not to use the smbmap,
>>> just
>>> use it, **everybody** who has any sense uses it.
>>>
>> I have stopped using usermapping because I get the following error in
>> smbd.log:
>>
>> [2014/10/23 21:32:46.464772, 0]
>> ../lib/util/become_daemon.c:136(daemon_ready)
>> STATUS=daemon 'smbd' finished starting up and ready to serve
>> connectionsFailed to fetch record!
>> [2014/10/23 21:32:49.389720, 0]
>> ../source3/smbd/uid.c:153(check_user_share_access)
>> user root connection to home denied due to share security descriptor.
>> [2014/10/23 21:32:49.475638, 0]
>> ../source3/smbd/uid.c:153(check_user_share_access)
>> user root connection to home denied due to share security descriptor.
>>
>> I also get access denied to the security tab in Computer Management
>> MMC/Shared Folders/Shares/<ShareName>. Trying to have a peek at
>> Computer Management MMC/Shared Folders/Sessions renders an access
>> denied message box. Likewise for "Open Files". Commenting "username
>> map" makes it all work again.
>
>
> I would think that you have other problems, I use smbmap without problem,
> also there are probably quite a lot of other people using smbmap and I have
> never heard of the problems that you have posted.
>
I don't have problems. As implied above; I have assigned uidNumber and
gidNumber to all domain accounts, including the domain administrator
account. And all groups as well, built-in or man made.
Some history:
First create a directory and add it to the [share] in smb.conf.
Nothing new here.
root at ostraaros:~# ls -al /data/
drwxr-xr-x 2 root root 4096 Oct 26 09:26 test2
Start Computer Management MMC, open Shares and show Properties about
the share gives me an access denied. But adding 'smbmap' to smb.conf
allows me to view the properties and looks like this:
Share-ACL:
C:\Users\administrator>setacl -on \\ostraaros\test2 -ot shr -actn list
\\ostraaros\test2
DACL(not_protected):
Everyone full allow no_inheritance
SetACL finished successfully.
And the NTFS ACL:
C:\Users\administrator>setacl -on \\ostraaros\test2 -ot file -actn
list \\ostraaros\test2
DACL(not_protected):
Unix User\root full allow no_inheritance
Unix Group\root read_execute allow no_inheritance
Everyone read_execute allow no_inheritance
Creator Owner full allow container_inherit+object_inherit+inherit_only
Creator Group read_execute allow
container_inherit+object_inherit+inherit_only
Everyone read_execute allow
container_inherit+object_inherit+inherit_only
SetACL finished successfully.
C:\Users\administrator>
Adding the group 'Domain Admins' to the share-ACL and removing
'Everyone' renders me access denied to the Security tab. Removing any
of the ACEs in the Security tab is not possible.
Running the command below and all possibilities to edit both share-
and NTFS-ACLs suddenly appears and all seems correct (from a Windows
point of view).
root at ostraaros:~# chown -R administrator:root /data/test2/
root at ostraaros:~# ls -al /data/
drwxr-xr-x 2 administrator root 4096 Oct 26 09:26 test2
Changing ACLs also changes the POSIX accesslist from 755 to 770.
root at ostraaros:~# ls -al /data/
drwxrwx---+ 2 administrator root 4096 Oct 26 09:26 test2
But simultanously I get the error mentioned, so I comment 'username
map' in smb.conf. All works fine. And I can also have a peek at
Sessions and Open Files. This was not possible when using 'smbmap.
Giving this a little more thought, I come to this conclusion: all
Windows servers, may it be a member server or a MS ADS DC (Microsoft
Active Directoy Services Domain Controller), contains the well known
SIDs -500 and -544 (well explained here:
http://support2.microsoft.com/kb/243330).
Samba has got the groupmapping shown with
root at ostraaros:~# net groupmap list
Administrators (S-1-5-32-544) -> BUILTIN\administrators
Users (S-1-5-32-545) -> BUILTIN\users
root at ostraaros:~#
but no 'local administrator' account (-500). The closest a Linux
server installed with Samba comes to a local administrator account is
root. The domain administrator account (EXAMPLE\Administrator)
should/could be a member of BUILTIN\Administrators (-544).
Using 'smbmap' to map the domain administrator account to the local
root account is a really ugly circumvention. And not correct. Is there
any unwanted securtiy issues involved with mapping domain
administrator account to the local root account?
>> I'm not that sure that "username map" is the right way to solve this.
>> But assign a uid- and gidNumber to all user accounts and gidNumber to
>> all groups is. Even the Administrator account is just a user account.
>> But with really elevated priviliges.
>
>
> OK, what uidNumber do you suggest we use for Administrator ?? if you give it
> any other number than '0' it becomes just another user as far as Unix is
> concerned and as such, can only do what a standard user can do. Do I hear
> you saying 'what about sudo ?' , well yes, but what does this do, it makes
> the user run as user '0'. If you examine idmap.ldb what does the
> Administrator get mapped to ?? I will save you the bother, it is '0'
> What does smbmap do ? it maps a domain user to a unix user, so by using
> smbmap you can map the domain user 'Administrator' to the local user 'root',
> who just so happens to have the uidNumber '0'.
>
This is the AD DC, right? And the domain administrator account? It
doesn't matter what uidNumber and gidNumber you assign this or any
other account. Winbind on memberservers and -clients will check the
uidNumber and gidNumber attributes. Not the xidNumber. I think you
should treat xidNumbers as an internal representation needed for the
AD DC or the AD DCs (plural) in collaboration.
Regards
Davor
> Rowland
>
>>
>> Regards
>> Davor
>>
>>> Rowland
>>>
>>>
>>>> Any help appreciated. Thanks to all.
>>>>
>>>> Mirco
>>>
>>>
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions: https://lists.samba.org/mailman/options/samba
>
>
> --
> 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