Remote Assistance in a External Kerberos Trust Realm
I am trying to Offer unsolicited Remote Assistance from one client machine to another in the Domain. I get event id which states bad username or bad password. I have looked down and noticed this as well. This is a Domain with an external kerberos realm trust. Detailed Authentication Information: Logon Process: NtLmSsp Authentication Package: NTLM Transited Services: - Package Name (NTLM only): - I am not sure why it is trying ntlm when I know that will not work since this is a kerberos account to the external kerberos realm trust. I have set the security level for remote assistance to negotiate on both machines I have added my user account in the helpers group for the destination client and host client I have tried setting both the host client and destination client computer account for kerberos delegation I am not sure what else to do to force remote assistance to use kerberos authentication.
July 18th, 2012 4:41pm

Hi, Please check if the following article is helpful. http://blogs.msdn.com/b/rds/archive/2008/07/21/configuring-terminal-servers-for-server-authentication-to-prevent-man-in-the-middle-attacks.aspx If the issue persists, I suggest you post in group policy forum to get more insights. http://social.technet.microsoft.com/Forums/en-US/winserverGP/threads Niki TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedback here Niki Han TechNet Community Support
Free Windows Admin Tool Kit Click here and download it now
July 24th, 2012 2:15am

Hi, I am currently standing by for an update from you and would like to know how things are going. If you have any feedback, please let us know. Niki TechNet Subscriber Support If you are TechNet Subscription user and have any feedback on our support quality, please send your feedbackhere Niki Han TechNet Community Support
July 25th, 2012 2:09am

Hi Niki, I have set Computer Configuration/Administrative Templates/Windows Components/Remote Desktop Session Host/Security Require use of specific security layer for remote (RDP) connections Enabled Security Layer RDP NLA seem to always break Auth to a external kerberos trust so it never works. We have to disable NLA to even get RDP working. We do not allow ntlm since our accounts are just shadow accounts with random passwords. Reading the information provided, this seems to be related to a terminal server, which we are not running. Also it's only suggestions are NLA, SSL/TLS or certificates. So does this mean Remote assistance does not support passing of a external kerberos realm ticket since the introduction of NLA? -Phil
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2012 10:36am

http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/4d4db548-beeb-4e8f-a038-16d677710540?persist=True SOLUTION - sort of The problem is with the new NLA protocol that authenticates you before you connect to the server. This fails when authentication is attempted to the external Kerberos realm.Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp] "SecurityLayer"=dword:00000000 There is however a workaround on the server side - turn of NLA On a Windows Server 2008 machine go the Terminal Services Configuration Admin tool and double click on the RDP-Tcp connection. Under Security layer select RDP Security Layer. This forces the server to use the native RDP encryption instead of trying and failing to use the SSL TLS encryption. Setting this option is slightly less secure than using the newer SSL encryption, however it is still encrypted. I would encourage everyone to use alternate ports for Remote desktop for this reason. For Windows 7 and Vista machines that need to be authenticated to with Kerberos credentials, there is no gui to set this option. The registry bit that must be set is below. It is not necessary to reboot with any of these fixes.
August 4th, 2012 12:17pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics