# MSSQL

> Guia completo sobre a integração do SQL Server com o Active Directory, abordando autenticação Kerberos, SPNs, contas de serviço gerenciadas, delegação e melhores práticas para ambientes corporativos.

***

## 🔍 Introdução

A integração do Microsoft SQL Server com o Active Directory (AD) permite **autenticação centralizada**, **gerenciamento simplificado de permissões** e **auditoria unificada**. Quando configurada corretamente, essa integração elimina a necessidade de credenciais SQL separadas e proporciona maior segurança através do protocolo **Kerberos**, que oferece autenticação mútua e delegação restrita.

***

## 🔐 Modos de Autenticação no SQL Server

O SQL Server oferece dois modos principais de autenticação:

| Modo                        | Descrição                                                                                                      | Casos de Uso                                                                          |
| --------------------------- | -------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------- |
| **Autenticação do Windows** | Utiliza credenciais do Active Directory. O usuário ou serviço é autenticado pelo domínio.                      | Ambientes corporativos com AD; recomendado para segurança e auditoria centralizada.   |
| **Modo Misto**              | Permite tanto autenticação do Windows quanto autenticação do SQL Server (logins/passwords armazenados no SQL). | Aplicações legadas ou ambientes com sistemas que não suportam autenticação integrada. |

### Por que escolher Autenticação do Windows?

* ✅ **Credenciais centralizadas** – gerenciadas no AD com políticas de senha unificadas.
* ✅ **Suporte a Kerberos** – autenticação mútua, delegação restrita e maior segurança.
* ✅ **Auditoria unificada** – rastreabilidade integrada com logs de segurança do Windows.
* ✅ **Expiração de senha** – gerenciada automaticamente pelo AD.
* ✅ **Grupos de segurança** – permissões atribuídas a grupos do AD, simplificando a administração.

***

## 🎫 Kerberos e Service Principal Names (SPNs)

Para que a autenticação Kerberos funcione entre clientes e SQL Server, duas condições são essenciais:

1. **Cliente e servidor devem estar no mesmo domínio Windows ou em domínios confiáveis.**
2. **Um Service Principal Name (SPN) deve estar registrado no Active Directory**, mapeando o serviço SQL Server à conta de serviço que o executa.

{% hint style="warning" %}
Se o SPN não estiver registrado corretamente ou falhar, a camada de segurança do Windows não consegue determinar a conta associada e a autenticação **reverte para NTLM**.
{% endhint %}

### 3.1 O Papel do SPN na Autenticação

Quando um aplicativo abre uma conexão usando Autenticação do Windows:

1. O cliente SQL Server Native Client envia o nome do servidor, instância e, opcionalmente, um SPN.
2. Se o SPN não for fornecido, um SPN padrão é construído com base no protocolo usado, nome do servidor e instância.
3. O SPN é enviado ao **Key Distribution Center (KDC)** – o Controlador de Domínio – para obter um token de autenticação.
4. Se o token for obtido com sucesso, a autenticação é **Kerberos**. Caso contrário, **NTLM** é utilizado.

{% hint style="info" %}
O SQL Server **tenta primeiro Kerberos**. Se falhar, a autenticação pode ser rebaixada para NTLM, o que pode impactar recursos como delegação.
{% endhint %}

### 3.2 Formatos de SPN para SQL Server

Os SPNs para SQL Server seguem o formato `MSSQLSvc/<FQDN>:[<porta> | <nome_instancia>]`.

| Formato                            | Descrição                                                                              |
| ---------------------------------- | -------------------------------------------------------------------------------------- |
| `MSSQLSvc/<FQDN>:<porta>`          | Instância padrão ou nomeada via TCP. `<porta>` é o número da porta TCP (padrão: 1433). |
| `MSSQLSvc/<FQDN>`                  | Instância padrão quando protocolo diferente de TCP é usado (ex.: named pipes).         |
| `MSSQLSvc/<FQDN>:<nome_instancia>` | Instância nomeada quando protocolo diferente de TCP é usado.                           |

**Exemplos:**

