[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
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
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