There are three separate groups of users in our organisations (development, support, implementation). As it stands everyone is using a single login for everything. We are starting to move away from this. Everyone is accessing the database though their own login where each person has access to their groups systems. So Support has access to support functions and jobs etc.
The allowed permission for the procedures and tables are really easy. Create a login from the windows group. Then create an user based on that login and allow it to read and execute on the new schema that we're creating for them.
We are running SQL Server 2012 and 2008 R2.
The SQL Agent Jobs sits above the user level and requires a login to be assigned to the owner. But it doesn't take a group login as an accepted parameter:
@owner_login_nameis invalid (valid values are returned by
sp_helplogins[excluding Windows NT groups]).
The hope is to allow the groups to have their own set of jobs that they can manipulate directly (on a reporting server not the live database). Without effecting others departments work or the other jobs (DB maintenance tasks, replication etc). But allowing other members of a team to manipulate a job if the original writer is out of the office or has left.
I've tried searching around but so far the only thing I've found on sqlservercentral.com from back in 2010 saying it can't be done.
Things I'm looking at
Having the SQL Agent job assigned to a support / devopment generic account that nobody has access to. But everyone somehow has access to manipulate their jobs.
This would allow people to alter the group's jobs while allowing jobs to continue being used after an individual leaves the company.
I've not found a way for people to be able to access / run jobs by that have other owners (even when they are using the same windows group login to sql). Without granting them
SQLAgentOperateorRole (which would defeat the point in locking them out) of each other's (and the admin's) jobs.
Create a user per group that has the added access of the msdb rights along with the standard support abilities that they can log into to manipulate jobs.
The disadvantage of this is now the users have two logins one of which won't change. So an user leaving the company would still have the login credentials for that account potentially, it would also lead to users being lazy and only ever logging in under that account. (They shouldn't but let's be honest, they will).
Having a SQL job that runs every 5 minutes, each group has a table with commands for run this command at frequency x (essentially one SQL agent job runs a custom written SQL Agent list of jobs).
I don't think I need to go through how horrible an idea this is. But it's something that has semi been considered.
Obviously the best solution that we can see for us, would be to allow a group to own a SQL Agent job but it doesn't seem like this is possible.
Anyone have any ideas? For now guidance on how to implement something like this would be appreciated.