```
# Instância padrão via TCP
MSSQLSvc/srv-sql.dominio.local:1433

# Instância nomeada "FINANCEIRO" via TCP
MSSQLSvc/srv-sql.dominio.local:5000

# Instância padrão via named pipes
MSSQLSvc/srv-sql.dominio.local

# Instância nomeada via named pipes
MSSQLSvc/srv-sql.dominio.local:FINANCEIRO
```

{% hint style="info" %}
O SPN não exige obrigatoriamente a porta. Servidores com múltiplas portas ou protocolos sem porta podem usar Kerberos igualmente, desde que o SPN esteja corretamente registrado.
{% endhint %}

### 3.3 Registro Automático de SPN

Quando o serviço **SQL Server Database Engine** é iniciado, ele tenta **registrar automaticamente** o SPN no Active Directory. Ao parar, tenta removê-lo.

#### Condições para registro automático:

* A conta de serviço deve ter **permissões adequadas** no AD para registrar/modificar SPNs.
* Contas que **suportam registro automático**:
  * **Contas de serviço gerenciadas (MSA/gMSA)**
  * **Contas virtuais**
  * **Local System** (não recomendado)
  * **NETWORK SERVICE**
  * **Contas de domínio com permissões delegadas**

#### Concedendo permissões para registro automático:

1. No **Controlador de Domínio**, abra **Active Directory Users and Computers**.
2. Ative **View > Advanced Features**.
3. Localize o objeto do computador SQL Server, clique com botão direito > **Properties**.
4. Acesse a aba **Security** > **Advanced**.
5. Adicione a conta de serviço (se não estiver listada).
6. Para a conta, conceda:
   * **Validated write to service principal name**
   * Em **Properties**: **Read servicePrincipalName** e **Write servicePrincipalName**
7. Aplique as alterações.

### 3.4 Registro Manual de SPN

Se o registro automático falhar (ex.: conta sem permissões), o SPN deve ser registrado manualmente usando a ferramenta **setspn.exe**.

#### Verificar SPNs existentes:

```powershell
# Listar SPNs de uma conta
setspn -L dominio\conta_servico

# Localizar SPNs duplicados
setspn -X
```

#### Registrar SPN manualmente:

```powershell
# Instância padrão via TCP
setspn -S MSSQLSvc/srv-sql.dominio.local:1433 dominio\sqlservice

# Instância nomeada via TCP
setspn -S MSSQLSvc/srv-sql.dominio.local:5000 dominio\sqlservice

# Instância padrão via named pipes
setspn -S MSSQLSvc/srv-sql.dominio.local dominio\sqlservice

# Instância nomeada via named pipes
setspn -S MSSQLSvc/srv-sql.dominio.local:INSTANCIA dominio\sqlservice
```

{% hint style="warning" %}
Se um SPN já existir para o mesmo serviço, ele deve ser removido antes do novo registro usando o parâmetro `-D` (delete).
{% endhint %}

```powershell
# Remover SPN existente
setspn -D MSSQLSvc/srv-sql.dominio.local:1433 dominio\conta_antiga
```

### 3.5 Verificação da Autenticação

Para confirmar que uma conexão está usando Kerberos, consulte a DMV `sys.dm_exec_connections`:

```sql
SELECT session_id, net_transport, auth_scheme, client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
```

**Resultado esperado:** `auth_scheme = 'KERBEROS'`

#### Ferramentas de Diagnóstico:

* **Microsoft Kerberos Configuration Manager for SQL Server** – ferramenta oficial da Microsoft para diagnosticar problemas de Kerberos.
* **klist.exe** – exibe tickets Kerberos em cache no cliente.

```cmd
klist
klist get <SPN>
```

***

## 🖥️ Contas de Serviço do SQL Server

A escolha da conta de serviço impacta diretamente a segurança e a manutenção do ambiente.

### 4.1 Tipos de Conta

