Server settings authentication fails for domain users

Forums / NoMachine for Mac / Server settings authentication fails for domain users

Viewing 15 posts - 1 through 15 (of 18 total)
  • Author
    Posts
  • #36683
    skibbidypaps
    Participant

    Several other threads exist where individuals are able to authenticate from the NoMachine client to a remote system running NoMachine but are subsequently unable to authenticate to do things such as restart the service on Mac OS. I’m creating this thread to seek a canonical resolution to this issue as previous threads seem to have been prematurely closed.

    Background

    I connect from a Windows 11 client running NoMachine 7.7.4 for Windows

    I connect to a Mac OS 11.6.1 server machine running NoMachine 7.7.4 for Mac OS X

    On the Mac OS system, my user is part of a Windows domain

    uid=1974106972(redacted) gid=1987437277 groups=1987437277,12(everyone),20(staff),61(localaccounts),80(admin),702(com.apple.sharepoint.group.2),33(_appstore),98(_lpadmin),100(_lpoperator),204(_developer),250(_analyticsusers),395(com.apple.access_ftp),398(com.apple.access_screensharing),399(com.apple.access_ssh),400(com.apple.access_remote_ae),701(com.apple.sharepoint.group.1)

    When using the Server Settings interface to restart the server, I’m prompted with an authorization dialog under Mac OS and enter my credentials. The NoMachine user interface then displays an error (see the attached image)

     

    Correlated to the user interface error above is the nxerror.log entry (which repeats per-attempt):

    12506 259 11:53:45 396 nxexecGetUser: Got error 0.

    12506 259 11:53:45 396 nxexecGetUser: The given uid was not found: 1974106972.

    12506 259 11:53:45 396 main: ERROR! Failed to get current username.

     

    The contents of my ${HOME}/.nx directory are as follows:

    drwx——  30 redacted  1987437277    960 Dec 15 17:19 ./

    drwxr-xr-x+ 53 redacted  1987437277   1696 Dec 15 17:26 ../

    drwx——   5 redacted  1987437277    160 Nov 29 23:43 F-M-M-C02VM1UTHV2Q-13001-16C5E828945BC04D4157ADB4654682F7/

    drwx——   5 redacted  1987437277    160 Nov 23 13:57 F-M-M-C02VM1UTHV2Q-13001-48CC57B41CEDAB1C3C2B08C42AF59B8E/

    drwx——   5 redacted  1987437277    160 Nov 23 13:53 F-M-M-C02VM1UTHV2Q-13001-AA38D38B9A21DAA4E8B29E68E40B2345/

    drwxr-xr-x   3 redacted  1987437277     96 Nov  4 10:49 K-localhost-1397-325C473C95161FE80AA79667B12959D6/

    drwxr-xr-x   3 redacted  1987437277     96 Dec 15 16:21 K-localhost-1816-AB3142AD4586A2CBE7B6E7CDCACA5EF9/

    drwxr-xr-x   3 redacted  1987437277     96 Nov 30 00:01 K-localhost-782-CF018146AF5DDC0916219AE68B9E8F5E/

    drwxr-xr-x   3 redacted  1987437277     96 Nov 30 12:24 K-localhost-783-2ED70CB4E5FD4D994B426855FE1A2571/

    drwx——   5 redacted  1987437277    160 Nov  3 13:22 M-F-M-C02VM1UTHV2Q-13002-5D0589BCA2AEBCE5FD31B1EFD21C580C/

    drwx——   5 redacted  1987437277    160 Nov 30 12:24 M-F-M-C02VM1UTHV2Q-13002-A74D63E07EDF5DC18D491C39DCCC0FB0/

    drwx——   5 redacted  1987437277    160 Nov  4 10:49 M-F-M-C02VM1UTHV2Q-13003-5955A2F26C17C45422D9C23E8B96260F/

    drwx——   5 redacted  1987437277    160 Dec 15 11:19 M-M-C02VM1UTHV2Q-13001-BC92A9E6121A453EB870CDB6C449143D/

    drwx——   3 redacted  1987437277     96 Nov 30 10:16 M-localhost-11708-1307761C8086854D9A3F6F02E08EC581/

    drwx——   3 redacted  1987437277     96 Nov 30 10:16 M-localhost-13088-1E7E303DAAAB64AC5DB867D40D6812F6/

    drwx——   3 redacted  1987437277     96 Nov 30 10:16 M-localhost-19176-02414D3AA65CE8ADB86718621EA22E07/

    drwx——   4 redacted  1987437277    128 Nov  4 10:49 R-localhost-1479-C778117D1309932C5BD7ED5B126EF86E/

    drwx——   4 redacted  1987437277    128 Nov 30 00:01 R-localhost-1858-64EC01DFAA87333FF156EBBD9118B5E1/

    drwx——   4 redacted  1987437277    128 Dec 15 16:21 R-localhost-26933-CC2EE6A05F71BBED8060425D275A9C72/

    drwx——   4 redacted  1987437277    128 Nov 30 12:24 R-localhost-850-D20FDE951863502C7CA69BF3C8C2A650/

    drwx——   4 redacted  1987437277    128 Dec 15 17:20 S-localhost-59996-FA832D44CE55772AB44502B13FC4D2BE/

    drwx——   4 redacted  1987437277    128 Dec 15 16:21 S-localhost-63145-08194DE2AC0E7E58A7B2B9AE193E1369/

    drwx——   4 redacted  1987437277    128 Dec 15 16:40 S-localhost-63853-0149A08862DA6C578C0BA5B31307C2EC/

    drwx——   2 redacted  1987437277     64 Nov  3 12:36 cache/

    drwx——   3 redacted  1987437277     96 Nov 30 10:31 config/

    drwx——  27 redacted  1987437277    864 Dec 15 17:24 node/

    drwx——   3 redacted  1987437277     96 Dec 15 17:24 nxdevice/

    -rw——-   1 redacted  1987437277  11962 Dec 15 17:22 nxerror.log

    -rw——-   1 redacted  1987437277  11141 Dec 15 16:13 nxserver.log

    drwxr-xr-x   6 redacted  1987437277    192 Nov 30 12:25 temp/

    The contents of /Applications/NoMachine.app/Contents/Frameworks/bin are as follows:

    drwxr-xr-x  20 root  wheel      640 Nov 30 10:17 drivers/

    -rwxr-xr-x   1 root  wheel    48368 Oct 19 10:26 nxagent*

    -rwxr-xr-x   1 root  wheel    61168 Oct 19 10:23 nxauth*

    -rwxr-xr-x   1 root  wheel      906 Jan  7  2021 nxclient*

    drwxr-xr-x   3 root  wheel       96 Nov 30 10:18 nxclient.app/

    -rwxr-xr-x   1 root  wheel   142160 Oct 19 10:26 nxcodec.bin*

    -rwxr-xr-x   1 root  wheel    36672 Oct 19 10:26 nxd*

    -r-sr-xr-x   1 root  wheel   278784 Oct 19 10:23 nxexec*

    -rwxr-xr-x   1 root  wheel   765744 Oct 19 10:23 nxfs*

    -rwxr-xr-x   1 root  wheel    92864 Oct 19 10:23 nxfsserver*

    -rwxr-xr-x   1 root  wheel   246192 Oct 19 10:23 nxkb*

    -rwxr-xr-x   1 root  wheel    37920 Oct 19 10:23 nxkeygen*

    -rwxr-xr-x   1 root  wheel    40752 Oct 19 10:26 nxlocate*

    -rwxr-xr-x   1 root  wheel    71568 Oct 19 10:23 nxlpd*

    -rwxr-xr-x   1 root  wheel      849 Oct 19 10:26 nxnode*

    drwxrwxr-x   3 root  wheel       96 Nov 30 10:18 nxnode.app/

    -rwxr-xr-x   1 root  wheel   126768 Oct 19 10:26 nxnode.bin*

    -rwxr-xr-x   1 root  wheel   153760 Oct 19 10:23 nxpost*

    -rwxr-xr-x   1 root  wheel     5663 Nov 30 10:17 nxprint*

    -rwxr-xr-x   1 root  wheel      539 Oct 19 10:27 nxserver*

    drwxrwxr-x   3 root  wheel       96 Nov 30 10:18 nxserver.app/

    -rwxr-xr-x   1 root  wheel   128192 Oct 19 10:27 nxserver.bin*

    -rwxr-xr-x   1 root  wheel    36304 Oct 19 10:23 nxsh*

    -rwxrwxr-x   1 root  wheel    32864 Oct  8 15:14 nxsign*

    -rwxr-xr-x   1 root  wheel   444912 Oct 19 10:23 nxssh*

    -rwxr-xr-x   1 root  wheel   174896 Oct 19 10:23 nxssh-add*

    -rwxr-xr-x   1 root  wheel   154144 Oct 19 10:23 nxssh-agent*

    -rwxr-xr-x   1 root  wheel  1028784 Oct 19 10:23 nxusbd*

     

    #36701
    skibbidypaps
    Participant

    To clarify what’s written above, when using the terms client and server that refers to the use of NoMachine. The Mac is not running a Mac OS server operating system.

    #36725
    skibbidypaps
    Participant

    This might only be an error for me, but I’m unable to load the error in my browser on the forums. Attaching it once again here. And hoping for some replies to my thorough post.

    #36807
    Britgirl
    Keymaster

    We’ve not been able to reproduce. We would like to send you a debug package in order to understand why authentication is failing. Would you be able to install it and send us the logs? (we’ll send you instructions).

    #36882
    skibbidypaps
    Participant

    Happy to run a debug version and assist in debugging it. One problem you may have in reproducing it is having Macs configured to resemble corporate deployments with various profiles.

    In other posts related to this issue (which I believe were prematurely closed) the uid was similarly a large integer that indicated active directory users

    #36896
    PB
    Participant

    Hi.  I’m having a problem that seems like it may be similar. It has the same symptoms, and also involves connecting to a mac OSX, and also started with upgrade to 7.7.4.  The error given on client machine is:

    “A connection timeout has occurred while trying to connect to ‘XX.XXX….’ on port ‘NNNNN’.

    I’ve been connecting between two macs, 10.15.7.  After upgrading to NoMachine 7.7.4 (from 7.6.x) on both machines, the server no longer responded to the client’s mouseclicks or keyboard entries.  After restarting the server, the client was no longer able to connect at all.  I’m using nx protocol over internet and have limited access to the server.  I have reset permissions (system preferences> security & privacy > privacy > accessibility) on both machines with no change.

    On client machine, nxerror.log reads (for latest login attempt):

    1342 775 12:18:39 641 nxexecGetUser: Got error 0.
    1342 775 12:18:39 642 nxexecGetUser: The given uid was not found: 501.
    1342 775 12:18:39 642 main: ERROR! Failed to get current username.

     

     

    #37081
    Bilbotine
    Keymaster

    Hello @skibbidypaps and @PB,

    We sent you both an email with a debug package.

    Please check your mailboxes and follow the instructions.

    Thanks!

     

    #37094
    skibbidypaps
    Participant

    Hi,

    A gmail search for in:all nomachine debug doesn’t return any results in my inbox. A search for in:all nomachine only returns results related to this thread.

    Would you please share the subject and/or from address of the email that sent the debugging packages?

     

     

    #37104
    Britgirl
    Keymaster

    Hi, I’ve just forwarded it on to you again. It was originally issued from the Forums backend. I’m not sure what happened there. Let me know that you got it.

    #37218
    skibbidypaps
    Participant

    Received and installed, will follow-up with logs.

    #37220
    skibbidypaps
    Participant

    Just send the logs on to you via email, Britgirl.

    #37221
    skibbidypaps
    Participant

    The tag currently associated with this is a bit of a misnomer, and since I had more to add it was the perfect opportunity to add a tag.

    Under Mac OS, the uid_t type is an unsigned 32-bit int: /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/sys/_types/_uid_t.h:

    #ifndef _UID_T

    #define _UID_T

    #include <sys/_types.h> /* __darwin_uid_t */

    typedef __darwin_uid_t        uid_t;

    #endif  /* _UID_T */

     

    And from /usr/include/sys/_types.h:

    typedef __uint32_t      __darwin_id_t;          /* [XSI] pid_t, uid_t, or gid_t*/

    I wrote a little test program that uses getuid() to get the pid of the running process and then uses both getpwnam (for my user) and getpwuid(). It prints out the entries from the returned passwd structure just fine for both calls. I repeated this for root and it too works just fine.

    It appears as though all but one of the running NoMachine processes are running as my local user, and the outlier is nxexec.

    I’m not sure where NoMachine’s code has gone wrong, and there are many interfaces to these syscalls that are language dependent, but I’m able to retrieve the data using the most obvious and POSIX compliant interfaces.

    #include <sys/types.h>

    #include <uuid/uuid.h>

    #include <pwd.h>

    #include <stdio.h>

    #include <unistd.h>

     

    int

    main(int argc, char *argv[]) {

     

    uid_t this_uid = 0;

    struct passwd *u_mypw, *i_mypw;

    char *who = “root”;

    uid_t whos_uid = 0;

     

    this_uid = getuid();

    u_mypw = getpwnam(who);

    i_mypw = getpwuid(whos_uid);

     

    printf(“uid is %d\n”, this_uid);

    printf(“%s’s UID is %d via getpwnam()\n”, who, u_mypw->pw_uid);

    printf(“UID %d’s name is %s via getpwuid()\n”, whos_uid, i_mypw->pw_name);

    }

    $ ./test

    uid is 1974106972

    root’s UID is 0 via getpwnam()

    UID 0’s name is root via getpwuid()

     

    #37242
    Guro
    Contributor

    Hello

    Do you still have login problems after install debug package on macOS?

    Thanks

    #37258
    skibbidypaps
    Participant

    Yes, the problem persists in the debugging package. The debugging package just appears to just have all the debugging options turned on (refer to https://knowledgebase.nomachine.com/DT11R00182)

    It wasn’t an actual new release – so I wasn’t expecting a resolution to my issue. And when I tested it, the issue still presented itself in the package I was sent.

    #37280
    Guro
    Contributor

    Hello.

    As I see in logs AD user recognizes in later tests but server unable to check daemon status(this part logs are not full).
    Please could you run one more test with new package which we can prepare?

    Thanks

Viewing 15 posts - 1 through 15 (of 18 total)

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