A user is trying to connect to an Azure SQL Database via SQL Server Management Studio (SSMS v16.5.1).
The user's current IP address is not listed in the Azure SQL Server's firewall rules.
Because of this the user is shown the New Firewall Rule dialog.
When the user signs in using their Azure Active Directory (Azure AD) credentials they get an error message saying:
Account has no subscriptions
Clicking "Details" shows:
We experienced issues in connecting to Azure
Additional information:
login account does not have Azure subscriptions.
(Microsoft.SqlServer.Management.ApplicationAuthenticationManagement)
Why is the user getting this error message and how can they add a new firewall rule for their IP address?
Azure support have shared the below with me, based on an Azure documentation article.
Given an Azure SQL Server, only the Active Directory admin or SQL Server admin have permissions to add firewall rules at the server level.
The above error message (somewhat obscurely) indicates that the user is neither.
My personal experience also suggests that Azure AD accounts that are assigned as Subscription Co-administrators can also set firewall rules.
If, and only if, giving the user permissions is appropriate, this can be done by one of three ways:
Specifying the user as the SQL Server admin.
Setting the server's Active Directory admin to be an Azure Active Directory Group and making the user's AD account a member of this group.
Making the user a Co-administrator for the Subscription via https://manage.windowsazure.com/
Be sure to understand the security implications of each option before taking action.
Look at these two tutorials that will be live shortly (later on 1/13/2017):
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-control-access-sql-authentication-get-started
https://learn.microsoft.com/en-us/azure/sql-database/sql-database-control-access-aad-authentication-get-started
These tutorials discuss using server and database level firewall rules with SQL Server authentication and Azure Active Directory authentication.
I hope these help,
Carl
In Azure Portal (https://portal.azure.com/#resource/subscriptions/{Your-GUID}/resourceGroups/AdminPortalDev/providers/Microsoft.Sql/servers/wjidentityserver/databases/{Your-DATABASE_SERVER}/overview )
Select your database
Select "Overview"
"Set server firewall" on the toolbar
Add client IP on the toolbar
Then you will be able to connect from the new IP address.
I was able to add the IP address without being administrator.
The steps in more details are described in https://learn.microsoft.com/en-us/azure/sql-database/sql-database-security-tutorial#create-a-server-level-firewall-rule-in-the-azure-portal.
Other question Client with IP addres is not allowed to access the server Azuredb describes more meaningful message and the same resolution.
Related
I've setup an SSAS server and I've connected it with my active directory server.
But when I try to login on the ssas server (sql server management studio) using an active directory account I get the following error:
Cannot connect to SQLASServer.
The integrated security 'ClaimsToken' is not supported for native connections. (Microsoft.AnalysisServices.AppLocal.AdomdClient)
This error shows up before it actually tries to connect or anything so if I try to login using a bogus username and no password I still get the same error.
When I login to the server with an active directory account and then login on sql server management studio using Windows Authentication it does work without any errors.
Does anybody know how I can solve this issue?
Make sure you choose Windows Authentication from the Authentication dropdown. The options that say “Active Directory” are poorly worded as they mean Azure Active Directory and are not appropriate for on premises SSAS.
If that does not solve it provide a screenshot of your connection dialog in SSMS.
my mistake was that I had chosen Azure Analysis Services from before from the first drop down menu so I was getting this error. Once I changed it to SQL database, the option to connect with Azure Active Directory was available as well as to connect through SQL database credentials. In order to use the Azure Active Directory you need to create an active directory account and set that account as admin on Azure Portal first.
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.
I was troubleshooting a SQL Server 2008 R2 today and the server was generating a ton of connection errors from multiple services. In looking at how the server had been setup the user had a number of services set to run under specific login credentials. The client had setup within the configuration manager the SQL Server default instance to run under the account someusername#somedomain.org with a set password
I saw this used in a number of locations including the SQL Server Analysis Service SQL Server Agent as well as within the IIS app pools and other windows services that communicate with SQL Server. Looking at the SQL console logs the server was churning out failed login errors on the minute.
In the past I have always setup these service accounts using either Network Service (for intranet deployments) or a domain account somedomain\somename that is provisioned to work as a service account. The email address which was being used was not provisioned as a SQL Server login but there was a domain user account domain\someusername added as a SQL Server login on the server. To me these are not the same in SQL Server, domain\someusername != someusername#somedomain.org is that incorrect to assume?
I am in the process of setting everything to a baseline by resetting all the services to use NetworkService so I can at least get everything working properly.
My question is, are there restrictions on using special characters in login's for SQL Server? I had always thought that you did not want( or could not ) use special characters for creating logins such as an email addresses. I know when registering an IIS machine against SQL you can use the machine name as domain\machinename$. It seems to me that an email address is not a valid domain account as it could be an alias etc and that you would want to explicitly use a valid domain user/service account.
Can anyone provide me some reference material on what is allowed? When I search msdn or google I get more results on SQL injections or escaping passwords. I just want to have a more solid understanding of what is allowed as it pertains to a SQL Server login, as well as what a documented best practice is moving forward so when explaining what to do or what not to do I have some legit reference.
The client has the server set to use mixed mode authentication but it looks as if they are trying to set everything up to rely on windows authentication for connectivity to the server.
thanks for any insight,
-cheers
User Account Objects have two names - a User Principal Name and a SAMID - both of which must be unique in the Forest. These can be seen in the Account tab in Active Directory Users and Computers.
The User Principal Name consist of the logon name followed by a UPN Suffix. For example, andrea#adventure-works.com. UPN Suffixes are properties of the Forest and are unrelated to email domains (though for sanity's sake, they should match email addresses :-).
The SAMID consists of the NetBIOS name of the Active Directory domain followed by the logon name (pre-Windows 2000). For example ADVENTURE-WORKS\andrea.
Most software accepts both types of name but a few accept only one or the other.
We have a 3rd party product that allows some of our users to manipulate data in a database (on what we'll call SvrSQL) via a website on a separate server (SvrWeb).
On SvrWeb, we have a specific, non-default website setup for this application so instead of going to http://SvrWeb.company.com to get to the website we use http://application.company.com which resolves to SvrWeb and the host headers resolve to the correct website.
There is also a specific application pool set up for this site which uses an Active Directory account identity we'll call "company\SrvWeb_iis". We're setup to allow delegation on this account and to allow it to impersonate another login which we want it to do. (we want this account to pass along the AD credentials of the person signed into the website to SQL Server instead of a service account.
We also set up the SPNs for the SrvWeb_iis account via the following command:
setspn -A HTTP/SrvWeb.company.com SrvWeb_iis
The website pulls up, but the section of the website that makes the call to the database returns the message:
Cannot execute database query.
Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
I thought we had the SPN information set up correctly, but when I check the security event log on SrvWeb I see entries of my logging in, but it seems to be using NTLM and not kerberos:
Logon Type: 3
Logon Process: NtLmSsp
Authentication Package: NTLM
Any ideas or articles that cover this setup in detail would be extremely appreciated!
If it helps, we are using SQL Server 2005, and both the web and SQL servers are Windows 2003.
There are several possible reasons for kerberos failures which includes lack of SPN and duplicate SPN as well.
If SQL is running under custom account you would need to add SPN for SQL as well.
Also keep in mind, you should be adding SPN for the FQDN which is the host (A) entry in DNS and not a CNAME.
Check the value of NTAuthenticationProviders
http://support.microsoft.com/kb/215383
Try DelegConfig which would show what is missing if its SPN or something else.
http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1887
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!