[Samba] samba 4 ad member - idmap = ad for machine accounts

Sun Sep 17 21:49:41 UTC 2017

Hello,

I think I'm not explaining the issue correctly and I'm being misunderstood.

I'll give an example:

windows 7 machine PC1$ is running AD GPO startup script that forces it 
to read some files from network share hosted on the centos server with 
samba 4.

The script will be run as windows SYSTEM user (that's the default 
behaviour of autostart scripts).

But since SYSTEM is a local windows user it's unable to authenticate to 
the network share, Windows knows this, so to access network share will 
try to use credentials of the PC1$ machine account instead (the only one 
it really knows), and it fails. It fails becuase samba is unable to map 
PC$ to any of the accounts from smb.conf, since it PC1$ will have NO UID 
no PRIMARY GROUP etc.. It won't have those values, because idmap = ad 
forces samba member to read those values from AD, and machine accounts 
don't have those set in any way, that I was able to find.

At first I thought that setting windows ACL should "just work" but it 
didn't, only switching idmap to rid helped, as I was unable to find the 
correct attributes to set in the AD for machineaccounts$ - that's why I 
asked my question :)

I've tried creating a clone of this server with only difference in 
smb.conf being idmap = rid.  And then everything works flawlessly, with 
all machine accounts$ being able to do, what I need to them to do. This 
is obvious to me, that all I'm lacking is some settings in machine 
accounts (domain joined windows machines) in the ldap attributes, those 
attributes that are set with windows RSAT - unix attributes: nisdomain, 
user id, primary group

So my goal is to enable "MYDOMAIN\Domain Computers" or any of the 
machineaccounts$ to be able to access read/write files from samba 4 
domain server.

As to my smb.conf.

The values for ranges are working for me, because no user and or groups 
in passwd or groups are "overlapping".

The server is a centos minimal install with just samba 4 running and has 
no "local" users except for some default system (with uids <100) and 
will never ever use any. It's a virtual machine used ONLY as a file 
server without any users except for root. It was used as file server for 
some time without issues - except for the "domain computers" group 
and/or individual machine accounts (computer accounts that is).

The script is windows batch script. When script is used as GPO for 
"autostart" it's ran as local SYSTEM, soe when SYSTEM looks up if file 
exists in network share it's trying to use it's "machineaccount$" to 
access and that's when it fails with idmap = ad, but succeeds with idmap 
= rid. And that's because for idmap = ad I have to set proper UID and 
nisdomain values through RSAT (or other means) to users. ANd while there 
is good tool for "normal" accounts, it's unavaiable for computer accounts.

Yes, computer accounts are almost the same as user accounts, but from 
windows RSAT point of view, the options are not the samme. WHat I'm 
simply asking is this:

- which of the machineaccount$ AD attributes should be "manually" 
edited, to achieve same effect, as setting nisdomain and UID through 
windows RSAT unix extension? I've been looking at the ldap editor, I've 
managed to get the attributes which should be enough (I think primary 
group, uid and gid), I managed to get proper output from winbind: it was 
able to read the user id and group id of one of the machine accounts, 
but still didn't allow it access to the share.

I hope I'm making myself clear enough.

W dniu 2017-09-17 o 22:46, Rowland Penny via samba pisze:
> On Sun, 17 Sep 2017 21:37:37 +0200
> Kacper Wirski via samba <samba at lists.samba.org> wrote:
>
>> Hello,
>> Thanks for quick reply.
>>
>> File server config looks exactly like this, except more shares, all
>> with same simple config. I know that "use defualt domain" isn't
>> necessery, but it's not the issue for me right now.
>>
>> [global]
>>          netbios name = VS-FILES
>>          security = ADS
>>          workgroup = MYDOMAIN
>>          realm = MYDOMAIN.COM
>>
>>          log file = /var/log/samba/%m.log
>>          log level = 1
>>
>>          idmap config *:backend = tdb
>>          idmap config *:range = 100-2000
>>
>>
>>          idmap config MYDOMAIN:backend = ad
>>          idmap config MYDOMAIN:schema_mode = rfc2307
>>          idmap config MYDOMAIN:range = 4000-99999
> Have you read the Samba wikipage I pointed you to ?
>
> Your '*' range tramples all over the local system users and ends 1000
> above where the local Unix users & groups are supposed to be stored.
>
>>           winbind enum users = yes
>>           winbind enum groups = yes
> You should remove the above two lines once you have everything working,
> you should only use them for testing purposes.
>
>>           winbind nested groups = yes
>>           winbind expand groups = 5
>>           winbind use default domain = yes
>>           winbind nss info = rfc2307
>>           vfs objects = acl_xattr
>>           map acl inherit = yes
>>           store dos attributes = yes
>>
>> [SOME_SHARE]
>>           path = /home/shares/SOME_SHARE/
>>           read only = no
>>
>>
>>
>> Some uses I have for machine accounts:
>> 1) I have v. important windows application that is running as windows
>> service as "SYSTEM" account. It writes a lot of image-type files.
>> Because it's running as SYSTEM, machine account has to have
>> "read/write" to the share.
> 'SYSTEM' is a Windows group and is meaningless to Unix, it should be
> mapped to a Unix ID only on a Samba AD DC and there it is an
> 'xidNumber' not a 'uidNumber or 'gidNumber'. Running 'wbinfo -S
> S-1-5-18' (the SID for 'SYSTEM' is S-1-5-8-18) on a UNIX domain member,
> returns:
> failed to call wbcSidToUid: WBC_ERR_DOMAIN_NOT_FOUND
> Could not convert sid S-1-5-18 to uid
>
> However "wbinfo -Y  S-1-5-18" returns:
> 2005 (note your ID may be different)
>
> As I said, you could use the kerberos machine account instead, but are
> these scripts being run on the fileserver, Samba DC or windows
> machines ? if the later, then you shouldn't need a Unix IDs.
>
>> 2)'m using some machine autostart scripts, for various tasks, which
>> work again as SYSTEM, so if they have to get anything from network
>> share, they need to have read/write permission. What I'm doing is,
>> for example, as autostart run a batch script, that would check
>> \\fileserver\public\test-file.txt if %COMPTURNAME% exists in this
>> file. if not - run some robocopy script, then >> %COMPUTERNAME% to
>> the end of the file.
>> or even something simple like this:
>> "if exist \\server\share\%computername%.txt (exit)
>> else robocopy some-files
>> echo . > \\server\share\%computername%.txt
>> exit"
> That looks like a Windows script (not that I am an expert on Windows
> script languages) so I presume that it is run a Windows machine and
> 'SYSTEM' should be available on it via its name or SID.
>
>> 3) Some windows applications that I use also run as SYSTEM account
>> and they have built-in backup utilities, and if I want to backup
>> straight to network share - again - machine account needs direct
>> write access to share.
> Hmm, I think I am beginning to understand your problem, you are
> confusing 'SYSTEM' with the computers account in AD.
>
> 'SYSTEM' does not exist in AD, so you cannot give it a uidNumber or
> gidNumber attribute.
>
> I think you need to find another way to do what you are doing now.
>
>> I do know that machine accounts are "normal" accounts, and I tried
>> simply adding them to windows ACL, but it just tidn't work. I had to
>> go with "idmap = rid", and it did just fine, so the issue must be
>> iwth idmap backend - ad not supplying valid uid for winbind, right?
>>
> You should be able to add a uidNumber to a computer, but to make it
> work as a user on Unix, you will have to give the Domain Computers
> group a gidNumber.
>
> Rowland
>