Web lists-archives.com

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


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@xxxxxxxxxxxxxxx> 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.


To unsubscribe from this list go to the following URL and read the
instructions:  https://lists.samba.org/mailman/options/samba