Criptografando a comunicação do SQL Server com SSL

Para aqueles que ficaram meio que ‘sem chão’ quando viram que com um Sniffer é possível obter informações dos dados que transitam entre as aplicações clientes e SQL Server na rede (ver artigo sobre sniffer no SQL Server), vou apresentar a solução.

A solução que trabalharemos é semelhante à utilização do SSL para comunicação HTTP (HTTPS), mas sobre o protocolo TDS.

Com o SDK da .NET Framework, criaremos um certificado por meio do makecert via prompt de comando:

#Caso estiver com um Windows x64:
cd C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin

#Caso estiver com um Windows x86:
cd C:\Program Files\Microsoft SDKs\Windows\v7.0A\Bin

#Criando o certificado:
makecert -r -pe -n "CN=NomeDoComputador" -b 01/01/2000 -e 01/01/2036 -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localMachine -sky exchange -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12

Abrimos o Microsoft Management Console (mmc):

Em “File\Add or Remove Snap-ins…”, adicionamos o Snap-in de certificados:

Informamos que gerenciaremos os certificados da conta do computador:

E no caminho “Personal\Certificates”, encontramos o certificado que acabamos de criar:

Por fim, copiamos o certificado para o caminho “Trusted Root Certification Authorities\Certificates”:

Em seguida, pelo SQL Server Configuration Manager (SSCM), acessamos as propriedades da configuração de rede da nossa instância do SQL Server:

Exigimos que a comunicação entre os clientes e o SQL Server seja criptografada:

E selecionamos o nosso certificado:

Depois de reiniciarmos o SQL Server, com o Microsoft Network Monitor 3.4, onde anteriormente tínhamos a comunicação pelo protocolo TDS, agora teremos somente comunicação criptografada TLS:

Referências:

Configuring Certificate for Use by SSL
http://msdn.microsoft.com/en-us/library/ms186362.aspx

Um sniffer na comunicação do SQL Server

Em qualquer cenário onde há comunicação remota do SQL Server com outros computadores, se torna fácil identificar os dados que são trafegados na rede utilizando um sniffer, principalmente quando não há muita dificuldade em uma máquina entrar na rede onde esta o SQL Server.

Para mostrar que a comunicação entre máquinas clientes e o SQL Server não é muito segura se não há utilização de criptografia, utilizarei o Microsoft Network Monitor 3.4 com um parse específico para obter informações do SQL Server, mostrando os dados trafegando pela rede.

Iniciando o Network Monitor, criaremos uma nova aba de capturada (New capture tab):

Definindo em ‘Tools\Options’ o parse do SQL Server:

Iniciaremos a captura e executando algumas consultas em um SQL Server, já teremos informações para analisar:

Basicamente teremos informações sobre qual protocolo utilizando (TCP, TDS…), qual a ação realizada (SQLBatch, Response, Flags, Prelogin…) e o SPID da conexão (ex.: 52):

Como exemplo de um TDS:SQLBatch, no qual executei o comando “SELECT name FROM sys.tables” no SQL Server Management Studio (SSMS), será fácil encontrar o comando nos detalhes da comunicação:

E um TDS:Response, no qual tive o seguinte retorno no SSMS:

E no Network Monitor, também é possível visualizar os dados trafegados:

Fiquem tranquilos, próxima semana publico a solução para este cenário! (ver artigo sobre SSL no SQL Server)

Programas utilizados:

Microsoft Network Monitor 3.4
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=en

Network Monitor Open Source Parsers (NetworkMonitor Parsers forSQLServer)
http://nmparsers.codeplex.com/releases/view/64054

Utilizando certificados para autenticação entre bancos de dados no SQL Server

Uma alternativa mais saudável para cenários onde é necessário executar stored procedures, funções, triggers e assemblies que requerem utilizar objetos de outros bancos de dados, é a utilização de certificados, ao invés da já conhecida configuração de Cross DB Ownership Chaining.

A desvantagem dos certificados se dá a complexidade na utilização dos mesmos, mas com a demonstração a seguir, acredito que vocês terão poucas dúvidas.

Para o início da demonstração, temos dois bancos de dados com Cross DB Ownership Chaining desabilitado (configuração padrão em muitos cenários), onde teremos uma stored procedure em um banco tentando acessar uma tabela de outro.

-- Criando os bancos de dados
CREATE DATABASE DB01;

