Le Blog SQL Server d'ElSüket » Sécurité

Reprendre le contrôle d’une instance SQL Server lorsqu’on a perdu le mot de passe de la connexion sa ou lorsque tous les DBAs en ont perdu l’accès

elsuket — Fri, 31 May 2013 00:36:28 +0000

Comment faire lorsqu’on a perdu le mot de passe de la connexion sa pour se connecter à l’instance ?
Ou comment est-il possible de prendre le contrôle d’une instance SQL Server installée par une personne avec son propre compte, et qui a quitté l’entreprise depuis une durée plus grande que celle de l’expiration des mots de passe ?

Il est pour cela nécessaire d’avoir accès à la machine avec un compte d’administrateur local : en effet dans ce cas, le démarrage en mode mono-utilisateur d’une instance de SQL Server autorise l’accès à un tel compte. Cela permet donc de créer une nouvelle connexion, à laquelle on octroie le privilège et sésame d’appartenance au rôle fixe de serveur sysadmin.

Voyons tout d’abord quelles sont les connexions qui disposent du privilège d’appartenance au rôle sysadmin. La requête suivante liste l’ensemble des connexions inscrites aux rôles d’instance :

1
2
3
4
5
6
7
8

SELECT SPR.name AS server_role_name
, SPM.name AS server_role_member_name
, SPR.type_desc
FROM sys.server_role_members AS SRM
INNER JOIN sys.server_principals AS SPR
ON SRM.role_principal_id = SPR.principal_id
INNER JOIN sys.server_principals AS SPM
ON SRM.member_principal_id = SPM.principal_id

La connexion ELSUKET8\Nicolas est celle d’administrateur local de mon PC : je la supprime :

1	DROP LOGIN [ELSUKET8\Nicolas]

A l’ouverture d’une nouvelle fenêtre de requête, nous obtenons bien l’erreur :

Rendons-nous maintenant dans le gestionnaire de configuration de SQL Server. Si l’instance est sous SQL Server 2012 et que l’on souhaite ouvrir cette console à partir d’une fenêtre de ligne de commandes, il faudra saisir SQLServerManager11.msc. Une fois la console ouverte, on peut double-cliquer sur SQL Server Services dans l’un des deux panneaux, et on obtient la liste des services SQL Server installés :

Un clic-droit sur le service SQL Server nous permet d’accéder, en outre, aux paramètres de démarrage du service. Sous SQL Server 2005 et 2008, ils se trouvent dans l’onglet Avancé, mais sous SQL Server 2012, l’onglet Paramètres de démarrage a fait son apparition :

Nous ajoutons ici le paramètre l’option -m, qui permet de démarrer une instance en mode mono-utilisateur. Sous SQL Server 2005 et 2008, dans l’onglet Avancé, il est nécessaire de placer le curseur à la fin de la chaîne du paramètre Paramètres de démarrage, et d’ajouter ;-m après la fin de cette chaîne. Une fois fait, nous sommes avertis qu’il est évidemment nécessaire de redémarrer le service :

On peut redémarrer le service toujours à partir de la même console, par un clic-droit sur le service. Une fois fait, nous démarrons SQL Server Management Studio (SSMS) en tant qu’administrateur. Cette option est accessible par un simple clic-droit sur le raccourci. Attention : comme nous sommes en mode mono-utilisateur, il n’est pas possible d’ouvrir une connexion pour l’explorateur d’objets. Donc si l’on ne ferme pas la connexion de ce dernier (par clic-droit sur le nom de l’instance dans celui-ci), il est impossible d’ouvrir une fenêtre de requête.

Nous nous octroyons maintenant le droit de connexion et d’appartenance au rôle de serveur sysadmin :

1
2
3
4
5
6
7
8
9

CREATE LOGIN [ELSUKET8\ElSuket]
FROM WINDOWS
GO

-- SQL Server 2012
ALTER SERVER ROLE sysadmin ADD MEMBER [ELSUKET8\ElSuket]

-- SQL Server 2000, 2005 et 2008
EXEC sp_addsrvrolemember 'ELSUKET8\ElSuket', 'sysadmin'

Nous devons maintenant retourner dans la console de configuration des services de SQL Server, retirer le paramètre -m, et redémarrer à nouveau le service, de sorte que l’instance soit de nouveau accessible par plusieurs connexions. Une fois fait, on peut démarrer SSMS normalement (i.e. pas en tant qu’administrateur), et nous pouvons de nouveau accéder à l’instance SQL Server :

Changer le mot de passe de la connexion sa

