Change to Azure Service Bus Portal: Default Authentication Mechanism for Service Bus Namespaces now SAS

What are we changing

A change has been made to the user experience in the Azure portal for Service Bus namespace creation.  When creating a Service Bus namespace in the Azure portal only SAS authentication will be enabled by default.  The accompanying ACS namespace will no longer be created and paired to the Service Bus namespace. 


Why did we change it

The vast majority of our customers only use ACS for the access key functionality, not for identity federation.  SAS provides better capabilities and higher scale for these use cases so we have decided to make it our default in the portal experience.  This simplifies our customer experience for the majority of use cases.


How does this impact customers and how can you use ACS

Current namespaces will not be affected in any way.  Customers who were dependent on ACS features such as claims and federation will also not be affected if they use automation to create their namespaces; namely PowerShell, the Azure CLI and the REST API. 


In order to create a new namespace in PowerShell use the cmdlet New-AzureSBNamespace


New-AzureSBNamespace -Name 'MyNamespace' -Location 'Central US'


This will create the Service Bus namespace and a paired ACS namespace.  The ACS connection string will appear in the Azure portal. 


In the future there will be a new optional parameter to this cmdlet which will allow you to control ACS namespace creation.  At first this cmdlet will default to creating ACS namespaces, but further in the future this default will be reversed and ACS namespaces will not be created by default. 


In Azure CLI, you will run:

sb namespace create ‘MyNamespace’ ‘Central US’


For the REST API: 

By default the ACS companion namespace will be created, unless you specified a x-ms-version header bigger than '2014-05'


As we continue to expand and improve our Azure messaging platform the Service Bus team will continually examine customer usage, dependencies, and impact.  Creating namespaces without a paired ACS namespace is faster and creates one less dependency for our customers.  This change streamlines the user experience for the majority of our customers today. 


Are we moving away from ACS?

No! ACS is still fully supported in Service Bus and will be for the foreseeable future.  As Azure Active Directory (AAD) expands to support more service federation identity scenarios we will increasingly align with the AAD service offering. 

