NX Linux-SSSD-AD Issues with NFS4-Kerberos Home Dir

Forum / NoMachine for Linux / NX Linux-SSSD-AD Issues with NFS4-Kerberos Home Dir

Tagged: , ,

Viewing 12 posts - 1 through 12 (of 12 total)
  • Author
    Posts
  • #40221
    fractal-admin
    Participant

    Hi,

    We are trying to NX to a Linux machine that’s directly integrated with SSSD-AD with NFSv4 (sec=krb5) mounted home directories. While doing so we are running into the below errors, can you please help fix this?

    /usr/NX/var/log/nxerror.log

    Info: Handler started with pid 2319 on Tue Sep 20 21:44:44 2022.
    Info: Handling connection from 192.168.0.214 port 38094 on Tue Sep 20 21:44:44 2022.
    2349 2349 21:44:57 797 nxexecPAMCheckCredentials: ERROR! Authentication failed.
    2349 2349 21:44:57 797 nxexecPAMCheckCredentials: Error code ‘7’, ‘Authentication failure’.
    Info: Connection from 192.168.0.214 port 38094 closed on Tue Sep 20 21:44:57 2022.

    /usr/NX/var/log/nxserver.log

    2354 2354 2022-09-20 21:44:58 022.714 NXSERVER Connected from remote machine ‘192.168.0.214’ using protocol ‘NX’.
    2354 2354 2022-09-20 21:45:06 690.856 NXSERVER User ‘contoso’ logged in from ‘192.168.0.214’ using authentication method NX-password.
    2417 2417 2022-09-20 21:45:09 586.763 NXSERVER Connected from remote machine ‘192.168.0.214’ using protocol ‘NX’.
    2417 2417 2022-09-20 21:45:09 938.212 NXSERVER ERROR! Received error message from node ‘:’, ‘Cannot write to .Xauthority file in /fs/althome/contoso on the local host. Please verify permission attributes for that file.’.
    1850 1850 2022-09-20 21:45:09 966.009 NXSERVER ERROR! NXFrameBuffer failed to start.
    1850 1850 2022-09-20 21:45:09 966.067 NXSERVER ERROR! Received error message from nxserver NX> 598 ERROR: Cannot write to .Xauthority file in /fs/althome/contoso on the local host. Please verify permission attributes for that file.
    2354 2354 2022-09-20 21:45:09 966.428 NXSERVER ERROR! Received error from nxserver –daemon NX> 598 ERROR: Cannot write to .Xauthority file in /fs/althome/contoso on the local host. Please verify permission attributes for that file.
    2354 2354 2022-09-20 21:45:09 976.354 NXSERVER Remote machine ‘192.168.0.214’ disconnected.
    2354 2354 2022-09-20 21:45:09 980.352 NXSERVER User ‘contoso’ from ‘192.168.0.214’ logged out.
    2354 2354 2022-09-20 21:45:09 980.806 NXSERVER Remote machine ‘192.168.0.214’ disconnected.

    sssd.conf is configured to allow ad_gpo_map_permit = +nx

    Also, node.cfg is modified to use:

    UsersDirectoryPath “/tmp/nxdir”

    Please let us know if we might be missing something obvious and silly as there are log mo components with SSSD-AD and not sure if that OR Kerberos authentication OR some of the NX settings would be required to be tuned to get this working. So, any help will be greatly appreciated.

    Rocky Linux 8.6, NXServer LS 8.0.168

    Thanks,

    #40232
    fractal-admin
    Participant

    More debugging leads to this being prevented for some reason and we are not sure what is causing this! Any thoughts on debugging this further OR how can we fix/workaround it?

    6057 6057 2022-09-21 03:39:33 882.951 NXSERVER ERROR! Received error message from node ‘:’, ‘Cannot write to .Xauthority file in /fs/althome/contoso on the local host. Please verify permission attributes for that file.’.

     

    #40284
    Cato
    Participant

    Hello fractal-admin,

    When krb5 option is used, process accessing mounted directories need to have valid Kerberos credentials. This means that you either need to connect using Kerberos authentication with ‘Forward authentication’ enabled or password authentication with PAM stack for NX procotol configured so that it correctly obtains Kerberos ticket during authentication. The second option only works with virtual desktops.

    #40516
    fractal-admin
    Participant

    Thanks Cato,

    With that said, would the below settings to “/usr/NX/etc/server.cfg” be sufficient?

    EnableNXKerberosAuthentication 1
    NXKerberosUsePAM 1

    Or something more is necessary?

     

    Thanks,

     

     

    #40556
    Cato
    Participant

    Setting EnableNXKerberosAuthentication to 1 should suffice.

    #40562
    fractal-admin
    Participant

    Thanks again Cato, so what’s happening is, despite these settings “EnableNXKerberosAuthentication 1″ and “NXKerberosUsePAM 1″ the AD-user login to the Linux system keeps failing with the “permission denied” to the respective users’ mounted (NFS v4, sec=krb5) home directory.

    And this starts occurring only after a given user connects/login over NX once.

    UsersDirectoryPath “/temp/nxdir” is set and below log snippets from

    cat /temp/nxdir/bsukhadia/.nx/nxerror.log

    18895 18895 17:27:18 427 main: ERROR! Could not renew kerberos ticket.
    18863 18863 2022-09-28 17:27:18 428.042 NodeRenewKerberosTicket: ERROR! Unlog failed with status 65280.
    18863 18863 2022-09-28 17:27:18 428.141 NodeRenewKerberosTicket: ERROR! Unlog failed with code 255.
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    18863 18863 2022-09-28 18:18:20 082.401 Io/Io: WARNING! Descriptor FD#30 type socket still open at exit.
    29725 29725 09:09:13 574 main: ERROR! Could not renew kerberos ticket.
    29705 29705 2022-09-29 09:09:13 575.205 NodeRenewKerberosTicket: ERROR! Unlog failed with status 65280.
    29705 29705 2022-09-29 09:09:13 575.311 NodeRenewKerberosTicket: ERROR! Unlog failed with code 255.
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    unable to open tmp file “/fs/althome/uat/bsukhadia/.Xauthority-n”
    unable to write authority file /fs/althome/uat/bsukhadia/.Xauthority-n
    29705 29705 2022-09-29 09:09:49 215.827 Io/Io: WARNING! Descriptor FD#30 type socket still open at exit.

    Surely, these are a little older logs but since this time when I attempt to login over the SSH the access to the mounted home directory (NFSv4, sec=krb5) is giving a “permissions denied” error.

    Additionally, the sssd.conf has,

    ad_gpo_map_permit = +nx

    Please suggest if anything else to be looked into to fix this behavior. And not sure why would the Kerberos ticket renewals are failing only after NX connection!

    Thanks,

    #41005
    Cato
    Participant

    Hello,

    Sorry for late reply. Can you check if mounting user’s home directory with no_root_squash option helps?

    #41116
    fractal-admin
    Participant

    Thanks, @Cato for your response. Wouldn’t the “no_root_squash” be an export option?

    Although I tried mounting with, “no_root_squash” option from the client side that resulted into this error/log:

     

    Oct 31 16:27:08 fprdsk022 mount[1705]: mount.nfs4: an incorrect mount option was specified
    Oct 31 16:27:08 fprdsk022 kernel: nfs4: Unknown parameter ‘no_root_squash’
    Oct 31 16:27:08 fprdsk022 systemd[1]: fs-althome-uat.mount: Mount process exited, code=exited status=32
    Oct 31 16:27:08 fprdsk022 systemd[1]: fs-althome-uat.mount: Failed with result ‘exit-code’.
    Oct 31 16:27:08 fprdsk022 systemd[1]: Failed to mount /fs/althome/uat.

     

    Any thoughts?

     

    Thanks,

     

    #41529
    Cato
    Participant

    Hi,

    Yes, ‘no_root_squash’ is an export option. What I meant is to mount directory exported with ‘no_root_squash’. It seems that you figured that out for yourself 🙂 Did it help?

    #41532
    fractal-admin
    Participant

    Hi Cato,

    hmm! yeah you can say that since I am close but not close enough 🙂 since for our proprietary storage, the export with “no_root_squash” seems not so straight-forward but hoping to get it implemented and tested soon. I shall keep this thread updated as to what the behavior will be with “no_root_squash” home-mounts.

    Thanks,

     

    #41790
    fractal-admin
    Participant

    Hi Cato,

    Finally, I see some light here… 🙂 and hope I am not shooting my guns soon but in my quick tests today, we do see this is working as expected with the export “no_root_squash” and the “node.cfg” as well as “server.cfg” modifications, I will add later to this thread. Also, in this case, the Linux client machines are integrated with SSSD-AD Direct integration!

    Thanks again,

    #42721
    Britgirl
    Participant

    This thread is now closed. Please open a new topic with new information if the issue is encountered again.

Viewing 12 posts - 1 through 12 (of 12 total)

This topic was marked as solved, you can't post.