ALTER DATABASE DB01 SET DB_CHAINING OFF;

CREATE DATABASE DB02;

ALTER DATABASE DB02 SET DB_CHAINING OFF;
GO

-- Criando a tabela
USE DB01;
GO
CREATE TABLE SuperTabela (Id INT);
GO

-- Criando a stored procedure
USE DB02;
GO
CREATE PROC SuperProc AS
	SELECT * FROM DB01.dbo.SuperTabela
	WHERE ID > 10;
GO

A nossa usuária Maria somente terá acesso á stored procedure, mas não a tabela, logo numa tentativa de utilizar o usuário dela para executar a stored procecure teremos um erro por falta de permissão:

-- Criando a usuária Maria
USE [master];
GO
CREATE LOGIN Maria WITH PASSWORD = '9455w0rd';
GO

USE DB02;
GO
CREATE USER Maria FOR LOGIN Maria;
GO

-- Permitindo o acesso à stored procedure
USE DB02;
GO
GRANT EXEC ON dbo.SuperProc TO Maria;
GO

-- Executando a stored procedure
USE DB02;
GO
EXECUTE AS LOGIN = 'Maria';
GO
EXEC dbo.SuperProc;
GO
REVERT;
GO

Msg 916, Level 14, State 1, Procedure SuperProc, Line 2
The server principal “Maria” is not able to access the database “DB01″ under the current security context.
Ah “Maria” sua n00b!!

Agora para resolver a questão da permissão, criaremos um certificado no banco de dados onde esta a tabela que precisamos de acesso, e permitimos acesso a esta tabela por meio de um usuário criado a partir deste certificado:

USE DB01;
GO

-- Criando o certificado
CREATE CERTIFICATE CERT_DB01
	ENCRYPTION BY PASSWORD = '5up3r53nh4'
	WITH SUBJECT = 'CERT_DB01';

-- Criando um usuário a partir do certificado
CREATE USER USU_CERT_DB01
	FOR CERTIFICATE CERT_DB01;

-- Permitindo acesso do usuário à tabela
GRANT SELECT ON dbo.SuperTabela
	TO USU_CERT_DB01;

Salvamos o certificado para o movimentarmos para o outro banco de dados:

-- Salvando o certificado para movimentar para o outro banco de dados
BACKUP CERTIFICATE CERT_DB01
	TO FILE = 'C:\Projetos\CERT_DB01.cer'
	WITH PRIVATE KEY (
		DECRYPTION BY PASSWORD = '5up3r53nh4',
		FILE = 'C:\Projetos\CERT_DB01.pvk',
		ENCRYPTION BY PASSWORD = '5up3r53nh4-01'
	);

-- Apagando a chave privada do certificado
ALTER CERTIFICATE CERT_DB01
	REMOVE PRIVATE KEY;
GO

Restauramos o certificado onde esta a stored procedure, e assinamos a stored procedure com o certificado:

USE DB02;
GO

-- Restaurando o ceritificado no banco de dados
CREATE CERTIFICATE CERT_DB01
	FROM FILE = 'C:\Projetos\CERT_DB01.cer'
	WITH PRIVATE KEY (
		DECRYPTION BY PASSWORD = '5up3r53nh4-01',
		FILE = 'C:\Projetos\CERT_DB01.pvk',
		ENCRYPTION BY PASSWORD = '5up3r53nh4'
	);
GO

-- Assinando a stored procedure com o certificado
ADD SIGNATURE TO dbo.SuperProc
	BY CERTIFICATE CERT_DB01
	WITH PASSWORD = '5up3r53nh4';
GO

Agora podemos executar a stored procedure com o usuário da Maria sem problemas:

-- Executando a stored procedure
USE DB02;
GO
EXECUTE AS LOGIN = 'Maria';
GO
EXEC dbo.SuperProc;
GO
REVERT;
GO

Por fim, finalizamos o cenário:

-- Finalizando o cenário
USE [master];

DROP DATABASE DB01;

DROP DATABASE DB02;

DROP LOGIN Maria;
GO

Cross DB Ownership Chaining

Uma solução muito comum para situações onde temos um usuário que precisa executar uma procedure ou VIEW que relaciona dados de outro banco de dados, mas este usuário não deve ter acesso direto a este outro banco de dados, é utilizar a opção de Cross DB Ownership Chaining (SQL Server 2005+).

