Fournir le rôle `RDB$ADMIN` dans une base de données conventionnelle

Les opérateurs GRANT et REVOKE sont utilisés pour attribuer et supprimer le rôle RDB$ADMIN dans une base de données normale, tout comme les autres rôles.

Syntaxe

GRANT [DEFAULT] [ROLE] RDB$ADMIN TO username

REVOKE [DEFAULT] [ROLE] RDB$ADMIN FROM username

Table 1. Paramètres pour les opérateurs de création et d’annulation du rôle `RDB$ADMIN`.
Paramètre	Description
username	Le nom de l’utilisateur à qui le rôle `RDB$ADMIN` est attribué ou sélectionné.

Si le mot-clé DEFAULT est présent dans l’instruction GRANT, l’utilisateur recevra automatiquement des privilèges d’administration même s’il n’a pas spécifié le rôle RDB$ADMIN lors de la connexion. Seuls les administrateurs peuvent donner des privilèges au rôle RDB$ADMIN.

Voir aussi :

GRANT, REVOKE.

Utilisation du rôle `RDB$ADMIN` dans une base de données conventionnelle

Pour utiliser les permissions du rôle RDB$ADMIN, l’utilisateur doit simplement le spécifier lorsqu’il se connecte à la base de données, ou bien le rôle RDB$ADMIN lui est donné à l’aide du mot-clé DEFAULT. Il peut également le spécifier ultérieurement à l’aide de l’instruction SET ROLE.

docnext count = 8

Accorder le rôle `RDB$ADMIN` dans la base de données des utilisateurs.

Comme personne ne peut se connecter à la base de données des utilisateurs, les instructions GRANT et REVOKE ne peuvent pas être utilisées ici. Au lieu de cela, le rôle RDB$ADMIN est accordé et retiré par les commandes de gestion des utilisateurs SQL : CREATE USER et ALTER USER, qui spécifient les options spéciales GRANT ADMIN ROLE et REVOKE ADMIN ROLE.

Syntaxe (incomplet)

CREATE USER newuser
PASSWORD 'password'
...
GRANT ADMIN ROLE
...

ALTER USER existinguser
GRANT ADMIN ROLE

ALTER USER existinguser
REVOKE ADMIN ROLE

Table 1. Paramètres pour les opérateurs de création et d’annulation du rôle `RDB$ADMIN`.
Paramètre	Description
newuser	Le nom de l’utilisateur nouvellement créé. Longueur maximale de 63 caractères.
existinguser	Le nom d’un utilisateur existant.
password	Mot de passe de l’utilisateur, sensible à la casse.

Important

N’oubliez pas que GRANT ADMIN ROLE et REVOKE ADMIN ROLE ne sont pas des opérateurs GRANT et REVOKE mais des paramètres pour CREATE USER et ALTER USER.

Seuls les administrateurs peuvent donner des privilèges au rôle RDB$ADMIN.

Voir aussi :

[fblangref-security-grant], [fblangref-security-revoke].

Effectuer la même tâche en utilisant l’utilitaire `gsec`.

