Mike's questions

Hoje descobrimos que dois de nossos SQL Servers (ambos 2017 CU21) estão aceitando conexões de qualquer conta de domínio aleatório, mesmo aqueles que definitivamente não têm login direto ou acesso via associação ao grupo AD.

Em cada servidor há um banco de dados de usuários que permite que essas contas de domínio aleatórias se conectem.

Com base na configuração que vemos, esperamos que qualquer conta de domínio aleatório (ou seja, qualquer conta que não tenha um login na instância) tenha uma falha de login e, além disso, também seja bloqueada para se conectar ao banco de dados do usuário.

Para esses bancos de dados, a conta de convidado está desabilitada, mas para uma boa medida, executamos:

REVOKE CONNECT FROM guest

Isso não fez diferença.

Então duas perguntas:

1. Como podemos desligar/impedir que essas conexões públicas sejam bem-sucedidas?
2. Que instrução TSQL poderia nos mostrar a configuração problemática?

Coisas que vimos até agora:

• A função de servidor 'público' parece ter a configuração padrão, igual a todos os nossos outros servidores onde isso não é um problema
• O usuário convidado definitivamente aparece como desabilitado em todos os bancos de dados e servidores
• A função de banco de dados 'pública' tem apenas as permissões padrão que esperamos ver
• É apenas 1 banco de dados de usuário (mais master & msdb & tempdb) em cada servidor que é acessível a essas contas aleatórias -- todos os outros bancos de dados se comportam normalmente, ou seja, a conta não pode se conectar a eles.
• A configuração do tipo de contenção do banco de dados é 'Nenhum' para todos os casos.
• Não há login presente em nenhum dos servidores que abranja todos os usuários do domínio

Algum contexto: os dois servidores estão relacionados -- eles são os servidores DEV e PROD para o mesmo aplicativo. É muito provável que essa configuração tenha sido feita deliberadamente por algum motivo histórico - mas ninguém que trabalha aqui agora sabe o porquê, então gostaríamos de desabilitar esse acesso público.

Estamos usando certificados SSL de uma CA pública em cada SQL Server em nossa topologia de replicação transacional (push) e desejamos ter o EncryptionLevel = 2 para nossos Agentes Distribuidores. Atualmente EncryptionLevel está definido como 1 e funciona bem. (A diferença entre 1 e 2 é que 1 diz ao agente apenas para usar criptografia e 2 diz para ele também validar a cadeia de certificação dos certificados SSL)

Os certificados SSL são de uma CA pública. O Nome da Entidade é o FQDN completo do Windows do servidor (SERVER1.mywindowsdomain.com) e a lista Nomes Alternativos da Entidade contém o FQDN DNS completo (MYAPP.MYDOMAIN.COM).

Posso confirmar que, usando o SSMS, posso me conectar corretamente a cada SQL Server sem marcar 'Trust Server certificate' na caixa de diálogo de conexão, o que significa que a cadeia de certificados está sendo validada corretamente com sucesso.

Quando altero o EncryptionLevel para = 2, nossos Agentes de Distribuição não podem mais se conectar ao Publicador/Distribuidor em execução no mesmo servidor. Isso faria sentido porque eles estão tentando se conectar ao SERVER1\DEV, enquanto o certificado SSL é para um nome DNS público - MYAPP.MYDOMAIN.COM e, portanto, a validação da cadeia falha.

Portanto, estou procurando uma maneira de configurar a replicação do zero, mas usando o nome DNS (MYAPP.MYDOMAIN.COM) em vez do nome da máquina (SERVER1).

Porém, quando executo o seguinte comando:

exec sp_adddistributor @distributor = N'MYAPP.MYDOMAIN.COM\DEV', @password = N'12345'

Então recebo a seguinte mensagem de erro de volta:

Msg 18483, Level 14, State 1, Line 48 Não foi possível conectar ao servidor 'SERVER1\DEV' porque 'distributor_admin' não está definido como um logon remoto no servidor. Verifique se você especificou o nome de login correto. . Msg 14114, nível 16, estado 1, procedimento sp_adddistributiondb, linha 169 [Linha inicial do lote 65] O servidor 'SERVER1\DEV' não está configurado como um distribuidor.

Observe que este comando funcionou bem no passado quando era isso:

exec sp_adddistributor @distributor = N'SERVER1\DEV', @password = N'12345'

Depois de muito pesquisar, eu tentei muitas variações sobre isso. Eu tentei:

• Usando aliases de cliente (32+64 bits) no editor
• Variando como minha sessão SSMS está conectada ao servidor, ou seja, o nome do servidor de diálogo de conexão. Eu tentei usar SERVER1\DEV, MYAPP.MYDOMAIN.COM\DEV e também SERVER1.mywindowsdomain.com\DEV.

Qualquer sugestão sobre o que tentar a seguir seria apreciada. Eu ficaria feliz em explorar a) obter os Agentes de Distribuição para validar o certificado do servidor local [mas tendo em mente que não posso modificar os certificados SSL], ou b) recriar a replicação inteiramente do zero para que ele usa o DNS FQDN, ou seja. MYAPP.MYDOMAIN.COM\DEV.

---

Nota : Apenas para evitar qualquer pessoa que pesquise no Google essa mensagem de erro e sugira que nosso servidor SQL pode ter sido renomeado, esse definitivamente não é o caso. O problema é o nome da máquina versus o nome DNS.

Como posso definir as configurações nesta tela no Replication Monitor usando TSQL? Para referência, estamos no SQL 2014.

Eu tenho executado este comando em nosso domínio de teste:

sqlcmd -L

E descobri que entre todos os resultados válidos, ele também retorna vários servidores que definitivamente não possuem o SQL Server instalado. É possível que eles tenham o SQL instalado em um passado distante, mas definitivamente não atualmente.

Como isso é possível? Eu teria pensado que o SQL Browser teria que ser instalado e executado em um servidor para responder à transmissão sqlcmd -L.

Caso ajude, os servidores que são falsos positivos são: -um controlador de domínio -um servidor para Microsoft SCCM -um servidor para gerenciamento de PKI

Obrigado Mike