SSMS 18.0 GA Unable to Connect to Azure SQL With SQL Auth When Runas /netonly Used RRS feed

  • Question

  • My regular domain account does not have permissions to our on premise SQL servers. I have a special SQL domain account that I use for this purpose.

    I start SSMS using a batch file with the following:

    runas /netonly /user:domain\sqluser "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"

    While I am able to successfully connect to our on premise SQL servers via Windows Authentication, SSMS now refuses to connect to Azure SQL via SQL Server Authentication. Once I hit "Connect" on the "Connect to Server" dialog box it goes away without an error message and nothing happens. This was not an issue with SSMS 17.9.1.

    Edit 08/29/2019:

    Issue still exists in 18.2. It appears that it connects to Azure SQL if you don't check "Remember Password". Checking "Remember Password" makes the dialog box go away with nothing happening. My guess is that it's confused as to which user profile to store the saved creds under.

    • Edited by ltctech Thursday, August 29, 2019 8:11 PM
    Wednesday, May 1, 2019 12:22 AM

All replies

  • Hi,

    If you're connecting to Azure SQL with SQL auth, do you need to use the run as command?

    I cant test this myself today but why would you need to use run as if you're connecting with SQL auth?


    Wednesday, May 1, 2019 8:59 PM
  • The runas /netonly command is needed to login to local on premise SQL servers that require Windows Authentication. Without it I would only be able to authenticate against Azure SQL but not the on premise servers.

    Interestingly enough if I only do runas without /netonly it works, but then SSMS is running as another user entirely and that causes it's own issues with file access permissions.

    Wednesday, May 1, 2019 9:08 PM
  • What are you doing where you need to auth to both separately though? Sounds like this is a bug with the new version but I'm wondering what you're doing connecting to both to see if there is another way round it rather than downgrading SSMS?
    Wednesday, May 1, 2019 9:14 PM
  • Well for example if I need to modify stored procedures on both instances. I shouldn't need to close SSMS and run it as a different user to access the other instance.

    I honestly don't see any significant difference between 17.9.1 and 18.0 to justify using any kind of workaround. Both are installed on my machine so I'll just keep using the old one until they fix these kind of bugs. MS seems to be intent on rushing beta products to production.

    Wednesday, May 1, 2019 9:26 PM
  • Ah OK that makes sense. Thats frustrating - I guess you could open 2 separate instances of SSMS 18 and run the second without run as but then thats still 2 separate windows which makes it harder to work between them :-/
    Wednesday, May 1, 2019 9:30 PM
  • I have this same issue - connecting over VPN to local servers with Kerberos and also to servers in AWS with SQL auth doesn't work. Makes v18 more or less unusable for me. :(
    Thursday, July 11, 2019 4:35 PM