So what I'm trying to accomplish here is basically just like an SQL server connection, I want to connect SSAS instance from another computer in the same network using a login account. Things I search online mostly deviates from this a lot at some point. What I need to know is what configurations should I do on SSAS services to enable this? How to crate a new login account (the system I am connecting from is not windows based so no windows authentication) and basically how to build connection string?
I have checked some documents of windows but mostly I am lost.
SSAS clients support NTLM, Kerberos, and (only with the data pump) HTTP Basic and Anonymous auth.
Of those Kerberos and HTTP Basic (with the data pump) are usable on non-Windows platforms. But I don't know if ADOMD.NET for .NET Core (the only non-Windows driver) supports Kerberos on non-Windows platforms.
Related
We are currently investigating the viability of using OBIEE as the presentation tier for our BI solution (SQL Server 2012, using both the database and analysis services). IIS (which is utilized as a pass through for OBIEE to access SSAS via XMLA) is version 7.
When trying to import SSAS cube metadata into OBIEE, we are receiving "401 - Unauthorized: Access is denied due to invalid credentials". The connection from IIS to SSAS has been tested via Excel and established as working. Looking at the IIS logs, it appears that the username is not passed through when connecting via OBIEE, but is passed through when using Excel.
We have also tried using a local user to no avail.
Thanks in advance.
Undoubtedly there is a better solution, however, here is how I was able to get it to work.
Use anonymous authentication on IIS
Provide IUSR access to the cubes in question
Configure IIS to accept connections from the OBIEE server only, for
the XMLA pass-through site in IIS
Now, certainly less than ideal, but works.
Is there a way how to restrict access to SSAS Cube by application?
I would like to have access only from "my application" and restrict all other application, like Excel.
Maybe add some special key in to connection string and then deny all connections without it on windows firewall? (but I can't find if this is possible, its just an idea)
Thank you.
n-tier architecture
Client Apps <== HTTP WS ==> Server Apps <=> SSAS
access to SSAS - only on the local network (from Server Apps).
The client application accesses the Server only through web-services
I'm trying to test a migration of moving a BizTalk SQL Server from one server to another. Here are the details.
Currently it was all on a single server in a dev environment, BizTalk SQL, SSO and BizTalk runtime all on one server. It is a Windows 2008 R2 server with SQL Server 2008 R2.
What I want to do is split out the SSO Master secret server and BizTalk databases to a Windows Server 2012/SQL Server 2012 setup. So far I got SSO all setup on the new SQL server. I configured just the SSO portion on that server and all went well.
I then unconfigured the existing BizTalk Runtime and then went to configure again, using the new Windows/SQL Server/SSO in the configuration process.
All goes well up to the point where it tries to configure the BizTalk runtime. That being said all the database are created, SSODB, BizTalkMessageBoxDb, all of them. But when it goes to configure BizTalk Runtime, it hangs for a while and several of the following errors show up in both of the Server's logs:
Could not access the SSO database. If this condition persists, the SSO service will go offline.
Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding..
SQL Error code: 0xFFFFFFFE
It shows up in the SQL/SSO servers logs first, then the Runtime server a few seconds later. Eventually the configuration times out and fails. I believe it's permissions related, but I can't seem to figure out what it would be.
Questions:
what permissions do I need to review?
would the fact that the new server is Windows 2012/SQL 2012 while the runtime server is Windows 2008 be an issue?
is there any way I can get more details on this error?
Edit to add both DTCPing and DTCTester pass with flying colours and I can connect to SQL via SSMS from the server. Firewall has been completely disabled for now in order to eliminate that as well.
How were your service accounts configured in the first environment? Typically a single DEV environment with everything on one box can be done by using a local account on that server. If you now split out your SSO onto another server (it doesn't matter if it's W2K12 instead of W2K8), you are going to have to switch your service account(s) and groups for BizTalk to Domain accounts.
In a multicomputer environment, BizTalk Server supports only domain groups and domain service accounts. Domain groups include Domain Local groups (not recommended), Global groups, and Universal groups. Built-in accounts such as NT AUTHORITY\LOCAL SERVICE, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\SERVICE, NT AUTHORITY\SYSTEM, and Everyone are not supported if you want to configure BTS in a multicomputer environment.
Make sure your SSO is running as a domain account, and a member of an SSO Administrators domain group - and ensure this domain account/group combo is configured for the SSO system on the SQL server (instead of local accounts):
After that the SSO system you join from the BizTalk Server before configuring the runtime on BizTalk Server usually needs to be configured with the same domain service account for SSO:
We are developing an application that uses a Windows Azure cloud service, and a SQL Azure database. We have an ASP .NET MVC project that uses database-first to create the entities in our Visual Studio solution. Now we need to deploy the database schema to Azure.
Currently this is not possible because our network blocks outbound access on port 1433, which is the only port SQL Azure is available on. We have asked our security team for permission to open port 1433 outbound, but they have some concerns:
There is unencrypted database traffic (port 1433) allowed at Microsoft's firewall over the internet for Azure. Although there is no sensitive information in the database, management credentials are probably in clear text if database credentials are not encrypted and can lead to defacement risks.
What network ports are opened at the internet firewall for access to the system hosting the website and database?
I believe the concern in the first question is that credentials for managing the Azure DB will be sent over on port 1433 unencrypted during deployment. For the second one, I think the answer is that we can configure endpoints to open whatever ports we want for our cloud service, but they are closed by default.
I did some research, but was unable to find any definitive answers on these questions from Microsoft, which makes me think we are asking the wrong questions. I would be interested in insight from anyone with more experience in this than I have.
SQL Azure only accepts encrypted (SSL) communication per the Security Guidelines and Limitations (Windows Azure SQL Database) article here: http://msdn.microsoft.com/en-us/library/windowsazure/ff394108.aspx
Encryption and Certificate Validation All communications between
Windows Azure SQL Database and your application require encryption
(SSL) at all times. If your client application does not validate
certificates upon connection, your connection to Windows Azure SQL
Database is susceptible to "man in the middle" attacks. To validate
certificates with application code or tools, explicitly request an
encrypted connection and do not trust the server certificates. If your
application code or tools do not request an encrypted connection, they
will still receive encrypted connections. However, they may not
validate the server certificates and thus will be susceptible to "man
in the middle" attacks. To validate certificates with ADO.NET
application code, set Encrypt=True and TrustServerCertificate=False in
the database connection string. For more information, see How to:
Connect to Windows Azure SQL Database Using ADO.NET. SQL Server
Management Studio also supports certificate validation. In the Connect
to Server dialog box, click Encrypt connection on the Connection
Properties tab. SQL Server Management Studio does not support Windows
Azure SQL Database in versions prior to SQL Server 2008 R2.
SQL Azure uses 1433 and 8443. The port requirements for Azure are available here: http://msdn.microsoft.com/en-us/library/windowsazure/jj136814.aspx
If you want to limit firewall traffic to and from specific IP addresses, the Azure datacenter IP ranges are available here: http://msdn.microsoft.com/en-us/library/windowsazure/dn175718.aspx
Some options (in addition to DarrelNorton's answer):
- you can use a dedicated SQL Server VM, then you can use port forwarding and the port issue is not a problem and you have additional firewall options and additional security software you can instal
- dedicated SQL VM allows you to take advantage of TDE (Trans. Data Encryption) in SQL Server or you can do more advanced encryption techniques that are not available in SQL Azure DB
- Dedicated SQL VM you are isolated from other MSFT clients. If you get hacked, you can re provision the VM from scripts
- you can use a Virtual Network connection between the MSFT data center and your local network if you are concerned about security (the VPN is encrypted)
I'm trying to connect a web forms application to an SSAS Cube. The app is using web forms authentication and it is using web roles in Azure. The SSAS cube is on a Virtual Machine within Azure. There is no domain installed. The web app is using GrapeCity's Active Analysis control. When running the app i get the error "An existing connection was forcibly closed by the remote host". While profiling on the server I get an "Anonymous Logon" attempt.
How can I set this up?
SSAS uses Windows authentication only, so either:
1) You somehow get your web app's application pool to run under a windows account that can access the cube box (Sounds unlikely).
2) You have your application pool run under a windows account and create a windows account with the same username/password on the cube box, and assign it the permissions (Used to work, I think it still does).
3) You allow Anonymous Logon read permissions to your cube. I know you can do this at the server level (Dev enviroments..), I haven't tried it at the cube role level.
These are the ones I know of, best of luck.
EDIT: Sorry, thought I'd forgotten one, there is basic authentication if you add IIS as an extra layer, you have to set it up to go via the MSDMPump.dll, full explanation here: http://msdn.microsoft.com/en-us/library/gg492140.aspx