Couldn't find anything online about this, but I'd like to give a SQL Server role access to a linked server using a specific login to that server. I know you can assign a specific local login to a linked server login with sp_addlinkedsrvlogin but I'm not looking to do this for every login (nor am I looking for a script to do it for every login). I suppose there's some security reasons to prefer the use of an account, but I'd like to know if it's possible.
Not exactly possible, no.
To manage group-wise access, you're supposed to use the Be made using the login's current security context option (doc here). Then, if you're authenticating with Windows authentication, configure the login and user and security access on the remote server with a Windows group that your users are a member of. (If you were using SQL authentication, you'd need to have a login with an identical password on both servers to use this context.) Then you'd have to create the role on the remote server, assign permissions to that role, and assign the group to that role.
This is kind of a pain, but it does mean that no matter how your Windows users connect to the second server, they'll get the same access.
Related
I have installed an Azure MFA on our network to provide two form Id for our VPN. We are using the Azure MFA pay as you go option where users are added and charged as we add them to the server.
I have import the users from AD. Ninety percent of the users imported work file. I have both enabled an not enabled users listed on the server.
When I run a test from within the MFA server the authentication process works. The server will call the number I have listed and when I press the # key to accept the system returns that that use authenticated ok.
The ones I am have problems with will authenticate with I use the test button on MFA server, but when I try to use the same user to login to the VPN
I get this error
Pfauth failed for user 'CN=test#xxxx.com,CN=Users,DC=xxxx,DC=com' (distinguishedName format) from xxx.xxx.xxx.xxx. Call status: SKIPPED_NO_USER - "Couldn't match supplied username to a defined user".
Other users have no problem logging in.
I have tried to re-import the user, recreate the use manual in the MFA server nothing changes the results.
It looks to me that the error is that the MFA server does not recognize the server. Has anyone seen this problem or can direct me to thing to check.
It looks like you are either securing the VPN using LDAP, or are using RADIUS but doing the primary authentication using LDAP bind. After primary authentication is performed, the MFA Server needs to find the user in its data store to look up the phone number and auth method configured. It either uses Windows SIDs or LDAP unique identifiers to do that lookup. Take a look at Company Settings-->Username Resolution in the MFA Server. It is set to use Windows SIDs by default. Try changing that to use LDAP unique identifiers.
Like title says, is it possible to connect to SSAS without any of the AD or windows accounts? Can I store users credentials e.g. on my own SQL Server database or do I still need only AD? Because i think it is possible in SSRS with custom authentication (or I am wrong).
Windows authentication is only option, however you can login from remote machine this way:
Prepare on remote machine user account with exactly same login and password as user from ssas machine (with proper ssas access set) and you should be able to login using this user.
Or opposite: create on ssas machine user account with execly name and password as remote user and give him access to ssas.
I have my sql server 2008 setup with mixed mode authentication. I went into sql server and added a new login and referenced an active directory user.
But it seems like all the windows authentication based stuff only ever works with whatever was used to login to the operating system. So I'm outside their domain on my machine and I can't connect. But even if I remote desktop into the server itself, using a seperate remote desktop login, even on that machine, I can't login using the active directory user since in the login box, if I choose window auth, I can't specifiy a different name, and sql server auth says invalid login. I don't see how to supply a windows username and password JUST when logging into sql server.
And also, what about my .net apps? I don't want to hardcode a sql server auth username/password into my encrypted connection string, i want to hard code a windows active directory username/password into the connection string.
And then reporting services, aarrghhh.. Does reporting servies ONLY work with windows logins? If so, then I'm stuck with getting the above working. If not, how do I configure a sql server login to also let me access all our reports?
This is a really broad question; I'll give a survey of some of the different topics you address. I work in a hosting provider and we have many domains with no trusts between them, so I deal with this on a daily basis.
Yes, SQL Server Windows authentication really wants to use the credentials running the client application. You can work around this with the RunAs /netonly switch:
runas /netonly /user:domain\username “C:\Program Files (x86)\Microsoft
SQL Server\100\Tools\Binn\VSShell\Common7\IDE\Ssms.exe”
Authentication for .NET apps is a big topic. Lots of options and chapters, if not books have been written on this.
Regarding Reporting Services: most of this access is through a browser. So this will use whatever credentials you supply to your browser. In IE this is controlled through the security zones and settings of whether your current credentials should be used or if you should be prompted.
Some clues:
If you're external user and SQL Server is in mixed mode it will be easier for you to have SQL login not mapped to AD user (so you use SQL auth and not Windows auth). You may have two SQL Logins - one for Windows auth, second for SQL auth.
If you don't your .NET apps have hard coded passwords use Windows auth and Trusted Connection mode in your ConnectionString. If your .NET app is a service create dedicated AD user then create SQL Login mapped to this AD user. Give your SQL User mapped to SQL Login permissions whatever it needs. Run service in context of dedicated AD user. If app is directly executed by users (.EXE file) also use Trusted Connection. Create AD security group for your app users. Create SQL "group" Login mapped to this AD group. Give your SQL "group" User mapped to SQL Login permissions whatever it needs.
It's not possible to provide login and password for SQL Login with Windows auth in ConnectionString. You use TrustedConnection for Windows auth and login/password for SQL auth.
You may play with switching context inside SQL session - EXECUTE AS, see: http://msdn.microsoft.com/en-us/library/ms181362.aspx
Is it possible to authenticate a user from an Active Directory through SQL Server using LDAP? Assuming that I enter the Windows domain username and password in an ADSI SQL Select query.
Not clear what your desired outcome would be.
SQL 2008, AFIK, could be setup with integrated Active Directory Authentication or not.
You certainly could perform authentication via LDAP (or some other form of Authentication) to the WEB Site from AD.
And if not integrated authentication within SQL, also prompt for the credentials for SQL.
But not at all clear what your desires are.
I have an MS-Access 2007 front end. I will have multiple users on it. They are all going to be on the network company domain. Should I be using Windows authentication or SQL Server authentication to be connecting to SQL Server 2008 via ODBC?
Windows auth will allow a more seamless authentication process, single sign on!
From the below article:
Disadvantages of SQL Server Authentication
If a user is a Windows domain user
who has a login and password for
Windows, he must still provide
another (SQL Server) login and
password to connect. Keeping track of
multiple names and passwords is
difficult for many users. Having to
provide SQL Server credentials every
time that one connects to the
database can be annoying.
SQL Server Authentication cannot use
Kerberos security protocol.
Windows offers additional password
policies that are not available for
SQL Server logins.
Advantages of SQL Server Authentication
Allows SQL Server to support older
applications and applications
provided by third parties that
require SQL Server Authentication.
Allows SQL Server to support
environments with mixed operating
systems, where all users are not
authenticated by a Windows domain.
Allows users to connect from unknown
or untrusted domains. For instance,
an application where established
customers connect with assigned SQL
Server logins to receive the status
of their orders.
Allows SQL Server to support
Web-based applications where users
create their own identities.
Allows software developers to
distribute their applications by
using a complex permission hierarchy
based on known, preset SQL Server
logins.
Here is a good article on the pro's/con's for each. http://technet.microsoft.com/en-us/library/ms144284.aspx
Dustin hit on a good list of pros/cons. I know nobody wants to make a decision like this for you, but based on your criteria (multiple users, all on company domain); I can't think of a single reason to use SQL Server Authentication instead of Windows Authentication. It was designed primarily for scenarios like this.
If you have a Domain, and Active Directory, you should not even think of something else than Windows Authentication .... not a single second!
Like many things when it comes to security implementations what you should do depends on your goals.
I am not sure from your question if you intend to pass each user's credentials to SQL Server or if you plan on having a single login using either Windows Authentication or SQL Server Authentication. If you choose the later option SQL Server Authentication is probably the way to go as it limits network accounts. If you choose the former Windows Authentication is probably better for your users as it provides single sign on.
As an aside my personal preference is to have each application use its own set of credentials for database interaction. This limits users to only having the privileges provided to them by the application. In this manner your users needn't worry about authenticating to the database as your application will take care of that for them.
Seeing as you have a desktop front end that is connecting directly to database...your best option is to go with windows auth. Keep in mind by doing this, the user can bypass the frontend and access the database directly. You'll need to grant them the minimum db permissions required. Also, you'll want to use a AD security group instead of adding each user.
Sql auth is best for when you control the config file...for example a web app.