locked
Initialising remote desktop on a EAP client after reboot RRS feed

  • Question

  • Hi - normally my NAP compliant remote computer is connected to my server via a VPN connection and there is no problem with remote desktop because I connect via the domain. However on the occasion i have to reboot my remote computer the VPN connection has not been started yet because I have not logged in. Starting a remote desktop in this case is via its public IP address. The remote desktop program is able to communicate with the remote client because it asks me for a login name and password but when I press enter i get the following message:

    "An authentication error has occured.
    The Local Security Authority cannot be contacted"

    Any ideas?

    Thanks
    Lngo 
    Sunday, December 20, 2009 4:18 AM

All replies

  • Hi,

    I'm not quite sure I fully understand the scenario.

    You connect to your corporate network via VPN, and this allows you to remote desktop to your server. That makes sense. I do the same thing myself.

    I think you might be trying to get remote desktop to work via the server's public IP address. This interface probably has different DNS servers assigned, right? So if the server tried to query your account information then these DNS servers will not have a clue about your internal domain and thus the "local security authority cannot be contacted."

    -Greg

    Friday, March 19, 2010 9:10 PM
  • Hi there,

    I have a similar situation where a client cannot connect to the Remote Desktop session of his SBS 2008 server, but has no problems at all to connect using Remote Web Workplace.

     

    Indeed in this thread, the user is trying to connect to the external (aka public) interface in case he has not established an VPN connection to the server.

    I think this might be related to an SPN issue, but I will be able to provide more information tomorrow after I get a trace between the client and the server.

     

    Cheers,

    SV

    Sunday, April 11, 2010 7:57 AM
  • Hi there,

    I have a similar situation where a client cannot connect to the Remote Desktop session of his SBS 2008 server, but has no problems at all to connect using Remote Web Workplace.

     

    Indeed in this thread, the user is trying to connect to the external (aka public) interface in case he has not established an VPN connection to the server.

    I think this might be related to an SPN issue, but I will be able to provide more information tomorrow after I get a trace between the client and the server.

     

    Cheers,

    SV

    Sunday, April 11, 2010 7:57 AM
  • Hi,

    I am pretty sure what I said above holds true. If you attempt to remote in to the server using the public IP address, the server will attempt to verify your domain credentials. To do this, it must contact the DC. When it tries to query the DC it can't find it because you are coming in from the outside. I might not understand the scenario fully because I'm not a remote desktop expert (this is the NAP forum). The server is trying to query (for example) DC1.domain.com using the public interface, which fails.

    The solution would seem to be that you just need to provide local user credentials instead of domain user credentials when you remote in from a public address. Alternatively you could gimmick the server to query the DC via the hosts file instead of DNS, but would be a security risk and might lead to other problems.

    -Greg

    Sunday, April 11, 2010 5:58 PM
  • Hi,

    actually the case I am observing is a bit different from the original thread - in my case no password prompt appears, just the error message and we are contacting the SBS2008 server on its internal interface, so the only thing in common is the error message 0x80090308 + 0x80090304 both pointing to "Local security authority cannot be contacted" . Even more interestignly, if we try Remote Web Workplace, it works as a charm.

    We can resolve the FQDN and NetBios of the domain and of the server, yet the error message stays where it was.

    @LNgo, can you please check your event logs for TermDD eventID 56 and read out the last 8 bytes from the binary data ?

    Tuesday, April 13, 2010 7:16 AM