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.
Related
I have a Microsoft Access Application which generates a connection string like:
Provider=SQLNCLI11;Server=servername;Database=db_name;Trusted_Connection=yes;
This works without any problem.
What I want to do is to connect to a SQL Server instance where the user must insert his Active Directory name and password.
Like this:
Provider=SQLNCLI11;Server=servername;Database=db_name;Uid=username;Pwd=password;
This only works for users which are created on the SQL Server directly.
I tried Uid=DOMAIN\username, but it isn't working.
Is this possible? Or is there another way how I can get through this?
The environment:
The User is using a local PC with a local account and then he's doing a "NetworkConnect" with his AD-User and password.
After that, "RunAs" as his AD-User is working BUT there is another Application that is started from the Access Application and this App must be started with the local User-Account.
SQL-Server and the AD-User are member of the same domain.
Your choices are
Login to SQL Server using your the Windows Domain account that you are currently logged into. You do this automatically by specifying Trusted_Connection=yes;, or
Login to SQL Server using a SQL Login.
Those are the only two choices possible using a SQL provider connection string. Specifically, you cannot use the SQL access provider to do impersonation, that is, to login to SQL Server using a different Windows domain account than the one that you are currently logged into.
Microsoft designed the AD integration with SQL Server to use the account of the client application, not to be able to handle logging in as a part of the connection string. If the user isn't going to be logged into the machine using the account needed for the database access, the next best option may be something like ShellRunAs in order to let the user run your client app as the correct AD account.
Using the example below, which is in my App.Config file, are the uid and password values for the SQL Server, or the SQL Server instance, or for the database that is on the SQL Server?
value="server=localhost;database=myDb;uid=myUser;password=myPass;"
Thanks,
ADawn
Sql Server separates the concept of a login from a user. A server instance itself has logins. Individual databases hosted on a server instance have users.
When you want to run a query or otherwise interact with a database, you generally first connect to the server. You supply a username (uid) and password that match a server login. This login in turn maps to a user in one (or more!) databases hosted by that server.
You can see the user mappings by opening Sql Server Management Studio and connecting to your server. In the Object Explorer area expand the Security and then Login folders (just under "Databases"). Double-click a login to open it's Properties window, and find the User Mappings section.
The connection string also includes a database. The purpose here is (again) because a login might map to more than one database. Specifying a database as part of the connection provides context, so you don't need a database name with every table reference in your SQL code.
There's also Windows/Active Directory authentication (Integrated Security). This makes things even messier, because you can set up Active Directory groups (in addition to users) as server logins to manage access for a number of people at once. An Active Directory user can belong to more than one of these groups... and thus map to more than one user in a single database. In my experience, when this happens you tend to get the union of the set of permissions from every database user you could claim, but I haven't studied that situation thoroughly.
server=localhost;
This is the location of the server. You can use the IP address or the name of the computer. Localhost means this code is on the same machine as the SQL server
database=myDb;
This is your database. Such as master (which is a system one)
uid=myUser;
This is a login on the SQL server. Make sure that login has permissions to the database you are trying to access (and subsequent tables). See the picture below, that is a login abc_test.
password=myPass;
The password for the above user
It is possible to have those Logins as Windows Authenticated logins but in my experience in code it's usually SQL Server authentication (mixed mode) logins.
As sniperd said You can create a new login with a new username and password by right clicking on Logins. Or you can use an existing Login name and change its password. Hope this gonna work!
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.
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!