# Configuración de la autenticación basada en Kerberos mediante los grupos de seguridad de Active Directory para Babelfish
A partir de la versión 4.2.0 de Babelfish, puede configurar la autenticación Kerberos para Babelfish con grupos de seguridad de Active Directory. Estos son los requisitos previos que debe cumplir para configurar la autenticación Kerberos mediante Active Directory:
+ Debe seguir todos los pasos que se mencionan en [Autenticación Kerberos con Babelfish](babelfish-active-directory.md).
+ Asegúrese de que la instancia de base de datos esté asociada a Active Directory. Para comprobarlo, puede ver el estado de la suscripción al dominio en la consola o ejecutar el comando [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) de la CLI de AWS.
El estado de la instancia de base de datos debe estar habilitado para Kerberos. Para obtener más información sobre cómo entender la pertenencia a un dominio, consulte [Descripción de la pertenencia a los dominios](postgresql-kerberos-managing.md#postgresql-kerberos-managing.understanding).
+ Compruebe las asignaciones entre el nombre de dominio NetBIOS y el nombre de dominio DNS mediante la siguiente consulta:
```
SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping;
```
+ Antes de continuar, compruebe que la autenticación Kerberos mediante el inicio de sesión individual funcione según lo previsto. La conexión mediante la autenticación Kerberos como usuario de Active Directory debería realizarse correctamente. Si tiene algún problema, consulte [Errores frecuentes](babelfish-active-directory.md#babelfish-active-directory-errors).
## Configuración de la extensión pg\$1ad\$1mapping
Debe seguir todos los pasos que se mencionan en [Configuración de la extensión pg\$1ad\$1mapping](AD.Security.Groups.md#AD.Security.Groups.Setup). Para comprobar que la extensión está instalada, ejecute la siguiente consulta desde el punto de conexión de 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)
```
## Administración de inicios de sesión de grupo
Cree inicios de sesión de grupo siguiendo los pasos que se mencionan en [Administración de inicios de sesión](babelfish-active-directory.md#babelfish-active-directory-login-managing). Se recomienda que el nombre de inicio de sesión sea el mismo que el nombre del grupo de seguridad de Active Directory (AD) para facilitar el mantenimiento, aunque no es obligatorio. Por ejemplo:
```
CREATE LOGIN [corp\accounts-group] FROM WINDOWS [WITH DEFAULT_DATABASE=database]
```
# Asignación de inicios de sesión de grupos T-SQL con grupos de seguridad de AD
Debe proporcionar explícitamente el inicio de sesión grupal de Windows de T-SQL para cada grupo de seguridad de AD que requiera acceso al servidor de base de datos. Un usuario de AD que forme parte de al menos un grupo de seguridad de AD aprovisionado tendrá acceso al servidor de la base de datos.
**nota**
Este inicio de sesión de T-SQL ya no se puede autenticar mediante una autenticación basada en contraseñas.
Por ejemplo, accounts-group es un grupo de seguridad de AD y, si quisiese aprovisionar este grupo de seguridad en Babelfish, debería usar el formato [corp\$1accounts-group].
+ Grupo de seguridad de AD: accounts-group
+ Inicio de sesión en TSQL: [corp\$1accounts-group]
+ Rol PG equivalente para un inicio de sesión de TSQL determinado: accounts-group@CORP.EXAMPLE.COM
Ahora, el administrador puede crear la asignación entre el grupo de seguridad de AD y el inicio de sesión de T-SQL desde el punto de conexión de PostgreSQL mediante el siguiente comando psql. Para obtener más información sobre el uso de la función, consulte [Uso de las funciones de la extensión `pg_ad_mapping`](AD.Security.Groups.md#AD.Security.Groups.functions).
**nota**
El inicio de sesión de T-SQL debe especificarse en el formato login\$1name@FQDN al añadir la asignación. Al conectarse a través del punto de conexión TDS, las ponderaciones se ignoran. Para obtener más información sobre el uso de ponderaciones, consulte [Conexión a Babelfish a través del punto de conexión de PostgreSQL en el puerto PostgreSQL](babelfish-kerberos-securityad-connect-pgendpoint.md).
```
postgres=>select pgadmap_set_mapping('accounts-group', 'accounts-group@CORP.EXAMPLE.COM', , );
```
Para obtener información sobre cómo recuperar el SID del grupo de seguridad de AD, consulte [Recuperación del SID del grupo de Active Directory en PowerShell](AD.Security.Groups.md#AD.Security.Groups.retrieving).
En la siguiente tabla se muestra un ejemplo de asignación desde grupos de seguridad de AD a inicios de sesión T-SQL:
| Grupos de seguridad de AD | Inicios de sesión de TSQL | Rol PG equivalente para un inicio de sesión de TSQL determinado | Peso |
| --- | --- | --- | --- |
| 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)
```
# Conexión a Babelfish a través del punto de conexión de TDS
En el siguiente ejemplo, user1 es miembro de accounts-group y sales-group, mientras que user2 es miembro de accounts-group y dev-group.
| Nombre de usuario | Pertenencia a los grupos de seguridad de AD |
| --- | --- |
| user1 | accounts-group, sales-group |
| user2 | accounts-group, dev-group |
Conéctese al servidor de bases de datos Babelfish mediante la utilidad sqlcmd. Puede comprobar si un usuario (user1 en este ejemplo) se ha autenticado mediante Kerberos, como se ve en este ejemplo:
```
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)
```
En este ejemplo, user1 heredará los privilegios de accounts-group y sales-group. Puede verificar la pertenencia al grupo mediante la vista de sistema `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)
```
## Auditoría y registro
Para determinar la identidad de la entidad principal de seguridad de AD, utilice el siguiente comando:
```
1> select suser_name();
2> GO
suser_name
----------
corp\user1
(1 rows affected)
```
Actualmente, la identidad del usuario de AD no se puede ver en los registros. Puede activar el parámetro `log_connections` para registrar el establecimiento de la sesión de base de datos. Consulte [log\$1connections](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/log-connections.html) para obtener más información. La salida incluye la identidad del usuario de AD como entidad principal, como se ve en el siguiente ejemplo. A continuación, el PID del backend asociado a este resultado puede ayudar a atribuir las acciones al usuario real de AD.
```
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)
```
# Uso de los privilegios de pertenencia a un grupo de seguridad de AD
## Cómo heredar privilegios en el nivel de servidor
Los usuarios de AD que sean miembros de un grupo de seguridad de AD determinado heredarán los privilegios del nivel de servidor otorgados al inicio de sesión del grupo de Windows asignado. Por ejemplo, al grupo de seguridad de AD `accounts-group` se le concede la pertenencia al rol de servidor `sysadmin` en Babelfish. Puede heredar los privilegios de nivel de servidor mediante el siguiente comando:
```
1> ALTER SERVER ROLE sysadmin ADD MEMBER [corp\accounts-group];
```
En consecuencia, cualquier usuario de Active Directory que sea miembro del grupo de seguridad de AD `accounts-group` heredará los privilegios de nivel de servidor asociados al rol `sysadmin`. Esto significa que un usuario como `corp\user1`, que es miembro de `accounts-group`, podrá realizar operaciones en el nivel de servidor dentro de Babelfish.
**nota**
Para ejecutar los DDL a nivel de servidor, debe existir el inicio de sesión de Windows para cada usuario de AD. Para obtener más información, consulte [Limitaciones](babelfish-kerberos-securityad-limitations.md).
## Cómo heredar privilegios en el nivel de base de datos
Para conceder los privilegios del nivel de base de datos, se debe crear y mapear un usuario de la base de datos con un inicio de sesión grupal de Windows. Los usuarios de AD que sean miembros de un grupo de seguridad de AD determinado heredarán los privilegios de nivel de base de datos otorgados a ese usuario de base de datos. En el siguiente ejemplo, puede ver cómo se asignan los privilegios de nivel de base de datos para el grupo de 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
```
Cree un usuario de base de datos [corp\$1sales-group] para el inicio de sesión en grupo de Windows [corp\$1accounts-group]. Para realizar este paso, conéctese a través del punto de conexión de TDS utilizando el inicio de sesión que sea miembro de sysadmin.
```
1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group];
2> GO
```
Ahora, conéctese como user1 de AD para comprobar el acceso a la tabla t1. Como aún no hemos otorgado los privilegios del nivel de base de datos, se generará un error de permiso denegado.
```
1> SELECT * FROM dbo.t1;
2> GO
Msg 33557097, Level 16, State 1, Server db-inst, Line 1
permission denied for table t1
```
Conceda SELECT en la tabla t1 al usuario de la base de datos [corp\$1accounts-group]. Para realizar este paso, conéctese a través del punto de conexión de TDS utilizando el inicio de sesión que sea miembro de sysadmin.
```
1> GRANT SELECT ON dbo.t1 TO [corp\accounts-group];
2> GO
```
Conéctese como user1 de AD para validar el acceso.
```
1> SELECT * FROM dbo.t1;
2> GO
a
-----------
(0 rows affected)
```
# Gestión del comportamiento de la instrucción DDL en función de un esquema predeterminado o explícito
Cuando se utiliza una sesión autenticada por AD, el esquema predeterminado de la sesión actual viene determinado por las siguientes condiciones:
+ Si existe un usuario de base de datos individual, el esquema predeterminado del usuario se considera el esquema predeterminado de la sesión actual.
+ Si hay un esquema predeterminado para un usuario de base de datos de grupo, el esquema predeterminado del usuario de la base de datos de grupo se considera el esquema predeterminado de la sesión actual, con el identificador principal más pequeño.
## Comprensión del comportamiento de la instrucción CREATE DDL
Si no hay ningún esquema explícito especificado en la instrucción CREATE DDL, la creación del objeto se realizará en el esquema predeterminado de la sesión actual. Si no se puede determinar si el esquema es predeterminado o explícito, la instrucción DDL generará el siguiente error:
```
"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 : Default schema doesn’t exist for Windows group user**
El usuario del grupo de Windows [corp\$1accounts-group] tiene un esquema predeterminado NULL y user1 de AD está intentando ejecutar la DDL sin especificar el esquema de forma explícita. Como no hay un usuario ni un inicio de sesión de Windows individual para user1, solo obtendrá los privilegios del nivel de base de datos del usuario de grupo de Windows [corp\$1accounts-group].
```
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.
```
No hay un usuario ni un inicio de sesión de Windows individual para user1 de AD
**Example : Default schema exists for Windows group users**
Cree un usuario de grupo de Windows para iniciar sesión en [corp accounts-group] con el esquema predeterminado mediante 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)
```
Intente crear un objeto sin especificar el esquema de forma explícita con user1 de AD. La tabla t2 se creará en el esquema predeterminado del usuario del grupo de Windows [corp\$1 accounts-group]. El propietario de este objeto será el mismo que el propietario del esquema 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)
```
No hay un usuario ni un inicio de sesión de Windows individual para user1 de AD
**Example : Individual database user also exists for an AD user**
Si también existe un usuario de base de datos individual para un usuario de AD, los objetos siempre se crearán en el esquema asociado al usuario de base de datos individual. Si no hay un esquema para el usuario de la base de datos, se utilizará el esquema dbo. Cree un usuario de base de datos y un inicio de sesión de Windows individuales para user1 de AD. Conexión a través del punto de conexión de TDS mediante un inicio de sesión 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)
```
Conéctese con user1 de AD e intente crear el objeto sin especificar el esquema explícitamente. La tabla t2 se creará en el esquema sch1. Tenga en cuenta que el propietario de este objeto será el mismo que el propietario del esquema 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)
```
# Limitaciones
+ La utilidad Dump/Restore no admite la descarga de las asignaciones de la extensión pg\$1ad\$1mapping. Deberá volver a crear esas asignaciones después de la restauración.
+ La implementación azul/verde no es compatible con las instancias de Aurora PostgreSQL y Babelfish con `pg_ad_mapping`.
+ No se admite la creación de esquemas implícitos. No se admiten las instrucciones DDL que requieran la creación de esquemas implícitos.
+ Los DDL de nivel de servidor ALTER AUTHORIZATION ON DATABASE, CREATE DATABASE, CREATE LOGIN, ALTER LOGIN, ALTER SERVER ROLE y ALTER DATABASE no se admiten en una sesión autenticada de Group AD cuando no existe un inicio de sesión individual de Windows (solo hay inicios de sesión de Windows en grupo). Para evitar esta limitación, es recomendable llevar a cabo estas operaciones en una sesión autenticada por contraseña o crear un inicio de sesión individual en Windows.
+ No se admite la creación de usuario implícito. El comportamiento ideal de T-SQL (de momento, no compatible con Babelfish). En algunos casos, como en las instrucciones DDL y de control de acceso (como GRANT/REVOKE) en las que se especifica el nombre del usuario de AD en el comando, pero no existe en la base de datos, se crea implícitamente el usuario de la base de datos, denominado usuario de AD.
+ Para los DDL en los procedimientos o funciones de PL/pgSQL que se crean desde el punto de conexión de PSQL y se ejecutan desde el punto de conexión de TDS en una sesión autenticada de Group AD:
+ Se admiten las instrucciones ALTER/DROP.
+ CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE FUNCTION/PROC, CREATE TYPE, CREATE SEQUENCE, CREATE TRIGGER, SELECT INTO, CREATE FULLTEXT INDEX y CREATE UNIQUE INDEX generarán un error si el esquema no se proporciona de forma explícita y el esquema predeterminado es nulo para la sesión actual.
+ CREATE DATABASE, CREATE EXTENSION, todas las demás instrucciones CREATE para objetos específicos de PG (no en T-SQL), CREATE subscription, CREATE tablespace, CREATE policy y CREATE conversion no son compatibles.
+ Los DDL del punto de conexión de PostgreSQL no se admiten en la sesión autenticada de Group AD. Como solución alternativa, siempre puede conectarse mediante un usuario maestro o cualquier otro usuario mediante un mecanismo de autenticación basado en contraseñas.
+ Los objetos del sistema, como SUSER\$1SID(), IS\$1SRVROLEMEMBER(), IS\$1MEMBER() o sys.dm\$1exec\$1sessions, tienen las siguientes limitaciones.
+ SUSER\$1SID () no devolverá el SID cuando se proporcione el usuario de AD o el grupo de seguridad de AD.
+ IS\$1SRVROLEMEMBER () no considerará la pertenencia al rol si el usuario actual de AD hereda la pertenencia al rol de servidor de algún miembro del rol de servidor del inicio de sesión en un grupo de Windows.
+ IS\$1MEMBER () devolverá el valor falso para cualquier consulta relacionada con un grupo de Windows.
+ sys.dm\$1exec\$1sessions no mostrará los valores esperados en las columnas login\$1name y nt\$1user\$1name.
# Conexión a Babelfish a través del punto de conexión de PostgreSQL en el puerto PostgreSQL
Puede utilizar inicios de sesión de grupo creados desde el puerto TDS para conectarse también a través del puerto PostgreSQL. Para conectarse a través del puerto PostgreSQL, debe especificar el nombre del usuario de AD en el formato `` desde las aplicaciones cliente de PostgreSQL. No puede utilizar el formato ``.
De forma predeterminada, PostgreSQL usa en los nombres de usuario comparaciones que distinguen entre mayúsculas y minúsculas. Para que Aurora PostgreSQL interprete los nombres de usuario de Kerberos sin distinción entre mayúsculas y minúsculas, debe configurar el parámetro krb\$1caseins\$1users como verdadero en el grupo de parámetros personalizado del clúster de Babelfish. Este parámetro está establecido en falso de forma predeterminada. Para obtener más información, consulte [Configuración del clúster de base de datos de Aurora PostgreSQL para nombres de usuario que no distinguen mayúsculas de minúsculas](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins.set-case-insentive).
## Diferencias de comportamiento entre los puntos de conexión de T-SQL y PostgreSQL cuando un usuario de AD forma parte de varios grupos
Tenga en cuenta que user1 de AD forma parte de dos grupos de seguridad de AD ([corp\$1accounts-group] y [corp\$1sales-group]) y que el administrador de base de datos ha configurado la asignación de usuarios de la siguiente manera.
```
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 el usuario se conecta desde el punto de conexión de T-SQL, heredará durante la autorización los privilegios de todos los inicios de sesión de T-SQL asociados. En este ejemplo, user1 heredará la unión de privilegios del inicio de sesión de ambos grupos T-SQL y se ignorarán las ponderaciones. Esto está en consonancia con el comportamiento estándar de T-SQL.
Sin embargo, si el mismo usuario se conecta desde el punto de conexión de PostgreSQL, solo puede heredar los privilegios de un inicio de sesión de T-SQL asociado, el que tenga la ponderación más alta. Si a los dos inicios de sesión de grupos T-SQL se les asignase la misma ponderación, el usuario de AD heredaría los privilegios del inicio de sesión T-SQL correspondiente a la asignación que se haya efectuado más recientemente. Para PostgreSQL, lo recomendable es especificar ponderaciones que reflejen los permisos y privilegios relativos de los roles de base de datos individuales, a fin de evitar la ambigüedad. En el siguiente ejemplo, user1 se ha conectado a través del punto de conexión de PSQL y ha heredado solo los privilegios de los grupos de ventas.
```
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)
```