Temos um grupo de AD como Login em vários servidores, geralmente como sysadmin,
mas encontrei um servidor que esse login não tem acesso a nenhum DB e tem função pública de servidor apenas.
Conversei com um membro deste grupo sobre esse problema
e ele me disse que tem acesso aos bancos de dados deste servidor.
E acabou abrindo o SSMS como usuário diferente (usando suas credenciais de AD) na minha estação local,
ele pode selecionar, atualizar tabelas neste servidor, até mesmo encolher um arquivo de log (mas não pode ver os logins, exceto sa e este grupo).
Não consigo encontrar uma fonte para essas permissões:
não há login\usuário com suas credenciais,
existem outros grupos AD, mas se eu revogar a conexão deste grupo,
ele não poderá mais se conectar a este servidor.
A função de servidor público só tem permissão para visualizar qualquer banco
de dados A função de banco de dados público não tem permissões no esquema dbo O
banco de dados não está em contenção parcial....
Onde mais posso procurar uma fonte das permissões deste Login?
*SQL Server 2012 em meus computadores e servidores.
Eu usei esta consulta para encontrar este login
USE [master]
GO
DECLARE @username sysname
DECLARE @objname sysname
DECLARE @found integer
DECLARE @sql nvarchar(4000)
DECLARE @results TABLE (Login sysname)
SET @username = ' '
WHILE @username IS NOT NULL
BEGIN
SELECT @username = MIN(name)
FROM master.dbo.syslogins WITH (NOLOCK)
WHERE sysadmin = 0
AND securityadmin = 0
AND serveradmin = 0
AND setupadmin = 0
AND processadmin = 0
AND diskadmin = 0
AND dbcreator = 0
AND bulkadmin = 0
AND name > @username
AND Name NOT LIKE N'NT %'
AND Name NOT LIKE N'##%'
-- this is the list of non system logins
-- ids in server roles may not have corresponding users
-- any database but they should not be removed
SET @found = 0
IF @username IS NOT NULL
BEGIN
-- now we search through each non system database
-- to see if this login has database access
SET @objname = ''
WHILE @objname IS NOT NULL
BEGIN
SELECT @objname = MIN( name )
FROM master.dbo.sysdatabases WITH (NOLOCK)
WHERE
name > @objname
AND DATABASEPROPERTYEX(name, 'status') = 'ONLINE'
IF @objname IS NOT NULL
BEGIN
SET @sql = N'SELECT @found = COUNT(*) FROM [' + @objname
+ N'].dbo.sysusers s WITH (NOLOCK) JOIN master.dbo.syslogins x WITH (NOLOCK)
ON s.sid = x.sid WHERE hasdbaccess = 1 AND x.name = '''+ @username + ''''
EXEC sp_executesql @sql,N'@found Int OUTPUT',@found OUTPUT
--SELECT @found, @objname, @username
IF @found IS NOT NULL AND @found > 0
SET @objname = 'zzzzz' -- terminate as a corresponding user has been found
END
END
IF @found = 0
BEGIN
INSERT INTO @results
SELECT @username
END
END
END
SELECT SERVERPROPERTY('ServerName') ServerName ,Login
FROM @results r
ORDER BY Login
GO
Faça login como o usuário misterioso. Então corra:
Em algum lugar na lista de saída estará o token que lhe concede acesso. Por exemplo, você pode tentar isso (não é garantido que funcione):
Finalmente encontrei a fonte dessas permissões:
Este usuário AD tinha um usuário "órfão" no banco de dados com permissões mais altas do que o grupo AD.
Portanto, para se conectar à instância, esse usuário precisa fazer parte do grupo
Mas após a conexão, ele pode obter permissões diretamente de seu usuário "órfão" nos bancos de dados
Mesmo que o grupo do qual ele faz parte seja apenas um grupo público
Este grupo nem precisa ter um usuário correspondente no banco de dados.
Espero ter sido claro porque não estava familiarizado com esse problema.