June 21, 2002 at 4:01 am
I have a secuity issue that I think I may be stuck with:
I have an application which partly uses it's own application security and also sql servers. To create a new user you must login to the application with a sql server account that can create sql server logins. The difficulty is that to create server logins the user must be part of the security admin group which is a server wide role. I'm running other databases on the server and do not want to give the application adminisrtator access to the other databases.
Is there anyway around this? At the moment I'm thinking the only way to do this is migrate the applications database to a complete seperate instance of the server!! Not an ideal solution! Any ideas anyone?
June 21, 2002 at 4:35 am
Do they have to create the SQL logins via the application? Or can they pre-exist. If they can one method I've used it create a very simple UI that allows users to task x, inside the app I embed an obfuscated sql logn/password that allows the needed access level. You can then further restrict it's use by requiring that the NT user be a specific person or group member. That way they can do the work and ONLY the work they need to do!
Andy
June 21, 2002 at 5:09 am
Thanks for the prompt reply!
Yep SQL Logins via the application. The App is a 3rd party app.
Out of interest (I'm quite new to SQL Server!) isn't this a typical issue for SQL Server. Any multiuser app written for SQL Server would need server wide access if it has the ability to create users from within the app.
Is the way around this, just to create/database users and use a single login which the app would use either with ODBC/JDBC or ADO for example and then control security level at the application level. I assume this is what most apps would do!
June 21, 2002 at 5:56 am
Explain how this app works and is it inhouse or third party. If third party and doesn't have a built in piece for the security you can adjust then put on another machine for security of the other databases. However some vendors do allow you to pick the password so it is not know and put in the registry (encrypted with a tool they provide you). Check on this if they offer then only the app will know and if you find anyone has hacked the information that is grounds in most companies for termination (sorry but I get mad with people who disobey security without permission). If in house then have the developers provide you a way to do this so hat periodicaly it can be changed, sure they know how to get but you can handle this much better. Otherwise get them to create a way via stored procedure you can add the users and not have to give out this info. The code anyone uses can be put into an xp or sp to allow you to setup users.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
June 21, 2002 at 6:16 am
The answer is it depends. Im in favor of one login for data access and securing the application via NT group membership.
Andy
June 21, 2002 at 9:53 am
If it doesn't have to be realtime, then I usually insert the data into a table and have a job come create those users every minute.
I had a similar issue with Great Plains and eventually dug down and got them to admit that the app does not have to create the login. It can, but it can also use existing logins created by the sysop.
Steve Jones
Viewing 6 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply