[Samba] Samba4: "MYDOM\Administrator" quite useless on a member server?
Rowland Penny
rowlandpenny at googlemail.com
Mon Oct 27 08:07:47 MDT 2014
On 27/10/14 13:33, Davor Vusir wrote:
> 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.
Hi, I never felt insulted, so no apology required ;-)
>
> 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).
oops, my mistake.
> root at ostraaros:~# getent passwd
> root:x:0:0:root Ostraaros:/root:/bin/bash
> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
> ...
> ntp:x:111:121::/home/ntp:/bin/false
> dnsmasq:x:108:65534:dnsmasq,,,:/var/lib/misc:/bin/false
> EXAMPLE\administrator:*:10500:10513:Administrator:/data/home/administrator:/bin/false
OK, by giving 'Administrator' the uidNumber of '10500' you have turned
him into a standard user as far as Unix is concerned, now there is no
difference between him and any other Unix user.
There is only one admin user on Unix, that is 'root' and root's id is
'0', so if you want the windows admin user 'Administrator' to do on Unix
what the Unix user 'root' can, then 'Administrator' must pretend to be
'root', you do this by the use of smbmap.
Rowland
> EXAMPLE\davor:*:11105:10513:Davor Vusir:/data/home/davor:/bin/false
> EXAMPLE\dns-dc1:*:11123:10513:dns-DC1:/data/home/dns-dc1:/bin/false
> EXAMPLE\krbtgt:*:10502:10513:krbtgt:/data/home/krbtgt:/bin/false
> EXAMPLE\guest:*:10501:10514:Guest:/data/home/guest:/bin/false
>
> root at ostraaros:~# getent group
> root:x:0:
> ...
> libvirtd:x:120:admind,root
> ntp:x:121:
> 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\fileacc-common:x:11107:EXAMPLE\davor
> EXAMPLE\cert publishers:x:10517:
> EXAMPLE\dnsupdateproxy:x:11103:
> EXAMPLE\domain admins:x:10512:EXAMPLE\administrator
> EXAMPLE\domain guests:x:10514:
> EXAMPLE\schema admins:x:10518:EXAMPLE\administrator
> EXAMPLE\domain users:x:10513:
> EXAMPLE\fileacc-home:x:11106:EXAMPLE\davor
> EXAMPLE\dnsadmins:x:11102:
>
> 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.
>
> Regards
> Davor
>
>> 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