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

Rowland Penny rowlandpenny at googlemail.com
Fri Oct 24 03:27:58 MDT 2014


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'm not that sure that "username map" is the right way to solve this.
> But assign a uid- and gidNumber to all user accounts and gidNumber to
> all groups is. Even the Administrator account is just a user account.
> But with really elevated priviliges.

OK, what uidNumber do you suggest we use for Administrator ?? if you 
give it any other number than '0' it becomes just another user as far as 
Unix is concerned and as such, can only do what a standard user can do. 
Do I hear you saying 'what about sudo ?' , well yes, but what does this 
do, it makes the user run as user '0'. If you examine idmap.ldb what 
does the Administrator get mapped to ?? I will save you the bother, it 
is '0'
What does smbmap do ? it maps a domain user to a unix user, so by using 
smbmap you can map the domain user 'Administrator' to the local user 
'root', who just so happens to have the uidNumber '0'.

Rowland
>
> Regards
> Davor
>
>> Rowland
>>
>>
>>> Any help appreciated. Thanks to all.
>>>
>>> Mirco
>>
>> --
>> 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