1. So wondering if a local account (not AD) account can be used with the LSB.
To test this setup a local account and using Set-SBNamespace gave that account namespace management rights.
Then logged in with that account and manipulated the service bus. So, yes a local account can be used.
2. Then wondering if a mirrored local account can be used.
To test this setup a local account on a second machine with same password as on the first machine.
Then logged in on machine2 with that account intending to operate only against machine1. But made a mistake. In the connection string modified the STS endpoint to point to machine2, but left the SB endpoint pointed at machine1. So the connection string looked like this:
Endpoint=sb://machine1.local/namespace;StsEndpoint=https://machine2.local:9355/namespace;RuntimePort=9354;ManagementPort=9355" />
And it worked. Both machines do have SB 1.0 For Windows installed. The STS from one machine delivered up a token, and the SB on the other machine serviced the request.
The token service delivering the token (on machine2) had no knowledge of the local account's rights, and that local account had no rights on the local SB on machine2, only rights on machine1's SB.
3. Wondering about this and wanted to know what else is possible. So wanted to know if an account with NO rights on machine1, could access machine1's SB and manipulate.
The answer is yes, it can.
So, logged on with a domain account on machine2. Obtained a token from machine2, then proceeded to manipulate the namespace on machine1 with no rights whatsoever.
Sure seems like a fairly wide open security Hole. It appears all that is needed is a token and with that token a namespace can be manipulated.
Note, the namespace is the same on both machines. That's likely the clue needed to close this hole.