Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra. # Configuration de l’authentification Kerberos à l’aide de groupes de sécurité Active Directory pour Babelfish Configuration de l’authentification Kerberos à l’aide de groupes de sécurité Active Directory pour Babelfish À partir de la version 4.2.0 de Babelfish, vous pouvez configurer l’authentification Kerberos pour Babelfish à l’aide de groupes de sécurité Active Directory. Voici les conditions préalables à remplir pour configurer l’authentification Kerberos à l’aide d’Active Directory : + Vous devez suivre toutes les étapes mentionnées sous [Authentification Kerberos avec Babelfish](babelfish-active-directory.md). + Assurez-vous que l’instance de base de données est associée à Active Directory. Pour vérifier cela, vous pouvez consulter l'état de l'appartenance au domaine dans la console ou en exécutant la commande [https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html](https://docs.aws.amazon.com/cli/latest/reference/rds/describe-db-instances.html) AWS CLI. L’état de l’instance de base de données doit être compatible avec Kerberos. Pour plus d’informations sur l’identification de l’appartenance à un domaine, consultez [Présentation de l’appartenance au domaine](postgresql-kerberos-managing.md#postgresql-kerberos-managing.understanding). + Vérifiez les mappages entre le nom de domaine NetBIOS et le nom de domaine DNS à l’aide de la requête suivante : ``` SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping; ``` + Avant de poursuivre, vérifiez que l’authentification Kerberos à l’aide d’un identifiant individuel fonctionne comme prévu. La connexion utilisant l’authentification Kerberos en tant qu’utilisateur Active Directory devrait aboutir. Si vous rencontrez des problèmes, consultez [Erreurs fréquentes](babelfish-active-directory.md#babelfish-active-directory-errors). ## Configuration de l’extension pg\$1ad\$1mapping Configuration de l’extension pg\$1ad\$1mapping Vous devez suivre toutes les étapes mentionnées sous [Configuration de l’extension pg\$1ad\$1mapping](AD.Security.Groups.md#AD.Security.Groups.Setup) . Pour vérifier que l’extension est installée, exécutez la requête suivante à partir du point de terminaison TDS : ``` 1> SELECT extname, extversion FROM pg_extension where extname like 'pg_ad_mapping'; 2> GO extname extversion ------------- ---------- pg_ad_mapping 0.1 (1 rows affected) ``` ## Gestion des connexions des groupes Gestion des connexions des groupes Créez des connexions de groupe en suivant les étapes mentionnées sous [Gestion des connexions](babelfish-active-directory.md#babelfish-active-directory-login-managing). Pour faciliter la gestion, nous recommandons que l’identifiant soit le même que le nom du groupe de sécurité Active Directory (AD), bien que cela ne soit pas obligatoire. Par exemple : ``` CREATE LOGIN [corp\accounts-group] FROM WINDOWS [WITH DEFAULT_DATABASE=database] ``` # Mappage des connexions de groupes T-SQL avec le groupe de sécurité AD Mappage des connexions de groupes T-SQL avec le groupe de sécurité AD Vous devez explicitement configurer un identifiant de groupe Windows T-SQL pour chaque groupe de sécurité AD qui nécessite un accès au serveur de base de données. Un utilisateur AD, qui fait partie d’au moins un groupe de sécurité AD provisionné, aura accès au serveur de base de données. **Note** Cet identifiant T-SQL ne pourra plus s’authentifier à l’aide d’une authentification basée sur un mot de passe. Par exemple, accounts-group est un groupe de sécurité dans AD et si vous souhaitez configurer ce groupe de sécurité dans Babelfish, vous devez utiliser le format [corp\$1accounts-group]. + Groupe de sécurité AD : accounts-group + Identifiant TSQL : [corp\$1accounts-group] + Rôle PG équivalent pour un identifiant TSQL donné : accounts-group@CORP.EXAMPLE.COM L’administrateur peut maintenant procéder à la création du mappage entre le groupe de sécurité AD et l’identifiant T-SQL à partir du point de terminaison PostgreSQL via la commande psql suivante. Pour plus d’informations sur l’utilisation des fonctions, consultez [Utilisation des fonctions de l’extension `pg_ad_mapping`](AD.Security.Groups.md#AD.Security.Groups.functions). **Note** L’identifiant T-SQL doit être spécifié au format login\$1name@FQDN lors de l’ajout du mappage. Les poids sont ignorés lors de la connexion via le point de terminaison TDS. Pour plus d’informations l’utilisation de la pondération, consultez [Connexion à Babelfish via le point de terminaison PostgreSQL sur le port PostgreSQL](babelfish-kerberos-securityad-connect-pgendpoint.md). ``` postgres=>select pgadmap_set_mapping('accounts-group', 'accounts-group@CORP.EXAMPLE.COM', , ); ``` Pour plus d’informations sur la récupération du SID du groupe de sécurité AD, consultez [Récupération du SID du groupe Active Directory dans PowerShell](AD.Security.Groups.md#AD.Security.Groups.retrieving). Le tableau suivant présente un exemple de mappage entre les groupes de sécurité AD et les identifiants T-SQL : | Groupes de sécurité AD | Identifiants TSQL | Rôle PG équivalent pour un identifiant TSQL donné | Pondération | | --- | --- | --- | --- | | accounts-group | [corp\$1accounts-group] | accounts-group@CORP.EXAMPLE.COM | 7 | | sales-group | [corp\$1sales-group] | sales-group@CORP.EXAMPLE.COM | 10 | | dev-group | [corp\$1dev-group] | dev-group@CORP.EXAMPLE.COM | 7 | ``` postgres=> select admap.ad_sid, admap.ad_grp, lgn.orig_loginname, lgn.rolname, admap.weight from pgadmap_read_mapping() as admap, sys.babelfish_authid_login_ext as lgn where admap.pg_role = lgn.rolname; ad_sid | ad_grp | orig_loginname | rolname | weight --------------+----------------+---------------------+---------------------------------+-------- S-1-5-67-890 | accounts-group | corp\accounts-group | accounts-group@CORP.EXAMPLE.COM | 7 S-1-2-34-560 | sales-group | corp\sales-group | sales-group@CORP.EXAMPLE.COM | 10 S-1-8-43-612 | dev-group | corp\dev-group | dev-group@CORP.EXAMPLE.COM | 7 (7 rows) ``` # Connexion à Babelfish via un point de terminaison TDS Connexion à Babelfish via un point de terminaison TDS Dans l’exemple suivant, user1 est membre d’accounts-group et de sales-group, et user2 est membre d’accounts-group et de dev-group. | Nom d’utilisateur | Appartenance aux groupes de sécurité AD | | --- | --- | | user1 | accounts-group, sales-group | | user2 | accounts-group, dev-group | Connectez-vous au serveur de base de données Babelfish à l’aide de l’utilitaire sqlcmd. Vous pouvez vérifier si un utilisateur (user1 dans cet exemple) a été authentifié à l’aide de Kerberos en suivant l’exemple ci-dessous : ``` 1> select principal, gss_authenticated from pg_stat_gssapi where pid = pg_backend_pid(); 2> GO principal gss_authenticated ---------------------- ----------------- user1@CORP.EXAMPLE.COM 1 ((1 rows affected)) 1> select suser_name(); 2> GO suser_name ---------- corp\user1 (1 rows affected) ``` Dans cet exemple, user1 hérite des privilèges d’accounts-group et de sales-group. Vous pouvez vérifier l’appartenance au groupe à l’aide de la vue système `sys.login_token`. ``` 1> SELECT name, type FROM sys.login_token; 2> GO name type ------------------- ---- corp\accounts-group WINDOWS GROUP corp\sales-group WINDOWS GROUP (2 rows affected) ``` ## Audit et journalisation Audit et journalisation Pour déterminer l’identité du principal de sécurité AD, utilisez les commandes suivantes : ``` 1> select suser_name(); 2> GO suser_name ---------- corp\user1 (1 rows affected) ``` Actuellement, l’identité de l’utilisateur AD n’est pas visible dans les journaux. Vous pouvez activer le paramètre `log_connections` pour journaliser l’établissement des sessions de base de données. Pour plus d’informations, consultez [log\$1connections](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/log-connections.html). La sortie inclut l’identité de l’utilisateur AD en tant que principal, comme illustré dans l’exemple suivant. Le PID du système dorsal associé à cette sortie pourra ensuite aider à attribuer les actions à l’utilisateur AD réel. ``` bbf_group_ad_login@babelfish_db:[615]:LOG: connection authorized: user=bbf_group_ad_login database=babelfish_db application_name=sqlcmd GSS (authenticated=yes, encrypted=yes, principal=user1@CORP.EXAMPLE.COM) ``` # Utilisation des privilèges liés à l’appartenance à un groupe de sécurité AD Utilisation des privilèges liés à l’appartenance à un groupe de sécurité AD ## Hériter des privilèges au niveau du serveur Hériter des privilèges au niveau du serveur Les utilisateurs AD membres d’un groupe de sécurité AD donné héritent des privilèges de niveau serveur accordés à l’identifiant du groupe Windows mappé. Par exemple, considérez le groupe de sécurité AD `accounts-group`, qui est autorisé à appartenir au rôle serveur `sysadmin` sur Babelfish. Vous pouvez hériter des privilèges au niveau serveur à l’aide de la commande suivante : ``` 1> ALTER SERVER ROLE sysadmin ADD MEMBER [corp\accounts-group]; ``` Par conséquent, tout utilisateur Active Directory membre du groupe de sécurité AD `accounts-group` hérite des privilèges de niveau serveur associés au rôle `sysadmin`. Cela signifie qu’un utilisateur comme `corp\user1`, en tant que membre de `accounts-group`, a désormais la possibilité d’effectuer des opérations au niveau du serveur dans Babelfish. **Note** Pour fonctionner au niveau du serveur DDLs, l'identifiant Windows de chaque utilisateur AD doit exister. Pour de plus amples informations, veuillez consulter [Limitations](babelfish-kerberos-securityad-limitations.md). ## Hériter des privilèges au niveau de la base de données Hériter des privilèges au niveau de la base de données Pour accorder des privilèges au niveau de la base de données, un utilisateur de base de données doit être créé et mappé avec un identifiant de groupe Windows. Les utilisateurs AD membres d’un groupe de sécurité AD donné héritent des privilèges accordés à cet utilisateur de base de données au niveau de la base de données. Dans l’exemple suivant, vous pouvez voir comment les privilèges au niveau de la base de données sont attribués au groupe Windows [corp\$1accounts-group]. ``` 1> CREATE DATABASE db1; 2> GO 1> USE db1; 2> GO Changed database context to 'db1'. 1> CREATE TABLE dbo.t1(a int); 2> GO ``` Créez un utilisateur de base de données [corp sales-group] pour la connexion du groupe Windows [corp\$1accounts-group]. Pour effectuer cette étape, connectez-vous via le point de terminaison TDS en utilisant un identifiant qui est membre de sysadmin. ``` 1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group]; 2> GO ``` Maintenant, connectez-vous en tant qu’utilisateur AD user1 pour vérifier l’accès à la table t1. Comme nous n’avons pas encore accordé les privilèges au niveau de la base de données, cela entraîne une erreur de refus d’autorisation. ``` 1> SELECT * FROM dbo.t1; 2> GO Msg 33557097, Level 16, State 1, Server db-inst, Line 1 permission denied for table t1 ``` Accordez SELECT sur la table t1 à l’utilisateur de base de données [corp\$1accounts-group]. Pour effectuer cette étape, connectez-vous via le point de terminaison TDS en utilisant un identifiant qui est membre de sysadmin. ``` 1> GRANT SELECT ON dbo.t1 TO [corp\accounts-group]; 2> GO ``` Connectez-vous en tant qu’utilisateur AD user1 pour valider l’accès. ``` 1> SELECT * FROM dbo.t1; 2> GO a ----------- (0 rows affected) ``` # Traitement du comportement des instructions DDL sur la base d’un schéma par défaut ou explicite Traitement du comportement des instructions DDL sur la base d’un schéma par défaut ou explicite Lorsque vous utilisez une session authentifiée AD, le schéma par défaut de la session en cours est déterminé par les conditions suivantes : + S’il existe un utilisateur de base de données individuel, le schéma par défaut de cet utilisateur est considéré comme le schéma par défaut de la session en cours. + S’il existe le schéma par défaut pour un utilisateur de base de données de groupe, le schéma par défaut de cet utilisateur est considéré comme le schéma par défaut de la session en cours avec l’identifiant de principal le plus faible. ## Comprendre le comportement de l’instruction CREATE DDL Comprendre le comportement de l’instruction CREATE DDL Si aucun schéma explicite n’est spécifié dans l’instruction CREATE DDL, la création de l’objet aura lieu dans le schéma par défaut de la session en cours. S’il est impossible de déterminer si le schéma est le schéma par défaut ou explicite, l’instruction DDL génère l’erreur suivante : ``` "Babelfish Unsupported Command : Schema required for CREATE DDLs when connecting with Active Directory Group authentication. Assign default schema to group user or specify schema in command." ``` **Example : il n’existe pas de schéma par défaut pour l’utilisateur du groupe Windows** L’utilisateur du groupe Windows [corp\$1accounts-group] a un schéma par défaut NULL, et l’utilisateur AD user1 essaie d’exécuter le DDL sans spécifier le schéma explicitement. Étant donné qu’il n’existe pas d’identifiant ni d’utilisateur Windows individuel pour user1, il obtiendra uniquement les privilèges de l’utilisateur du groupe Windows [corp\$1accounts-group] au niveau de la base de données. ``` 1> create TABLE t2(a int); 2> GO Msg 33557097, Level 16, State 1, Server db-inst, Line 1 Babelfish Unsupported Command : Schema required for CREATE DDLs when connecting with Active Directory Group authentication. Assign default schema to group user or specify schema in command. ``` Il n’existe pas d’identifiant ni d’utilisateur Windows individuel pour l’utilisateur AD user1 **Example : il existe un schéma par défaut pour les utilisateurs du groupe Windows** Créez un utilisateur de groupe Windows pour l’identifiant [corp\$1accounts-group] avec le schéma par défaut à l’aide de sysadmin. ``` 1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group] WITH DEFAULT_SCHEMA = sch_acc; 2> GO 1> CREATE SCHEMA sch_acc AUTHORIZATION [gad\accounts-group]; 2> GO 1> SELECT name, principal_id, default_schema_name FROM sys.database_principals WHERE name = 'corp\accounts-group'; 2> GO name principal_id default_schema_name ------------------ ------------ ------------------- corp\accounts-group 24162 sch_acc (1 rows affected) ``` Essayez de créer un objet sans spécifier explicitement le schéma à l’aide de l’utilisateur AD user1. La table t2 sera créée dans le schéma par défaut de l’utilisateur du groupe Windows [corp\$1accounts-group]. Le propriétaire de cet objet sera le même que le propriétaire du schéma sch\$1acc. ``` 1> CREATE TABLE t_group(a int); 2> GO 1> SELECT name, schema_name(schema_id) FROM sys.objects WHERE name like 't_group'; 2> GO name schema_name ------- ----------- t_group sch_acc (1 rows affected) ``` Il n’existe pas d’identifiant ni d’utilisateur Windows individuel pour l’utilisateur AD user1 **Example : il existe également un utilisateur de base de données individuel pour un utilisateur AD** S’il existe également un utilisateur de base de données individuel pour un utilisateur AD, les objets seront toujours créés dans le schéma associé à cet utilisateur. S’il n’existe pas de schéma pour l’utilisateur de base de données, le schéma dbo sera utilisé. Créez un identifiant et un utilisateur de base de données Windows individuels pour l’utilisateur AD user1. Connectez-vous via le point de terminaison TDS à l’aide d’un identifiant sysadmin. ``` 1> CREATE LOGIN [corp\user1] FROM WINDOWS; 2> GO 1> CREATE USER [corp\user1] FOR LOGIN [corp\user1] WITH DEFAULT_SCHEMA = sch1; 2> GO 1> CREATE SCHEMA sch1 AUTHORIZATION [corp\user1]; 2> GO 1> SELECT name, default_schema_name FROM sys.database_principals WHERE name = 'corp\user1'; 2> GO name default_schema_name --------- ------------------- corp\user1 sch1 (1 rows affected) ``` Connectez-vous à l’aide de l’utilisateur AD user1 et essayez de créer un objet sans spécifier explicitement le schéma. La table t2 sera créée dans le schéma sch1. Notez également que le propriétaire de cet objet sera le même que le propriétaire du schéma sch1. ``` 1> CREATE TABLE t2(a int); 2> GO 1> SELECT name, schema_name(schema_id) FROM sys.objects WHERE name like 't2'; 2> GO name schema_name ---- ----------- t2 sch1 (1 rows affected) ``` # Limitations Limitations + L’utilitaire de vidage et de restauration ne prend pas en charge le vidage des mappages d’extension pg\$1ad\$1mapping. Vous devrez recréer ces mappages après la restauration. + Le déploiement bleu/vert n’est pas pris en charge pour les instances Babelfish pour Aurora PostgreSQL avec `pg_ad_mapping`. + La création de schéma implicite n’est pas prise en charge. Les instructions DDL qui nécessitent la création d’un schéma implicite ne sont pas prises en charge. + Les instructions DDL ALTER AUTHORIZATION ON DATABASE , CREATE DATABASE, CREATE LOGIN, ALTER LOGIN, ALTER SERVER ROLE, ALTER DATABASE au niveau du serveur ne sont pas prises en charge dans une session authentifiée en tant que groupe AD lorsqu’il n’existe pas d’identifiant Windows individuel, mais seulement l’identifiant Windows du groupe. Pour contourner cette limitation, il est recommandé d’effectuer ces opérations dans le cadre d’une session authentifiée par mot de passe ou de créer un identifiant Windows individuel. + La création d’utilisateurs implicite n’est pas prise en charge. Comportement T-SQL idéal [pas encore pris en charge dans Babelfish] : dans certains cas, comme les instructions DDL et les instructions de contrôle d’accès telles que GRANT/REVOKE où le nom de l’utilisateur AD est spécifié dans la commande mais n’existe pas dans la base de données, l’utilisateur de base de données nommé en tant qu’utilisateur AD est implicitement créé. + Pour les instructions DDL dans les procédures ou fonctions PL/pgSQL créées à partir du point de terminaison PSQL et exécutées à partir du point de terminaison TDS dans une session authentifiée en tant que groupe AD : + Les instructions ALTER/DROP sont prises en charge. + CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE FUNCTION/PROC, CREATE TYPE, CREATE SEQUENCE, CREATE TRIGGER, SELECT INTO, CREATE FULLTEXT INDEX , CREATE UNIQUE INDEX génèrent une erreur si le schéma n’est pas fourni explicitement et si le schéma par défaut est nul pour la session en cours. + CREATE DATABASE, CREATE EXTENSION et toutes les autres instructions CREATE pour les objets spécifiques à PG (sauf dans T-SQL) CREATE subscription, CREATE tablespace, CREATE policy, CREATE conversion ne sont pas prises en charge. + Les instructions DDL provenant du point de terminaison PostgreSQL ne sont pas prises en charge dans les sessions authentifiées en tant que groupe AD. Pour contourner le problème, vous pouvez toujours vous connecter à l’aide d’un identifiant principal ou de tout autre utilisateur utilisant un mécanisme d’authentification basé sur un mot de passe. + Les objets système tels que SUSER\$1SID(), IS\$1SRVROLEMEMBER(), IS\$1MEMBER(), sys.dm\$1exec\$1sessions ont les limites suivantes. + SUSER\$1SID() ne renvoie pas le SID lorsque l’utilisateur AD ou le groupe de sécurité AD est fourni. + IS\$1SRVROLEMEMBER() ne tient pas compte de l’appartenance au rôle si l’utilisateur AD actuel hérite de l’appartenance au rôle serveur d’un identifiant de groupe Windows quelconque. + IS\$1MEMBER() renvoie false pour toute requête liée au groupe Windows. + sys.dm\$1exec\$1sessions n’affiche pas les valeurs attendues dans les colonnes login\$1name et nt\$1user\$1name. # Connexion à Babelfish via le point de terminaison PostgreSQL sur le port PostgreSQL Connexion à Babelfish via le point de terminaison PostgreSQL Vous pouvez utiliser les identifiants de groupe créées à partir du port TDS pour vous connecter via le port PostgreSQL. Pour vous connecter via le port PostgreSQL, vous devez spécifier le nom de l’utilisateur AD au format `` à partir des applications clientes PostgreSQL. Vous ne pouvez pas utiliser le format ``. PostgreSQL utilise par défaut des comparaisons sensibles à la casse pour les noms d’utilisateur. Pour qu’Aurora PostgreSQL interprète les noms d’utilisateur Kerberos comme non sensibles à la casse, vous devez définir le paramètre krb\$1caseins\$1users comme true dans le groupe de paramètres du cluster Babelfish personnalisé. Ce paramètre est défini sur false par défaut. Pour plus d’informations, consultez [Configuration de votre cluster de bases de données Aurora PostgreSQL pour les noms d’utilisateur insensibles à la casse](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins.set-case-insentive). ## Différences de comportement entre les points de terminaison T-SQL et PostgreSQL lorsqu’un utilisateur AD fait partie de plusieurs groupes Différences de comportement entre les points de terminaison T-SQL et PostgreSQL lorsqu’un utilisateur AD fait partie de plusieurs groupes Supposons que l’utilisateur AD user1 fasse partie de deux groupes de sécurité AD [corp\$1accounts-group] et [corp\$1sales-group], et que l’administrateur de la base de données ait défini le mappage des utilisateurs de la manière suivante. ``` postgres=> select * from pgadmap_read_mapping(); ad_sid | pg_role | weight | ad_grp -------------+---------------------------------+--------+--------------- S-1-5-67-980 | accounts-group@CORP.EXAMPLE.COM | 7 | accounts-group S-1-2-34-560 | sales-group@CORP.EXAMPLE.COM | 10 | sales-group (2 rows) ``` Si l’utilisateur se connecte depuis le point de terminaison T-SQL, lors de l’autorisation, il héritera des privilèges de tous les identifiants T-SQL associés. Dans cet exemple, user1 hérite de l’union des privilèges de l’identifiant du groupe T-SQL, et les poids sont ignorés. Ceci est conforme au comportement standard de T-SQL. Cependant, si le même utilisateur se connecte depuis le point de terminaison PostgreSQL, il ne peut hériter des privilèges que d’un seul identifiant T-SQL associé ayant le poids le plus élevé. Si le même poids a été attribué aux deux identifiants de groupe T-SQL, l’utilisateur AD héritera des privilèges de l’identifiant T-SQL correspondant au mappage ajouté le plus récemment. Pour PostgreSQL, il est recommandé de spécifier des pondérations qui reflètent le permissions/privileges rapport entre les rôles de base de données individuels afin d'éviter toute ambiguïté. Dans l’exemple ci-dessous, user1 s’est connecté via le point de terminaison PSQL et n’a hérité que des privilèges de sales-group. ``` babelfish_db=> select session_user, current_user; session_user | current_user ------------------------------+--------------------------- sales-group@CORP.EXAMPLE.COM | sales-group@CORP.EXAMPLE.COM (1 row) babelfish_db=> select principal, gss_authenticated from pg_stat_gssapi where pid = pg_backend_pid(); principal | gss_authenticated ------------------------+------------------- user1@CORP.EXAMPLE.COM | t (1 row) ```