Comments (26)
  1. Vadim says:

    I think this is a very bad practise to change the behaviour of the system. When I did the set up of service bus for the first time, everything was fine. But when I try to do it again I had troubles because of this changes. And you know, it wasn't easy to fine this post to solve issues

  2. Thuru says:

    how does this change affect the relays ?

  3. Joseph says:

    Okay, I am damn near puling my hair out with this change. I CANNOT get relays to work without the ACS instance. Sadly it just so happen there are 0 end to end documents out there( that actually work ) on getting a relay working without ACS. I was able to successfully create a new SB and sendrecieve messages tofrom queues incorperating the changes discussed here- but the relay in no way appears to work. Can you point me to a working example of this somewhere? The documentation on MSDN is either too fragmented for me( and other on message boards ) to understand or – something may be missing. I have been literally road blocked by this unless I leverage one of our older Service Bus instances( that came accompanied with ACS  and the "owner" credential). When trying to not use the ACS credentials the relay ALWAYS timesout( as it would be expected) trying to auth to an ACS instance that does not exist.  If you can provide even a little guidance here it would be immensely helpful.

  4. Dan Rosanova MSFT says:

    Sorry to hear about your experience here.  Relay requires ACS, so you will need to create namespaces via PowerShell or the REST API in order to use Relay in them.  We'll work on getting those documents updated.

  5. jeffammons says:

    I too found this change the hard way. I tried to create a namespace on the portal and noticed the ACS bits were missing. I tried PowerShell and got it working, but it was days later before I discovered the SAS info online.

    Now I'm trying to work my way through switching over to SAS (it looks like we are being ACS throttled), but we use multiple namespaces that should share keys. This was easy to accommodate under ACS, but it looks like the portal will only generate new keys, not allow you to give it a key. I believe I can do so programmatically, but the documentation is a bit thin.

    I have gotten SAS working with 1 namespace and the speed difference is apparent. We spin up a bunch of subscriptions to queues on start up and the time in the debug instance goes from 2-4 seconds down to about 1 second.

  6. Aki says:

    I'm trying to create new namespace by using the powershell commend in this article, but after typing in the command, it is asking  parameter value for NamespaceType. I've tried every possible NamespaceType I can think of, but can't get through this. I'm also not able to find any documentation regarding this online.

    Any suggestion or reference?

  7. Jos says:

    Same issue as Aki, looks like commands updated with extra parameters but the documentation hasn't been.

  8. Jan says:

    I'm running into the same issue. The New-AzureSBNamespace is asking for a new parameter, NamespaceType, which isn't documented (yet?).

    Have you guys found what to use for this already?

  9. Jan says:

    I found out this is indeed a new thingy in the API.

    The post over here describes it and how to solve it:…/azure-service-bus-namespacetype-default-value-change

  10. bryce says:

    wow we just found this out the hard way also after we had to re-create a service bus namespace due to it failing for no known reason.  This stuff is becoming very undependable for our up-time needs, and we are beginning to regret depending on it.

  11. SDI Webservice Admin says:

    We downloaded the Azure Powershell and attempted to set this up – we get this error message:

    "New-AzureSBNamespace : Cannot convert 'System.String' to the type 'System.Nullable 1 [System.Boolean]' required by parameter 'CreateACSNamespace'. "

    Documentation from MS Azure tends to be pretty light on this topic were wondering if you had any experience with this issue or any suggestions?

  12. Morten la Cour says:

    If Relay requires ACS and Relay is an important part of the Azure Service Bus, how can you just change the default behavior to use SAS instead of ACS, without also implementing SAS in Relays?


  13. Shirshank Deepankar says:

    I have found a simple solution.

    Instead of using :

    var sharedSecretServiceBusCredential = new TransportClientEndpointBehavior();

    sharedSecretServiceBusCredential.TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(issuerName, issuerSecret);


    var sharedSecretServiceBusCredential = new TransportClientEndpointBehavior();

    sharedSecretServiceBusCredential.TokenProvider = TokenProvider.CreateSharedAccessSignatureTokenProvider(policyName, policyKey);

    You can find policyName & policyKey values in "Configuration" tab -> "Shared access key generator"

  14. rajdey says:

    Thanks a ton Shirshank Deepankar, your suggestion made my day.Was trying to get it working since morning.

  15. Kenny Bright says:

    Its sad the way Microsoft is going. you are turning off developers that want to develop on your platform because you are becoming consistently inconsistent. Every time I need to do something simple I go Azure website then come to realize things have change, now I have to figure out how to work with the new thing. I have been a Microsoft Developer since the Window days. with all the goings am thinking of switching to open source and javascript.

  16. Shailendra says:


    I am also facing same issue, my old ACS is not working and trying to create new one, not able to see the option for create ACS and Relay. My App is faling due to this reason.

  17. Dinesh Kumar says:

    Just use the steps as provided by the "Shirshank Deepankar " to get resolve the Issue.

  18. Lars Nyström says:

    But you can only create up to 12 Shared Access Policies…

    Does anyone know if you can enable ACS on an existing namespace?

  19. Dan says:


    Will old SB created prior to this change  using ACS still work?

  20. Mikael Lundh says:

    This works

    New-AzureSBNamespace -Name 'namespace' -Location 'West Europe' -CreateACSNamespace $true -NamespaceType Messaging

  21. Anonymous says:

    I am trying to build a SQL LOB target in Azure BizTalk Services, initially I tried to create one through the Visual Studio and ran into the below error –

    Message: 'Error occurred while trying to bring up the relay service. Error Message: 'The remote name could not be resolved: ''

    This is because to create an LOB target we require an Services bus which is authenticated using ACS, but from August 2014 the support for ACS authenticated SB has been replaced by SSA.

    The workaround I found at several places was to use Azure PowerShell to create a new SB, but as it turns out the new Azure PowerShell SDK doesn't recognize the command itself –

    New-AzureSBNamespace : A parameter cannot be found that matches parameter name 'CreateACSNamespace'.

    New-AzureSBNamespace : A parameter cannot be found that matches parameter name 'useAcs'.

    Any pointers workarounds here would really help.

  22. Anonymous says:

    I've just been stung with this same problem….the setup of service bus namespaces was something I just happened to not be doing as part of my CI process. It's not ideal as it means I can't just nip into the portal and fire up a new instance, it all has to be done via API calls.

    Why couldn't this just be an option in the portal when creating a new service bus namespace?

  23. Anonymous says:

    Hi Team,

    I am trying to connect Azure Service Bus to my iPaaS Platform which is Dell Boomi. I am using a JMS Server Type as 'Generic JNDI'. I wanted to understand how to get the details which I need to connect:

    Details I need to find from the Azure side are –

    Connection Factory JNDI Lookup

    Initial Context Factory

    Provider URL

    JMS Properties: Name/Value if any

    My research is based on the below link which says JMS connector should work with similar config as Apache. Link Below:…/QpidJNDI.html

  24. James says:

    Maybe we should be consistent then in applications like BizTalk where the builtin port type configuration for SB-Messaging REQUIRES ACS! This is still the case in the latest version.

  25. Newton De Godoy says:

    Dhawal Thaker   (8 Jun 2015)  is telling us that the New-AzureSBNamespace cmdlet does not have a  -CreateACSNamespace any more. Does it mean that the work around to use ACS for the Service Bus is not an option today (30 Nov 2015) ?

    I know that SAS has the best practice for quite some time, but I would like to get an authoritative answer possibly from the Azure support team that it is now the only option.


  26. RichV12 says:

    Man…  Working with Microsoft software is becoming more and more a huge gamble.  I want to get to the point where I don't spend 95% of my time pissing around with environmental crap and can just write the logic.  

    I understand that this stuff is complex under the covers, but each time I invest effort to research and bang out the right answer and document it, Microsoft messes around with it.

    I have spent DAYS trying to write a remote event receiver in SharePoint Online and get debugging working…  This worked before (maybe a year ago), after a couple days of troubleshooting of course.  Now, again, it won't work.  

    God help us all…

Comments are closed.

Skip to main content