My organization has an Azure tenant. The tenant has three subscriptions. Each subscription has multiple Azure SQL Servers. On two of the subscriptions, the databases can be accessed via one of the Active Directory authentication methods. On the third subscription, the only method of access is via SQL Server Authentication. I am the owner of this third subscription.
If I configure an Active Directory Admin for the Server, the error I receive is:
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. (Microsoft SQL Server, Error: 18456)
When I remove the Active Directory Admin for the Server, the error I receive is:
Requested tenant identifier '00000000-0000-0000-0000-000000000000' is not valid. Tenant identifiers may not be an empty GUID.
How do I change this so that the SQL Servers can be accessed via Active Directory authentication? What is the best approach to determine the the differences between the subscription at issue and the other two subscriptions?
To solve this issue, you need to set Active Directory Admin for the SQL Server (Settings -> Active Directory Admin).
Related
I am trying to publish Azure SQL database using Azure SQL Dacpack task in Azure pipelines within an agent job. The authentication type I am using to publish is Service Principal.
I have added service principal as a contained DB user in the Azure SQL database and have given db owner permissions to service principal. When Service principal is a member of Active Directory Admin of Azure SQL Server, the deployment works fine. But , when Service principal is not a member of Active Directory Admin of Azure SQL Server , the deployment fails.
The error that I get is:
Unable to connect to target server . Please verify the connection information such as the server name, login credentials, and firewall rules for the target server. + Login failed for user '< token-identified principal>'. The Azure SQL DACPAC task failed. SqlPackage.exe exited with code 1.
Security team in my organization is not allowing me to have SP as Active Directory Admin of Azure SQL Server.
Azure SQL database only allow server admin/AD admin account to restore/backup the database. That's the permission limit and we can't change it.
Like you said, only if the service principal is a member of Active Directory Admin of Azure SQL Server, the account has the permission restore the database from .BACPAC file.
HTH.
I am trying to enable Active Directory access for an Azure SQL Database. But I ran in a bit of a chicken-egg problem:
On the properties tab of my SQL database, The Active Directory admin shows an AD user group I am a member of
I cannot login. If I try to connect to my database using this AD-user, either via the Query editor (preview) tab or through SSMS, I get "Login failed for user ''."
If I login using the Server admin login or through a SQL account, I can login, but I cannot execute CREATE USER myname FROM EXTERNAL PROVIDER. It returns "Only connections established with Active Directory accounts can create other Active Directory users"
How did I create this mess?
On Azure, I already had a SQL Server with a SQL database. I can login onto that server using my Active Directory account. I had a local database, and in SSMS I selected "Deploy database to Microsoft Azue SQL database..." and selected my existing SQL Server.
As I understand it, AAD needs to know the SQL server, not each individual SQL database. If I do a Point In Time restore of my main database, I can also access this database with my AAD-account. But of course, this database already contains the active directory user group.
So Azure thinks I can logon to the database with my AAD-account,
but the database itself does not know any AAD accounts.
And I can only create AAD accounts in the database when logged in with an AAD-account.
How do I create an Active Directory Account within my database without being logged on with an Active Directory Account?
How do I create an Active Directory Account within my database without being logged on with an Active Directory Account?
No, we can't. In Azure SQL database, you need to first to configure the Azure AD admin for the SQL Server, then login the database with AAD admin account to create the AAD user.
I think you have configured it. As you said you can login with you AAD-account. That's the Azure AD admin account. It has the permission to access all the database.
Important:
To create contained users mapped to Azure AD identities, you must be
logged in using an Azure AD account that is an administrator in the
database in Azure SQL Database. In SQL Managed Instance, a SQL login
with sysadmin permissions can also create an Azure AD login or user.
Ref here: Authorize database access to SQL Database, SQL Managed Instance, and Azure Synapse Analytics
So we have Azure AD synced with our on-premise domain. We have an Azure SQL Server configured with the active directory admin. We also have a non Azure SQL server running on a virtual machine in Azure that is domain joined to this same domain. The following are the results of using the various authentication mechanisms offered by SQL Management Studio (SSMS). Can someone explain why the failures occur with the various options that should be supported?
Facts about environment:
Passthrough authentication is the sign-in method configured on AD Connect
Password hash sync is also enabled so password hashes are stored in Azure AD
Azure SQL is configured with Active Directory admin
Latest version of SSMS was downloaded when performing these test
On premise account was used to test all scenarios
Domain joined client connecting to Azure SQL from SSMS
Active Directory Password (PASS)
Active Directory Universal (PASS)
Windows Integrated (FAIL - not supported by Azure SQL)
Active Directory Integrated (FAIL – see error below)
Failure when client is standard domain joined client
Failure when client is Azure domain joined client
Domain joined client connecting to non-Azure SQL hosted on same domain
Active Directory Integrated (PASS)
Windows Integrated (PASS)
Active Directory Password (FAIL – Login failed for user ‘’)
Active Directory Universal (FAIL – Login failed for user ’’)
This issue may be related with the AD Syncing options. Verify in your environment that AD is not syncing passwords into the tenant. This prevents AD Integration Authentication and AD Password Authentication. The only authentication that works on these cases is AD Universal Authentication, as your test shows.
It looks to me that his is an ADAL problem (WSTrust) related to network configuration. Please create a support case and work with the support team to solve this problem
I have an IIS 7.0 server connecting to an SQL 2012 Database. On the SQL database I have added a number of linked servers and created a distributed partitioned view to consolidate data from the multiple linked servers. I have a common Windows account on the main server and the linked servers that is common to all (same password). Querying this view from SSMS on the SQL server works fine logged in as the common user. The application pool I am using uses this same user (also on the IIS server) to connect to the SQL server using Integrated Security. I have a simple query of SELECT SYSTEM_USER when run from IIS reports the common user. When trying to retrieve the data from the linked server view I get Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. instead of the data in the view.
Help appreciated
This is basically what is happening: If you are running Active Directory, this is the famous "double-hop" problem. Double-hop is a term used to describe Microsoft's method of maintaining Kerberos authentication credentials over two or more connections. You must configure Kerberos delegation on the AD account running the application pool so that it can forward credentials to the SQL 2012 database server. You configure this on the Delegation tab of the AD account. Without Kerberos delegation, the AD credentials are not forwarded and instead local credentials are sent by the IIS server and get denied by the SQL server. Since the SQL Server doesn't understand the local credentials of the IIS 7 server it denies it as an anonymous logon attempt. The link I provided describes the resolution to this problem in full detail and explains how to expand it out to other servers. Note that if you are not using Active Directory and only local authentication then NTLM is being used and NTLM credentials cannot be delegated off the system so authentication to the SQL server will be in the form of anonymous authentication.
We currently have around 400 client databases hosted on a SQL Server in Azure. When initially setup, no Active Directory admin user was set, only a server admin and this server admin is used at the moment for all connection strings. If I were to add an Active Directory admin to the server, would this have any effect on the connection of any of the databases using the server admin? In other words, would the server admin still work fine and adding Active Directory admin not disconnect any users currently connected to the SQL server?
No, adding an Azure AD Admin won’t affect any connections using the Server Admin or any other login.
However, the recommended way applications should connect to SQL Azure databases is via contained users. Contained users do not get disconnected during failovers (geo-replication) and they travel with the databases (backups, readable copies).
Agree with Alberto Morillo, we should connect to SQL Azure databases via contained users.
More information about contained users, please refer to this link.
By the way, when we setting up the Azure AD admin, the new admin name
(user or group) cannot already be present in the virtual master
database as a SQL Server authentication user. If present, the Azure AD
admin setup will fail; rolling back its creation and indicating that
such an admin (name) already exists. Since such a SQL Server
authentication user is not part of the Azure AD, any effort to connect
to the server using Azure AD authentication fails.
More information about provision an Azure Active Directory adminstrator for your Azure SQL server, please refer to this article.