Forum / NoMachine for Windows / Windows 10 SSL client authentication fails
- This topic has 6 replies, 2 voices, and was last updated 3 weeks, 4 days ago by Britgirl.
-
AuthorPosts
-
September 9, 2024 at 07:36 #49578RedBossParticipant
Hi,
I am trying to do a basic Proof of Concept by configuring nomachine to use SSL client authentication and the NX protocol. I have followed the instructions here https://kb.nomachine.com/AR10M00866
When I attempt to connect from the client, it asks “Please type your username to login as a system user”. Firstly, I would not expect to be prompted for a username as the idea was that the user does not need to enter any name or password and instead seamlessly authenticate using the keys. However, if I enter the username and click next, I get authentication failed, please try again.
Client is Windows 10 – NoMachine Enterprise Client 8.13.1
Server is Windows 10 – NoMachine Enterprise Desktop 8.13.1
PS: Password authentication works fine.
September 9, 2024 at 18:18 #49597BritgirlKeymasterThat article is dedicated to configuring the device. Please check this article instead:
https://kb.nomachine.com/AR02L00785 which is for user authentication.
September 10, 2024 at 01:56 #49599RedBossParticipantI followed that article, and I get the same error. This time it is asking for username and passphrase, which i entered the passphrase i set and still receive authentication failed.
I had to also revert back EnableNXClientAuthentication back to 0 otherwise it would just timeout trying to connect. Do i need to follow the first article i posted at all? What username should i be entering with the passphrase?
I attempted authenticating using name and password and this still works.
September 10, 2024 at 02:13 #49600RedBossParticipantUpdate: I got it working by specifying the username of where the authorised.crt resides on the server.
Still not ideal. Does this mean we distribute 1 private key amongst our clients and 1 public key amongst the servers? In the first article i posted, it seemed we could specify unique keys in a single hosts file and the clients IP address for added security.
September 10, 2024 at 10:02 #49606BritgirlKeymasterThe first article (https://kb.nomachine.com/AR10M00866) is about identifying client devices. It’s an additional layer of security, to limit number of devices from where user can connect. It doesn’t replace user authentication which is still mendatory.
The second article, the one I linked in my reply (https://kb.nomachine.com/AR02L00785) is about using keys instead of passwords for user authentication. It removes the need to provide a password but the user still has to identify himself with a proper username. In that case you have to create at least one key pair for each user. The private key has to be securely stored on each client device from where a given user is connecting. The public key has to be distributed to all the server side hosts where that user needs to be able to log in.
September 11, 2024 at 00:34 #49610RedBossParticipantThank you for explaining.
One last question, when I distribute the public key to the servers, the article mentions to create the authorized.crt in this location: C:\Users\username\.nx\config
Lets say the server is logged on with username John, but the client logging in is user Sam, this does not work. I found that on the client i needed to specify the username John when attempting to connect, where the authorized.crt resides.
What i have done currently is create the authorized.crt under the user nx profile.
Can you confirm that the user logging in from the client should specify the user on the server where the authorized.crt resides? If so, this may not always be known to the client user, therefore I have used nx user instead.
Thanks,
September 13, 2024 at 07:52 #49658BritgirlKeymasterYou can login to the server as any other user provided the account is valid on the server. So, there could be users John, Jack and Jill. NoMachine handles key authentication in the same way as SSH. The keys are set per system user account. So, if the desktop on the server is owned by John, the user which connects should login as John. If you login with another valid system user (Jack or Jill), user John will have to authorize the connection.
-
AuthorPosts
You must be logged in to reply to this topic. Please login here.