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.
Related
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.
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 am in the preparation phase of testing an application that will be using LDAP for user authentication. What are some tips or advice you might have for this endeavor?
I don't have a great understanding of LDAP but I believe all that will be used is the application client calls to LDAP with a username and sees if the password matches. Is that an accurate description? Also, what are some edge cases to test? Thanks.
LDAP authentication is often (but not always) a 2-step process: first the application does an LDAP query to locate the "distinguished name" (dn) of the account the user's trying to authenticate to, then it tries to log in ("bind", in LDAP parlance) as that dn, using the user-supplied password.
If the "bind" attempt works, the application knows the password is correct. (The LDAP server is likely not configured to allow the application to actually extract the password and do the comparison itself, for obvious security reasons).
An LDAP-enabled application will typically require a way to configure:
hostname/port of LDAP server
search base (e.g., dc=mycompany,dc=org)
user search filter (e.g. "(|(cn=%userid)(mail=%userid))")
application credentials for the initial LDAP query (unless the server allows anonymous queries)
You will most likely need to support SSL, so you don't send the user's password to the LDAP server in cleartext.
This strongly depends on your technology.
If you are directly querying the ldap you have to care about performance e.g. how fast are your queries, how often you have to do them and if you server is sized appropriately.
If you are using some kind of container that it providing SSO then these will usually have some caching features, etc.. There you have to check if everything is working properly.
You would need ldap_connect and ldap_bind functions. Also once you are binded with the ldap server you can search for entries on the ldap and get the user information.
You should surely check if encodings are handled properly (try umlauts or other weird stuff in passwords).
And take care to test with the LDAP servers you care about, Active Directory, OpenLdap, Apaches LDAP Server, and a few others, they might show different behaviours.
Also check if the client handles 'referrals' correct, e.g. when you try to lookup users in a different domain (e.g. two AD forrests with forrest trust installed).
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.
We are planning on utilising kerberos in our architecture. I would like to know what perceived or actual advantages this technology has, and if there are any alternatives.
Note that we have a .net client side and java server side. communication will be via messaging bus and SOA
If you are working within a mostly Windows environment (i.e. Windows Server 2k3, a domain controller, Active Directory, etc.) one in particular is that you can use impersonation through .NET with a split web server and database server. Using the older NTLM method, you cannot do a "double-hop".
Let's look at an example:
You have a web server (WEB1)
You have a database server on a separate machine (DB1)
You have a user access your website (USER1)
USER1 hits a page that displays a list of orders. Your WEB1 server has to query DB1 for this info to display on the page. You want to constrain what orders are seen based on the user's credentials and access rights. Thus, you set up active directory groups and assign users accordingly. On your database you give the different groups different security (GROUP1 might have select only and GROUP2 might get select, insert, and update, for example).
NTLM doesn't support the double-hop necessary to do this. WEB1 has to send USER1's credentials to DB1 (otherwise WEB1 must log into DB1 with a known dedicated user id and password hardcoded into the web.config for example that usually has to have full access to support all possible user roles). You can imagine this could be a security hazard should WEB1 be compromised, so you can't do it, otherwise anyone who gains control of WEB1 (via sql injection perhaps) could do anything the dedicated user account could or impersonate whomever they want. Kerberos, through delegation on Windows Server, supports doing this second hop by keeping the encrypted credential key from your domain server intact and passed along, as well as verified that this is allowed (on both ends, see below for setting this up on your servers because it MUST be EXPLICITLY allowed).
It's very useful to do this when developing intranet web apps that have a database back-end (which is 99% of the time the case, right?) and you want to control authorization and authentication through Windows Integrated Security. Kerberos is really your only choice unless your web server and database server are on the same machine, which means there is no transferring of credentials and no impersonation necessary.
See also:
MSDN - How To: Use Impersonation and Delegation in ASP.NET 2.0
Microsoft Help & Support - How to configure an ASP.NET application for a delegation scenario
MSDN Magazine - Security Briefs: Credentials and Delegation