is it possible to use a database created in a Azure VM as a data source for model which is created in Azure Analysis Services?
So far, when I specify connection properties for the model in the web designer and test connection, I get an error stating "a connection was successfully established with the server, but then an error occurred during the login process. (provider SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.)
I can connect to the server via SSMS and via RDP.
I created a self-signed certificate in the azure key vault and was able to make the SQL server use it. However I can't seem to find out how to make use of it when connecting the model.
Does anyone know if it's possible and if so, what should I do to make it work?
In the end I managed to make it work. For anyone with similar problem, I will write my solution below.
For the error "The certificate chain was issued by an authority that is not trusted" - just as discussed in the thread linked by TJB in comment, this was because I did not have a CA signed certificate, but a self-signed one.
A CA signed certificate from Azure would probably solve the issue, but I tried the Let's Encrypt site (also linked in the other thread). The issue I had with Let's Encrypt was that I had a windows server, while they natively support linux-based systems.
However I found an article by Daniel Hutmacher called Encrypting SQL Server connections with Let’s Encrypt certificates which was solving the very issue I had.
(as for the client tool, the current version is different from the one described in the article, but you can still download the old version on github. I used the lastest november 2017 release). With this I was able to generate and add a CA signed certificate to SQL server.
At this point, I created a model in Azure Analytics Services, used Azure Database as type of source/connection and filled in the connection to my VM SQL server. I saw my database tables, but when I tried to query data, I got a new error, stating that the AAS need an On-premise data gateway set up.
The Microsoft docs Install and configure an on-premises data gateway describes how to install on-premise data gateway on the VM, but if you are like me and use personal account for azure, you will have issues binding your account to the gateway. The solution as hinted here is to create a new account in Azure Active Directory (I created a new user and registered it under my azure custom domain, so the login looked like XXX#zzz.onmicrosoft.com). I gave the user admin role, so as to temporarily avoid any azure permission setbacks. Next I added the user to my subscription via Subscriptions -> "My_subscription" -> Access Control (IAM) and assigned an owner role to the AD user.
Now back on my VM I could bind the new user's account to the gateway (don't forget to change the gateway's region to your preferred region before finishing the setup).
Next, on Azure I created an "on-premise data gateway" service (do note you need to select same region as the one which your VM gateway is located under). I am not sure now, if only the new AD user I created could see the gateway, so in case you do not see it, try the AD user as well.
Last but not least, in the Azure Analytics services I went to the "on-premises data gateway" settings and set it to use the one I just created.
With this I was able to create the model and query the data from database.
Note:
In the model web designed for analytics services I happened to be logged in under the AD user, not under my personal account. Attempting to change the account to my personal one ended up in login failure, however after a few such attempts and opening multiple web designers in separated tabs, I correctly logged in under my personal account. After a while I could no longer replicate the issue.
I guess the issue may have been that I was logged in to Azure under both my personal account and the AD user at the same time in same browser when setting eveything up.
Related
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.
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 developer MVC4 + EF Code First + SQL Server 2008 web app. Uploaded it to prod server with IIS7. Created new credentials PC. Added empty database PCDB to SQL Server and assigned user PC to it with owner permission. When I run web app I get error
Model compatibility cannot be checked because the database does not contain model metadata. Model compatibility can only be checked for databases created using Code First or Code First Migrations
My connection string is
data source=174.xx.x.x;initial catalog=pcdb;user id=pc;password=xxxxx;
The exception is understandable, I can delete PCDB database and let EFCode First create it by itself. But how about credentials PC? I do not want to make PC user as administrator but without it EF Code First will not be able to create new database in SQL Server.
How to solve the problem?
The overall design starts with Forms or Windows authentication at the WebsiteASP.NET/ IIS.
and ends with Application and DB authentication you want/need. Application authorization is another topic. I will not discuss that here.
You dont actually state the authentication model desired.
So I will start with a disclaimer. This a suggestion that I WOULD use in a production site. But it is not the ultimate end game nor is it the ONLY short term solution you might consider.
This is a solution that a one man show can get working. And is secure and without excessive admin effort to keep running.
Use SQL server logon via Windows Auth
BUT you do not need to add every user to SQL server.
There is also the option of impersonation. But that can get tricky and this explanation is not NOT impersonation. That is another another approach.
first make sure Website is using Windows Authentication
set IIS to use Windows Authentication:
Now the APP Pool behind the website on IIS you have configured. .
Im going to suggest a Psuedo-service user in the APP pool as a good way to start.
ie WEBAPPLICATION_X_USER. You can have a separate user per APP pool. Each user can access only its DB. So you get application separation. Your enter a user and password here. IIS will encrypt and decrypt as required. (better than plan text in Web.config)
This user should have reduced auth on the server itself. NOT AN ADMIN user on domain or even local admin. Just enough so it can use Sql server to create a DB. So create a regular windows user
Let ASP.Net logon to DB. Let ASP.net encrypt and decrypt the password.
So now the situation is Windows AUTH on IIS. IIS has an App pool with a special windows user that can logon to SQL server. You have added this user to SQL server instance and Allocated this service user the ability create DBs. Dont give the user access to ALL Dbs :-) Just the one it will create. Plus public access (via EF).
Verify the user credential situation in your WEB APP.
See [System.Security.Principal.WindowsIdentity]
This should show your windows authenticated end user.
System.Environment.UserName should have the service user ID you placed in the IIS APP POOL.
Now when EF goes to create or access data on the SQL server instance, it will connect with
System.Environment.UserName if the WEB.CONFIG entry is set to use windows integrated security
<connectionStrings>
<add name="DbContextName" connectionString="Data Source=Your SQL server Instance;Initial Catalog=The DBNAME;Integrated Security=True;MultipleActiveResultSets=True;App=EntityFramework" providerName="System.Data.SqlClient" />
And you KNOW the authenticated user.
httpContext will give it to you as does thread current principal.
HttpContext.User is by default mapped to {System.Security.Principal.WindowsPrincipal}
So you can perform application level checking.
The same approach should also work with Forms Authentication.
WARNING: If you have windows WPF approach (ie you are not using IIS and therefore no APP pool), then this approach MUST be changed and is more complex and no longer the best place to start.
I hope this helps you get started
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
I'm having a very confusing error between SharePoint and SQL Server 2k5.
My SQL Server acting as backend to my MOSS farm has several logins in it which correspond to the web front end servers in my farm, with the pattern: {my-domain}{my-machine}$
Now, those accounts do not exist in AD anywhere, despite the login name syntax, and were generated somehow (assume by MOSS, but can't confirm). One (and only one) of the servers is throwing login failures every 2 minutes; that server was the first in the farm and holds most of the services, just not search and indexing.
I did a number of traces in SQL Profiler, and all I can tell is that the failure is a type 16 error on 'master'; so the login exists but doesn't have rights to 'master'.
Having found that, I went back in and gave it progressively greater rights on Master, including db_owner, and eventually making it a sysadmin. Still no joy, same error.
Diggin further w/ tracing, I found that the actual failure was due to the SSO db not existing; probably b/c it wasn't configured in MOSS. When I tried configuring the error, I got a "Sorry, you're not authorized to do that" error in Central Admin, even though I was logged in as the farm admin, who's also a forest-level admin w/ rights to everything I can think of.
Turning off SSO as a windows service worked, but I'm concerned about my inability to configure it in MOSS, so I dont' want to leave that as a solution.
I'm out of ideas, anyone else have thoughts or experience on this?
Thanks
The {my-domain}{my-machine}$ account is an alias for the NETWORK SERVICE built-in local machine account. NETWORK SERVICE is a low privilege predefined account that was introduced in Windows 2003. It has network credentials and can therefore connect to remote databases (as long as they're within the same domain).
It sounds like you've created your SharePoint web applications with the default application pool identity. This will create the logins named {my-domain}{my-machine}$ in SQL Server. So yes, SharePoint created the SQL logins, but they're based on the built-in NETWORK SERVICE machine accounts on the servers in your farm.
I'd check that the account you're using to configure SSO has the rights to create the SSO database. Have a look at the table in Plan for single sign-on. It lists all the privileges required for all the different types of SSO accounts. For the configuration account, the document lists:
SSO configuration account:
Must be a user domain account. Cannot be a group account.
The user account must be a server farm administrator.
Must be a member of the Administrators group on the
encryption-key server computer.
Must be a member of the following SQL Server security roles on the
computer running SQL Server:
Dbcreator
Securityadmin
Must be either the same as the SSO administrator account, or be a member
of the group account that is the SSO
administrator account.
If that doesn't help, follow Alex Angas' advice and post this question to serverfault.com.
Try and follow this to configure SSO:
http://technet.microsoft.com/en-us/library/cc262932.aspx
We had this same problem - the source of your "Not authorized to do that" message when you configure SSO is that you need to be logged into Sharepoint Central Admin as the SSO user (in our case, it was DOMAIN\SSO_Proxy). This allowed us to make the changes we needed.
Good luck!