On peut faire de même avec l’utilitaire gsec en spécifiant le paramètre -admin pour sauvegarder l’attribut RDB$ADMIN` du compte utilisateur :

....
gsec -add new_user -pw password -admin yes
gsec -mo existing_user -admin yes
gsec -mo existing_user -admin no
....

Note	Selon le statut administratif de l’utilisateur actuel, l’utilitaire `gsec` peut exiger plus de paramètres tels que `-user` et `-pass`, ou `-trusted`.

Utilisation du rôle `RDB$ADMIN` dans la base de données des utilisateurs

Pour gérer les comptes utilisateurs via SQL, un utilisateur qui a des droits sur le rôle RDB$ADMIN doit se connecter à une base de données avec ce rôle. Comme personne n’a le droit de se connecter à la base de données des utilisateurs, l’utilisateur doit se connecter à une base de données normale où il a également des droits sur le rôle RDB$ADMIN. Il définit le rôle lors de la connexion à la base de données normale et peut exécuter n’importe quelle requête SQL sur celle-ci. Ce n’est pas la solution la plus élégante, mais c’est la seule façon de gérer les utilisateurs via des requêtes SQL.

A moins qu’il n’y ait une base de données normale où l’utilisateur a des droits sur le rôle RDB$ADMIN, la gestion des comptes via des requêtes SQL n’est pas disponible.

Utiliser le rôle RDB$ADMIN dans `gsec`

Pour gérer les utilisateurs via l’utilitaire gsec, le rôle RDB$ADMIN doit être spécifié dans le commutateur -role.

`AUTO ADMIN MAPPING`

Système d’exploitation

Windows uniquement.

Les administrateurs du système d’exploitation Windows n’obtiennent pas automatiquement les permissions SYSDBA lorsqu’ils se connectent à une base de données (à moins, bien sûr, qu’une autorisation de confiance soit autorisée). Le fait que les administrateurs aient des droits SYSDBA automatiques dépend de la valeur de l’indicateur AUTO ADMIN MAPPING. C’est un indicateur dans chacune des bases de données qui est désactivé par défaut. Si l’indicateur AUTO ADMIN MAPPING est activé, il est effectif lorsqu’un administrateur Windows :

se connecte en utilisant l’authentification de confiance .
ne définit aucun rôle lors de la connexion.

Après une connexion “auto admin” réussie, le rôle actuel sera RDB$ADMIN

Activer ou désactiver AUTO ADMIN MAPPING dans une base de données conventionnelle

L’activation et la désactivation de l’indicateur AUTO ADMIN MAPPING dans une base de données conventionnelle s’effectue comme suit

ALTER ROLE RDB$ADMIN SET AUTO ADMIN MAPPING -- Mise en marche

ALTER ROLE RDB$ADMIN DROP AUTO ADMIN MAPPING -- Mise hors tension

Ces opérateurs peuvent être exécutés par des utilisateurs disposant de droits suffisants, à savoir

le propriétaire de la base de données ;
administrateurs.

Note

Opérateur

ALTER ROLE RDB$ADMIN SET AUTO ADMIN MAPPING

est un type d’instruction simplifié pour créer une correspondance entre le groupe prédéfini DOMAIN_ANY_RID_ADMINS et le rôle RDB$ADMIN.

CREATE MAPPING WIN_ADMINS
USING PLUGIN WIN_SSPI
FROM Predefined_Group
DOMAIN_ANY_RID_ADMINS
TO ROLE RDB$ADMIN;

En conséquence, l’opérateur

ALTER ROLE RDB$ADMIN DROP AUTO ADMIN MAPPING

est équivalent à l’opérateur

DROP MAPPING WIN_ADMINS;

Pour plus d’informations, voir Security object mapping.

Dans les bases de données normales, l’état de AUTO ADMIN MAPPING n’est vérifié que pendant la connexion. Si Administrator a le rôle RDB$ADMIN parce que le mappage automatique s’est produit pendant la connexion, il conservera ce rôle pendant toute la session, même si lui ou quelqu’un d’autre désactive le mappage automatique au même moment.

De même, l’activation de AUTO ADMIN MAPPING ne changera pas le rôle actuel dans RDB$ADMIN pour les Administrateurs qui sont déjà connectés.

Activez ou désactivez AUTO ADMIN MAPPING dans la base de données de sécurité.

Vous ne pouvez pas activer ou désactiver l’indicateur AUTO ADMIN MAPPING dans la base de données utilisateur avec l’instruction ALTER ROLE RDB$ADMIN. Cependant, vous pouvez créer un mappage global du groupe prédéfini DOMAIN_ANY_RID_ADMINS au rôle RDB$ADMIN comme suit :

CREATE GLOBAL MAPPING WIN_ADMINS
USING PLUGIN WIN_SSPI
FROM Predefined_Group
DOMAIN_ANY_RID_ADMINS
TO ROLE RDB$ADMIN;

Alternativement, pour activer AUTO ADMIN MAPPING dans la base de données utilisateur, vous pouvez utiliser l’utilitaire de ligne de commande gsec :

gsec -mapping set

gsec -mapping drop

Note	Selon le statut administratif de l’utilisateur actuel, l’utilitaire `gsec` peut exiger plus de paramètres tels que `-user` et `-pass`, ou `-trusted`.

Seul SYSDBA peut activer AUTO ADMIN MAPPING s’il est désactivé, mais tout administrateur peut le désactiver.

Désactiver AUTO ADMIN MAPPING désactive le mécanisme même qui lui donnait accès et donc il ne peut pas réactiver AUTO ADMIN MAPPING. Même dans une session interactive de gsec, le nouveau paramètre du drapeau prendra effet immédiatement.

Administrateurs

Un administrateur est un utilisateur qui a des droits suffisants pour lire et écrire, créer, modifier et supprimer tout objet dans la base de données. Le tableau montre comment les privilèges `Superuser' sont activés dans divers contextes de sécurité Firebird.

