[Samba] samba 4 ad member - idmap = ad for machine accounts
k.wirski at babkamedica.pl
Sun Sep 17 21:49:41 UTC 2017
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
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
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:
>> 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.
>> 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
>> 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,
> 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
> 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.
More information about the samba