Ошибка аутентификации отправки сообщений в Windows Service Bus 1.0 на AWS

Question

Я пытаюсь отправлять и получать сообщения с локальной машины рабочей группы (Windows 7), называть ее «клиентом», на Service Bus 1.0, настроенной на сервере рабочей группы (размещенный на AWS EC2). После многих испытаний и исследований я не могу отправлять сообщения с клиентской машины на сервер. Я следил за рядом статей, которые показывают, что это возможно, но я не могу решить проблему проверки подлинности, которую я вижу.

Connecting to Windows Server Service Bus on AWS

Microsoft Service Bus on a Windows Workgroup

Замечу, системные требования Microsoft, как представляется, указывают, что он «не поддерживается» и «не представляется возможным». Мой вопрос в том, можно ли это сделать, и у кого-то был успех? Любая помощь будет принята с благодарностью.

msdn.microsoft.com/en-us/library/windowsazure/jj193011(v=azure.10).aspx

Мои попытки включают использование либо WindowsTokenProvider и OAuthTokenProvider. Я получаю тот же результат:

System.UnauthorizedAccessException: поставщик токенов не смог предоставить маркер безопасности при доступе к « $ STS/Windows /». Поставщик токена вернул сообщение: ''. ---> System.IdentityModel.Tokens.SecurityTokenException: поставщик токенов не смог предоставить маркер безопасности при доступе к 'https://xx.xx.xx.xx:9355/ServiceBusDefaultNamespace/ $ STS/Windows /'. Поставщик токена вернул сообщение: ''. ---> System.Net.WebException: Удаленный сервер ответил на ошибку: (401) Неавторизованный.

Пространство имен служебной шины настроено с помощью AddressingScheme «Путь» для установки рабочей группы. И строка подключения на стороне клиента включает IP для доступа к серверу, и я установил RemoteCertificateValidationCallback перед созданием очередей.

Endpoint=sb://xx.xx.xx.xx/ServiceBusDefaultNamespace;StsEndpoint=https://xx.xx.xx.xx:9355/ServiceBusDefaultNamespace;RuntimePort=9354;ManagementPort=9355;WindowsUsername=SBUser;WindowsDomain=[NotUsed];WindowsPassword=[Password] 

код для подключения к удаленной очереди и отправить сообщение выглядит следующим образом:

счет

ServiceBusConnectionStringBuilder connBuilder = new ServiceBusConnectionStringBuilder(ConfigurationManager.AppSettings["Microsoft.ServiceBus.ConnectionString"]); // Gets the connection string above 
TokenProvider tokenProvider = WindowsTokenProvider.CreateWindowsTokenProvider(connBuilder.StsEndpoints, new NetworkCredential(connBuilder.WindowsCredentialUsername, connBuilder.WindowsCredentialPassword)); 
MessagingFactorySettings messagingFactorySettings = new MessagingFactorySettings(); 
messagingFactorySettings.TokenProvider = tokenProvider; 
MessagingFactory messagingFactory = MessagingFactory.Create(connBuilder.GetAbsoluteRuntimeEndpoints(), messagingFactorySettings); 
requestQueue = messagingFactory.CreateQueueClient("RequestQueue"); 
... 
requestQueue.Send(sendMessage); // Fails here 

Сервер SBUser с паролем, и я оставил домен/хост указанный пробел в маркере поставщик. Я отмечаю, что средство просмотра событий на сервере показывает, что попытка аутентификации - это учетная запись пользователя клиента, а не та, которая принадлежит провайдеру токенов. Почему это? Мне явно не хватает чего-то для аутентификации на сервере.

An account failed to log on. 

Subject: 
    Security ID: NULL SID 
    Account Name: - 
    Account Domain: - 
    Logon ID: 0x0 

Logon Type: 3 

Account For Which Logon Failed: 
    Security ID: NULL SID 
    Account Name: [ClientLogin] 
    Account Domain: [ClientMahcine] 

Failure Information: 
    Failure Reason: Unknown user name or bad password. 
    Status: 0xc000006d 
    Sub Status: 0xc0000064 

Цените любую помощь. Благодарю.

Answer 1

Попробуйте использовать OAuthTokenProvider и убедитесь, что connBuilder передает правильные значения.

TokenProvider tokenProvider = TokenProvider.CreateOAuthTokenProvider (connBuilder.StsEndpoints, новый NetworkCredential (connBuilder.WindowsCredentialUsername, connBuilder.WindowsCredentialPassword));

После того как вы попробуете это, ответьте, пожалуйста, за исключением того, что вы получаете в своем клиенте. Кроме того, на сервере найдите событие в разделе «Шина обслуживания», которое даст более подробную информацию об исключении.

С этой информацией мы должны перейти к следующему шагу.

Answer 2

Вы дошли до конца?

Мне удалось обойти эту же проблему, установив полное доменное имя сервера, на которое привязан сертификат в файле хостов клиентского компьютера.

Итак, если вы ввели IP-адрес в строку соединения, вы должны ввести «AMAZONA-PQxxxxx». И в вашем файле hosts есть разрешение «AMAZONA-PQxxxxx» на IP-адрес.

Answer 3

у нас были те же проблемы. Сервер W2k12R2, автономный, Workgroup; Клиент Windows 7, то же Workgroup.

Необходимо иметь одинаковые учетные записи пользователей в обеих системах. Похоже, что это какой-то «прокси-сервер аутентификации».

Посмотрите на матрицу совместимости упомянутых выше: http://msdn.microsoft.com/en-us/library/windowsazure/jj193011(v=azure.10).aspx

Спасибо,

Хольгера