We currently use SQL 2008 with Windows Authentication disabled, we only allow SQL Mixed for accessing SQL.
We are wanting to switch our version control software to Team Foundation Server, which requires Windows Authentication.
Which ended up being a bit of a problem, I've talked to our DBA and Windows Authentication is not an option, nor is putting SQL on the server where TFS will reside.
Issue is, from what he is telling me, you are unable to just enable Windows Authentication just for a single user, its either on or off for all users.
Is this correct? What other options are there?
You need to have another talk with the DBA.
There are 2 options for authenticating to SQL Server:
Windows Authentication (only)
Both Windows Authentication and SQL Server Authentication
Yes it is true that if you turn on the latter option also known as Mixed Mode, and it applies to the server (which will now accept Windows Auth) - it does not mean that suddenly all valid Windows users will get access to SQL Server!
The Windows logins still have to be added as SQL users (SQL login != SQL user[principal]) and they can then belong to roles etc, so you would only need to add the users for TFS.
In fact, you cannot possibly disable Windows Auth - so I don't see why the DBA should be complaining about "turning on" Windows Auth.
This is probably what you need to do:
Add a new domain group "sqltfs"
Create a SQL user out of the Windows security Group "domain\sqltfs"
Grant all the access required to the new user (or indirectly through a role)
add all the TFS users into the domain group "sqltfs"
This way you can all continue to use SQL logins where it matter (existing code), while still gaining access via TFS -> SQL Server through the domain group membership
This probably belongs on superuser, but I'll take a stab at it. From my SQL 2008 R2 management console, the DB server can run in either pure Windows Auth mode, or mixed Windows auth + SQL auth. It can't run in SQL auth only.
Since you say you're in mixed mode, I can't see why he can't add another user to the DB that uses a windows domain account, rather than a local SQL server account. Mixed mode allows both.
Related
Case
I want to work with Azure SQL Server, as noted in the best practices how to secure Azure SQL Server it is good to use AAD account for accessing your server/database instead of SQL Accounts.
I read several posts on the documentation site of Microsoft and blogs, but I cannot find that it is possible to disable/remove the Server Admin account, after you have the Azure SQL Server and an created AAD SQL Administrator and attached it to Azure SQL Server.
I know Server Admin Login and Password is mandatory, when you create the Azure SQL, but I hoped it was possible to delete after creation of server and AAD SQL Admin.
Why do I want this?
There are enough companies who have to rule (inherited from the on-prem) that accounts must be controlled by a centralized Identity Store, such as AAD.
Password rotation must be done, it is a lot easier when you have a centralized identity Store instead that you have to do it for a lot of Azure SQL Servers.
Question
Is it possible to disable the SQL Server Admin (sql account)?
I don't believe it is (or can be) possible to disable the SQL Server Admin.
The Azure Subscription Owner and the AAD SQL Admin identity have joint ownership of the Azure SQL Server. Either one needs to be able to re-acquire administrative access to the server.
And the mechanism that the Azure Subscription Owner uses to force their way into their own database is to reset the SQL Server Admin password from the Azure Portal.
This is roughly analogous to how a Windows Administrator can force sysadmin access to a SQL Server by starting the service in single-user mode.
I think the best you can do is to throw away the SQL Server Admin's password, so no one could log in using that account without first resetting the password in the portal. EG run:
declare #sql nvarchar(max) = concat(N'alter LOGIN [youradmin] WITH PASSWORD=N''',newid(), N'''')
exec (#sql)
Update 06/21:
Microsoft released Azure Active Directory only authentication for Azure SQL which effectively disables the possibility to use any SQL user for authentication.
Note the caveats
Azure AD-only auth is supported at the Azure SQL server level
This means that when this mode is enabled, all databases that belong to this server can only be accessed using Azure AD
authentication
Enabling Azure AD-only auth does not remove existing SQL logins or SQL users based on these logins. They continue being stored in SQL
metadata, but cannot be used for SQL authentication
Even though the Azure AD-only auth is enabled, with proper SQL permissions for Azure AD users, SQL logins and SQL users can be
created. However, the authentication process to connect to Azure SQL
using SQL logins/users will fail
Azure AD users with proper permissions can impersonate existing SQL users
Impersonation continues working between SQL authentication users even though the Azure AD-only auth feature is enabled. This is
consistent to the way impersonation works today, where even disabled
users can be impersonated.
Microsoft is working on allowing so called "AAD-only authentication" which will effectively disable the server admin login, as the complete SQL authentiction is disabled.
I've inherited a VB.Net Windows forms application that is used across several hundred remote sites. On the remote sites the application connects locally to a local SQL server instance using the currently logged in Windows user at the workstation - this all works fine.
The application however also needs to connect to a remote SQL server - currently this is done using a set of connection strings and sql authentication. The DBA wants to move away from using SQL server authentication and make everything Windows authentication.
Clearly, adding hundreds of users to the remote DB is not an option. Therefore I need to be able to use the currently logged in user if connecting locally to a local SQL server and a different Windows users (which will have permissions to the db server) if I am connecting remotely.
Does anyone have any suggestions of how this can be done or can suggest an approach.
Thanks
Since both servers are on the same domain, create Active Directory Groups for the application, put the users' Windows logins into the groups, and then give the 2, 3 or 10 or whatever app-specific AD groups permissions in the databases. If you're using stored procedures, create a database role for each AD group, grant the DB role execute permissions, and add the AD groups to the DB roles.
I have a question relating to SQL Server management studio,
I have downloaded the SQL Server Express onto my PC and was told to expect SQL Server to prompt me for a username and password, which I could use to login as "SQL Server Authentication", and use the login and password function.
I followed every single instance of the Installation but was never propted about any such password and user name setting having to be created.
Big deal however I need to practice methods for loging into SQL Server using password and Username functionality ussing vb.net (Automating login procedures).
What are the steps I need to undertake to make correct this?
The Authentication Mode can be changed at any time. In Microsoft SQL Server Management Studio, right-click on your server, and go to properties.
In the Security page, you have the option to change the Server Authentication mode to Windows or Both (Windows and SQL).
Make sure the "sa" user has a strong password (it may be empty or disabled by default).
I have been allocated the responsibility at work of revising the current reporting services authentication process. The aim is to maintain the necessary level of security and also simplify the maintenance/configuration of granting access to the individual reports.
I do NOT have access to the domain controllers to be able to modify or create new AD groups. I have to work with the groups/users that currently exist.
In terms of authentication, it seems that I have the option of using either:
Windows authentication
SQL Server authentication.
Both the report server and the report database will reside on the same server. With this in mind, I understand that Windows authentication is probably a better solution as there is no need to maintain a separate SQL Server table of Users (and their passwords). Granting access to a report once it has been deployed on the report server, would simply involve adding the user/group to the report (load the report in a browser and access the Properties\Security option).
Using the second option of SQL Server authentication does not seem as appropriate as using Windows authentication for the reason the report server and report database are on the same box.
I am using SQL Server 2000 databases. The version of reporting services I have installed is Microsoft SQL Server 2008.
Please could someone let me know if my thinking is correct (i.e. I should go for Windows authentication). Cheers.
Jimmy
Sql Server authentication is not an option for users connecting to SSRS. It is an option for SSRS connecting to databases where it will get its data.
So bottom line, yes, you need to use Windows Authentication for user connections to SSRS. You can use special user names such as "Authenticated Users" or "Everyone" in SSRS to allow broad access.
I understand that you don't have access to AD, but managing the user accounts' membership in AD groups would be much easier than tracking and managing individual access in SSRS.
But without the AD access you can still add Windows/AD accounts to the report permissions and use those. You just create a more complex system, since you need to manage permissions for every individual separately. You can group the reports in folders and secure the folders: the reports can inherit that security.
I have built an application that uses SQL Express 2005 and I want to deploy it, but the problem is that anyone who has SQL Management Studio(or something like that) installed on his computer, can connect to my database and change it.
Is there anyway to prevent end-users from seeing or editing the content of my database, even those with the Administrator privileges?
I guess you're referring to the fact that by default SQL Server installs allow Windows and SQL Server Authentication. If you remove the Windows Authentication mode then users will have to connect via SQL Server authentication.
This from http://support.microsoft.com/kb/247931
SQL Server authentication SQL Server
authentication relies on the internal
user list maintained by the SQL Server
computer. This list does not include
Windows NT users, and is specific to
the SQL Server computer. Users are
created and configured using the SQL
Server Enterprise Manager. To use this
authentication method, perform with
the following steps:
• If you connect
through Open Database Connectivity
(ODBC), in the ODBC Administrator,
choose SQL Server authentication when
you configure the data source.
•In
the ActiveX Data Objects (ADO)
connection string, include the
parameters "UID" and "PWD" when you
use ODBC, and "User ID" and "Password"
when you use the SQLOLEDB provider.
I suppose this is not the answer you hoped for but it is unavoidable that anyone with administrative rights will be able to browse and edit information in the database.
You cannot change this.
Perhaps you could consider WHY you want to prevent this kind of access?
I expect you want to prevent tampering or accidental corruption of the data?
If that is the reason then you can go a long way to prevent corruption by adding constraints to your database. Add foreign key constraints, uniqueness constraints, everything that will help prevent data corruption.
Then an administrator would need to deliberately undo these constraints before they tamper, which would prevent most accidental corruption but of course not prevent malicious vandalism.
If you are concerned about protection of your intellectual property, you could encrypt the programmatic components (stored procedures and views and functions). This kind of encryption is not very strong but prevents casual inspection.
Encryption is added by using the
WITH ENCRYPTION
clause in your CREATE or ALTER statements.