Cela se fait de la même façon, en suivant les étapes suivantes :

1. Ajouter le paramètre -m aux paramètres de démarrage du service SQL Server, puis redémarrer le service;
2. Se connecter à l’instance SQL Server avec SSMS en tant qu’administrateur;
3. Changer le mot de passe de la connexion sa avec l’instruction suivante :

1	ALTER LOGIN sa WITH PASSWORD = 'unMotDePasseRobuste'

4. Supprimer le paramètre -m des paramètres de démarrage du service SQL Server, puis redémarrer le service une nouvelle fois;
5. Se connecter normalement avec SSMS, le nom de connexion sa et le nouveau mot de passe.

Effectuer ces mêmes opérations en ligne de commande avec l’utilitaire SQLCMD

Il est pour cela nécessaire d’ouvrir un fenêtre de lignes de commande en tant qu’administrateur. On peut tout simplement créer une raccourci qui pointe sur cmd, puis par clic-droit sur celui-ci, choisir de mode :

Une fois fait, on démarre l’utilitaire en lignes de commande SQLCMD très simplement :

1	sqlcmd -S [uneInstance]

Puis, par exemple, changer le mot de passe de la connexion sa :

Après chaque ligne de code tapée sous SQLCMD, si l’on appuie sur Entrée, la commande n’est pas exécutée : il faut pour cela utiliser la marqueur de fin de lot GO (qui n’est pas une instruction SQL ou T-SQL !). Enfin, pour sortir de l’utilitaire SQLCMD, il suffit de taper exit.

Bonne récupération d’accès à tous !

ElSüket.

Les posters des permissions pour SQL Server 2008 R2, 2012 et Azure

elsuket — Tue, 07 May 2013 05:44:33 +0000

Si l’on est un peu perdu dans les privilèges que l’on peut octroyer à des utilisateurs ou des connexions (logins), ou que l’on souhaite tout simplement explorer les possibilités offertes par les entités de sécurité, on peut télécharger des posters qui les présentent sous forme de groupes : serveur, base de données, ou pour chaque fonctionnalité du moteur de base de données.

Bon octroi de privilèges !

Scripter les connexions, rôles et utilisateurs avec leurs privilèges sous SQL Server 2005 et suivants

elsuket — Mon, 29 Apr 2013 23:19:52 +0000

La procédure que Microsoft fournit pour transférer les connexions d’une instance de SQL Server à l’autre s’applique très bien à SQL Server 2000, qui a près de 13 ans ! Pourtant, avec les possibilités de transtypage ajoutées aux versions suivantes de SQL Server, une requête suffit pour générer le script de création des logins.
En sus, je vous donne les requêtes nécessaires à la génération des rôles, des utilisateurs, et de leurs privilèges respectifs.

Voici donc la requête qui permet de scripter les connexions :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

SELECT 'CREATE LOGIN [' + name + '] FROM WINDOWS' AS sql_statement
FROM sys.server_principals
WHERE type_desc IN ('WINDOWS_LOGIN', 'WINDOWS_GROUP')
AND is_disabled = 0
AND name NOT IN ('NT AUTHORITY\SYSTEM', '')
AND name NOT LIKE '%sqlserveragent%'
UNION ALL
SELECT 'CREATE LOGIN ' + name
+ ' WITH PASSWORD = ' + CONVERT(varchar(max), password_hash, 1) + ' HASHED'
+ ', SID = ' + CONVERT(varchar(max), sid, 1)
AS sql_statement
FROM sys.sql_logins
WHERE type_desc IN ('WINDOWS_LOGIN', 'SQL_LOGIN')
AND is_disabled = 0
AND name NOT IN ('sa', 'NT AUTHORITY\SYSTEM')
ORDER BY sql_statement

Ci-dessous, la requête qui scripte les rôles de base de données :

1
2
3
4
5
6
7

SELECT 'CREATE ROLE [' + name + '] AUTHORIZATION dbo' AS create_role_statement
FROM sys.database_principals
WHERE type_desc = 'DATABASE_ROLE'
AND name NOT LIKE 'MS%' COLLATE SQL_Latin1_General_CP1_CS_AS
AND name NOT IN ('public')
AND is_fixed_role = 0
ORDER BY name

Puis les utilisateurs de base de données :

1
2
3
4
5

SELECT 'CREATE USER [' + name + '] FOR LOGIN [' + name + ']' AS create_user_statement
FROM sys.database_principals
WHERE type_desc IN ('SQL_USER', 'WINDOWS_USER')
AND name NOT IN ('dbo', 'guest', 'sys', 'INFORMATION_SCHEMA')
ORDER BY name

