Kacper Wirski
2017-Sep-17 21:49 UTC
[Samba] samba 4 ad member - idmap = ad for machine accounts
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 >
Rowland Penny
2017-Sep-18 07:12 UTC
[Samba] samba 4 ad member - idmap = ad for machine accounts
On Sun, 17 Sep 2017 23:49:41 +0200 Kacper Wirski via samba <samba at lists.samba.org> wrote:> Hello, > > I think I'm not explaining the issue correctly and I'm being > misunderstood. >I have asked once, but I will ask again, please post your full smb.conf from the Unix domain member. Rowland
Kacper Wirski
2017-Sep-18 11:57 UTC
[Samba] samba 4 ad member - idmap = ad for machine accounts
I posted already, but here it is again (it's everythign except it has not 1 but ~10 SOMESHARE, all with exact same config) Full entry from smb.conf: [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 for domain MYDOMAIN idmap config MYDOMAIN:backend = ad idmap config MYDOMAIN:schema_mode = rfc2307 idmap config MYDOMAIN:range = 4000-99999 #I'm gonna remove enum users/groups as recommended winbind enum users = yes winbind enum groups = yes winbind nested groups = yes winbind expand groups = 5 #i'm gonna remove this one too to avoid confusion winbind use default domain = yes winbind nss info = rfc2307 vfs objects = acl_xattr map acl inherit = yes admin users = "@MYDOMAIN\Domain Admins","@MYDOMAIN\Enterprise Admins" store dos attributes = yes [SOMESHARE1] path = /home/shares/SOMESHARE1/ read only = no [SOMESHARE2] path = /home/shares/SOMESHARE2/ read only = no ...... [SOMESHARE10] path = /home/shares/SOMESHARE10/ read only = no ............. Correct me please if I'm wrong, but: idmap = AD means that winbind on the samba 4 domain member, when idmapping domain users looks at: gidNumber uidNumber attributes set in AD for this users when mapping windows - to - unix users? At least these values i'm getting from samba 4 domain member when using getent for domain users and these values can be viewed when looking at files from unix perspective. At first I thought, that setting those values for machine accounts, as long as they're in range of the MYDOMAIN:range should be enough, but I was unable to make it work, I'm getting access denied. Since changing from idmap = ad to idmap = rid fixes everything it leads me to believe some other attribute is checked by winbindd when doing domain-to-local user mappings.