On 11/9/2020 3:00 PM, Rowland penny via samba wrote:> On 09/11/2020 19:41, Jason Keltz via samba wrote: >> Hi. >> >> I have Samba AD configured correctly, and can mount kerberized NFS >> from all the CentOS 7 clients.? I'm not able to use "root" on the >> client even though the nfs export specifies the option: >> no_root_squash option. >> >> I completely understand that in order to use the "root" identity >> (which doesn't exist as a user in the domain) on the NFS client, this >> identity has to be mapped to somewhere else.? That's why my samba >> config specifies a file for "username map" which contains: >> >> !root = SAMDOM\Administrator > This works in the opposite way to what you think it does, it maps > Administrator on the client to root on the server i.e. it allows > Administrator on one machine to do things on another. The only problem > is that Administrator is a Windows user and shouldn't be used on a > Unix machine, so it only really works from Windows machines.Ah... got it.. thanks.. my misunderstanding.>> >> I figured that I should just need to do a "kinit Administrator" on >> the client, and take on the root identity, then I could write as root >> where I have no_root_squash configured...? However, when I tried this >> on a client, I get a permission denied when trying to write. > > You need to do the kinit as root or using sudo, so the resultant > ticket belongs to root. >So that would mean I need to "samba-tool user create root "password" ?? I was under the impression that the "idmapd.conf" mapping would have avoided that.. But that's fine... I created "root" with samba-tool, then did a kinit root, but removed all the other things I did, and it surprisingly still doesn't work.>> >> I saw a reference to adding? to /etc/idmapd.conf a static mapping: >> >> Method = static,nsswitch >> [Static] >> MYHOST$@MYREALM = root >> >> ... but it's really not clear why this would be necessary if the >> username map entry is working. I added this on the server and it's >> not working either after restarting rpcidmapd. > The username map is probably working, just not as you think.Do I still need this in nfsidmap.conf?>> >> I also saw a red hat document that talked about adding to >> /etc/krb5.conf: >> >> [realms] >> ? >> EXAMPLE.COM = { >> ? >> auth_to_local = >> RULE:[2:$1/$2@$0](host/nfsclient.example.com at EXAMPLE.COM)s/.*/root/ >> auth_to_local = DEFAULT >> } >> >> ... but that doesn't seem to change the permission denied. > > Not sure if that will work. > > Where do you have the username map defined, if it is on the DC, remove > it immediately, the mapping is already done in idmap.ldb.I just uncommented those lines, and doesn't make a difference either... I had the username map defined on the DC and on all the AD clients.? They all actually point to the same file, but it only has that one line and it's otherwise just empty (which is the case now).? I restart the samba-ad-dc on DC and rebooted the client... no difference.> > Can you please post the smb.confSure.. on the dc: # Global parameters [global] ??????? netbios name = DC1 ??????? realm = AD.EECS.YORKU.CA ??????? workgroup = EECSYORKUCA ??????? dns forwarder = 130.63.94.4 ??????? server role = active directory domain controller ??????? idmap_ldb:use rfc2307 = yes ??????? interfaces = 127.0.0.1 130.63.94.66 ??????? bind interfaces only = yes [netlogon] ??????? path = /local/samba/sysvol/ad.eecs.yorku.ca/scripts ??????? read only = no ??????? guest ok = no [sysvol] ??????? path = /local/samba/sysvol ??????? read only = no ??????? guest ok = no and on the AD client: [global] workgroup = EECSYORKUCA security = ADS realm = AD.EECS.YORKU.CA dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab idmap config * : backend = tdb idmap config * : range = 1000000-1999999 idmap config EECSYORKUCA : backend = ad idmap config EECSYORKUCA : schema_mode = rfc2307 idmap config EECSYORKUCA : range = 1000-999999 idmap config EECSYORKUCA : unix_primary_group = yes idmap config EECSYORKUCA : unix_nss_info = yes winbind refresh tickets = yes winbind offline logon = yes winbind nss info = rfc2307 winbind use default domain = yes winbind enum users? = no winbind enum groups = no vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes template shell = /bin/bash template homedir = /eecs/home/%U debug timestamp = yes debug uid = yes debug pid = yes debug level = 1 max log size = 0 load printers = no printing = bsd printcap name = /dev/null disable spoolss = yes username map = /xconf/samba/usermap Jason.
On 09/11/2020 20:20, Jason Keltz via samba wrote:> On 11/9/2020 3:00 PM, Rowland penny via samba wrote: >>> I figured that I should just need to do a "kinit Administrator" on >>> the client, and take on the root identity, then I could write as >>> root where I have no_root_squash configured...? However, when I >>> tried this on a client, I get a permission denied when trying to write. >> >> You need to do the kinit as root or using sudo, so the resultant >> ticket belongs to root. >> > So that would mean I need to "samba-tool user create root "password" > ?? I was under the impression that the "idmapd.conf" mapping would > have avoided that..No, 'root' is a Unix user and should never be in AD, the same way that the Windows user 'Administrator' should never be /etc/passwd> > But that's fine... I created "root" with samba-tool, then did a kinit > root, but removed all the other things I did, and it surprisingly > still doesn't work.It wouldn't, see above, I suggest you remove 'root' from AD again.> Do I still need this in nfsidmap.conf?Probably, but I would wait until Louis comments, he uses NFS in production.> > I had the username map defined on the DC and on all the AD clients.? > They all actually point to the same file, but it only has that one > line and it's otherwise just empty (which is the case now).? I restart > the samba-ad-dc on DC and rebooted the client... no difference.The Samba DC's do not need the username.map, but each Unix domain member requires it. Do you have Unix clients ? (not talking about Samba servers here), if you don't, why are you using NFS ?> > on the dc: > > # Global parameters > [global] > ??????? netbios name = DC1 > ??????? realm = AD.EECS.YORKU.CA > ??????? workgroup = EECSYORKUCA > ??????? dns forwarder = 130.63.94.4 > ??????? server role = active directory domain controller > ??????? idmap_ldb:use rfc2307 = yes > ??????? interfaces = 127.0.0.1 130.63.94.66 > ??????? bind interfaces only = yes > > [netlogon] > ??????? path = /local/samba/sysvol/ad.eecs.yorku.ca/scripts > ??????? read only = no > ??????? guest ok = no > > [sysvol] > ??????? path = /local/samba/sysvol > ??????? read only = no > ??????? guest ok = no >The 'guest ok = no' lines are not required, it is the default.> and on the AD client: > > [global] > workgroup = EECSYORKUCA > security = ADS > realm = AD.EECS.YORKU.CA > dedicated keytab file = /etc/krb5.keytab > kerberos method = secrets and keytab > > > idmap config * : backend = tdb > idmap config * : range = 1000000-1999999 > idmap config EECSYORKUCA : backend = ad > idmap config EECSYORKUCA : schema_mode = rfc2307 > idmap config EECSYORKUCA : range = 1000-999999 > idmap config EECSYORKUCA : unix_primary_group = yes > idmap config EECSYORKUCA : unix_nss_info = yesHave you added any uidNumber & gidNumber attributes to AD ? Why are you using '1000' as the start number for the 'EECSYORKUCA' domain, this means you cannot have any local Unix users (not to be confused with Unix domain users). Rowland
On 11/9/2020 3:57 PM, Rowland penny via samba wrote:> On 09/11/2020 20:20, Jason Keltz via samba wrote: >> On 11/9/2020 3:00 PM, Rowland penny via samba wrote: >>>> I figured that I should just need to do a "kinit Administrator" on >>>> the client, and take on the root identity, then I could write as >>>> root where I have no_root_squash configured...? However, when I >>>> tried this on a client, I get a permission denied when trying to >>>> write. >>> >>> You need to do the kinit as root or using sudo, so the resultant >>> ticket belongs to root. >>> >> So that would mean I need to "samba-tool user create root "password" >> ?? I was under the impression that the "idmapd.conf" mapping would >> have avoided that.. > No, 'root' is a Unix user and should never be in AD, the same way that > the Windows user 'Administrator' should never be /etc/passwdSeems I misunderstood again...>> >> But that's fine... I created "root" with samba-tool, then did a kinit >> root, but removed all the other things I did, and it surprisingly >> still doesn't work. > It wouldn't, see above, I suggest you remove 'root' from AD again.Done.> >> Do I still need this in nfsidmap.conf? > Probably, but I would wait until Louis comments, he uses NFS in > production. >> >> I had the username map defined on the DC and on all the AD clients.? >> They all actually point to the same file, but it only has that one >> line and it's otherwise just empty (which is the case now).? I >> restart the samba-ad-dc on DC and rebooted the client... no difference. > > The Samba DC's do not need the username.map, but each Unix domain > member requires it. > > Do you have Unix clients ? (not talking about Samba servers here), if > you don't, why are you using NFS ? >Yes - soon to be several hundred mounting home directories, various software and other stuff over NFS.? That's why I'm doing this.? The NFS part is all working perfectly actually except for root access.>> >> on the dc: >> >> # Global parameters >> [global] >> ??????? netbios name = DC1 >> ??????? realm = AD.EECS.YORKU.CA >> ??????? workgroup = EECSYORKUCA >> ??????? dns forwarder = 130.63.94.4 >> ??????? server role = active directory domain controller >> ??????? idmap_ldb:use rfc2307 = yes >> ??????? interfaces = 127.0.0.1 130.63.94.66 >> ??????? bind interfaces only = yes >> >> [netlogon] >> ??????? path = /local/samba/sysvol/ad.eecs.yorku.ca/scripts >> ??????? read only = no >> ??????? guest ok = no >> >> [sysvol] >> ??????? path = /local/samba/sysvol >> ??????? read only = no >> ??????? guest ok = no >> > The 'guest ok = no' lines are not required, it is the default.Ok .. thanks..>> and on the AD client: >> >> [global] >> workgroup = EECSYORKUCA >> security = ADS >> realm = AD.EECS.YORKU.CA >> dedicated keytab file = /etc/krb5.keytab >> kerberos method = secrets and keytab >> >> >> idmap config * : backend = tdb >> idmap config * : range = 1000000-1999999 >> idmap config EECSYORKUCA : backend = ad >> idmap config EECSYORKUCA : schema_mode = rfc2307 >> idmap config EECSYORKUCA : range = 1000-999999 >> idmap config EECSYORKUCA : unix_primary_group = yes >> idmap config EECSYORKUCA : unix_nss_info = yes > > Have you added any uidNumber & gidNumber attributes to AD ?For sure...? all users have that, in addition to the home directory, shell, etc. That part is all working great..> Why are you using '1000' as the start number for the 'EECSYORKUCA' > domain, this means you cannot have any local Unix users (not to be > confused with Unix domain users).All of our users have uid > 1000.? <1000 would be OS provided users. Jason.