I have recently been working on a ASP.NET project for a client. The project was to migrate the database from the old Oracle database to a new SQL Server 2008 database. The migration went well and most of the procedures did not take to long to fix. However we are now having a problem, up until now we have been using SQL Server authentication and using a username and password to access the database from the .NET code. Below shows the connection string:
<add key="DatabaseConnectionString" value="Data Source=DATASOURCE;Initial Catalog=DATABASE;User Id=USERID;Password=PASSWORD;"/>
This was working fine however recently i have recieved an email from the client saying:
"Instead of using a local SQL account for the .NET app to access the database could you please use an Active Directory account. In the web.config it will say <domain name>/<username> rather than just <username>."
What i am confused about is:
Do i have to change the Authentication mode within SQL Server to Windows Authentication?
Does the client mean to change it from <username> to <domain>/<username> or the other way round?
Where abouts in the web.config do i need to make this change to the username? Is it in the connectionstring?
Any help on this would be great.
Also im not sure if you would need to know this but i have added it anyway...
This is the Authentication section of the web.config:
<identity impersonate="true"/>
<authentication mode="Windows"/>
Do i have to change the Authentication mode within SQL Server to Windows Authentication?
No, because Windows Authentication is always enabled. However, disabling Sql Server Authentication is a good practice.
Does the client mean to change it from "username" to "domain/username"
No. This is not only about adding the domain name. You need to authenticate the user against the active directory and use delegation for the sql connection. To use the windows account, you need to decide whether you want a specific account to access the Sql Server, or the web site logged in user account.
I think the first way is almost always better. For that you need to delete the user id and password from the connection string and replace it with "Integrated Security=SSPI", and set the application pool identity to the active directory user account. In Sql Server you need to give this account the right to do what you need.
For the second way, you need windows authentication for users in your web site, and use delegation for the connection. I don't know if impersonation is enough for that.
Related
Haven't done enough web development, and have searched a bit here, and have not found an answer yet.
I wanted to find out how to configure my website/web.config to allow me to use SUSER_NAME() on my audit triggers in Microsoft SQL Server.
Currently we are connecting to our database with a service account, but other users are authenticating and accessing the web site. When a record is changed, we want to capture the user that made the change, and not the service account used to log into the database.
The App Pool is configured to the service account and the web site is configured using Windows authentication and ASP.NET Impersonation (but this keeps getting turned off somehow).
The web.config has
<identity impersonate="true" />
and Windows authentication.
Any help would be greatly appreciated.
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.
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
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.