|
Home > Archive > MS SQL Server security > April 2005 > users and logins
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| What is the differnce between managing Logins under the Security folder in
the EM and managing Logins from the User object in a database? My developers
tend to navigate to the database, then to the Users, then to Login Name. If
the Login is not there, they must press new.
I like to manage everything out of the Security/Logins. I then end up
giving a login Database Access, then just make the login Permit in Database
Roles as the "Owner". I like Roles because the have the permissions all
built in. None of our logins need the granulartiy of Select or Delete
because everything is done by way of calling a stored procedure. The code in
the stored procedure manages what they end up doing in the database.
If you manage permissions within the database, it seems that you could OVER
restrict a login by not turning on enough permissions.
| |
| Jens Süßmeyer 2005-04-20, 1:23 pm |
| So, i think that your only qquestins, eh ?
What is the differnce between managing Logins under the Security folder in
the EM and managing Logins from the User object in a database?
-Users must be created at server level to grant them permissions at database
level.
-At the database level you can only give them permissions to the database,
to objects and so on...
-At server Level you can put the users into database or server Roles and map
them to specific users on database level.
HTH, Jens Suessmeyer.
---
http://www.sqlserver2005.de
---
"Rich" <Rich@discussions.microsoft.com> schrieb im Newsbeitrag
news:C1635985-AF0C-4A5F-A452- 62FACB29EBFD@microso
ft.com...
> What is the differnce between managing Logins under the Security folder in
> the EM and managing Logins from the User object in a database? My
> developers
> tend to navigate to the database, then to the Users, then to Login Name.
> If
> the Login is not there, they must press new.
>
> I like to manage everything out of the Security/Logins. I then end up
> giving a login Database Access, then just make the login Permit in
> Database
> Roles as the "Owner". I like Roles because the have the permissions all
> built in. None of our logins need the granulartiy of Select or Delete
> because everything is done by way of calling a stored procedure. The code
> in
> the stored procedure manages what they end up doing in the database.
>
> If you manage permissions within the database, it seems that you could
> OVER
> restrict a login by not turning on enough permissions.
|
|
|
|
|