Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


The Case for SQL Logins - Part 1


The Case for SQL Logins - Part 1

Author
Message
Andy Warren
Andy Warren
SSCrazy Eights
SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)

Group: Moderators
Points: 9459 Visits: 2727
Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/awarren/thecaseforsqlloginspart1.asp>http://www.sqlservercentral.com/columnists/awarren/thecaseforsqlloginspart1.asp

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
marten_brege
marten_brege
SSC Rookie
SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)SSC Rookie (38 reputation)

Group: General Forum Members
Points: 38 Visits: 2
x

Edited by - marten_brege on 06/24/2002 12:18:05 AM



johnnypenet
johnnypenet
Forum Newbie
Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)Forum Newbie (2 reputation)

Group: General Forum Members
Points: 2 Visits: 1
You got it right, even Microsoft push for this approach on ASP.NET. One SQL account, hidden for the user, for doing the job, and a table of users maintained by your application. By preference use the same usernames as in the domain. In this way you can use role based security, maintained by the domain. This is the approach in the ASP.NET, but it could easily be extended for other client / server applications.



Paul Thornett
Paul Thornett
SSC Rookie
SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)SSC Rookie (44 reputation)

Group: General Forum Members
Points: 44 Visits: 96
While I agree completely with your comments about Windows authentication, I don't believe they go far enough.

Sql Server comes in many flavours, one of which is a Desktop version. I believe the very existence of this version of the product strongly implies that Microsoft expects, even encourages, us to develop bespoke databases for clients (and of course, the existence of the MSDE engine supports this inference).

In such an environment, I can expect to provide a tailored solution to one or more clients. Such a solution may involve software (programming), hardware (machines) and data (stored in databases <g>Wink. The client may elect to allow a number of users some type of access to all or some of the data - including a mobile access requirement (e.g. for a travelling salesman to work on his numbers at night in his hotel room). Now, in order to meet this type of requirement, the client can make available a copy of the database to run under the Desktop version of Sql Server.

As the designer and implementor, I can impose whatever security my client desires. Perhaps his salesmen are to be denied access to one or more tables. But once the database has been copied to the salesman's machine, all existing Sql Server security has just gone out the window. Removing the BUILTIN/Administrators works only on the database machine on which you remove that login. By copying such a database to another machine, anyone who has administrative NT rights on that second machine instantly has unfettered access to the copied database (I've tested this by creating a test database and removing all access; as soon as I copied the database to another machine, all read/write access was restored).

Even humble old Microsoft Access does better than this with its user security. The problem lies in where Sql Server chooses to store its security information - i.e. not in the target database.

I have discussed this issue with various Microsoft technical people - once they understand the problem, they simply trot out the usual trite remarks about "there's no security without physical security". Even most of the Sql gurus don't seem to realize just how fatally flawed Sql Server is in this respect - I guess they're not really thinking of Sql Server being used in this way.

Imagine the howls of protest (and even the derision and laughter) that would ensue if Microsoft were to announce that anyone with NT administrative rights on _any_ machine would _automatically_ have similar rights over _all_ other NT machines!

--------
Paul Thornett



pauldurdin
pauldurdin
SSC-Enthusiastic
SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)SSC-Enthusiastic (175 reputation)

Group: General Forum Members
Points: 175 Visits: 1
Well it's good to keep this topic under discussion. I agree that WA dosnt do anything for internet sites where there is a problem that has to be addressed.
However i use WA and application roles for all my intranet and internal apps because it allows me to switch people on and off easily, but dosnt give them any access to the database, apart from views & spocs that i explicitly give them. If an employee leaves he cannot even get onto the network and cannot connect to the database so knowledge of the app role password is not an issue after he has left.
App Roles are essential to controlling access to rows and columns, which (unless i've missed something) cant be done in SQL Server 7.
The problems with app roles are;
1. you have to store the role name & password somewhere. This can be dealt with as suggested in the article.
2. third party tools and components such as crystal reports dont support app roles - which is a serious drawback imo.
One ommision that i would like to see a solution to is being able to see the sum total of access that a user has via the various roles etc. E.g. User W has read permission on table X through role Y and role Z



Rayven
Rayven
Say Hey Kid
Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)Say Hey Kid (691 reputation)

Group: General Forum Members
Points: 691 Visits: 428
Excellent article. We use SQL to back end intranet and web applications and NT security is pretty much useless for what we need.

Unless the operator somehow figures out how to set up an ODBC, work out the connection and the password, they can't access the data. If anyone needs data, it can always be extracted to a spreadsheet, or they can have a view designed for them


---------------------------------------
It is by caffeine alone I set my mind in motion.
It is by the Beans of Java that thoughts acquire speed,
the hands acquire shaking, the shaking becomes a warning.
It is by caffeine alone I set my mind in motion.

Andy Warren
Andy Warren
SSCrazy Eights
SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)SSCrazy Eights (9.5K reputation)

Group: Moderators
Points: 9459 Visits: 2727
Thank you all for your comments so far!

Andy
http://www.sqlservercentral.com/columnists/awarren/

Andy
SQLAndy - My Blog!
Connect with me on LinkedIn
Follow me on Twitter
r3patel
r3patel
Grasshopper
Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)Grasshopper (15 reputation)

Group: General Forum Members
Points: 15 Visits: 58
Thanks, very good article, makes me rethink about WA security (how safe is safe!!!!)



SueStill
SueStill
Valued Member
Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)Valued Member (54 reputation)

Group: General Forum Members
Points: 54 Visits: 3
We tend to use WA because we also use groups to control software installation. The fact is, if you're using WA everywhere else, why change it. WA plus app roles provides enough control for us. Also, what about the transaction log? How do you know who's performing which transactions if you use a "service id"?



zacek@improve.cz
zacek@improve.cz
SSC Rookie
SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)SSC Rookie (40 reputation)

Group: General Forum Members
Points: 40 Visits: 1
WA or mixed is as good as DBA is.

The are lot of pro's and con's with each approach and no universal recommendation can be made. I assume that account lockout is excellent feature on sites which are often target to some attacks. In bookkeeping software is this feature unpleasant. You decide what is best in your deployment scenario and you have to try to guard the server whatever the security mode is.

We use WA as much as possible, but my issue is that SAP R/3 package does not support WA, so we have non-WA island in sea of WA, which makes me much more nervous because different support procedures, hotline etc.



Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search