При каких обстоятельствах * локальная * учетная запись пользователя может получить доступ к удаленному серверу SQL с доверенным соединением?

Один из наших клиентов имеет следующую конфигурацию:

На контроллере домена есть SQL Server.
На своем ПК (WinXP) он входит в систему с LocalPC\LocalUser.
В проводнике Windows он открывает DomainController\SomeShare и аутентифицируется как Domain\Administrator.
Он запускает наше приложение, которое открывает доверенное соединение (аутентификация Windows) с SQL Server. Оно работает. В SSMS соединение отображается с пользователем Domain\Administrator.

Во-первых, меня удивило, что это вообще работает. (У меня первое подозрение было, что в домене есть пользователь с таким же именем и паролем, но нет пользователя LocalUser в домене.)

Затем мы попытались воспроизвести то же поведение на его новом ПК, но безуспешно:

На своем новом ПК (Win7) он входит в систему с OtherLocalPC\OtherLocalUser.
В проводнике Windows он открывает DomainController\SomeShare и аутентифицируется как Domain\Administrator.
Он запускает наше приложение, которое открывает доверенное соединение (аутентификация Windows) с SQL Server. Выдает сообщение об ошибке Login failed for user ''. The user is not associated with a trusted SQL Server connection.

Отсюда мой вопрос: При каких условиях пользователь, не являющийся пользователем домена, может получить доступ к удаленному серверу SQL с помощью проверки подлинности Windows с другими учетными данными? Видимо, это возможно (работает на его старом ПК), но почему? А как это воспроизвести?

Как заметил Берни Уайт, вероятно, это связано с различиями в конфигурации Kerberos. KerbTray будет работать на WinXP, klist встроен в W7 и выше.

За исключением этого, если проблема, которую вы пытаетесь решить, заключается в том, чтобы сервер SQL мог использовать аутентификацию Windows, вы можете сделать это, запустив, runas /netonly /user:DOMAIN\Administrator application.exe.

Другой метод, который я использую, - это подключение пользователей к сети через VPN, даже если они находятся во внутренней сети. Это приведет к тому, что сетевые учетные данные будут использоваться для всех открытых приложений, а также будет разрешен единый вход для Outlook, SQL Server, LDAP и любого другого приложения, к которому они могут получить доступ.