Table 1. Administrateurs
Utilisateur	Rôle `RDB$ADMIN`	Note
SYSDBA	Automatiquement	Existe automatiquement au niveau du serveur. Possède unepour tous les objets de toutes les bases de données. CanCréer, modifier et supprimer des utilisateurs, mais n’a pas d’accès direct à l’information.l’accès à la base de données de sécurité.
Utilisateur root dans POSIX	Automatiquement	Similaire à `SYSDBA`. Seulement dans Firebird Embedded.
Superuser dans POSIX	Automatiquement	Similaire à `SYSDBA`. Seulement dans Firebird Embedded.
Propriétaire de la base de données	Automatiquement	Identique à `SYSDBA`, mais seulement dans cette base de données.
Administrateurs Windows	En cas de réussite de la connexion, la valeur est fixée à `CURRENT_ROLE`.	Similaire à `SYSDBA` si les conditions suivantes sont remplies : Dans le fichier de configuration firebird.conf (paramètre `AuthServer`) le fournisseur Win_Sspi était présent dans la liste des plugins.En outre, ce plugin doit également être présent dans la liste des plugins côté client (paramètre `AuthClient`). Dans toutes les bases de données où l’autorité du super-utilisateur est requise, la fonction `AUTO ADMIN MAPPING` doit être activée ou un mappage du groupe prédéfini `DOMAIN_ANY_RID_ADMINS` au rôle `RDB$ADMIN` doit être créé. Aucun rôle n’est spécifié lors de la connexion.
Utilisateur ordinaire	Doit être pré-émis et doit être spécifié à la connexion	Même chose que `SYSDBA`, mais seulement dans les bases de données où ce rôle a été accordé.
Utilisateur POSIX	Doit être pré-émis et doit être spécifié à la connexion	Identique à `SYSDBA`, mais seulement dans les bases de données où ce rôle est accordé.Seulement dans Firebird Embedded.
Utilisateur Windows	Doit être pré-émis et doit être spécifié à la connexion	Identique à `SYSDBA`, mais seulement dans les bases de données où ce rôle a été accordé.Disponible uniquement si le fichier de configuration firebird.conf.(paramètre `AuthServer`) dans la liste des pluginsLe fournisseur `Win_Sspi` était présent dans la liste des plugins. En outre, ce plugin doitégalement dans la liste des plugins côté client (paramètre `AuthClient`).

Fournir Le Rôle RDB$ADMIN Dans Une Base De Données Conventionnelle

Fournir le rôle RDB$ADMIN dans une base de données conventionnelle

Utilisation du rôle RDB$ADMIN dans une base de données conventionnelle

docnext count = 8

Accorder le rôle RDB$ADMIN dans la base de données des utilisateurs.

Effectuer la même tâche en utilisant l’utilitaire gsec.

Utilisation du rôle RDB$ADMIN dans la base de données des utilisateurs

Utiliser le rôle RDB$ADMIN dans gsec

AUTO ADMIN MAPPING