Como exemplo desta funcionalidade, vamos criar no primeiro banco de dados, uma tabela e no segundo banco de dados, uma VIEW que retorna os valores desta tabela do primeiro banco dados:

USE DB01
GO
CREATE TABLE SuperTabela (Id INT)
GO

USE DB02
GO
CREATE VIEW SuperVisao AS
SELECT * FROM DB01.dbo.SuperTabela
WHERE ID > 10
GO

Vamos criar um LOGIN para a Maria e um USER em cada um dos bancos de dados do nosso cenário:

USE [master]
GO
CREATE LOGIN Maria WITH PASSWORD = '9455w0rd'
GO

USE DB01
GO
CREATE USER Maria FOR LOGIN Maria
GO

USE DB02
GO
CREATE USER Maria FOR LOGIN Maria
GO

Em seguida, damos permissão de SELECT na VIEW que criamos ao usuário da Maria:

USE DB02
GO
GRANT SELECT ON dbo.SuperVisao TO Maria
GO

Sem Cross DB Ownership Chaining

Com o Cross DB Ownership Chaining desabilitado nos bancos de dados, primeiramente testamos se ela não tem acesso diretamente à tabela (acesso negado):

-- Desabilitando o Cross DB Ownership Chaining
USE [master]
GO
ALTER DATABASE DB01 SET DB_CHAINING OFF
GO
ALTER DATABASE DB02 SET DB_CHAINING OFF
GO

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperTabela
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

E testamos o acesso dela na View e teremos como retorno que ela não tem acesso a tabela:

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperVisao
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

Com Cross DB Ownership Chaining

Habilitamos o Cross DB Ownership Chaining, e testamos o acesso dela à tabela (acesso negado):

-- Habilitando o Cross DB Ownership Chaining
USE [master]
GO
ALTER DATABASE DB01 SET DB_CHAINING OFF
GO
ALTER DATABASE DB02 SET DB_CHAINING OFF
GO

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperTabela
GO
REVERT
GO

Msg 229, Level 14, State 5, Line 1
The SELECT permission was denied on the object ‘SuperTabela’, database ‘DB01′, schema ‘dbo’.

Agora, testamos o acesso á VIEW, e ela terá o acesso sem problemas:

USE DB02
GO
EXECUTE AS LOGIN = 'Maria';
GO
SELECT * FROM SuperVisao
GO
REVERT
GO

Id
———–
(0 row(s) affected)

Caso você dar o acesso da Maria á tabela do primeiro banco de dados, não será necessário utilizar a opção “Cross DB Ownership Chaining”.

Também é possível habilitar esta opção em todo o servidor com o seguinte comando:

sp_configure 'cross db ownership chaining', 1
GO
RECONFIGURE
GO

Referências:
http://msdn.microsoft.com/en-us/library/ms188694.aspx

Ocultando a instância do SQL Server

Nestes dias, me questionaram “como esconder as instâncias do SQL Server” numa rede, mas ainda possibilitando se conectar a elas (mais ou menos igual aos cenários de rede wireless, onde escondem o SSID, nome da rede, para “tentar” evitar invasões), pois o cenário que me foi apresentado, só mudar as portas de conexão do SQL Server não faria o que eles desejavam.

Vamos ao nosso cenário, precisamos esconder uma das instâncias do SQL Server que estão facilmente visíveis para toda rede.

Para isso, precisaremos do “SQL Server Configuration Manager”:

Nas configurações de rede do SQL Server, vamos às propriedades dos protocolos da instância que desejamos “ocultar”:

Alteremos a propriedade “Hide Instance” para “Yes” e em seguida reiniciamos o SQL Server.

Para validar, vamos ao Browser for Servers do SQL Server Management Studio… e onde esta aquela instância?

Pronto! De forma rápida resolvemos este “mini” cenário, fique tranquilo pois ainda é possível se conectar à instância que foi ocultada.

Se alguém esta em um cenário onde existe criptografia em todas conexões com o SQL Server, portas padrões do SQL Server alteradas, instâncias escondidas, autenticação somente por Windows Authentication, bloqueios de MAC e IP, dentre outras estratégias de segurança físicas e/ou lógicas, pode ficar tranquilo, neste mundo há cenários que isso é somente o básico do básico.

Existem vulnerabilidades no seu SGBD?

Para avaliar um software na perspectiva de segurança e vulnerabilidades, temos um site de bastante credibilidade para obter informação nesta prespectiva, o Secunia.com, que possui uma relação de milhares de softwares e quantitativos de vulnerabilidades.

