Authentication error sending messages to Windows Service Bus 1.0 on AWS - amazon-web-services

Question

I am trying to send and receive messages from a local workgroup machine (Windows 7), call it the 'client', to Service Bus 1.0 set up on a workgroup server (hosted on AWS EC2). After many trials and research I'm unable to send messages from the client machine to the server. I've followed a number of articles that appear to indicate that it is possible to do, but I cannot resolve the authentication issue I'm seeing.
Connecting to Windows Server Service Bus on AWS
Microsoft Service Bus on a Windows Workgroup
I note the Microsoft system requirements appears to indicate that it is "not supported" and "not possible". My question is can this be done, and has anyone had success? Any help would be greatly appreciated.
msdn.microsoft.com/en-us/library/windowsazure/jj193011(v=azure.10).aspx
My attempts include using either the WindowsTokenProvider and OAuthTokenProvider. I get the same result:
System.UnauthorizedAccessException: The token provider was unable to provide a security token while accessing 'https://xx.xx.xx.xx:9355/ServiceBusDefaultNamespace/$STS/Windows/'. Token provider returned message: ''. ---> System.IdentityModel.Tokens.SecurityTokenException: The token provider was unable to provide a security token while accessing 'https://xx.xx.xx.xx:9355/ServiceBusDefaultNamespace/$STS/Windows/'. Token provider returned message: ''. ---> System.Net.WebException: The remote server returned an error: (401) Unauthorized.
The Service Bus namespace is set up with AddressingScheme "Path" for a workgroup install. And the client side connection string includes the IP to reach the server, and I've set a RemoteCertificateValidationCallback before creating the queues.
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]
Code to attach to the remote queue and send a message is as follows:
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
The server account is SBUser with a password and I have left the domain/host specified blank on the token provider. I note that the Event Viewer on the server shows the authentication being attempted is the client's user account not the one from the token provider. Why is this? I'm obviously missing something in order to authenticate on the server.
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
Appreciate any help. Thanks.

Answer 1

Try with the OAuthTokenProvider and make sure that connBuilder is passing the right values.
TokenProvider tokenProvider = TokenProvider.CreateOAuthTokenProvider (connBuilder.StsEndpoints, new NetworkCredential(connBuilder.WindowsCredentialUsername, connBuilder.WindowsCredentialPassword));
Once you try this, please, reply with the exception you get in your client. Also, in the server, search for a event in the Service Bus section that would give more details about the exception.
With that information we should continue to the next step.

Answer 2

Did you get to the bottom of this?
I have managed to get around the exact same issue by setting the Fully Qualified domain name of the server that the certificate is bound to in the client machine hosts file.
So where you have entered the IP address in the connection string, you should instead enter 'AMAZONA-PQxxxxx'. And in your hosts file, have the 'AMAZONA-PQxxxxx' resolve to the IP address.

Answer 3

we had the same issues. Server W2k12R2, standalone, Workgroup; Client Windows 7, same Workgroup.
It's necessary to have the same user accounts on both systems. Looks like this is some kind of "authentication proxy stuff" running.
Take a look at the compatibility matrix mentioned above:
http://msdn.microsoft.com/en-us/library/windowsazure/jj193011(v=azure.10).aspx
Thank you,
Holger