[Samba] Samba4: "MYDOM\Administrator" quite useless on a member server?

Rowland Penny rowlandpenny at googlemail.com
Mon Oct 27 03:52:21 MDT 2014

On 27/10/14 08:07, Davor Vusir wrote:
> 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>
Two things from the above jump out at me, one you are trying to stop 
root doing something, good luck with that on a Unix machine. secondly, 
you have a user called 'root' and a group called 'root', don't know how 
you managed that because it is not supposed to be possible (or allowed 
anyway), see here: 

Look under 'To create a user account on a local computer'

You have also given the Unix user 'root' a uidNumber, I have never done 
this, so I thought I would give it a try, I first had to create 'root' 
in AD and then add the 'uidNumber', well yes it works, BUT I now have 
two 'root' users:

rowland at ThinkPad ~ $ getent passwd
~ ~ ~ ~ ~ ~ ~ ~

Still think it is a good idea ??


Going now to delete the 'phantom' root user!!

More information about the samba mailing list