Et enfin l’appartenance des utilisateurs aux rôles, pour SQL Server 2005 et 2008 :

1
2
3
4
5
6
7
8
9

SELECT 'EXEC sp_addrolemember ''' + R.name + ''', ''' + M.name + '''' AS role_members_statement
FROM sys.database_role_members AS RM
INNER JOIN sys.database_principals AS R
ON R.principal_id = RM.role_principal_id
INNER JOIN sys.database_principals AS M
ON M.principal_id = RM.member_principal_id
WHERE R.name NOT LIKE 'MS%' COLLATE SQL_Latin1_General_CP1_CS_AS
AND M.name 'dbo'
ORDER BY role_members_statement

Et pour SQL Server 2012 :

1
2
3
4
5
6
7
8
9

SELECT 'ALTER ROLE ' + R.name + ' ADD MEMBER ' + M.name AS role_members_statement
FROM sys.database_role_members AS RM
INNER JOIN sys.database_principals AS R
ON R.principal_id = RM.role_principal_id
INNER JOIN sys.database_principals AS M
ON M.principal_id = RM.member_principal_id
WHERE R.name NOT LIKE 'MS%' COLLATE SQL_Latin1_General_CP1_CS_AS
AND M.name 'dbo'
ORDER BY role_members_statement

Il nous faut enfin les privilèges des rôles :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

;WITH
CTE AS
(
SELECT R.name AS role_name
, G.permission_name
, CASE G.class
WHEN 1 THEN O.name
WHEN 3 THEN S.name
WHEN 0 THEN DB_NAME()
END AS object_name
, CASE G.class
WHEN 1 THEN O.type_desc
WHEN 3 THEN 'SCHEMA'
WHEN 0 THEN 'DATABASE'
END AS object_type_desc
FROM sys.database_principals AS R
INNER JOIN sys.database_permissions AS G
ON G.grantee_principal_id = R.principal_id
LEFT JOIN sys.schemas AS S
ON G.major_id = S.schema_id
LEFT JOIN sys.objects AS O
ON G.major_id = O.object_id
WHERE R.name 'public'
AND G.permission_name 'CONNECT'
--ORDER BY R.name, object_name, G.permission_name
)
SELECT 'GRANT ' COLLATE database_default + permission_name
+ ' ON ' + CASE WHEN object_name IS NULL THEN 'SCHEMA::dbo TO [' ELSE object_name + ' TO [' END
+ role_name + ']' AS role_grant_statement
FROM CTE

Et nous terminons avec les privilèges des utilisateurs :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

;WITH
CTE AS
(
SELECT DB_USER.name AS user_name
, DB_GRANT.class_desc
, DB_GRANT.state_desc
, DB_GRANT.permission_name
, CASE DB_GRANT.class_desc
WHEN 'OBJECT_OR_COLUMN' THEN O.name
WHEN 'SCHEMA' THEN S.name
WHEN 'TYPE' THEN TY.name
ELSE O.name
END AS object_name
, O.type_desc AS DB_object_type
FROM sys.database_permissions AS DB_GRANT
INNER JOIN sys.database_principals AS DB_USER
ON DB_GRANT.grantee_principal_id = DB_USER.principal_id
LEFT JOIN sys.objects AS O
ON O.object_id = DB_GRANT.major_id
LEFT JOIN sys.types AS TY
ON TY.user_type_id = DB_GRANT.major_id
LEFT JOIN sys.schemas AS S
ON S.schema_id = DB_GRANT.major_id
WHERE DB_USER.name 'public'
AND DB_GRANT.permission_name 'CONNECT'
)
SELECT state_desc COLLATE database_default + ' ' + permission_name
+ CASE
WHEN object_name IS NULL THEN ''
ELSE ' ON ' + object_name
END + ' TO [' + user_name + ']' AS create_user_statement
FROM CTE
ORDER BY create_user_statement

Bon transfert d’entités de sécurité !

ElSüket

Que faire avec l’erreur 18486 : Login failed for user ‘unLogin’ because the account is currently locked out

elsuket — Tue, 02 Oct 2012 09:11:10 +0000

Voici comment se dépatouiller de cette erreur, qui peut se produire lorsque :

– le nombre de tentatives de connexion avec un mot de passe incorrect a dépassé
– et que le nom de connexion est paramétré pour vérifier que les stratégies de mot de passe Windows de l’ordinateur sur lequel l’instance SQL Server s’exécute

On peut se rendre compte de cette erreur en lisant les journaux de SQL Server, doit depuis l’Explorateur d’Objets de SQL Server Management Studio, soit en exécutant :

1	EXEC xp_readerrorlog 0, 1, 'locked out', NULL, '20121002', '20121003'

Pour s’extraire de cette situation, on peut tout simplement changer le mot de passe; il est de toute façon nécessaire d’adjoindre l’option UNLOCK à l’instruction ALTER LOGIN.
En effet, ceci peut par exemple se produire après une attaque à force brute dans le but de révéler le mot de passe d’une connexion.

1 2	ALTER LOGIN [uneConnexion] WITH PASSWORD = 'unMotDePasse' UNLOCK

@++

ElSüket

Les posters des privilèges et permissions sous SQL Server 2008 R2, SQL Server 2012 et SQL Azure

elsuket — Tue, 17 Jul 2012 21:29:45 +0000

Voici un lien intéressant qui offre pour chaque version de SQL Server, une vue d’ensemble des privilèges et permissions que l’on peut octroyer à un utilisateur ou une connexion, quelle que soit l’entité.

Bonne lecture !

ElSüket

Lister quelques propriétés des logins

elsuket — Thu, 11 Feb 2010 03:01:37 +0000

Voici une petite requête qui retourne quelques propriétés pour tous les logins d’un instance SQL Server, avec la prochaine date d’expiration des mots de passe …

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

-------------------------------
-- 22/01/2010 - Nicolas SOUQUET
-------------------------------
WITH
LOGIN_PROPERTIES AS
(
SELECT SP.name
, SP.type_desc
, SP.is_disabled
, SP.create_date
, SP.modify_date
, SP.default_database_name AS default_db
, SP.default_language_name AS default_lang
, CAST(LOGINPROPERTY(SP.name, 'PasswordLAstSetTime') AS DATETIME) AS password_last_set_time
, CAST(LOGINPROPERTY(SP.name, 'DaysUntilExpiration') AS DATETIME) AS days_until_expiration
FROM sys.server_principals AS SP
)
SELECT name
, type_desc
, is_disabled
, create_date
, modify_date
, default_db
, default_lang
, password_last_set_time
, DATEADD(day, -DATEDIFF(day, password_last_set_time, GETDATE()), GETDATE()) + days_until_expiration AS password_expiry_date
FROM LOGIN_PROPERTIES

Bonne sécurisation !

ElSuket

Empêcher un utilisateur de consulter le code source d’un objet de base de données (procédure stockée, fonction, trigger, vue, …)

elsuket — Mon, 07 Dec 2009 20:58:33 +0000

On demande parfois comment on peut crypter le code d’un objet de base de données (procédure stockée, trigger, fonction, vue, …) afin qu’un utilisateur ou qu’un groupe d’utilisateurs ne puisse pas en consulter le code.

Or il faut bien se rappeler que le cryptage d’un objet de base de données implique que celui-ci soit décrypté lors de chacune de ses exécutions, ce qui peut infliger au serveur de base de données une consommation de ressources élevée, peu souhaitable dans un environnement OLTP ou pour un serveur OLAP fortement sollicité.

Une alternative bien simple existe pourtant : le refus d’autorisation.
Voyons comment l’utiliser …

Nous allons créer une connexion et un utilisateur TOTO, et lui refuser le droit de voir la définition d’une procédure stockée.
Je me limite ici au cas d’une procédure stockée, mais le squelette est le même pour tout autre objet de base de données.
Si nous exécutons le script suivant, dans une session sous le login sa (connexion super-admnistrateur par défaut d’une instance SQL Server ) :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

-- Crée une connexion d'identifiant TOTO
CREATE LOGIN TOTO
WITH PASSWORD = '***'
GO

-- Change de contexte de base de données
USE ELSUKET
GO

-- Crée un utilisateur de base de données
CREATE USER TOTO
FOR LOGIN TOTO
GO

-- Une petite procédure
CREATE PROCEDURE PsTestDroits
AS
BEGIN
SELECT 1
END
GO

-- Refuse l'autorisation du vue de la définition à l'utilisateur TOTO
-- de la base de données ELSUKET
DENY VIEW DEFINITION
ON PsTestDroits TO TOTO

Nous voyons, dans l’explorateur d’objet de SQL Server Management Studio:

Connectons nous maintenant comme le ferait l’utilisateur TOTO :

La nouvelle connexion s’ouvre dans l’explorateur d’objets avec le contexte de navigation dans la base de données de TOTO : on ne peut pas voir la procédure stockée PsTestDroits :

ElSuket

Lister les permissions dont un utilisateur dispose sous SQL Server 2005 et 2008 : la fonction fn_my_permission

elsuket — Sun, 06 Sep 2009 09:09:23 +0000

La gestion des droits sous SQL Server étant complexe, puisqu’on peut octroyer des droits au niveau de l’instance et au niveau de la base de données, il est moins simple d’obtenir la liste complète des droits octroyés à un utilisateur, ou de connaître la liste des droits qu’on nous a octroyés.
Voyons comment obtenir cette liste de façon simple, avec la fonction fn_my_permission

Pour obtenir la liste complète des droits qui me sont octroyés, il me suffit d’exécuter :

1 2	SELECT * FROM fn_my_permissions(NULL, NULL)

Le premier paramètre de cette fonction correspond à l’objet sur lequel on cherche les droits octroyés, tandis que le second correspond au type de l’objet (‘OBJECT’, ‘DATABASE’, ‘LOGIN’, ‘SCHEMA’, ‘SERVER, ‘USER’, …).

Si l’on souhaite voir le résultat filtré, on peut par exemple écrire :

1 2	SELECT entity_name, permission_name FROM fn_my_permissions(NULL, 'SERVER')

Supposons que nous sommes administrateur d’une instance, et que nous venons d’octroyer des droits à un utilisateur de base de données.
Sans avoir à ouvrir une nouvelle session en spécifiant le login de l’utilisateur et son mot de passe, on peut lister ses droits :

1
2
3
4
5
6
7
8
9

USE maBD
GO

EXECUTE AS USER = 'monUtilisateur';
SELECT *
FROM fn_my_permissions(NULL, 'OBJECT')

REVERT
GO

ElSuket

Différence entre LOGIN et USER, entre connexion et utilisateur

elsuket — Mon, 06 Jul 2009 20:25:01 +0000

Quelle est la différence entre une connexion, ou LOGIN, et un utilisateur de base de données ?

Une connexion, ou login, permet d’accéder à une instance de SQL Server, mais c’est tout.
Une instance de SQL Server pouvant héberger plusieurs bases de données utilisateur, nous ne souhaitons peut-être pas que tous les utilisateurs aient accès à toutes les bases de données d’une instance, et de la même façon.
On peut aussi créer une connexion à un utilisateur pour qu’il puisse seulement effectuer des sauvegardes de base de données

A toute connexion|login, peut correspondre un utilisateur de base de données.
L’utilisateur de base de données est alors « mappé » sur une connexion, qui le donne le droit de naviguer dans 0 à autant de bases de données que l’instance en héberge.
Un administrateur ou les personnes à qui l’administrateur en a délégué le droit peuvent accorder des droits d’accès et des privilèges.

Un droit d’accès permet à un utilisateur de naviguer dans une base de données suivant des privilèges que l’administrateur lui a octroyés.
Un privilège permet de limiter l’accès aux données, par exemple en refusant le droit de SELECT sur la colonne salaire de la table des employés aux utilisateurs employés.

On peut encore gérer plus globalement au niveau de la base de données ou de l’instance les accès aux données en créant des rôles : on affecte ainsi au rôle des droits d’accès et des privilèges, et lors de l’arrivée d’un nouvel utilisateur, il nous suffit de l’ajouter au rôle de base de données.

Pour créer une connexion :

CREATE LOGIN monLogin WITH PASSWORD = 'monMotDePasse'

Pour permettre la navigation dans la base de données :

1
2
3

USE maBD
GO
CREATE USER monUtilisateur FOR LOGIN monLogin

On peut créer de plusieurs façon un rôle :

=> Soit par « recopie » des drois d’un utilisateur :

1
2
3

USE maBD;
CREATE ROLE monRole AUTHORIZATION unUtilsateur;
GO

=> Soit par recopie d’un rôle de base de données existant :

1
2
3

USE maBD;
CREATE ROLE monRole AUTHORIZATION db_securityadmin;
GO

Pour gérer les privilèges, on peut voir la documentation des instructions GRANT, REVOKE et DENY

On peut également réaliser tout cela à l’aide de SQL Server Management Studio :

– Pour la création de la connexion, ouvrez la node « Sécurité » de votre instance, puis faites un clic-droit sur la node « Connexions », et choisissez « Nouvelle connexion »

– Pour la création de l’utilisateur, après avoir ouvert la node possédant le nom de la base de données en question, ouvrez la node « Sécurité », puis cliquez-droit sur la node « Utilisateurs » en choisissant « Nouvel utilisateur »

Un peu de lecture par ici et ici, par SQLPro

ElSuket