| Tipo de Conta                                   | Descrição                                                                | Vantagens                                             | Desvantagens                                     |
| ----------------------------------------------- | ------------------------------------------------------------------------ | ----------------------------------------------------- | ------------------------------------------------ |
| **Local System / NETWORK SERVICE**              | Contas integradas do Windows. Usam a conta do computador no domínio.     | Sem gerenciamento de senha.                           | Permissões excessivas; difícil auditoria.        |
| **Conta de domínio tradicional**                | Conta de usuário do AD criada especificamente para o serviço.            | Controle granular.                                    | Senha manual; expiração pode parar o serviço.    |
| **Conta de Serviço Gerenciada (MSA)**           | Conta de domínio com gerenciamento automático de senha.                  | Senha rotacionada automaticamente.                    | Limitada a um único servidor.                    |
| **Conta de Serviço Gerenciada de Grupo (gMSA)** | Conta compartilhada por vários servidores, com gerenciamento automático. | Ideal para clusters, Always On, múltiplas instâncias. | Requer Windows Server 2012+ e schema atualizado. |

### 4.2 Contas de Serviço Gerenciadas (gMSA)

A **gMSA** é a prática recomendada para SQL Server em ambientes corporativos.

#### Criando uma gMSA:

```powershell
# Criar grupo de segurança para os servidores
New-ADGroup -Name "SQL_Servers" -GroupScope Global -GroupCategory Security

# Adicionar servidores ao grupo
Add-ADGroupMember -Identity "SQL_Servers" -Members "SRV-SQL01$", "SRV-SQL02$"

# Criar gMSA
New-ADServiceAccount -Name "gmsa-sql" -DNSHostName "gmsa-sql.dominio.local" -PrincipalsAllowedToRetrieveManagedPassword "SQL_Servers"
```

#### Instalando e configurando a gMSA no SQL Server:

```powershell
# Instalar gMSA no servidor
Install-ADServiceAccount -Identity "gmsa-sql"

# Configurar SQL Server para usar a gMSA (via Configuration Manager ou PowerShell)
```

***

## 🔑 Gerenciamento de Logins e Permissões

### Criando Logins Baseados em AD

```sql
-- Login para um usuário específico
CREATE LOGIN [DOMINIO\usuario] FROM WINDOWS;
GO

-- Login para um grupo de segurança do AD
CREATE LOGIN [DOMINIO\GrupoSQL_Admins] FROM WINDOWS;
GO
```

### Atribuindo Permissões a Níveis

```sql
-- Nível de servidor (ex.: permissão para criar bancos)
ALTER SERVER ROLE sysadmin ADD MEMBER [DOMINIO\GrupoSQL_Admins];
GO

-- Nível de banco de dados
USE MeuBanco;
CREATE USER [DOMINIO\usuario] FOR LOGIN [DOMINIO\usuario];
EXEC sp_addrolemember 'db_datareader', 'DOMINIO\usuario';
GO
```

### Mapeamento Automático

O SQL Server pode mapear automaticamente logins do Windows a usuários de banco de dados quando:

* O login é criado com `FROM WINDOWS`.
* O banco de dados possui um usuário com o mesmo nome (ou usando `AUTO_CREATE_STATISTICS`).

***

## 🔄 Delegação e Autenticação em Camadas

Em arquiteturas de aplicação (ex.: aplicação web → SQL Server), pode ser necessário **delegação restrita**, permitindo que o SQL Server atue em nome do usuário final.

### Configuração no AD

1. No **Active Directory Users and Computers**, localize a conta de serviço do SQL Server.
2. Acesse **Properties > Delegation**.
3. Selecione **"Trust this user for delegation to specified services only"**.
4. Escolha **"Use any authentication protocol"**.
5. Adicione os SPNs dos serviços que a conta pode delegar (ex.: para um aplicativo web).

{% hint style="info" %}
O SPN da conta de serviço do SQL Server deve estar registrado e a conta deve ser confiável para delegação.
{% endhint %}

***

## 🛠️ Resolução de Problemas

### 7.1 SPN Duplicado ou Incorreto

**Sintoma:** Falhas de autenticação intermitentes; eventos de segurança com ID 4769 (ticket solicitado para um SPN duplicado).

