Olá, espero que você esteja bem! 😉
A configuração do Database mail nem sempre é algo trivial, pois possui vários fatores agregados fazendo com que algo simples se torne trabalhoso.
Escrevi um post recentemente sobre o tema, e nele abordo a configuração do Database Mail no Microsoft SQL Server Management Studio, desde o básico com a criação do Profile e depois a criação de uma conta (que no caso foi usado do GMAIL), abordando também a autenticação de 2 fatores.
Portanto dando continuação no tema, neste post vou abordar sobre os erros que encontro no meu dia a dia como DBA, de empresas que usam o SMTP do office, e precisamos atuar para resolver a falha no envio do e-mail.
Após a atualização da Microsoft (transição para o TLS 1.2), o Database-mail passou a apresentar várias falhas no envio.
Mensagem contendo motivo da falha:
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (2022-10-11T01:10:38). Exception Message: Cannot send mails to mail server. (Failure sending mail.). )
Sendo necessário algumas validações para detectar onde está desatualizado, e com base no resultado realizar algumas alterações, seguem:
- Foi feito alguma alteração recentemente no portal do office?
- A conta configurada no Database-mail do SSMS que está tendo problema no envio, funcionava normalmente e recentemente parou de enviar ou nunca enviou e-mail?
- Foi trocado alguma senha recentemente?
- Chegou a fazer algum teste se o envio está normal caso use esta mesma conta por outro aplicativo?
Antes de começar, vamos para um breve referencial teórico.
Por motivo de segurança, alguns serviços de envio de e-mail passaram a adotar o MFA (autenticação multifator). Mas afinal o que é isso?
“A MFA (autenticação multifator) adiciona uma camada de proteção ao processo de entrada. Os usuários fornecem uma verificação de identidade adicional ao acessar contas ou aplicativos, como a leitura de uma impressão digital ou a adição de um código recebido por telefone”.
Segue abaixo um link da Microsoft sobre como realizar esta configuração:
Outro ponto a ser validado é o SMTP AUTH.
O diagrama a seguir mostra uma visão geral conceitual de como funciona a submissão de clientes SMTP AUTH.
Features of SMTP AUTH client submission:
- SMTP AUTH client submission allows you to send email to people in your organization and outside your company.
- This method bypasses most spam checks for email sent to people in your organization. This bypass can help protect your company IP addresses from being blocked by a spam list.
- With this method, you can send email from any location or IP address, including your (on-premises) organization’s network, or a third-party cloud hosting service, like Microsoft Azure.
Para enviar e-mail de uma conta do office 365, configurada no Database mail, é preciso que o SMTP AUTH esteja habilitado no portal em Centro de administração do Microsoft 365.
Podendo ser feito via tela.
Ou via Exchange Online Powershell.
|
1 |
Set-CASMailbox -Identity <MailboxIdentity> -SmtpClientAuthenticationDisabled <$true | $false | $null> |
Sobre o Multi Fator de Autenticação (MFA), é necessário que para a conta usada no envio do e-mail, não pode estar habilitado essa configuração. Habilita nas demais contas, mas nesta que usará no SSMS tem que estar desabilitada.
Segue referência no site da Microsoft.
Configurar a autenticação multifator para usuários – Microsoft 365 admin | Microsoft Learn
Uma informação importante:
Após o STMP AUTH estar habilitado e o MFA estar desabilitado (para a conta de e-mail em questão), iremos então continuar.
Conforme dito no início deste post, vamos falar agora sobre a transição para o TLS 1.2, e explicar sobre as informações de configuração de registros suportadas para a implementação do Windows do protocolo TLS (Transport Layer Security, segurança da camada de transporte) através do Schannel Security Support Provider (SSP). Este novo padrão TLS 1.2 fornece melhorias de segurança em relação às versões anteriores.
Para habilitar o TLS 1.2 teremos alguns passos a seguir:
- Certificar que o TLS 1.2 esteja habilitado como um protocolo para o SCHANNEL no nível de sistema operacional;
- Atualizar/Configurar o .Net Framework para suportar o TLS 1.2;
Quais versões do Windows Server suportam o TLS 1.2?
O Windows Server 2008 R2 e versões posteriores suportam o TLS 1.2.
Segue também um link com referência de um KB relacionado ao assunto.
Teremos que fazer as seguintes alterações necessária no TLS (são necessárias para computadores Cliente e Servidor):
- criar um valor de registro DWORD chamado “Enabled” com um valor 1 e “DisabledByDefault” com um valor 0.
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS\1.2\Client]
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS\1.2\Server]
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001
Seguindo as orientações da Microsoft, para o .NET Framework 3.5 – 4.5.2 e não WCF recomenda-se atualizar para o .NET Framework 4.7 ou posterior. Caso não puder atualizar, atualize as chaves de registro do “SchUseStrongCrypto” e “SystemDefaultTlsVersions”.
O SchUseStrongCrypto ao ser configurado com um valor 1, fará com que seu aplicativo use criptografia forte e bloquei protocolos que não são seguros.
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SchUseStrongCrypto
Portanto para versões .NET Framework 4.6 ou posterior, essa chave já vem com valor padrão 1, e .NET Framework 4.5.2 ou anteriores, padrão 0. Esta chave só deve ter um valor 0 caso você precisar se conectar a serviços legados que não suportam criptografia forte e não podem ser atualizados.
SystemDefaultTlsVerções ao ser configurado com um valor 1, faz com que seu aplicativo permita que o sistema operacional escolha o protocolo. Se o valor estiver com 0, fará com que seu aplicativo use protocolos escolhidos pelo .NET.
HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SystemDefaultTlsVersions
Neste caso, se o aplicativo estiver na versão .NET Framework 4.7 ou posterior, o valor padrão será 1, e se a versão for .NET Framework 4.6.1 ou anteriores, a chave padrão será 0.
Portanto se resumirá com as seguinte configurações, seguindo os valores mais seguros conformes citados acima:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001
Vamos agora para a parte prática! 🙂
A configuração inicial no Database-mail vou pressupor que está tudo OK. Serviço de e-mail habilitado e startado.
Caso tenha dificuldade na configuração “inicial”, veja este meu outro post.
Portanto estando com a conta Office inserida e configurada (SMTP, PORTA, SSL) corretamente, vamos fazer um teste de envio.
O teste pode ser feito via T-SQL ou via SSMS via interface.
Basta ir em Mamagement / Database Mail / Send Test E-Mail...
Com o Profile setado basta colocar um e-mail que receberá o teste e clicar em “Send Test E-Mail“.
Clicar em “OK”.
Usaremos a query para validar o envio.
|
1 2 3 4 5 6 |
select top 50 sent_status, CASE sent_status WHEN 0 THEN 'Unsent' WHEN 1 THEN 'Sent' WHEN 2 THEN 'Failed' WHEN 3 THEN 'Retrying' END as sent_status_description, send_request_date, * from msdb.dbo.sysmail_mailitems order by 3 desc |
Envio falhou.
Vamos verificar a mensagem de erro com o motivo da falha.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
-- Verifica Motivo Falha Envio Email SELECT SEL.event_type, SEL.log_date, SEL.description, SF.mailitem_id, SF.recipients, SF.copy_recipients, SF.blind_copy_recipients, SF.subject, SF.body, SF.sent_status, SF.sent_date FROM msdb.dbo.sysmail_faileditems AS SF JOIN msdb.dbo.sysmail_event_log AS SEL ON SF.mailitem_id = SEL.mailitem_id order by log_date DESC |
Description:
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (2022-10-11T16:24:52). Exception Message: Cannot send mails to mail server. (Failure sending mail.). )
Portanto agora vamos coletar algumas configurações para em seguida fazer as alterações recomendadas conforme orientações da Microsoft a qual comentamos neste post.
SISTEMA OPERACIONAL.
VERSÃO DO .NETFRAMEWORK.
VERSÃO DO SQL.
CUIDADO!!!
A CONFIGURAÇÃO DAS CHAVES DE REGISTRO AFETA TODOS OS APLICATIVOS DO SISTEMA. USE ESTA OPÇÃO SOMENTE SE VOCÊ ESTIVER NO CONTROLE TOTAL DA MÁQUINA E PUDER CONTROLAR AS ALTERAÇÕES NO REGISTRO.
Portanto, antes de iniciar, é de suma importância fazer um backup dos registros atuais para caso tenhamos algum problema possamos então voltar as informações como estavam.
Vamos salvar 5 backups e darei os seguintes nomes:
– BKP_REG1_TLS
– BKP_REG2_NETFramework_v4
– BKP_REG3_NETFramework_v2
– BKP_REG4_WOW_NETFramework_v2
– BKP_REG5_WOW_NETFramework_v4
Com o comando regedit, vamos acessar o Registre Editor para iniciar os backups.
Arquivo 1)
CAMINHO:
Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Botão direito em “Protocols“ clique em “Export“.
Escolha um caminho para salvar o backup, dê um nome e clique em “Save”.
Faremos mesmos procedimentos para salvar (export) os outros registros.
Arquivo 2)
CAMINHO:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319
Arquivo 3)
CAMINHO:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727
Arquivo 4)
CAMINHO:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727
Arquivo 5)
CAMINHO:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
Vamos agora conferir a pasta com os backups feitos.
Iniciaremos as alterações conforme citadas acima.
Resumi em 5 passos para facilitar o entendimento:
PASSO 1)
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS\1.2\Client]
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS\1.2\Server]
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001
Vamos para a prática!?
Veja que seguindo o caminho que fizemos o backup, o registro Protocols não contém as chaves referentes ao TLS 1.2. Porém se no seu ambiente tiver as informações do TLS 1.0, mesmo assim será necessário fazer o mesmo procedimento a seguir, pois vamos adicionar o TLS 1.2 com as respectivas chaves.
Usaremos a seguinte “hierarquia”:
Protocols\TLS\1.2\Client
Protocols\TLS\1.2\Server
Botão direito em Protocols / New / Key e preencha com a palavra “TLS“
Feito.
Continuaremos a inserir Key, conforme “hierarquia” citada, bastando clicar com botão direito.
Conferindo como ficou.
Agora iremos inserir os DWORD.
“DisabledByDefault”=dword:00000000
“Enabled”=dword:00000001
Botão direito Client, depois New / DWORD (32-bit) Valuel.
Inserir “DisabledByDefault” e “Enabled”.
Ao inserir, o valor default é zero, porém temos que alterar o “Enabled” para 1.
Para isso basta dar duplo clique, alterar o “Value data” para 1 e clicar em “OK“.
Repetiremos os mesmos procedimentos para a chave “Server“.
PASSO 2)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001
Vamos continuar com a mesma lógica, seguir o caminho acima e inserir os “DWORD (32-bit) Value” e depois dar duplo clique para passar o “Value” para 1.
Após as alterações, ficará dessa maneira:
PASSO 3)
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001
Mesma coisa, daí como sei que você já está fera nos procedimentos, vou então apenas postar o print de como ficará.
PASSO 4)
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001
PASSO 5)
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
“SystemDefaultTlsVersions”=dword:00000001
“SchUseStrongCrypto”=dword:00000001
Pronto, feito, basta fechar o Registry Editor.
Temos que dar um STOP no serviço de envio de e-mail e em seguida START.
Usaremos os seguintes scripts:
|
1 2 3 4 5 |
use msdb exec dbo.sysmail_stop_sp exec dbo.sysmail_start_sp |
E agora, será que deu certo?
Hora da verdade…
Faremos novo teste de envio.
Obaaaaaaa, deu certo!!!!!
Mas ainda não acabou o Post, que tal aquele Bônus que sempre deixo no final para quem resistiu até o fim!?! 😉
Vou facilitar um pouco na resolução deste problema!
Digamos que ensinei você a pescar, pois é essencial aprender do zero e conhecer o porquê de cada configuração realizada. Agora vou entregar o “peixe já pescado”. rsrs.
Bora?
Como terminamos tudo, vou fazer um backup de todas as Key criadas e salvar seguindo aquele raciocínio com aqueles 5 arquivos, levando em consideração o mesmo caminho para salvar os backups, apenas vou renomear com as iniciais diferentes para não confundir.
– REG1_TLS
– REG2_NETFramework_v4
– REG3_NETFramework_v2
– REG4_WOW_NETFramework_v2
– REG5_WOW_NETFramework_v4
Irei mostrar apenas o primeiro backup (darei o nome de REG1_TLS) para relembrar, sendo os demais na mesma ideia.
Portanto repetindo o procedimento, basta clicar com o botão direito em “Protocols” e depois em “Export“.
Veja que as Key que criamos estão inseridas dentro de Protocols, portanto este que faremos o backup.
Pronto, todos os backups foram feitos e salvos em uma pasta onde irei compartilhar com uma outra VM criada para o Lab.
Para comprovar os comandos realizados e salvos nos arquivos, basta abrir eles como “Bloco de notas” e verá exatamente o que foi feito.
Veja no “REG1_TLS”, mostra a “hierarquia” que usamos e as Key inseridas.
Acessando agora uma outra VM, que coincidentemente possui as mesmas configurações da primeira (versão do Windows, SQL Server, .NetFramework).
OBS: Porém não necessariamente precisa ter as mesmas versões, pois conforme orientações da Microsoft, para várias versões diferentes citadas no início deste post, o procedimento é o mesmo.
Conferindo a conta de e-mail do office 365 desta nova VM.
Faremos um teste de envio dessa vez via script.
|
1 2 3 4 5 6 7 8 |
-- TESTE ENVIO DE EMAIL EXEC msdb.dbo.sp_send_dbmail @profile_name = 'MSSQLServer', @recipients = 'contato@ederlelis.com.br', @subject = 'ASSUNTO: Teste envio de e-mail' , @body = 'VM Lab2' , @body_format = 'HTML' |
Ao validar, comprovamos falha no envio.
Mensagem de erro:
The mail could not be sent to the recipients because of the mail server failure. (Sending Mail using Account 1 (2022-10-12T02:24:22). Exception Message: Cannot send mails to mail server. (Failure sending mail.). )
Conferindo o Registre Editor.
Teremos que realizar todas as configurações necessária inserindo as Key e DWORD.
Exemplo: Protocols não constas a Key “TLS\1.2\Client” e “”TLS\1.2\Server”.
Agora vem a parte boa, lembra dos arquivos de registros que fizemos backups e compartilhamos?
SEGUE LINK CASO QUEIRAM FAZER DOWNLOAD, BASTA CLICAR AQUI.
Vamos dar “enter” em cada um e clicar em “Run“.
“YES”.
Sucesso!
Repetiremos o mesmo processo nos demais arquivos.
Vamos agora conferir pelo menos um deles?
Veja que foram inseridas as informações corretas.
Uau, será que vai dar certo?! Foi tudo tão rápido nesta VM! 😉
Agora o teste final, enviar novamente um e-mail.
Antes do envio do e-mail, vamos fazer um STOP e START no serviço.
|
1 2 3 4 5 |
use msdb exec dbo.sysmail_stop_sp exec dbo.sysmail_start_sp |
Em seguida executar o script com o teste de envio.
Veja que maravilha, e-mail enviado com sucesso. Nessa VM tivemos apenas uma falha e conseguimos resolver o problema com pouco mais de 20min (incluído tempo para pegar os prints e escrever o trecho do post pra você).
Depois de bastante testes em labs e resolução em case, resolvi detalhar o máximo possível para compartilhar com você. Me preocupando de não ficar muito grande o Post, porém tive que fazer uma breve introdução com os referenciais teóricos.
Obrigado novamente e espero que tenha contribuído alguma coisa para o seu aprendizado. 😉
Quaisquer dúvidas, sugestões, podem mandar mensagens, escrever nos comentários…
Seguem alguns links com referências usadas para escrever este post.
- https://www.microsoft.com/pt-br/security/business/identity-access/azure-active-directory-mfa-multi-factor-authentication
- https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/how-to-set-up-a-multifunction-device-or-application-to-send-email-using-microsoft-365-or-office-365?source=recommendations
- https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12
- https://support.microsoft.com/pt-br/topic/kb3135244-suporte-para-tls-1-2-para-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe
- https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#configuring-schannel-protocols-in-the-windows-registry
- https://learn.microsoft.com/en-us/mem/configmgr/core/plan-design/security/enable-tls-1-2-server
- https://learn.microsoft.com/en-us/dotnet/framework/network-programming/tls#the-sch_use_strong_crypto-flag
