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
Related
Is there an advantage in using a trusted connection vs a sql login for web application? Is there any pros/cons from one to another?
I usually use Windows Authentication, which is more secure, with a service account. If you are doing an internal application within your own domain and you want to authenticate your users to the database server, you will need to set up delegation on that service account along with the IIS and SQL services. If it is outward facing or you aren't concerned with authenticating users to the database, you simply need to give the relevant permissions to the service account login in SQL. In either case, assuming your webserver is IIS, you would change the web application to run under the service account. This will encrypt and store the credentials on the webserver.
The main reason windows authentication is more secure is it makes use of the Active Directory infrastructure to authenticate users using encrypted messages between the servers. With SQL Authentication the credentials are passed across the network. If you do use SQL Authentication, you should make sure to encrypt the connection string portion of your web config, as you would embed the credentials including the password.
my database filename is crystal.mdf, I tried adding logins with the help from this link VB.net and SQL Server 2005 Setting up Database password for standalone app
I can login using sql server authentication using a password and username.
The problem is, I CAN open the database using windows authentication.
This will allow the user (if the user is a techie guy and would like to dig things up) to change the values on the database, which might give errors to my application..
I don't want the users to open the database using windows authentication for security purposes, because I will deploy the application on a different place.
To summarize,
I want to disable windows authentication (is this even possible?)
If not, how can I, atleast make the database secure that the user won't be able to open it via windows authentication?
EDIT
Answer from different forum
You can disable the Windows Authenticated User by : Security Tab --> logins --> Right click on that login -> Properties -> status ->Enable/Disable -> click Disable
OR
ALTER LOGIN [Domain\username] DISABLE
At the moment you may can't do this. Backup all DBs(not into default location) and re-install SQL Server using create fresh windows user account which have admin privileges. Then you can keep your windows authentication mode loin safer by protecting the windows user account.
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.
I have a database with LDAP login enabled. It works fine when logging in through the PIA or when logging into app-designer through the application server.
I need to make app-designer allow me to login with 2-tier mode using LDAP authentication. Is this possible without customization?
I do not think this is possible. 2-tier logs directly into the database and more importantly, does not run the signon peoplecode that does call-outs for LDAP authentication. In fact, 2-tier is really just a Win32 app that runs no peoplecode - it isn't a peoplesoft "application." There is a user callout dll delivered with peoplesoft, and some scant documents on what you have to do to use it - but again, likely not going to meet your need. You may need to use the ldap synch online app engine job to pull in your ldap users to security tables if you want to use those login identities for 2-tier access.
The only delivered way to use LDAP Authentication for App Designer is to use connection 3-Tier through the app server. Only with the 3-Tier connection will the Signon PeopleCode be executed. With 2-Tier, there is no hook to the LDAP Server.
You could look at using the Grey Sparling Desktop Single Signon, which does integrate with App Designer and uses Windows and NTLM to grab Active Directory authentication. This would give you some degree of LDAP Authentication if you Windows machine authenticates with a domain. But it is an add-on product you would need to purchase.
Otherwise, as Epictetus mentioned, you can use the LDAP Username if you have it synced with your PeopleSoft database and use the local password stored in PSOPRDEFN.
One problem I have seen is that when using LDAP and 2 tier when you login with LDAP it somehow decrypts the password in PSOPRDEFN. The next login 2 tier by that same account throws the error cannot login please encrypt password using data movoer encrypt password *. If you encrypt that users password the same results happen following that users next LDAP login.