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

Davor Vusir davortvusir at gmail.com
Mon Oct 27 07:33:52 MDT 2014

2014-10-27 10:52 GMT+01:00 Rowland Penny <rowlandpenny at googlemail.com>:
> 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: http://technet.microsoft.com/en-gb/library/cc783323%28v=ws.10%29.aspx
It was not my intention to neither insult you nor offend you. My apoligies.

I'm not trying to stop root from doing anything. I don't have an
account named root in AD. Nor a group with that name. Commenting
'winbind use default domain = yes' makes it clearer. See listing
below. The root account (Unix User\root) in the listing above is the
root account on the Linux server (from /etc/passwd).

root at ostraaros:~# getent passwd
root:x:0:0:root Ostraaros:/root:/bin/bash
EXAMPLE\davor:*:11105:10513:Davor Vusir:/data/home/davor:/bin/false

root at ostraaros:~# getent group
EXAMPLE\allowed rodc password replication group:x:10571:
EXAMPLE\enterprise read-only domain controllers:x:10498:
EXAMPLE\denied rodc password replication group:x:10572:EXAMPLE\krbtgt
EXAMPLE\read-only domain controllers:x:10521:
EXAMPLE\group policy creator owners:x:10520:EXAMPLE\administrator
EXAMPLE\ras and ias servers:x:10553:
EXAMPLE\domain controllers:x:10516:
EXAMPLE\enterprise admins:x:10519:EXAMPLE\administrator
EXAMPLE\domain computers:x:10515:
EXAMPLE\cert publishers:x:10517:
EXAMPLE\domain admins:x:10512:EXAMPLE\administrator
EXAMPLE\domain guests:x:10514:
EXAMPLE\schema admins:x:10518:EXAMPLE\administrator
EXAMPLE\domain users:x:10513:

And a directory listing:
root at ostraaros:~# ls -al /data/
total 48
drwxr-xr-x   8 root                root                4096 Oct 26 09:26 .
drwxr-xr-x  23 root                root                4096 Oct 14 21:08 ..
drwxrwx---+ 24 EXAMPLE\administrator root                4096 Oct  5
17:31 common
drwxrwx---+ 11 root                users               4096 Oct  2 06:40 home
drwxrwx---+  2 EXAMPLE\davor         EXAMPLE\domain admins 4096 Aug 12
20:38 test
drwxrwx---+  2 EXAMPLE\administrator root                4096 Oct 26 09:26 test2
drwxr-xr-x   6 libvirt-qemu        libvirtd            4096 Jul 15 06:30 virt
root at ostraaros:~#

> 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:
The account root is from the Linux server. It is not a account in AD.
See listing above.

> rowland at ThinkPad ~ $ getent passwd
> root:x:0:0:root:/root:/bin/bash
> ~ ~ ~ ~ ~ ~ ~ ~
> root:*:10007:10000:root:/root:/bin/bash
> Still think it is a good idea ??
Yes. I do.


> Rowland
> Going now to delete the 'phantom' root user!!
> --
> 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