NTLM authentication

Follow the suggestion, I did

1. Rdfarm point to rdcb1 ip only in DNS
2. Setspn -a termsrv/rdfarm rdcb1 and setspn -a termsrv/rdfarm.<ourdomain>.local rdcb1

When mstsc to rdfarm.<ourdomain>.local, I got following error message:

The remote computer rdfarm.<ourdomain>.local that you are trying to connect to is redirecting you to another remote computer named <one of our RDSH>. Remote Desktop Connection cannot verify that the computer belong to the same RD Session Host server farm. You must use the farm name. not the computer name. when you connect to an RD Session Host server farm.

When setup RDCB about 5 years ago, I setup a centre rdp in

Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\CentralPublishedResources\PublishedFarms\xxx_RDS_Farm\RemoteDesktops\xxx_RDS_Farm\ RDPFileContents in rdcb1 and rdcb2, it has include following items

loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.xxx_RDS_Farm

use redirection server name:i:1

alternate full address:s: rdfarm.<ourdomain>.local

if we use NTLM, we don’t need setup these items in each user’s RDP file and centre rdp items work.

now when we switch to Kerberos, we got mentioned error message.

If I add above three items in rdp file locally, I can connect to RDSHs from RDFarm.

My question here is that can we keep use centre rdp items.

Hi,

We use rdfarm to access RDSH in mstsc.exe, it will go to one of rdcb server first relate to DNS round robin; then rdcb broker the traffic to RDSH.

We use rdcb1 and rdcb2 in mstsc.exe to access broker server themselves.

termsvc/rdcb1 has associated with server rdcb1; and termsvc/rdcb2with rdcb2.

When we use rdcb1 or/and rdcb2 in mstsc.exe, we connect to these server themselves in remote desktop admin mode, not go to RDSH.

Hi, this result is usually correct. In DNS, rdfarm should have two A records pointing to the IP addresses of rdcb1 and rdcb2. This way, when a client tries to connect to rdfarm, the request will be load balanced to the two servers.

The current problem may be due to Kerberos authentication not handling this situation correctly. When a client tries to connect to rdfarm through Kerberos, it looks for the SPN associated with rdfarm. However, because there are two servers using the same SPN, Kerberos may not be able to determine which server the request should be routed to, causing problems.

You can try to create a unique SPN for each server and then use these SPNs on the client to connect. For example, you can create two SPNs, termsvc/rdcb1 and termsvc/rdcb2, and associate them with the user accounts of rdcb1 and rdcb2 respectively. Clients can then connect directly to rdcb1 or rdcb2 instead of going through rdfarm.

Hi Jacen,

Thanks for the reply.

Have tried but the suggested steps cannot fix our issue. And I type wrong, it is setspn -a termsrv/rdfarm rdfk, not termsvc/rdfarm.

Checked in DNS server, we have two A records for rdfarm, one is rdcb1 IP; one is rdcb2 IP.

Hello.

When setting up Kerberos authentication, this error usually indicates a problem with the configuration of the Service Principal name (SPN) or Kerberos authentication. Please refer to the following steps to troubleshoot this problem:

1. When connecting with 'mstsc.exe', specify the correct FQDN (fully qualified domain name).
2. On the client machine, clear any cached credentials to ensure that there is no old NTLM authentication residue causing problems.
3. Ensure that SPN registers domain user accounts correctly. You can check that SPN is registered correctly by using the 'sh setspn -L rdfk' command, which lists SPN termsvc/rdfarm for the account 'rdfk'.
4. Ensure that the domain user account (' rdfk ') has been trusted for delegation. You can do this through Active Directory Users and Computers (ADUC) : Open ADUC > Locate User Account 'rdfk' > Right-click and select 'Properties' > Go to the Delegate TAB > Select' Allow Kerberos to delegate to any service (unless specified) '.
5. Check that the time synchronization between all servers and clients is within the allowed Kerberos offset range. Kerberos is very sensitive to time differences, and large time differences can cause authentication failures.
6. If the problem persists, check the event log on 'rdcb1', 'rdcb2', and the client machine for any Kerberos-related errors. Please enable the options below before viewing.

I hope this helps.

Best regards