I have an environment where a cloud based server is hosting a SQL Database. Users connect directly to this in order to run queries and download data.
Rather than setting up user logins and assigning them to roles manually I'd like to inherit these from the company Active Directory account. I can get LDAP credentials on the remote SQL Database but I'm unclear on how I can use this to provide login access for the users (and to correctly assign them to roles).
Many thanks.
You can do it with the help of SSIS. Please check the below link for the same.
Importing data from Active Directory Using SSIS
Related
I read this article and concluded that the file system permissions needs to be manually set when I change the service account for my SQL server instance.
So I changed the service account for my SQL server instance to a brand new local account via SQL Server Configuration Manager and got surprised that the SQL server service can start, even though I haven't set any file or folder permissions for the new account yet. So the service now runs as the local user, but that user does not have access to the default SQL data folder when I check from Windows. I can also read and write to the default backup folder. Why does it work despite the missing permissions?
It works because you used SQL Server Configuration Manager to change the service account. It does all the extra legwork with permissions so that you don't have to.
If, on the other hand, you would use the standard "Services" snap-in found in Control Panel -> Administrative Tools, then nothing would work out of the box, and it would be a truly harrowing experience to set it all up by hand.
From this article we get the answer:
SQL Server service accounts must have access to resources. Access control lists are set for the per-service SID or the local Windows group
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.
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 have a .NET application which connects to SQL Server 2008 for storing some data. I use SQL Server authenthication providing an sq username and a password to my end-user in app.config file. If something more needs to be changed I give to the end-user some other credentials.
How can I limit the sql user to only have permission to read/write data and executing existing stored procedures and everything else to be forbidden?
What is the best practice for setting permisions for a sql user that an application is using to connect to a database? Can I prevent somehow the user from logging in Management Studio and mess with my data?
I'm not searching for the perfect 100% reliable solution, but the best existing practice to do this. Thank you very much in advance.
Update: I work on a shared hosting SQL Server environment.
You'll need to create a new SQL user, something like 'LimitedUser'. To do this in SSMS, select the Security Folder of the server you are using, right-click, select New, select Login.
Select your authentication type (SQL server authentication is easily managed), and set the Default database to your database.
You'll need to set Server Roles so this new user only maps to your DB, and in the last page (Status), set Login to false so they cannot use these credentials to login to SSMS and 'mess with your data'.
Click OK, and you're done creating your limited user.
Assign it to your database, and then in SSMS, right-click on your db, select Properties, Permissions.
Select your user or role, and in the permission grid below, switch on only what need to be switched on.
As I see, your question is fully concerned with SQL server security.
You can limit user permissions on server, database or object scope, using GRANT statement, server or database roles. For example, you can assign db_datareader role for user, and then grant EXECUTE permission to this user for some stored procedures (or for entire database).
The current practice in my organization is to create the database roles (e.g. application admin, operator, and so on), adding the appropriate permissions to these roles and then assign these roles to database users.
I'm not completelly sure that you can prevent login into SQL Server Managent studio (SSMS), but SSMS wll not display information that must be invisible for user with user current permissions.
Shared SQL Server hosting where a single instance is shared among multiple customers is not compatible with with typical client-server applications. You are expected to perform all operations through a middle tier server such a WCF Data Service and maintain user accounts within your database in a table with Forms Authentication etc.
For your client-server application you need VPS hosting with your own instance of SQL server where you can create server-level logins. Without creating server-level logins there is no method to secure a client-server application. Any workarounds are just pseudo-security.
I have a remote database I need to create a linked server to. The problem is it's been set up with my group's functional account an not my own. The only way I can think of doing this is logging out of my personal work account and then back in with out functional account and then set up the link that way, but that is impractical.
So my question is, is there any possible way to set up a linked server using different active directory credentials on a SQL Server 2005 server?\
EDIT: Bascially I am logged in as AD_MAIN\OhioDude but I need to authenticate to the remote server using AD_MAIM\DeptGroup
You can change the properties of the linked server so it uses an alternate set of credentials. From SSMS if you right-click on the linked server and go to Properties -> Security, you can change how the authentication is done for the remote server. I don't know if you can specify a Windows-based login for the remote security context, but it's worth a try.