sqlfriends (3/13/2013)...They may need to read and write and also execute stored procedures in the databases...

Typically when it comes to security you want to grant the least privileges that the user needs to do its work. If these 5 users are only doing read, write, and execute type of actions, then DB_OWNER seems excessive. If the databases have schemas then a handy trick is to use permissions at the schema level instead of each individual object, for example:

GRANT SELECT ON SCHEMA::[schemaname] TO [user or rolename]GRANT INSERT ON SCHEMA::[schemaname] TO [user or rolename]GRANT UPDATE ON SCHEMA::[schemaname] TO [user or rolename]GRANT DELETE ON SCHEMA::[schemaname] TO [user or rolename]GRANT EXECUTE ON SCHEMA::[schemaname] TO [user or rolename]

If it's the application account, DBOwner may be more expected depending on how it reacts. does it create tables, delete items, insert, update, drop? I agree with least privilege, though the application may actually need DBOwner.

sqlfriends (3/13/2013)...They may need to read and write and also execute stored procedures in the databases...

Typically when it comes to security you want to grant the least privileges that the user needs to do its work. If these 5 users are only doing read, write, and execute type of actions, then DB_OWNER seems excessive. If the databases have schemas then a handy trick is to use permissions at the schema level instead of each individual object, for example:

GRANT SELECT ON SCHEMA::[schemaname] TO [user or rolename]GRANT INSERT ON SCHEMA::[schemaname] TO [user or rolename]GRANT UPDATE ON SCHEMA::[schemaname] TO [user or rolename]GRANT DELETE ON SCHEMA::[schemaname] TO [user or rolename]GRANT EXECUTE ON SCHEMA::[schemaname] TO [user or rolename]

EXECUTE privilege is for stored procedures and scalar functionsSELECT privilege would be for tables, views, and table valued functionstriggers are events that happen behind the scenes and don't have permissions on them

sqlfriends (3/13/2013)...They may need to read and write and also execute stored procedures in the databases...

Typically when it comes to security you want to grant the least privileges that the user needs to do its work. If these 5 users are only doing read, write, and execute type of actions, then DB_OWNER seems excessive. If the databases have schemas then a handy trick is to use permissions at the schema level instead of each individual object, for example:

GRANT SELECT ON SCHEMA::[schemaname] TO [user or rolename]GRANT INSERT ON SCHEMA::[schemaname] TO [user or rolename]GRANT UPDATE ON SCHEMA::[schemaname] TO [user or rolename]GRANT DELETE ON SCHEMA::[schemaname] TO [user or rolename]GRANT EXECUTE ON SCHEMA::[schemaname] TO [user or rolename]