# Configurar a autenticação do Kerberos usando grupos de segurança do Active Directory para Babelfish
A partir da versão 4.2.0 do Babelfish, é possível configurar a autenticação do Kerberos para o Babelfish com grupos de segurança do Active Directory. Veja a seguir os pré-requisitos a serem atendidos para configurar a autenticação do Kerberos usando o Active Directory:
+ É necessário seguir todas as etapas mencionadas em [Autenticação do Kerberos com o Babelfish](babelfish-active-directory.md).
+ A instância de banco de dados deve estar associada ao Active Directory. Para verificar isso, é possível visualizar o status da associação ao domínio no console ou executando o 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) da AWS CLI.
O status da instância de banco de dados deve ser habilitado para Kerberos. Para saber mais sobre a associação ao domínio, consulte [Compreensão da associação de domínio](postgresql-kerberos-managing.md#postgresql-kerberos-managing.understanding).
+ Verifique os mapeamentos entre o nome de domínio NetBIOS e o nome de domínio DNS usando a seguinte consulta:
```
SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping;
```
+ Antes de continuar, verifique se a autenticação do Kerberos usando o login individual funciona conforme o esperado. A conexão usando a autenticação do Kerberos como usuário do Active Directory deve ser bem-sucedida. Se você enfrentar algum problema, consulte [Erros que ocorrem com frequência](babelfish-active-directory.md#babelfish-active-directory-errors).
## Configurar a extensão pg\$1ad\$1mapping
É necessário seguir todas as etapas mencionadas em [Configurar a extensão pg\$1ad\$1mapping](AD.Security.Groups.md#AD.Security.Groups.Setup). Para verificar se a extensão está instalada, execute a seguinte consulta no endpoint do 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)
```
## Gerenciar logins de grupo
Crie logins de grupo seguindo as etapas mencionadas em [Gerenciar logins](babelfish-active-directory.md#babelfish-active-directory-login-managing). Recomendamos que o nome de login seja igual ao nome do grupo de segurança do Active Directory (AD) para facilitar a manutenção, embora não seja obrigatório. Por exemplo:
```
CREATE LOGIN [corp\accounts-group] FROM WINDOWS [WITH DEFAULT_DATABASE=database]
```
# Associar logins de grupos do T-SQL ao grupo de segurança do AD
É necessário provisionar explicitamente o login do grupo do T-SQL Windows para cada grupo de segurança do AD que exija acesso ao servidor de banco de dados. Um usuário do AD, que faz parte de pelo menos um grupo de segurança do AD provisionado, terá acesso ao servidor de banco de dados.
**nota**
Esse login do T-SQL não pode mais ser autenticado usando uma autenticação baseada em senha.
Por exemplo, accounts-group é um grupo de segurança no AD. Se você quiser provisionar esse grupo de segurança no Babelfish, deverá usar o formato [corp\$1accounts-group].
+ Grupo de segurança do AD: accounts-group
+ Login do TSQL: [corp\$1accounts-group]
+ Perfil do PG equivalente para determinado login do TSQL: accounts-group@CORP.EXAMPLE.COM
Agora o administrador pode continuar criando o mapeamento entre o grupo de segurança do AD e o login do T-SQL por meio do endpoint do PostgreSQL pelo comando psql a seguir. Para ter mais informações sobre o uso de funções, consulte [Usar funções da extensão `pg_ad_mapping`](AD.Security.Groups.md#AD.Security.Groups.functions).
**nota**
O login do T-SQL deve ser especificado no formato login\$1name@FQDN ao adicionar o mapeamento. Os pesos são ignorados quando a conexão é feita por meio do endpoint do TDS. Para ter mais informações sobre o uso de pesos, consulte [Conectar-se ao Babelfish via endpoint do PostgreSQL na porta do PostgreSQL](babelfish-kerberos-securityad-connect-pgendpoint.md).
```
postgres=>select pgadmap_set_mapping('accounts-group', 'accounts-group@CORP.EXAMPLE.COM', , );
```
Para ter informações sobre como recuperar o SID do grupo de segurança do AD, consulte [Recuperar o SID do grupo do Active Directory no PowerShell](AD.Security.Groups.md#AD.Security.Groups.retrieving).
A tabela a seguir mostra um exemplo de mapeamento dos grupos de segurança do AD para logins do T-SQL:
| Grupos de segurança do AD | Logins do TSQL | Perfil do PG equivalente para determinado login do TSQL | Weight |
| --- | --- | --- | --- |
| 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)
```
# Conectar-se ao Babelfish via endpoint do TDS
No exemplo a seguir, user1 é membro de accounts-group e sales-group, ao passo que user2 é membro de accounts-group e dev-group.
| Nome de usuário | Associação a grupos de segurança do AD |
| --- | --- |
| user1 | accounts-group, sales-group |
| user2 | accounts-group, dev-group |
Conecte-se ao servidor de banco de dados do Babelfish usando o utilitário sqlcmd. É possível verificar se um usuário (neste exemplo, user1) foi autenticado usando o Kerberos seguindo o exemplo abaixo:
```
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)
```
Neste exemplo, user1 herdará os privilégios de accounts-group e sales-group. É possível verificar a associação ao grupo usando a visualização `sys.login_token` do sistema.
```
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)
```
## Auditoria e registro em log
Para determinar a identidade principal de segurança do AD, use os seguintes comandos:
```
1> select suser_name();
2> GO
suser_name
----------
corp\user1
(1 rows affected)
```
No momento, a identidade do usuário do AD não está visível nos logs. É possível ativar o parâmetro `log_connections` para registrar o estabelecimento da sessão de banco de dados. Para ter mais informações, consulte [log\$1connections](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/log-connections.html). A saída inclui a identidade do usuário do AD como entidade principal, como mostra o exemplo a seguir. O PID de back-end associado a essa saída pode então ajudar a atribuir ações de volta ao usuário real do 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)
```
# Utilizar os privilégios da associação ao grupo de segurança do AD
## Herdar privilégios em nível de servidor
Os usuários do AD que são membros de determinado grupo de segurança do AD herdarão os privilégios em nível de servidor concedidos ao login do grupo mapeado do Windows. Por exemplo, pense no grupo de segurança `accounts-group` do AD, ao qual é concedida a associação ao perfil do servidor `sysadmin` no Babelfish. É possível herdar os privilégios em nível de servidor usando o seguinte comando:
```
1> ALTER SERVER ROLE sysadmin ADD MEMBER [corp\accounts-group];
```
Consequentemente, qualquer usuário do Active Directory que seja membro do grupo de segurança `accounts-group` do AD herdará os privilégios em nível de servidor associados ao perfil `sysadmin`. Isso significa que um usuário como `corp\user1`, sendo membro do `accounts-group`, agora terá a capacidade de realizar operações em nível de servidor no Babelfish.
**nota**
Para executar DDLs em nível de servidor, deve existir um login do Windows para um usuário individual do AD. Para obter mais informações, consulte [Limitações](babelfish-kerberos-securityad-limitations.md).
## Herdar privilégios em nível de banco de dados
Para conceder privilégios em nível de banco de dados, um usuário do banco de dados precisa ser criado e associado ao login do grupo do Windows. Os usuários do AD que são membros de determinado grupo de segurança do AD herdarão os privilégios em nível de banco de dados concedidos a esse usuário do banco de dados. No exemplo a seguir, é possível ver como são atribuídos privilégios em nível de banco de dados para o grupo do 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
```
Crie um usuário de banco de dados [corp\$1sales-group] para o login do grupo do Windows [corp\$1accounts-group]. Para executar essa etapa, conecte-se por meio do endpoint do TDS usando o login que é membro do sysadmin.
```
1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group];
2> GO
```
Agora se conecte como user1 do AD para conferir acesso à tabela t1. Como ainda não concedemos os privilégios em nível de banco de dados, isso gerará um erro de permissão negada.
```
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 na tabela t1 ao usuário do banco de dados [corp\$1accounts-group]. Para executar essa etapa, conecte-se por meio do endpoint do TDS usando o login que é membro do sysadmin.
```
1> GRANT SELECT ON dbo.t1 TO [corp\accounts-group];
2> GO
```
Conecte-se como user1 do AD para validar o acesso.
```
1> SELECT * FROM dbo.t1;
2> GO
a
-----------
(0 rows affected)
```
# Tratar o comportamento da declaração DDL com base no esquema padrão ou explícito
Ao usar uma sessão autenticada pelo AD, o esquema padrão da sessão atual é determinado pelas seguintes condições:
+ Se existir um usuário individual do banco de dados, o esquema padrão do usuário será considerado o esquema padrão da sessão atual.
+ Se o esquema padrão para um usuário do banco de dados de grupo existir, esse esquema será considerado o esquema padrão da sessão atual com o menor ID da entidade principal.
## Noções básicas sobre o comportamento da declaração CREATE DDL
Se não houver um esquema explícito especificado na declaração CREATE DDL, a criação do objeto ocorrerá no esquema padrão da sessão atual. Se não for possível determinar se o esquema é padrão ou explícito, a declaração DDL gerará o seguinte erro:
```
"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 : o esquema padrão não existe para o usuário do grupo do Windows.**
O usuário do grupo do Windows [corp\$1accounts-group] tem um esquema padrão NULL e o user1 do AD está tentando executar o DDL sem especificar o esquema explicitamente. Como o login e usuário individuais do Windows não existem para user1, ele receberá os privilégios de nível de banco de dados somente do usuário do grupo do 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.
```
O login e usuário individuais do Windows não existem para o user1 do AD.
**Example : existe um esquema padrão para usuários do grupo do Windows.**
Crie um usuário de grupo do Windows para login [corp\$1accounts-group] com esquema padrão usando 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)
```
Tente criar um objeto sem especificar explicitamente o esquema usando o user1 do AD. A tabela t2 será criada no esquema padrão do usuário do grupo do Windows [corp\$1accounts-group]. O proprietário desse objeto será o mesmo proprietário do 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)
```
O login e usuário individuais do Windows não existem para o user1 do AD.
**Example : o usuário individual do banco de dados também existe para um usuário do AD.**
Se também existir um usuário de banco de dados individual para um usuário do AD, os objetos sempre serão criados no esquema associado ao usuário individual do banco de dados. Se o esquema não existir para o usuário do banco de dados, o esquema dbo será usado. Crie um login e um usuário de banco de dados individuais do Windows para o user1 do AD. Conectar-se por meio do endpoint TDS usando um login de administrador do sistema
```
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)
```
Conecte-se utilizando o user1 do AD e tente criar um objeto sem especificar explicitamente o esquema. A tabela t2 será criada no esquema sch1. Observe também que o proprietário desse objeto será o mesmo do 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)
```
# Limitações
+ O utilitário Dump/Restore não comporta o despejo de mapeamentos da extensão pg\$1ad\$1mapping. Você precisará recriar esses mapeamentos após a restauração.
+ Não é possível usar implantação azul-verde com instâncias do Babelfish e do Aurora PostgreSQL com `pg_ad_mapping`.
+ A criação implícita de esquemas não é aceita. Também não é possível usar declarações DDL que exijam a criação implícita de um esquema.
+ As DDLs em nível de servidor ALTER AUTHORIZATION ON DATABASE, CREATE DATABASE, CREATE LOGIN, ALTER LOGIN, ALTER SERVER ROLE e ALTER DATABASE não são aceitas em uma sessão autenticada do Grupo AD quando existe apenas o login do Windows do grupo, mas não o login individual do Windows. Para contornar essa limitação, é recomendável realizar essas operações em uma sessão autenticada por senha ou criar um login individual do Windows.
+ A criação implícita de usuários não é aceita. Comportamento ideal do T-SQL [ainda não aceito no Babelfish]: em alguns casos, como DDL e declarações de controle de acesso, como GRANT/REVOKE, em que o nome do usuário do AD é especificado no comando, mas não existe no banco de dados, o usuário do banco de dados nomeado como usuário do AD é criado implicitamente.
+ Para DDLs em procedimentos ou funções PL/pgSQL que são criados por meio do endpoint PSQL e executados com o endpoint TDS na sessão autenticada do Grupo AD:
+ As declarações ALTER/DROP serão aceitas.
+ CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE FUNCTION/PROC, CREATE TYPE, CREATE SEQUENCE, CREATE TRIGGER, SELECT INTO, CREATE FULLTEXT INDEX e CREATE UNIQUE INDEX vão gerar um erro se o esquema não for fornecido explicitamente e o esquema padrão for nulo para a sessão atual.
+ CREATE DATABASE, CREATE EXTENSION e todas as outras declarações CREATE para objetos específicos de PG (não em T-SQL), como CREATE subscription, CREATE tablespace, CREATE policy e CREATE conversion, não serão aceitas.
+ As DDLs do endpoint PostgreSQL não são aceitas na sessão autenticada do Grupo AD. Como solução alternativa, você sempre pode se conectar usando o usuário principal ou qualquer outro usuário usando o mecanismo de autenticação baseado em senha.
+ Objetos do sistema, como SUSER\$1SID (), IS\$1SRVROLEMEMBER (), IS\$1MEMBER () e sys.dm\$1exec\$1sessions, têm as limitações a seguir.
+ SUSER\$1SID () não exibirá o SID quando o usuário do AD ou o grupo de segurança do AD forem fornecidos.
+ IS\$1SRVROLEMEMBER () não considerará a associação ao perfil se o usuário atual do AD estiver herdando a associação ao perfil de servidor de qualquer associação ao perfil de servidor de login do grupo do Windows.
+ IS\$1MEMBER() exibirá falso para qualquer consulta relacionada ao grupo do Windows.
+ sys.dm\$1exec\$1sessions não mostrará as colunas login\$1name e nt\$1user\$1name dos valores esperados.
# Conectar-se ao Babelfish via endpoint do PostgreSQL na porta do PostgreSQL
É possível utilizar logins de grupo criados por meio da porta do TDS para se conectar por meio da porta do PostgreSQL. Para se conectar por meio da porta do PostgreSQL, é necessário especificar o nome do usuário do AD no formato `` das aplicações cliente do PostgreSQL. Não é possível usar o formato ``.
No entanto, o PostgreSQL usa comparações com distinção de maiúsculas e minúsculas por padrão para nomes de usuário. Para que o Aurora PostgreSQL interprete os nomes de usuário do Kerberos sem fazer distinção de maiúsculas e minúsculas, é necessário definir o parâmetro krb\$1caseins\$1users como verdadeiro no grupo de parâmetros de cluster personalizado do Babelfish. Esse parâmetro é definido como falso por padrão. Para obter mais informações, consulte [Configurar seu cluster de banco de dados do Aurora PostgreSQL para nomes de usuário que não fazem distinção de maiúsculas e minúsculas](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins.set-case-insentive).
## Diferenças de comportamento entre endpoints do T-SQL e do PostgreSQL quando um usuário do AD faz parte de vários grupos
Suponha que o usuário user1 do AD faça parte de dois grupos de segurança do AD [corp\$1accounts-group] e [corp\$1sales-group] e o administrador do banco de dados tenha definido o mapeamento do usuário da maneira a seguir.
```
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)
```
Se o usuário estiver se conectando por meio do endpoint do T-SQL, durante a autorização ele herdará os privilégios de todos os logins do T-SQL associados. Neste exemplo, user1 herdará a união de privilégios dos logins do grupo do T-SQL e os pesos serão ignorados. Isso está alinhado com o comportamento padrão do T-SQL.
No entanto, se o mesmo usuário se conectar por meio do endpoint do PostgreSQL, ele poderá herdar privilégios apenas de um login do T-SQL correspondente com o maior peso. Se os logins de dois grupos do T-SQL tiverem o mesmo peso, o usuário do AD herdará os privilégios do login do T-SQL correspondentes ao mapeamento que foi adicionado mais recentemente. Com relação ao PostgreSQL, a recomendação é especificar pesos que reflitam as permissões e privilégios relativos dos perfis individuais do banco de dados para evitar ambiguidade. No exemplo abaixo, user1 se conectou por meio do endpoint do PSQL e herdou somente privilégios de grupos de vendas.
```
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)
```