Abaixo alguns SGBDs comuns relacionados por este site:

IBM DB2 9.x
http://secunia.com/advisories/product/13504/

Oracle 11.x
http://secunia.com/advisories/product/18050/

Microsoft SQL Server 2008
http://secunia.com/advisories/product/21744/

MySQL 5.x
http://secunia.com/advisories/product/8355/

PostgreSQL 8.x
http://secunia.com/advisories/product/4587/

E um menos comum, mas que eu já tive oportunidade de trabalhar:

Caché 5.x
http://secunia.com/advisories/product/1808/

Usuários órfãos no SQL Server? Evite este problema!

Depois de um bom tempo tentando resolver problemas de usuários órfãos após backups, migração de bancos, log shipping, mirroring e outras ocorrências, pude verificar em diversos blogs e artigos na internet algumas formas de resolver este problema, mas não vi formas de evitar que ele aconteça… O que me deixou impressionado, pois o problema é bem mais simples do que parece (depois que você descobre como funciona, realmente parece simples).

Um exemplo comum de usuário órfão:

Solução para o problema:

Para quem chegou a este artigo procurando solucionar um problema de usuários órfãos, você possui várias alternativas:

No SQL Server 2000 e SQL Server 2005:

-- Associando a um login existente:
EXEC sp_change_users_login 'Update_One', 'nome do usuário', 'nome do login'

 

--Associando a um login existente com o mesmo nome do usuário,
--Ou se não existir login com o mesmo nome do usuário, criar um com a senha informada:
EXEC sp_change_users_login 'Auto_Fix', 'nome do usuário', NULL, 'senha'

