Fala pessoal!!
Nesse artigo eu gostaria de compartilhar com vocês um pequeno estudo sobre como conectar utilizando a conexão DAC (Dedicated Admin Connection) sem o SQL Browser. Essa ideia partiu de uma dúvida enviada no meu curso de Segurança de SQL Server – Módulo 1, onde o Fabiano Ferreira enviou a seguinte dúvida: “no script stpchecklist_seguranca, há uma validação sobre o SQL Browser ser executado com uma única instância e trata como erro. Porém, o SQL Browser não é usado para permitir o uso da conexão via remote admin connections? Se sim, seria um erro deixá-lo ativo?” – E essa foi uma EXCELENTE dúvida!
O que é a conexão DAC (Dedicated Admin Connection) ?
Como vocês sabem, a conexão DAC (Dedicated Admin Connection) permite que o SQL Server reserve um slot de conexão para que, em casos extremos, como todas as conexões sendo utilizadas ou trigger de logon impedindo as conexões, você ainda consiga logar na instância e tentar corrigir o problema, sem precisar reiniciar o serviço do SQL. Para saber mais sobre a conexão DAC, clique nesse link aqui.
O que é o SQL Browser? Como ele funciona?
Já o SQL Browser é o serviço do SQL Server que faz a “tradução” do nome da instância para a porta que ela está utilizando. Vou exemplificar como estão as instâncias do servidor dirceu-vm:
Ou seja, existem as instâncias SQL2008, SQL2012, SQL2014, SQL2016, SQL2017 e SQL2019 nesse servidor (Ex: dirceu-vm\sql2017). Quando você vai realizar uma tentativa de conexão utilizando essa instância, o SQL Browser vai identificar o nome da instância informada (SQL2017) e vai retornar qual porta essa instância está utilizando, de acordo com as configurações:
No caso acima, a minha instância está utilizando uma porta dinâmica, ou seja, você informa o valor “0” nesse campo e cada vez que o serviço é iniciado, essa instância vai utilizar uma porta aleatória. Nesse cenário, onde um servidor possui várias instâncias, o SQL Browser é importante, pois ele identifica o nome da instância solicitada na conexão e retorna qual a porta dinâmica que essa instância está utilizando nesse momento.
Conectando numa instância com o SQL Browser ativado:
Reparem que no exemplo acima, eu não precisei informar o número da porta que essa instância está utilizando, pois a partir do momento que eu informo o nome da instância, o serviço do SQL Browser vai identificar qual a porta que essa instância está utilizando e realizar a conexão pra mim. Se você desativar o SQL Browser, terá que informar manualmente na conexão, qual a porta que a instância está utilizando. Como essa porta muda a cada vez que o serviço é iniciado, fica difícil saber qual é a porta de cada instância.
Agora, vamos utilizar uma porta fixa para a nossa instância (1437):
Já no exemplo acima, eu já sei qual a porta que a minha instância vai utilizar, pois ela é fixa e eu que defini. Mesmo que o servidor tenha várias instâncias, se todas elas tiverem uma porta fixa, você pode deixar o SQL Browser desabilitado, pois a conexão utilizando o formato “servidor, porta” pode ser feita sem maiores dificuldades (embora o padrão “servidor\instancia” seja mais fácil decorar, é verdade).
Conectando em uma instância com o SQL Browser desativado:
Por quê desativar o SQL Browser?
Depois da explicação acima sobre o SQL Browser, ficou claro que o SQL Server não precisa desse recurso para funcionar normalmente (Exceto em ambientes que estão em Cluster. Nesse caso, o SQL Browser NÃO pode ser desativado), pois ele acaba expondo o nome e as portas utilizadas por cada instância na rede. Se você for pesquisar por checklists de segurança na internet ou boas práticas de segurança, verá que a maioria recomenda desativar esse serviço.
Embora eu não ache que isso vai ser uma grande melhoria de segurança, uma vez que o risco de manter o SQL Browser rodando é relativamente baixo, eu acho que qualquer dificuldade a mais que você possa oferecer para um possível invasor, vale a pena ser implementada.
Além disso, quando você informa “servidor, porta”, você pode trocar essa porta de tempos em tempos e com impacto de alterar apenas a string de conexão das aplicações e fazer uma alteração bem simples no protocolo da instância para alterar a porta (nessa tela do print acima). Já alterar o nome da instância envolve realizar modificações mais complexas no banco de dados também, além das aplicações, e se você utiliza o nome da instância algum monitoramento ou rotina, essa alteração pode impactar nisso.
E a conexão DAC? Desativando o SQL Browser ela não funciona!
Com o SQL Browser ativado, basta você adicionar o prefixo ADMIN: antes do nome do servidor\instância para se conectar utilizando o DAC (caso essa conexão não esteja sendo utilizada, é claro):
E assim, consigo me conectar utilizando a DAC:
Mas aí quando eu desativo o SQL Browser e tento conectar utilizando a DAC, me deparo com essa mensagem de erro:
Ou seja, o DAC não funciona sem o SQL Browser!!
Calma, jovens! Vou explicar por quê isso acontece.. Assim como ele faz a “tradução” do nome da instância para o número da porta, o serviço do SQL Browser também identifica o prefixo “ADMIN:” na conexão e retorna o número da porta da conexão DAC dessa instância, e assim, é feita a conexão com sucesso utilizando a DAC.
Ou seja, como o SQL Browser está desativado, ele não fez essa “tradução” para a porta utilizada pela conexão DAC nessa instância (Cada instância só pode ter 1 conexão DAC) e aí o SQL Server não conseguiu identificar em qual porta ele vai conectar. A “mágica” para utilizar a conexão DAC sem o SQL Browser é simplesmente informar a porta utilizada pelo DAC dessa instância no formato “servidor, porta”.
Quando estamos utilizando a instância padrão, a porta padrão da conexão DAC é a 1434, mas quando temos instâncias nomeadas e, especialmente, várias instâncias, a porta será dinâmica. E para descobrir qual a porta que está sendo utilizada pela conexão DAC, podemos utilizar as consultas abaixo:
Utilizando a sp_readerrorlog
|
1 |
sp_readerrorlog 0, 1, 'Dedicated admin connection' |
Utilizando a DMV sys.dm_tcp_listener_states
|
1 2 3 4 5 6 7 8 |
SELECT [port] FROM sys.dm_tcp_listener_states WHERE is_ipv4 = 1 AND [type] = 0 AND ip_address <> '127.0.0.1' |
Utilizando a DMV sys.dm_server_registry
|
1 2 3 4 5 6 7 |
SELECT * FROM sys.dm_server_registry WHERE value_name = 'TcpDynamicPorts' AND registry_key LIKE '%\AdminConnection\Tcp' |
Utilizando o SQL Server Log
Uma vez que identificamos qual é a porta utilizada pela conexão DAC (no caso desse exemplo, é a 49830), basta informá-la na string de conexão:
E agora, vou comprovar que estou utilizando a conexão DAC:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
SELECT DISTINCT A.endpoint_id, A.local_net_address, A.local_tcp_port, B.[name], A.session_id, @@SPID AS MEU_session_id FROM sys.dm_exec_connections A JOIN sys.endpoints B ON A.endpoint_id = B.endpoint_id WHERE A.endpoint_id IS NOT NULL AND A.local_tcp_port IS NOT NULL AND B.is_admin_endpoint = 1 |
E é isso aí, pessoal!
Espero que tenham gostado desse artigo!
Para saber mais sobre toda a parte de Segurança no SQL Server, não deixem de fazer o meu curso Segurança no SQL Server – Módulo 1, onde abordo sobre várias configurações, boas práticas e dicas para melhorar a segurança do seu ambiente SQL Server e também seria MUITO interessante fazer o curso de Fundamentos de Windows para DBA SQL Server, da lenda Rodrigo Ribeiro, onde ele aborda sobre vários temas muito importantes que um DBA deve saber, entre eles, a conexão DAC, mostrando até como alterar essa porta :).
Um abraço e até o próximo artigo.
Portuguese 
English