[Samba] Samba4: "MYDOM\Administrator" quite useless on a member server?
L.P.H. van Belle
belle at bazuin.nl
Mon Oct 27 08:41:12 MDT 2014
I dont get this problem, so i did sum it up.
>>>>>>> Why does "getent group" *NOT* returning the AD domain groups.
answer, this is by design in samba. to save cpu load on the DC's as far as i know.
google for it. the devs already told this, its somewhere in the list also.
>>>> isn't uid- and gidNumber to be considered the "bridge" to between the Windows-world and Linux-world?
answer, no it isnt, UID = UID , GID = GID, and has nothing to do with windows.
IMO. A windows user with a UID = just a linux user. ( depending where you login )
>>>>>>> I was told *NEVER* ever assign a UNIX attribute UID to the "MYDOM\Administrator"
>>>>>>> account on the [UNIX attribute] tab in ADUC tool.
Correct, you should NEVER assign any UID/GID to the Domain Administrator.
AND on a member server use the user mapping file/config.
AND you should not create a windows user account which exist already in linux!
>>>>>>> Wouldn't it be better to advice to assign both uid- and gidNumbers to user accounts
>>>>> and gidNumbers to groups? For compatability sake?
No, samba documentation says, that this isnt needed, this is done by samba.
go read : https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server again. the part after the smb.conf example.
and read: https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC after teh Advantages part.
Im thinking your mixing 2 things.
>>>>> I have stopped using usermapping because I get the following error in smbd.log: ....
and you did enable the privileges for the "Adminstrator or SomeGroup" ?
which needs to me done on ALL member servers.
I dont see any errors here.
>>>>> 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.
Im thinking here you did something wrong, or you assinged to an account which should not.
https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC
Using ADUC to set Unix Attributes on groups ..
It's not required to add users to the group in this tab! Winbind, sssd and nslcd retrieve the account membership from the Windows groups
>> root:x:0:0:root:/root:/bin/bash
>> ~ ~ ~ ~ ~ ~ ~ ~
>> root:*:10007:10000:root:/root:/bin/bash
will go give problems on the long run..
( i know i tried something like this about 10 years ago. )
>> Comment from Rowland.
>> 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.
>>
YES!!! thats correct. ... and for that you need to use the usermapping setting on a member server.
SO whats the problem besides, and this im guessing base on above.
1) you need windows users in linux groups ?
2) you need unix users in windows groups?
3) you need to have windows users work with unix users
4) did you set the privileges on the member server for groups which need it.
5) you need to set the user mapping file.
6) when all done, you need to setup your rights ( and share rights)
again.. since what you tried will mess up the rights in the long run.
7) remember ADDC samba is NOT member server Samba, 2 complete different things and setups.
But,, its just a suggestion, you can go trie what you want but you will get the same advice from us.
Louis
>-----Oorspronkelijk bericht-----
>Van: davortvusir at gmail.com
>[mailto:samba-bounces at lists.samba.org] Namens Davor Vusir
>Verzonden: maandag 27 oktober 2014 14:34
>Aan: samba at lists.samba.org
>Onderwerp: Re: [Samba] Samba4: "MYDOM\Administrator" quite
>useless on a member server?
>
>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/ad
>ministrator:/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
>--
>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