I have just finished the development of my application on asp.net mvc connected with SQL server, and I will love to deploy it. I want to use Azure App service, but I got an error "Unable to connect to master or target server 'DATABASE_NAME'. You must have a user with the same password in master or target server 'DATABASE_NAME'". I have tried every thing I found online like modifying the SSDT, but nothing changed.
Please is there any recommendation to fix this issue? If not, Please what are other ways for me to launch the application. The application will be used internally for Sales purpose and I don't need any fancy hosting. Thank you in advance.
Did you setup the sql azure firewall to accept connections from your computer?
Even if you set it up once, it is possible that your internet provider attributed a different IP address to your computer. So you must redo your firewall set up again for your computer to be accepted.
It is important to know that only sql logins/passwords are accepted here. So you must give the login/password of the admin user that you mentioned at the moment of creation of you sql server azure (there is a step that sets it up when you create your azure database), or the login/password of a user you created and granted in this database.
Related
I'm new to SQL Server. I was a postgres user before. I installed the default SQL Server on my local machine and I'm trying to get an old react with node js application of mine working with a SQL Server. When ever my frontend makes more than 1 call to the backend, if my SQL Server has admin privileges it throws
Error: 17810: Could not connect because the maximum number of '1' dedicated administrator connections already exists.
If not, it throws:
Error 18451: Only administrators may connect at this time.
I checked my database configs and it's set to MULTI_USERS, so I don't understand why I can't login without admin privileges. Can someone help me with this? I wasn't able to find anything online.
My NodeJS backend is using TypeORM to connect to the database
The dedicated administrator connection is a different kind of connection. It's not just "a connection being made by someone with administrative access". You would use the DAC when the SQL instance is having some kind problem, and you can't connect at all because resources are all tied up. SQL will reserve some resources especially for the DAC connection to make sure you can still connect.
A DAC connection can be made by specifying ADMIN: as part of your connection string, which will connect to the assigned DAC port.
You shouldn't use this for "routine" admin work. Just connect using a login with the required administrative server roles (eg, sysadmin). You definitely shouldn't use this as part of a regular application's connection string. You shouldn't be using a SQL Server sysadmin login either. Create a user with the appropriate permissions for your application, and don't use the admin connection.
Regarding your second issue: Make sure the instance wasn't set to start in single user or minimum configuration mode using startup flags. Note that this is for the whole instance, it's not the same as the configuration for an individual database.
I've deployed my project to Azure and my login page loads. When I attempt to login, it hangs for a moment and returns an "Access is denied" error. I've double and triple checked my connection string and it matches the one provided by Azure.
I've deployed to Azure in the past but it's been a while. Is there something I need to do in order to make my DB accessible? I read a couple articles about similar problems people had with remote connections. It involved turning on remote connection accessibility in SSMS, but I don't see that being the case in my situation as it's not being accessed thru Sql Server.
Are there modifications I must make to my DB to make it accessible on Azure?
Here's my error:
EDIT - I am using forms authentication for user handling if it makes a difference.
This error indicates that your Azure SQL Database is not configured to accept connections from the service you are trying to connect.
You have to Enable Windows Azure Services to connect to your Azure SQL Database Server.
To achieve that, navigate to your Azure SQL Database Dashboard and click on Manage Allowed IP Addresses, as shown bellow:
Then On this new page, make sure that Windows Azure Services are enabled (YES):
I had the same problem and found that I didn't have the database and the app service in the same location. One was in Australia East while the other was in Australia South East. I moved my app service to be in the same location as the DB and bingo. :)
I have a situation where clients connecting to my webservice(that exists on another server) must access SQL Server databases and SSAS servers.
It must use the credentials of the client that is calling the service when accessing the SQL Servers and SSAS cubes.
For this to work I do
var winId = HttpContext.Current.User.Identity as WindowsIdentity;
var ctx = winId.Impersonate();
//Access Database/SSAS
ctx.Undo();
in my service which works fine when accessing SQL Server databases.
However when I access the SSAS servers I get
"The connection either timed out or was lost"
There are a number of posts like
http://denglishbi.wordpress.com/2009/03/31/windows-server-2008-kerberos-bug-%E2%80%93-transport-connection-issues-with-ssas-data/
http://sqlblogcasts.com/blogs/drjohn/archive/2009/03/28/kerberos-kills-large-mdx-queries-on-windows-server-2008-ssas.aspx
on this but I am using Windows Server 2008 R2
where my service lives so this should not be a problem as this bug should have been fixed by Microsoft.
Any information as to how to best diagnose this problem would be appreciated.
To clarify the SSAS servers do have SPNs. This was actually working at one point but has now stopped. Appears no sign of duplicate SPNs or anything.
What is interesting is it works intermittently on one SSAS server but seems to work all the time for the other.
They both have named SPNs as mentioned by this document
https://support.pyramidanalytics.com/entries/22056243-Configuring-Kerberos-Delegation-for-Named-Instances-of-SSAS-with-Active-Directory-and-additional-pro
My production environment is a load-balanced (and under heavy load) on a very large corporate Active Directory network. The following took a lot of testing to finally nail down settings that work.
I also run on Windows 2008 Server R2
My web services are in ASP.NET in IIS. For authentication I enabled "Windows Auth" and "ASP.NET Impersonation". Kernel mode is disabled and provider is "Negotiate:Kerboros"
SPNS and Trusted Delegation are setup for an AD account. My AD account looks like sys_myservice (sys_ is just a naming convention at my company)
The Application Pool identity is set to use the sys_myservice
After you make all these changes in your dev env, restart the entire server. For some odd reason this is always necessary when we bring on new servers and configure them.
With this setup my web services access SSAS, SQL Server, and more that use Windows Kerboros auth and all queries are performed correctly under the user's credentials.
The difference in my setup from yours is ASP.NET Impersonation is enabled at the IIS level. I had trouble doing the impersonation in code which is what you are trying to do. If you get code-level impersonation to work with your workflow I would be really interested in seeing you post an update.
Forgot to mention. My services are in a MVC application, I apply a global filter to all Action methods to force the application to authenticate all connections.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
filters.Add(new System.Web.Mvc.AuthorizeAttribute());
}
and in my web.config system.web section
<authentication mode="Windows" />
<identity impersonate="true" />
I agree that the intermittently 'successful' SSAS instance is suspicious. I wonder if it's really using Kerberos all the time. Could be using a combination of negotiate/NTLM and Kerberos, with one auth method actually working and the other approaching failing. Might be worth another look at the SPN. This link might help: http://msdn.microsoft.com/en-us/library/dn194200.aspx
Did you try using Wireshark or any other Network Analysis tools to see anything red happening at that point of failure? Probably its better if you provide more troubleshooting observations from your end.
Also, does your web services has a Load balancer?
Regards,
Sasi.
I'm trying to configure Team Foundation Reporting but without any success.
The App Tier and the Data Tier are in separate servers.
I guess it's not a port/firewall problem, because I opened port 135, and I can see the established connection by using TCPView (from Sysinternals) whenever I click "Populate URLs" in the Reports tab in TFS Administration Console. I can also telnet servername 135 without any problems.
I also checked if WMI service is started in the Data-Tier. And for SQL Server Reporting Services. Also checked for RPC and RPC Locator in both servers. They're all started and automatic.
I also set tfs app user as admin in sql reporting services. Added all kinds of permissions to the tfs user in the Data-Tier server.
I set all user permissions in dcomcnfg.
Allowed all WMI namespaces permissions to the user. (Computer Management -> WMI Control)
Deactivated Windows Firewall in both servers temporarily.
No luck.
However, in the app-tier, when I click Computer Management -> Connect to another computer, and type the data-tier IP, i can't connect. I get the message "Computer xxx cannot be managed. The network path was not found". How is that ? Tried IP, name, and FQDN. I also tried browsing and selecting the computer. Nothing changed.
I'm lost, what could possibly be happening ?
Thanks in Advance!
i'm betting that you're having the double-hop issue. try having your system admin set an spn for the website on the sql server.
you also need the AD permission 'trust for delegation' on the AD Service Account, right?
do that and SetSpn with the service account, that should help I think that the SPN option was spot on
See this answer:
IIS to SQL Server kerberos auth issues
which links to an old but user-friendly troubleshooting web app called DelegConfig. It can try to run the SetSpn commands for you, at least giving you an idea of what they need to be.
I ran into SPN issues when using an externally-accessible URL (+SSL) everywhere.
I have an analysis services cube in SQL server 2005 which I'm connecting to via an excel front end.
When I connect via one user its fine, but when I log on to the same machine as another user I get an error in my excel spreadhseet - "user...does not have access to the [Cube name] database"
Obviously the first user has the correct permissions, but how do I set up analysis services to allow other users to join the party?
Login to the machine with an account that is an administrator (Domain\CubeAdmin) on the cube. Connect to the cube in BIDS (run devenv.exe and open Analysis Services Database).
Under Roles, create a reader role and in the Membership tab, add the user account (Domain\NewUser).
All this will only work if the SSAS Server Administrator gives the Domain\NewUser access to the server.
The Windows user accounts that you are trying to access SQL Analysis Services with need to be added to the Roles in the Cube that would allow the permissions you want.
If you are connecting over HTTP using msmdpump.dll through IIS you need to turn on Authentication for that site and allow the Windows user account to access the site.
If the IIS site using msmdpump is on another machine and you aren't using a domain then the accounts would need to exist on both servers with the same password.
I know this is old but for other's reference, I had to repair the MS Office install to resolve a connectivity issue with SSAS. The user was added to the role, but the error "Cannot connect to server" was displayed when connecting.
Raj has already answered the initial question... You need users to be set up with at least read access to your SSAS instance.
However, the error "Cannot connect to server" does not necessarily mean it's an authentication issue, it actually doesn't mean much. I've seen this error on Excel 2007 on various occasions, where the underlying error could be anything, this is just a generic error from Excel.
Several aspects that caused problems on my end were (things to check):
User has access to the web site (if not using anonymous auth)
ADOMD and OLEDB for Analysis Services are installed locally (correct version)
User propagated to SSAS has read access to instance (are you using ApplicationPoolIdentity?)
Handler mapping (script mapping for *.dll) is set up
For a complete guide of how to set up HTTP access for SSAS check:
Microsoft - Configure HTTP Access to SSAS via IIS
Cheers