I have 3 machines, one of them is acting like a server that contains the database and tables. However when I try to connect over the Named Pipes protocol, I need to add a domain account to each machine.
What I want to do is to access the database remotely using the 2 other machines without adding any user; I'm using Windows authentication.
When you use Windows authentication, you need to have the same Windows account on both the machine making the request, and the server.
To do what you are trying to do, you would need to use SQL Server authentication or user impersonation. Personally, I find user impersonation to leave too many potential security holes, so I recommend SQL Server authentication.
Very top level question so very top level answer:
Extend and manage permissions by Active Directory groups. Place individual user's accounts into the active directory groups. You are now managing permissions from an AD perspective and not by a individual machine perspective. ie user mgmt happens in one place instead of distro.
This way you are not constantly adding/removing users to multiple machines. They are just placed in the group and have access to X number of servers due to permission inheritance.
It also saves you from hard coding sql account credentials into distributable applications. Not a huge concern if this was a web application but think what would happen if you had the need to cycle your sql user password and you had your wpf application installed on X number of machines...becomes a management/release nightmare
Related
I'm trying to understand how I can impersonate a different user when accessing to SQL Server.
Basically my C# application has to access the local-filesystem with the same account as it was launched with, but should use another account when accessing the database.
IF the database is remote, I can achieve this splitting by using "runas /netonly", BUT if the server is local the process will use the credentials with which it was launched.
The user which has the right credential for DB access is different from the user which have access to the filesystem I need to use.
How can I solve this situation?
Basically my C# application has to access the local-filesystem with the same account as it was launched with
Split the app in two and separate this local file access requirement into a separate service that runs with the required privileges. the two parts of your app communicate using your IPC of choice (including authentication and authorization of the two app 'shards' between each other). This may sound complex, but is pretty much buletproof from security POV and not at all hard to implement. C# code can impersonate and reverse impersonation explicitly using WindowsIdentity. Access across network under impersonation is subject to delegation. But I believe going there (impersonating when connecting to DB, reverting when accessing local resources) is just a bugfarm in wait of a harvest... Separating the local access part code from the impersonating one in two services is much more robust imho.
I am wondering if i need to add any other kind of security on this asp.net application - web forms (available only on network domain and through VPN connection)?
Application Environment: Asp.net 4.0, Vb.net, Oracle 10g, Web Services, Window server 2003 or 2008, Hosted on domain
User Authentication Mode: Window (Not using asp.net membership)
Authentication Scenario:
Application is accessible via intranet site and system authenticates user with his system user name. On the default page system will first get the current user name (HttpContext.Current.User.Identity.Name) and then match it in the user table (oracle DB), if it is matched then store procedure will return all the access permissions (menu details) relevant to this user group. There is a user group and permission table in the oracle DB.
In the store procedure, system will also check the user permissions before any DML transaction.
Main security concern
Major: restrict people to access the information depends on their permissions. Normal user shouldn’t get access to other’s data.
Minor: We don’t want anyone to get into our system outside office network.
As Joachim says, this arrangement only supports Windows systems running on the local network. Shifting to basic authentication will allow more clients to connect but exposes the passwords on the network (effectively in clear text) without HTTPS. Forms authentication is similar.
Without server authentication, users could be redirected to a similar server without their knowledge or suffer a main-in-the-middle attack. HTTPS gives you this with the server certificate. This may not be a concern on a local network but users' hosts (in c:\windows\system32\drivers\etc) files are often vulnerable.
Without encryption, any user can sniff the information sent back and forward over the network assuming they are on the same subnet. This may be an acceptable risk for most applications but not if the information is sensitive, e.g. contains sensitive or personal information.
Consider replay attacks (see How do I prevent replay attacks? for an example) if people are performing important operations like approvals.
Consider auditing access to the database, particularly the user group and permission tables. Someone could add themselves or move them into a group, perform an operation then remove themselves. Check your pages for SQL injection and similar attacks which could accomplish this.
In summary, how likely are people to compromise or interfere with the system and how much are you willing to invest to protect it? Assuming the server can handle the load, HTTPS is a hard to go past as a first step.
Unsure what kind of ASP.Net technology you are using (MVC/Razor/Web Forms).
If you are using Web Forms, then you can immediately take advantage of ASP.NET Login Controls like LoginView Control. They work with ASP.Net Forms Authentication (with or without using ASP.net Membership). You can also take advantage of Roles.
Your intranet server should be "protected" if it's not exposed in your network publicly (in any way). Of course that's a bold statement that depends entirely on your network implementation - e.g. subnetting, internal net/no nat/route/no port forwarding, no dns, etc. This makes VPN as your only point of exposure from the outside, then you must enforce proper security policies for your VPN infrastructure - e.g. one-time passwords, client inspection, etc.
Update:
If you are using Active Directory, you can create users/groups in AD to provide access accordingly (e.g. Finance AD group can only access "finance" folder). I haven't kept abreast with browser support for NTLM outside of Internet Explorer however.
You did mention user data is in an Oracle db however(?). I'm not familiar with solutions that allow no login screen access (to network resources) using a db/Oracle.....
Also, that would mean one-time passwords for VPN access may not be available. Look into token based VPNs so users can still use their AD credentials but need a new token each time - this will help mitigate the "passwords in yellow sticky notes" (because you can have tighter control over tokens).
Many desktop applications use SQL tables to manage their users permissions and roles. In fact they restrict access to some parts of application in their application code. It means they need a constant connection string to SQL server with maximum permissions.
My target is C# 2010, Sql Server 2005 or 2008.
What if with any reason someone find that connection string ?(Network tracing, Software hacking, Fired Employee or ...), He can change everything with just Managemenst Studio and you can't understand which client did it. If you want to change connectionstring. You must do it in many clients and in a bad design you need to recompile application.
So i want to know is it good idea to use real SQL login instead of username and password in tables ? make connection string for each user by SQL Logins ?
In this way there is no afraid to loose connection string. Also in SQL codes you can use GetUser() function to indicate which user really runed the query ?
But maybe the managing permission is difficult with this way because there is no simple table to manage permissions and users.
In one long sentence. I want to know What is the best way for authenticating desktop application users in a way that managing permission can be done and also sql server can log user activity ?
Whenever possible, use Windows Authentication.
Define Roles. Add Groups to Roles. Add Users to Groups (as per usual Windows way of managing file system permissions).
Choosing an Authentication Mode
See: Application Roles
You can encrypt sensitive sections of your app.config file. Last time I checked, you have to go through some hoops, but it's not that difficult to set up.
See for example this question
For best security, you need one dedicated database account per user; each account should only have the privilegeds necessary for the tasks that the corresponding user may perform. Normally you grant privileges to roles (e.g. "clerk", "manager", "supervisor") and grant those roles to the users. Obviously, it requires some work to identify which privileges each role needs. In many cases, it might be necessary to not allow direct access to some tables, but only to database views that hide some parts that should not be visible to that role, or to stored procedures that do some additional checks and make sure that each transaction is processed as a whole.
The basic setup is classic - you're creating a Windows Forms application that connects to a DB and does all kinds of enterprise-y stuff. Naturally, such an application will have many users with different access rights in the DB, and each with their own login name and password.
So how do you implement this? One way is to create a DB login for every application user, but that's a pretty serious thing to do, which even requires admin rights on the DB server, etc. If the DB server hosts several applications, the admins are quite likely not to be happy with this.
In the web world typically one creates his own "Users" table which contains all the necessary info, and uses one fixed DB login for all interaction. That is all nice for a web app, but a windows forms can't hide this master login information, negating security altogether. (It can try to hide, but all such attempts are easily broken with a bit of effort).
So... is there some middle way? Perhaps logging in with a fixed login, and then elevating priviledges from a special stored procedure which checks the username and password?
Added: OK, so integrated authentication and windows groups seem to be a fair choice in most situations, so I accepted the relevant answer. Still, if anyone can come up with a non-integrated authentication solution, they'll get an upvote from me.
For WinForms use Windows groups. No passwords are needed because the credentials are inferred from the Windows login using your application.
This is best practice
Basically:
The user belongs to a group (assumes single domain)
Group is a login in the SQL Instance
SQL login maps to a database user
DB User belongs to a DB role
Role has object permissions
It's worth reading up first before having someone try to capture all the information here
Edit:
If you have a workgroup, you can still do it by setting up sqlbox\bob, sqlbox\hans etc in a sqlbox local group.
When someone tries to connect (say bob on his PC) windows will ask them for their details. As long as bob knows his SQLbox account detailsm he can connect.
But then, I've not tried this in a workgroup setting...
In addition to using Windows Domain/AD Groups (put the AD groups in appropriate roles you create in SQL Server, so all account maintenance moves to AD), be sure to use the Application Name in your connection string - this allows you to see which applications are performing operations in the profiler etc.
Because when everyone is logging on as themselves from different applications - windows and web, it helps to know that it's actions taking place through an application and not just any user's ad hoc query through ODBC and Excel, say (if you allow users access to certain views for data export or report writing).
Can't you use Active Directory Groups to make the management of the db connections easier?
From MSDN...
The name can be a Windows user name or a Windows group name, of the form DOMAIN\Name.
That way you may have a few groups, read-only, editor, manager, admin etc. It's how I have achieved similar things in that past with Click-Once apps.
It really is the best choice for what you are doing.
I am assuming this is an existing app? If it was new I would otherwise say to go client server with web-services or similar.
PK :-)
With regards to wanting to hide your authentication and use a single application login with WinForms, if the login has very little privilege - select only on views and execute only on stored procedures, anyone who manages to reverse engineer your encryption of the login information in your application will only be able to perform the same functions they could perform in your application. If you absolutely have to raise the level on the security, you could authenticate each stored proc against your users table (poassing user and hash to each SP). Also, rotate the central application login on a regular basis.
All this is a lot more difficult than using integrated authentication and implementing AD platform in your environment. So you're effectively writing your own directory and authentication instead of using one off the shelf.
In addition to gbn's update about workgroup versus domain, you can run the application with RUNAS /NETONLY /USER:SERVER\USER with user credentials on the domain or server which your machine is not a member of. At the point that the application makes the connection to the database, the remote credentials will be authenticated and used. I have an application which actually checks to see how it was run and if it not run with a particular switch, it prompts for username and password and then re-runs itself using the Windows API using a function equivalent to RUNAS /NETONLY /USER:DOMAIN\USER. This is because our workstations are not currently on the domain (or on a domain with a trust relationship) of the SQL Server. In this case, you could still manage the security in local groups on the SQL Server or groups on the domain of the SQL Server. You would basically just lose out on the automated authentication token.
ok i have my GUI installed on the server which has users as administrator as the role of an administrators and user1 which has the role of the guest...
I have one project and there are different pages for administrators and guests... when the login screen comes up and the administrator logs in he should be redirected to the admin.aspx page and for user1 he should be redirected to the guest.aspx page.
Now the scenario is i have 10 users in a company and one administrator. This GUI is on the network server and these 10 users are able to access it as guests.
How do the guest user logs in and can access the SQl database in the read only mode but when the administrator user logs in he can access the database in the read and write mode.?? I dont know how to do this really... any suggestions
(by IIS server or webconfig or some setting in SQL server)
and the previous question is what to use (forms or windows authentication) where can i get information on how to set up this kind of authentication???? Is there the need to use impersonation also??
I know this isn't directly answering your question, but unless you are letting your users (and administrators) write their own queries (which you should never do BTW!) it shouldn't matter.
Users should only have access to options that allow them to read data from the database, not update that data. If they do then it's bad UI design.
You should make sure that the account that "Users" use only has read access - do this from Management Studio. Connect to you server and expand Security > Logins in the Object Explorer. Right click and select New Login... fill out the form - select "SQL Server authentication". You can then grant and deny access to the relevant parts of your database. Check the SQL Server documentation for more details.
What do you mean when you say your GUI is installed...?
This might be something that's tied into your CODE (if guest then don't allow writes, etc).
You might use two different accounts for DB access depending on the user if you'd like to.