```powershell
# Localizar SPNs duplicados
setspn -X

# Exemplo de saída:
# Duplicate SPN found: MSSQLSvc/srv-sql.dominio.local:1433
```

**Solução:** Identificar a conta correta e remover o SPN da conta incorreta.

```powershell
# Remover SPN da conta incorreta
setspn -D MSSQLSvc/srv-sql.dominio.local:1433 dominio\conta_incorreta

# Adicionar à conta correta, se necessário
setspn -A MSSQLSvc/srv-sql.dominio.local:1433 dominio\sqlservice
```

### 7.2 Falha na Autenticação Kerberos

**Sintoma:** Conexões usam NTLM mesmo com SPN registrado.

**Causas comuns:**

* Diferença de horário entre cliente e servidor > 5 minutos (clock skew).
* SPN registrado para a conta de computador, mas serviço roda sob conta de domínio (ou vice-versa).
* Cliente não consegue resolver o FQDN do servidor.
* Conexão usando IP em vez de FQDN.

**Verificações:**

```sql
-- Verificar método de autenticação atual
SELECT auth_scheme, client_net_address, net_transport
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;
```

```powershell
# Verificar horário
w32tm /monitor /computers:srv-sql.dominio.local

# Testar resolução DNS
nslookup srv-sql.dominio.local
```

### 7.3 Conta de Serviço com Permissões Insuficientes

**Sintoma:** Eventos de aviso no log de aplicação ou erro do SQL Server: "The SQL Server Network Interface library could not register the Service Principal Name (SPN)".

**Solução:** Conceder permissões conforme seção 3.3 ou registrar SPN manualmente.

***

## ✅ Melhores Práticas e Checklist

### Configuração Inicial

* [ ] Use **Autenticação do Windows** como modo padrão.
* [ ] Execute o SQL Server sob **gMSA** sempre que possível.
* [ ] Registre **SPNs corretamente** – verifique com `setspn -L`.
* [ ] Configure **sincronização de horário** via PDC Emulator do domínio.
* [ ] Habilite **Kerberos logging** em ambiente de homologação para validação.

### Segurança

* [ ] Evite contas **Local System** ou **NETWORK SERVICE** em ambientes críticos.
* [ ] Utilize **grupos de segurança do AD** para gerenciar permissões no SQL Server.
* [ ] Monitore **eventos 4768, 4769, 4770** (Kerberos) no Controlador de Domínio.
* [ ] Remova **SPNs obsoletos** após descomissionar servidores.

### Manutenção

* [ ] Teste **renovação automática de senha** para gMSA.
* [ ] Documente **SPNs e contas de serviço**.
* [ ] Inclua a verificação de autenticação Kerberos em testes de conectividade periódicos.

### Script de Validação Rápida

```sql
-- Verificar método de autenticação das conexões ativas
SELECT 
    session_id,
    login_name,
    client_net_address,
    auth_scheme,
    net_transport,
    connect_time
FROM sys.dm_exec_connections
WHERE auth_scheme IS NOT NULL
ORDER BY connect_time DESC;
```

```powershell
# Verificar SPNs da conta de serviço
$serviceAccount = "dominio\gmsa-sql$"
setspn -L $serviceAccount

# Testar conexão Kerberos (PowerShell)
Test-ComputerSecureChannel -Repair
klist purge
# Em seguida, tente conectar ao SQL Server e execute klist novamente
```

***

## 📚 Referências

* [Microsoft Docs: Register a Service Principal Name for Kerberos Connections](https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections)
* [Microsoft Docs: Choose an Authentication Mode for SQL Server](https://learn.microsoft.com/en-us/sql/relational-databases/security/choose-an-authentication-mode)
* [Microsoft Docs: Group Managed Service Accounts Overview](https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview)
* [Microsoft Kerberos Configuration Manager for SQL Server](https://www.microsoft.com/en-us/download/details.aspx?id=39046)
* [setspn Command Reference](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc731241\(v=ws.11\))


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://0xmorte.gitbook.io/bibliadopentestbr/conceitos/ambientes/windows/mssql.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.