No SQL Server, você pode ter contas baseadas em contas do Windows ou contas SQL específicas separadas. Para ambas as variações, você precisa de uma conta para cada usuário que precisa usar seu banco de dados.
A única exceção é a capacidade de criar um logon do SQL Server para um grupo de segurança do Windows , por exemplo.
MyAppUsers e, em seguida, um usuário em seu banco de dados para esse logon. Com isso, qualquer conta do Windows que seja membro desse grupo de segurança (no Windows/AD) também terá permissões para ver/usar seu banco de dados. Com essa abordagem, você também está transferindo a administração de quem pode usar seu banco de dados para fora do SQL Server, já que realmente depende apenas da associação a um grupo de segurança do Windows.
Um login, um usuário - várias contas do Windows que obtêm permissões com isso. Me parece um vencedor!
Atualização:
Crie um logon para um grupo do Windows AD:
CREATE LOGIN [DOMAIN\GroupName] FROM WINDOWS
Crie um usuário em seu banco de dados com base nesse login:
USE (your database)
CREATE USER GroupNameUser
FOR LOGIN [DOMAIN\GroupName]
Cadeia de conexão para sua conexão do SQL Server:
server=(your server);database=(your database);integrated security=SSPI;
O que mais posso te dizer?
Atualização nº 2: o código não usando as contas do Windows é isso:
Crie um login para cada usuário que precisa usar seu aplicativo
CREATE LOGIN (some login name) WITH PASSWORD = 'Top$ecret'
Crie um usuário em seu banco de dados com base nesse login - novamente, uma vez para cada usuário do seu aplicativo:
USE (your database)
CREATE USER UserName
FOR LOGIN (some login name)
Cadeia de conexão para sua conexão do SQL Server:
server=(your server);database=(your database);
user id=UserName;Password=Top$ecret
Mas, novamente:isso requer um login incluindo uma senha e um usuário em cada banco de dados que você precisa acompanhar e possivelmente fazer coisas como operações de "redefinição de senha" etc. do seu aplicativo de banco de dados. Muito mais em termos de sobrecarga de administração!
