I have an MS Access front end app (accdb) with an Azure SQL back end. I'm currently using SQL Server Authentication, but I'd like to use some sort of Active Directory. I don't have an on-premise AD, so I initially considered setting up Azure AD. However, our small team is already using Office 365, and to the best of my knowledge O365 is powered by Azure AD.
So my question is whether it's possible to use an O365 account (what Microsoft typically calls a "Work Account") to authenticate against an Azure SQL back end? If so, what type of Connection String do I use?
Ideally, when my users open up the Access app, I'd like them to get a pop-up dialog to "Single Sign-On" to their Office 365 account and use those credentials to authenticate against the Azure SQL DB in the back end.
Unfortunately MS Access is not supported at this stage. As far as I know it requires an ODBC driver that supports Azure AD authentication. This driver will be delivered in May 2016. But then MA Assess team has to integrate Access with Azure AD auth. Currently I have no ETA for this task.
Thanks,
Mirek
Microsoft accounts ( like outlook.com, hotmail.com, live.com) are not supported in the current version of Azure AD authentication for Azure SQL DB. Only native or integrated Azure AD users are supported.
For more details see
https://azure.microsoft.com/en-us/documentation/articles/sql-database-aad-authentication/
Thanks,
Mirek
Related
What pre-requisite services/subscriptions do I need to get to that point?
Right now, we have Azure AD Connect. Can that be used to authenticate users' access to the network shares of Azure Files?
I had to setup an Azure subscription first to access storage services. The azure subscription did not show pricing because it was a trial subscription. I did not know whether it would be per user subscription or not.
Azure Files supports identity-based authentication for Windows file shares over Server Message Block (SMB) using the Kerberos authentication protocol through the following three methods:
On-premises Active Directory Domain Services (AD DS)
Azure Active Directory Domain Services (Azure AD DS)
Azure Active Directory (Azure AD) Kerberos for hybrid user identities
For your use case where you want to use Azure AD Connect, you need to go with Azure AD Kerberos for Hybrid User Identities. You can find more information here- https://learn.microsoft.com/en-us/azure/storage/files/storage-files-identity-auth-azure-active-directory-enable?tabs=azure-portal
Here are details regarding a subscription in Microsoft Cloud- https://learn.microsoft.com/en-us/microsoft-365/enterprise/subscriptions-licenses-accounts-and-tenants-for-microsoft-cloud-offerings?view=o365-worldwide#subscriptions
Hope this helps. Please do let me know if you have further questions and I will be glad to assist you further. Thank you!
I'm having a hard time figuring out how to connect to an Azure Analysis Services using Azure AAD account with MFA.
I've installed the SSAS latest drivers.
I have Microsoft SQL Server Analysis Services (AdomdClient) as the data source type and I'm able to test the connection (it prompts for Okta MFA)
I'm able to create a dataset and use the query designer.
When previewing the report in VS, it returns this error:
The server did not provide a meaningful reply. This might be caused by a contract mismatch, a premature session shutdown or an internal server error.
If I change the data source to prompt for credentials, I receive this error:
Authentication failed: User ID and password are required when user interface is not available
Visual Studio 2019 16.10. Latest version of SSRS extension (2.6.11). Including power bi tag since it might be relevant too.
We faced a similar issue.
Ensure the user whose credentials you insert within the datasource are excluded from MFA within Azure AD policy.
If I have an on-premise SSRS instance on the same domain as my Azure AD, can I configure SSRS to connect to Azure SQL and pass through credentials so that I can determine (at the database) who has logged in and is running the report (for row level security)?
In other words, can I connect from SSRS to Azure SQL as you would using SSMS AD universal or integrated authentication to flow credentials?
You can, if you have the following:
SSRS 2016 or later
The Active Directory Authentication Library for SQL Server (ADALSQL) (https://www.microsoft.com/en-us/download/details.aspx?id=48742) installed on the report server
ADFS to federate across on-premises AD and Azure AD
Kerberos Constrained Delegation (KCD) configured from the report server to the ADFS server
Then you can configure the report/data source to authenticate to Azure SQL Database "as the user viewing the report" and the other components should do the rest.
Does anyone have any experience using the REST API reference for Windows Store for Business (https://msdn.microsoft.com/en-us/library/windows/hardware/mt608306(v=vs.85).aspx)?
I'm trying to use it to but having authorization issues. Does anyone know what needs to be passed over for authorization when using the api?
Then Store for Business service reply on Azure Directory for authentication. The management toll must be registered as an Azure AD application within an organization tenant to authenticate against the Store for business. About configuring your Azure AD application you could refer to this document.
To learn more about Azure Ad and how to register your application within Azure Ad, here are some topics to get your started:
• Adding an application to Azure Active Directory - Azure Active Directory integration with MDM
• Accessing other Web applications and configuring your application to access other APIs - Integrating Applications with Azure Active Directory
• Authenticating to the Store for Business services via Azure AD - Authentication Scenarios for Azure Active Directory
We are planning to deploy reporting service using Microsoft Reporting Server 2012. As I understand it, there will be three components;
Database (SQL Server)
SSRS (Reporting Server)
IIS (Web front end) - SharePoint (alternate Front end)
In setting up the Proof-of-Concept, the dev installed SSRS and SQL Server on same box (let's call it the DB server) and is redirecting client browser to a URL on DB Server from web front end.
Is it possible to architect the solution so that the web front end is the only destination for client browsers, SSRS lives on its own dedicated server separate from both the Web server and the DB Server?
How will authentication work in this scenario? We are using integrated authentication using Enterprise AD.
Configurations I have used in the past are these:
SQL Server on one server; SSRS native on another server. Users accessed reports via the SSRS Report Manager web UI that comes with SSRS.
SQL Server on one server; SSRS install in SharePoint Hosting mode on another server. Users accessed reports via SharePoint.
I am not 100% sure what you mean by “web front end is the only destination for client browsers”. If you mean that the end user only hits a web server, and not the database server to get reports, then either one of the above will work. If you have an existing intranet site that you want to host reports in, you can do so via web parts, if you are using MS technologies. You will still need SSRS setup somewhere so you can deploy reports, and the web part would read from it. Or, you can continue the redirect to either Report Manager or SharePoint if you go that route.
As far as authentication: the authentication between SSRS and SQL Server is usually done via an AD (Active Directory) user/service account that SSRS runs under, and also has access to the databases is uses on the SQL Server.
The authentication that allows users to browse and execute reports is usually done via AD as well. You can add all users to a central AD group and give that group Browser permissions on the SSRS server. This authentication would still apply if you use web parts to host reports outside of SSRS Report Manager.
The authentication that SSRS uses to pull the data that ends up showing in reports is usually SQL Server authentication, or whatever authentication that your data source supports where you can send a user name and password (which is stored within a shares data source on SSRS).
More Info