(ref.: http://msdn.microsoft.com/pt-br/library/ms175475.aspx)

A partir do SQL Server 2005 e SQL Server 2008:

-- Associando a um login existente:
ALTER USER [nome do usuario] WITH LOGIN = [nome do login] 

(ref.: http://msdn.microsoft.com/en-us/library/ms176060.aspx)

Agora vamos saber por que isso ocorre:

Os usuários do banco de dados são associados a um código de segurança (SID) dos logins da instância do banco de dados, mas como este SID pode ser aleatório na criação dos logins, o fato de você possuir um login com mesmo nome em duas instâncias do SQL Server distintas, não quer dizer eles são iguais, pois quando o SQL Server tenta restaurar um banco de dados de outra instância, ele só consegue identificar os logins “pais” de seus usuários pelo SID.

Mas se eu forçar um SID para o meu login nas instâncias do SQL Server, será que ainda vou ter o problema? Então vamos conferir:

Utilizei a seguinte consulta para recuperar o SID de um determinado login:

SELECT name, sid FROM sys.server_principals WHERE type = 'S'

Em outro SQL Server, vou criar um login com mesmo SID:

CREATE LOGIN paulo
WITH PASSWORD = 'p@$$w0rd',
SID = 0x0F5AE6C15103B647A7BD41F744C256F3

Após restaurar o banco de dados neste outro servidor, como resultado, sem usuário órfão!

E se você tiver um login com nome diferente do login da outra instância, mas com um mesmo SID, o SQL Server ainda utilizará o SID como critério para associar os usuários aos seus respectivos logins, exemplo:

Então, criar logins com SIDs iguais entre instâncias do SQL Server, evitará que problemas de usuários órfãos ocorram novamente, seja por backups, migração de bancos, log shipping e mirroring! A partir de agora, só diversão!

Habilitando a conexão remota no SQL Server 2008

E ai pessoas, como tenho recebido alguns e-mails pedindo para mostrar “como fazer para que outros computadores acessem o meu banco de dados” e “habilitar o acesso remoto do SQL Server 2008”, então vamos à demonstração!

Antes de começar, se o servidor estiver fora de um “domínio” ou você não saiba o que é “domínio”, dê uma olhada neste artigo:
http://sqlfromhell.wordpress.com/2009/05/24/habilitando-sql-authentication-e-o-usuario-sa/

Em seguida, habilitamos o Firewall do Windows (permitindo exceções). Mas para ambientes de teste não há problema em deixá-lo desabilitado.

Dentre as diversas exceções, adicionamos mais uma porta:

Para boa parte dos cenários, a porta TCP 1433 já vai suprir as necessidades:

Em outros cenários mais específicos, pode existir a necessidade de habilitar as portas UPD 1434, TCP 1434 e outras (at. http://msdn.microsoft.com/en-us/library/ms175483.aspx ).

No SQL Server Management Studio, verifique se nas propriedades do servidor esta habilitada a opção “Allow remote connections to this server”. Caso não esteja habilitada, será necessário habilitá-la.

No SQL Server Configuration Manager, mais precisamente nos protocolos da sua instância (ex.: SQLEXPRESS, SQL2005, MSSQLSERVER…), entre nas propriedades do protocolo TCP/IP:

E habilite o protocolo TCP/IP. Em alguns cenários também se faz necessário habilitar o protocolo “Named Pipes”.

E recomendo definir a porta de conexão:

Se você quiser configurar outras portas para o SQL Server, dê uma olhada neste artigo:
http://sqlfromhell.wordpress.com/2009/09/05/portas-sql-server/

Reinicie o serviço do SQL Server da sua instância e o SQL Server Browser, depois em uma máquina cliente, tente se conectar ao servidor com um usuário válido:

Se tudo ocorrer como previsto, teremos a conexão:

Bem, estou usando uma VM “zerada” que até o momento tem o Windows Server 2003 R2 e o SQL Server 2008, assim existe grande possibilidade de não funcionar em outros cenários.

Pontos a levar em consideração para tratar outros cenários:

• Se você não conseguir ao menos dar um “ping” ou compartilhar uma pasta do servidor à rede ou conectar remoto com o Remote Desktop Connection (mstsc.exe), isso pode ser sinal que tem algo errado com o firewall ou a rede ou até mesmo com o Windows (então não é culpa do SQL Server, ainda…).
• Programas de Antivírus ou Firewall de terceiros, também são grandes culpados por problemas com o acesso remoto, tanto no servidor como no cliente.
• O usuário que você esta utilizando para se conectar pode não ter permissão para se conectar ou o servidor não esta no domínio (at. http://sqlfromhell.wordpress.com/2009/05/24/habilitando-sql-authentication-e-o-usuario-sa/ ). Para “testar”, no servidor tente se conectar ao SQL Server com o usuário que você esta utilizando na máquina cliente.
• Para “testar”, não utilize o SQL Server Management Studio 2005 para se conectar a um SQL Server 2008, pois algumas vezes isso não dá muito certo.

Mais uma coisa, se eu não responder um comentário em 24h é sinal que não estou com acesso à internet, pois possivelmente estarei preso na ilha de LOST (probabilidade 0,001%) ou estou numa “missão” extraordinária pelo Exército Brasileiro (probabilidade 4%) ou estou apagando algum incêndio em alguma consultoria (probabilidade 85%) ou dedicado a algum trabalho acadêmico (probabilidade 10%), então também vale a pena procurar os fóruns do MSDN e/ou o suporte da Microsoft.

Na internet, encontrei outros dois artigos bons sobre o assunto:

Instalando e Configurando o SQL Server 2005 Express – Nilton Pinheiro:
http://www.mcdbabrasil.com.br/downloads/install_sqlexpress.pdf

Como configurar Conexão Remota no SQL Server 2005 – Diego Nogare:
http://www.linhadecodigo.com.br/artigo/1260/como-configurar-conexao-remota-no-sql-server-2005.aspx

Alterando as portas de conexão do SQL Server

Como muitos já sabem, o SQL Server por padrão usa da porta 1433 (TCP) para se conectar por meio do protocolo TCP/IP. Mesmo que esta porta seja registrada para este fim em um órgão regulador, o Internet Assigned Numbers Authority, é possível alterar para utilizar outras portas se for necessário.

Antes de tudo, não recomendo esta alteração, principalmente por causar muito desconforto aos já acostumados com trabalhar da forma convencional e porque algumas ferramentas de terceiros não suportam o SQL Server com esta alteração. Na verdade, conheço alguns softwares muito bons que não suportam nem mesmo instâncias nomeadas como .\SQLEXPRESS e .\SQL2005.

Mas, voltando ao objetivo do post…

Primeiro, execute o “SQL Server Configuration Manager”, que se encontra normalmente no menu “Iniciar\Programas\Microsoft SQL Server 200X\Configuration Tools”.

Obs.: Para esta demonstração estou utilizando um Windows 2008 Server x64, então não se surpreendam com o número de opções que venham a aparecer, mas para esta demonstração não utilizarei nada que não seja possível em um Windows 2003, XP, Vista ou Seven, até mesmo porque estou optando por alterar uma instancia do SQL Server Express.

No menu laterial, expanda a opção “SQL Server Network Configuration” e clique sobre o item “Protocols for XXX” (XXX será o nome da instancia que você estará trabalhando, no meu caso SQLEXPRESS) e de um duplo clique em TCP/IP.

Se preocupe em verificar se as propriedades Enabled e Listen All desta primeira aba estão dispostas da seguinte forma:

Na segunda aba, inicialmente evite se preocupar com as várias propriedades existentes. Se atente ao grupo de propriedades IPAll e determine a porta TCP que você deseja configurar, no meu caso “666”:

Após clicar no botão OK, você receberá o aviso que para as configurações tenham efeito será necessário reiniciar o serviço do SQL Server.

Então, voltando para o menu lateral “SQL Server Services”, selecione o serviço do SQL Server que você acabou de configura e clique no botão “Restart Service”.

Pronto, agora é só testar…

Como assim, não sabe onde configurar a porta TCP no seu SQL Server Management Studio???

Fica tranqüilo! No campo “Server Name”, escreva conforme a sintaxe:
“EndereçoDoServidor\NomeDaInstancia, PortaConfigurada”

Pronto, agora você tem um SQL Server configurado na “porta errada”. Boa sorte e tomara que nenhum desenvolvedor irado queira te matar depois de você realizar esta alteração!

Até o próximo tópico!

Habilitando SQL Authentication e o usuário “sa”

Um problema comum quando se utiliza o SQL Server é quando não é possível entrar com usuários SQL Server, exemplo o super usuário “sa”, pois durante a instalação foi configurado para Windows Authentication.

Como mencionado em um post no Fórum do MSDN: “Criei a instância, criei senha para meu login, mais quando vou entrar pela autenticação do SQL SERVER, ele dá erro, já pela da autenticação do Windows ele dá certo…”

Visto que não é possível ficar reinstalando o SQL Server, somente para trocar a autenticação de Windows Authentication para “Mixed” Authentication, segue neste post a solução para este problema.

Primeiramente é necessário entrar no SQL Server utilizando o SQL Server Management Studio. Conforme a figura abaixo, estou conectando em uma instância do SQL Server 2008 Express utilizando a autenticação Windows Authentication, mas este exemplo funciona perfeitamente no SQL Server 2005 e nas edições superiores.

 

Após conectar, clicando com o botão direito do mouse sobre a instância do SQL Server na janela Object Explorer (Atalho F8 ou Menu “View\Object Explorer”), item Properties.

 

Nesta nova janela, na aba (“página”) Security, altere “Server authentication” para “SQL Server and Windows Authentication mode”.

 

Feito isso, uma janelinha informará que para esta alteração ter efeito, será necessário que o serviço do SQL Server deve ser reiniciado. Mas isso pode ser feito depois, quando for terminada a configuração dos usuários do SQL Server, então deixe para depois.

 

Continuando na janela Object Explorer, expandindo a instância, “folder” Security\Logins, pode ser criado novos usuários do SQL Server ou seguindo o objetivo inicial deste tópico, habilitar o usuário “sa”. Conforme a figura abaixo, botão direito sobre o login “sa”, menu Properties.

 

Na nova janela, altere o password do usuário, também é possível alterar o “idioma” e o banco de dados padrão deste usuário nesta janela, entre outras funcionalidades.

 

Na aba (“página”) Status, clique na opção “Grant” em “Permission to connect to database engine” e “Enable” em “Login”.

 

Outra maneira pratica de habilitar o usuário “sa” é por meio de script, exemplo:

ALTER LOGIN sa ENABLE;
GO
ALTER LOGIN sa WITH PASSWORD = 'P@ssw0rdM0del0';
GO 

Então, agora resta reiniciar o SQL Server. Para não ter que entrar nos Serviços do Windows ou SQL Server Configuration Manager ou qualquer variante como arquivos .bat ou SQL Server Surface Area.

Uma dica é clicar com o botão direito na instância do SQL Server na janela Object Explorer e “Restart”.

 

Clique em Yes nesta próxima janelinha, para dizer que você TEM CERTEZA QUE QUER REINICIAR O SERVIÇO…

 

Agora é só conectar com o usuário “sa” para testar.

 

Até o próximo post!