On 12/11/2020 13:27, Jason Keltz via samba wrote:> > On 11/12/2020 8:17 AM, Rowland penny via samba wrote: >> On 11/11/2020 10:54, Jason Keltz via samba wrote: >>> Hi Louis, >>> I've looked into that and I'm not sure how this would be done? >>> By the way, even with your NFS translation fix (which doesn't work >>> for me because gssproxy), do you do this before accessing root files..? >>> sudo root >>> kinit -k 'host$' >>> >> OK, after a bit of a battle, I now have a Centos 7 Unix domain member >> mounting an NFS share from a Devuan NFS4 server. >> >> The actual mount wasn't a problem, it was getting the NFS server to >> work ? >> >> I used Samba AD DC's for the authentication, a Unix domain member as >> the NFS server and a Centos 7 Unix domain member as the NFS client. I >> did minimal setup on the Centos machine. > > Hi Rowland, > > The problem wasn't getting NFS to work - it was getting NFS "root" > access to work between a CentOS 7 client and CentOS 7 server? (AKA > no_root_squash in /etc/exports). > > Finally, after a significant amount of effort, I figured that out last > night. > > In my case, I needed to add a realms section for realm > AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows: > > [realms] > ? AD.EECS.YORKU.CA = { > ??? auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/ > ??? auth_to_local = DEFAULT > ? } > > This allows root on "J1" to "really" be root.? Additional of the first > line are required for each system.? The DEFAULT line is required.?? > Lots of fun let me tell ya. > > Jason. > >Define what you mean by 'really root' ? The root user is a Unix user and, as such, has nothing to do with AD (or NFS). If you can login into a Unix domain member, you should be able to use root and if you login into a Windows domain member, then try to use root, it should go 'root ? who is that ?' So, when you log into a Unix domain member, what isn't working ? Rowland
On 11/12/2020 8:52 AM, Rowland penny via samba wrote:> On 12/11/2020 13:27, Jason Keltz via samba wrote: >> >> On 11/12/2020 8:17 AM, Rowland penny via samba wrote: >>> On 11/11/2020 10:54, Jason Keltz via samba wrote: >>>> Hi Louis, >>>> I've looked into that and I'm not sure how this would be done? >>>> By the way, even with your NFS translation fix (which doesn't work >>>> for me because gssproxy), do you do this before accessing root >>>> files..? >>>> sudo root >>>> kinit -k 'host$' >>>> >>> OK, after a bit of a battle, I now have a Centos 7 Unix domain >>> member mounting an NFS share from a Devuan NFS4 server. >>> >>> The actual mount wasn't a problem, it was getting the NFS server to >>> work ? >>> >>> I used Samba AD DC's for the authentication, a Unix domain member as >>> the NFS server and a Centos 7 Unix domain member as the NFS client. >>> I did minimal setup on the Centos machine. >> >> Hi Rowland, >> >> The problem wasn't getting NFS to work - it was getting NFS "root" >> access to work between a CentOS 7 client and CentOS 7 server? (AKA >> no_root_squash in /etc/exports). >> >> Finally, after a significant amount of effort, I figured that out >> last night. >> >> In my case, I needed to add a realms section for realm >> AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows: >> >> [realms] >> ? AD.EECS.YORKU.CA = { >> ??? auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/ >> ??? auth_to_local = DEFAULT >> ? } >> >> This allows root on "J1" to "really" be root.? Additional of the >> first line are required for each system.? The DEFAULT line is >> required.?? Lots of fun let me tell ya. >> >> Jason. >> >> > Define what you mean by 'really root' ? > > The root user is a Unix user and, as such, has nothing to do with AD > (or NFS). > > If you can login into a Unix domain member, you should be able to use > root and if you login into a Windows domain member, then try to use > root, it should go 'root ? who is that ?' > > So, when you log into a Unix domain member, what isn't working ?Rowland, In the NFS world, by default, "root" on the NFS client is actually mapped to user "nobody" or "nfsnobody" on the NFS share for security.? Try it.? Go into the NFS share, and touch a file as root. ?? With a sec=sys mount (no Kerberos security), you can allow root on the NFS client to access the NFS filesystem as root only if you export the share with the no_root_squash option (which is not the default).? With Kerberos, sec=krb5, etc. in order to not have root mapped to nfsnobody on the NFS share, you have to do use the no_root_squash option, PLUS the additional step that I described (at least for CentOS 7 with gssproxy).? When using Debian, without gssproxy, you would use /etc/idmapd.conf in the way that Louis described for creating a translation of the root user to "root". Jason.
On 12/11/2020 14:19, Jason Keltz via samba wrote:> > On 11/12/2020 8:52 AM, Rowland penny via samba wrote: >> On 12/11/2020 13:27, Jason Keltz via samba wrote: >>> >>> On 11/12/2020 8:17 AM, Rowland penny via samba wrote: >>>> On 11/11/2020 10:54, Jason Keltz via samba wrote: >>>>> Hi Louis, >>>>> I've looked into that and I'm not sure how this would be done? >>>>> By the way, even with your NFS translation fix (which doesn't work >>>>> for me because gssproxy), do you do this before accessing root >>>>> files..? >>>>> sudo root >>>>> kinit -k 'host$' >>>>> >>>> OK, after a bit of a battle, I now have a Centos 7 Unix domain >>>> member mounting an NFS share from a Devuan NFS4 server. >>>> >>>> The actual mount wasn't a problem, it was getting the NFS server to >>>> work ? >>>> >>>> I used Samba AD DC's for the authentication, a Unix domain member >>>> as the NFS server and a Centos 7 Unix domain member as the NFS >>>> client. I did minimal setup on the Centos machine. >>> >>> Hi Rowland, >>> >>> The problem wasn't getting NFS to work - it was getting NFS "root" >>> access to work between a CentOS 7 client and CentOS 7 server? (AKA >>> no_root_squash in /etc/exports). >>> >>> Finally, after a significant amount of effort, I figured that out >>> last night. >>> >>> In my case, I needed to add a realms section for realm >>> AD.EECS.YORKU.CA and include 2 auth_to_local rules as follows: >>> >>> [realms] >>> ? AD.EECS.YORKU.CA = { >>> ??? auth_to_local = RULE:[1:$1@$0](J1\$@AD.EECS.YORKU.CA)s/.*/root/ >>> ??? auth_to_local = DEFAULT >>> ? } >>> >>> This allows root on "J1" to "really" be root.? Additional of the >>> first line are required for each system.? The DEFAULT line is >>> required.?? Lots of fun let me tell ya. >>> >>> Jason. >>> >>> >> Define what you mean by 'really root' ? >> >> The root user is a Unix user and, as such, has nothing to do with AD >> (or NFS). >> >> If you can login into a Unix domain member, you should be able to use >> root and if you login into a Windows domain member, then try to use >> root, it should go 'root ? who is that ?' >> >> So, when you log into a Unix domain member, what isn't working ? > > Rowland, > > In the NFS world, by default, "root" on the NFS client is actually > mapped to user "nobody" or "nfsnobody" on the NFS share for security.? > Try it.? Go into the NFS share, and touch a file as root. ?? With a > sec=sys mount (no Kerberos security), you can allow root on the NFS > client to access the NFS filesystem as root only if you export the > share with the no_root_squash option (which is not the default).? With > Kerberos, sec=krb5, etc. in order to not have root mapped to nfsnobody > on the NFS share, you have to do use the no_root_squash option, PLUS > the additional step that I described (at least for CentOS 7 with > gssproxy).? When using Debian, without gssproxy, you would use > /etc/idmapd.conf in the way that Louis described for creating a > translation of the root user to "root". > > Jason. > > >Well, you learn something new everyday ? I suppose the next question is, why do you need to use root in a NFS share ? I keep reading that is easier to use NFS instead of CIFS, which it may be, just as long as you do not want to secure it with Kerberos. I think I will stick to CIFS ? Rowland