# Database authentication with Babelfish for Aurora PostgreSQL
Babelfish for Aurora PostgreSQL supports two ways to authenticate database users. Password authentication is available by default for all Babelfish DB clusters. You can also add Kerberos authentication for the same DB cluster.
**Topics**
+ [Password authentication with Babelfish](#babelfish-authentication)
+ [Kerberos authentication with Babelfish](babelfish-active-directory.md)
+ [Setting up Kerberos authentication using Active Directory security groups for Babelfish](babelfish-kerberos-securityad.md)
## Password authentication with Babelfish
Babelfish for Aurora PostgreSQL supports password authentication. Passwords are stored in encrypted form on disk. For more information about authentication on an Aurora PostgreSQL cluster, see [Security with Amazon Aurora PostgreSQL](AuroraPostgreSQL.Security.md).
You might be prompted for credentials each time you connect to Babelfish. Any user migrated to or created on Aurora PostgreSQL can use the same credentials on both the SQL Server port and the PostgreSQL port. Babelfish doesn't enforce password policies, but we recommend that you do the following:
+ Require a complex password that's at least eight (8) characters long.
+ Enforce a password expiration policy.
To review a complete list of database users, use the command `SELECT * FROM pg_user;`.
# Kerberos authentication with Babelfish
Babelfish for Aurora PostgreSQL 15.2 version supports authentication to your DB cluster using Kerberos. This method allows you to use Microsoft Windows Authentication to authenticate users when they connect to your Babelfish database. To do so, you must first configure your DB cluster to use AWS Directory Service for Microsoft Active Directory for Kerberos authentication. For more information, see [What is Directory Service?](https://docs.aws.amazon.com/directoryservice/latest/admin-guide/what_is.html) in the *AWS Directory Service Administration Guide*.
## Setting up Kerberos Authentication
Babelfish for Aurora PostgreSQL DB cluster can connect using two different ports, but Kerberos authentication setup is a one-time process. Therefore, you must first set up Kerberos authentication for your DB cluster. For more information, see [ Setting up Kerberos authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/postgresql-kerberos-setting-up.html). After completing the setup, ensure that you can connect with a PostgreSQL client using Kerberos. For more information, see [Connecting with Kerberos Authentication](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/postgresql-kerberos-connecting.html).
## Login and user provisioning in Babelfish
Windows logins created from the Tabular Data Stream (TDS) port can be used either with the TDS port or the PostgreSQL port. First, the login that can use Kerberos for authentication must be provisioned from the TDS port before it is used by the T-SQL users and applications to connect to a Babelfish database. When creating Windows logins, administrators can provide the login using either the DNS domain name or the NetBIOS domain name. Typically, NetBIOS domain is the subdomain of the DNS domain name. For example, if the DNS domain name is `CORP.EXAMPLE.COM`, then the NetBIOS domain can be `CORP`. If the NetBIOS domain name format is provided for a login, a mapping must exist to the DNS domain name.
### Managing NetBIOS domain name to DNS domain name mapping
To manage mappings between the NetBIOS domain name and DNS domain name, Babelfish provides system stored procedures to add, remove, and truncate mappings. Only a user with a `sysadmin` role can run these procedures.
To create mapping between NetBIOS and DNS domain name, use the Babelfish provided system stored procedure `babelfish_add_domain_mapping_entry`. Both arguments must have a valid value and are not NULL.
**Example**
```
EXEC babelfish_add_domain_mapping_entry 'netbios_domain_name', 'fully_qualified_domain_name'
```
The following example shows how to create the mapping between the NetBIOS name CORP and DNS domain name CORP.EXAMPLE.COM.
**Example**
```
EXEC babelfish_add_domain_mapping_entry 'corp', 'corp.example.com'
```
To delete an existing mapping entry, use the system stored procedure babelfish\$1remove\$1domain\$1mapping\$1entry.
**Example**
```
EXEC babelfish_remove_domain_mapping_entry 'netbios_domain_name'
```
The following example shows how to remove the mapping for the NetBIOS name CORP.
**Example**
```
EXEC babelfish_remove_domain_mapping_entry 'corp'
```
To remove all existing mapping entries, use the system stored procedure babelfish\$1truncate\$1domain\$1mapping\$1table:
**Example**
```
EXEC babelfish_truncate_domain_mapping_table
```
To view all mappings between NetBIOS and DNS domain name, use the following query.
**Example**
```
SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping;
```
### Managing Logins
**Create logins**
Connect to the DB through the TDS endpoint using a login that has the correct permissions. If there is no database user created for the login, then the login is mapped to guest user. If the guest user is not enabled, then the login attempt fails.
Create a Windows login using the following query. The `FROM WINDOWS` option allows authentication using Active Directory.
```
CREATE LOGIN login_name FROM WINDOWS [WITH DEFAULT_DATABASE=database]
```
**Example**
The following example shows creating a login for the Active Directory user [corp\$1test1] with a default database of db1.
```
CREATE LOGIN [corp\test1] FROM WINDOWS WITH DEFAULT_DATABASE=db1
```
This example assumes that there is a mapping between the NetBIOS domain CORP and the DNS domain name CORP.EXAMPLE.COM. If there is no mapping, then you must provide the DNS domain name [CORP.EXAMPLE.COM\$1test1].
**Note**
Logins based on Active Directory users, are limited to names of fewer than 21 characters.
**Drop login**
To drop a login, use the same syntax as for any login, as shown in the following example:
```
DROP LOGIN [DNS domain name\login]
```
**Alter login**
To alter a login, use the same syntax as for any login, as in the following example:
```
ALTER LOGIN [DNS domain name\login] { ENABLE|DISABLE|WITH DEFAULT_DATABASE=[master] }
```
The ALTER LOGIN command supports limited options for Windows logins, including the following:
+ DISABLE – To disable a login. You can't use a disabled login for authentication.
+ ENABLE – To enable a disabled login.
+ DEFAULT\$1DATABASE – To change the default database of a login.
**Note**
All password management is performed through Directory Service, so the ALTER LOGIN command doesn't allow database administrators to change or set passwords for Windows logins.
### Connecting to Babelfish for Aurora PostgreSQL with Kerberos authentication
Typically, the database users who authenticate using Kerberos are doing so from their client machines. These machines are members of the Active Directory domain. They use Windows Authentication from their client applications to access the Babelfish for Aurora PostgreSQL server on the TDS port.
### Connecting to Babelfish for Aurora PostgreSQL on the PostgreSQL port with Kerberos authentication
You can use logins created from the TDS port with either the TDS port or the PostgreSQL port. However, PostgreSQL uses case-sensitive comparisons by default for usernames. For Aurora PostgreSQL to interpret Kerberos usernames as case-insensitive, you must set the `krb_caseins_users` parameter as `true` in the custom Babelfish cluster parameter group. This parameter is set to `false` by default. For more information, see [ Configuring for case-insensitive user names](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/postgresql-kerberos-setting-up.html#postgresql-kerberos-setting-up.create-logins.set-case-insentive). In addition, you must specify the login username in the format from the PostgreSQL client applications. You can't use format.
### Frequently occurring errors
You can configure forest trust relationships between your on-premises Microsoft Active Directory and the AWS Managed Microsoft AD. For more information, see [Create a trust relationship](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/postgresql-kerberos-setting-up.html#postgresql-kerberos-setting-up.create-trust). Then, you must connect using a specialized domain specific endpoint instead of using the Amazon domain `rds.amazonaws.com` in the host endpoint. If you don't use the correct domain specific endpoint, you might encounter the following error:
```
Error: “Authentication method "NTLMSSP" not supported (Microsoft SQL Server, Error: 514)"
```
This error occurs when the TDS client can't cache the service ticket for the supplied endpoint URL. For more information, see [Connecting with Kerberos](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/postgresql-kerberos-connecting.html).
# Setting up Kerberos authentication using Active Directory security groups for Babelfish
Starting from Babelfish version 4.2.0, you can setup Kerberos authentication for Babelfish with Active Directory security groups. The following are prerequisites to complete for setting up Kerberos authentication using Active Directory:
+ You must follow all the steps mentioned at [Kerberos authentication with Babelfish](babelfish-active-directory.md).
+ Ensure that DB instance is associated with Active Directory. To verify this, you can view the status of the domain membership in the console or by running the [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 command.
The status of the DB instance should be kerberos-enabled. For more information on understanding domain membership, see [Understanding Domain membership](postgresql-kerberos-managing.md#postgresql-kerberos-managing.understanding).
+ Verify mappings between NetBIOS domain name and DNS domain name using the following query:
```
SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping;
```
+ Before proceeding further, verify Kerberos authentication using individual login works as expected. The connection using Kerberos authentication as an Active Directory user should be successful. If you face any issues, see [Frequently occurring errors](babelfish-active-directory.md#babelfish-active-directory-errors).
## Setting up the pg\$1ad\$1mapping extension
You must follow all the steps mentioned at [Setting up the pg\$1ad\$1mapping extension](AD.Security.Groups.md#AD.Security.Groups.Setup) . To verify that the extension is installed, run the following query from TDS endpoint:
```
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)
```
## Managing Group Logins
Create group logins by following the steps mentioned at [Managing Logins](babelfish-active-directory.md#babelfish-active-directory-login-managing). We recommend that the login name be the same as the Active Directory (AD) security group name for easier maintenance, although it's not mandatory. For example:
```
CREATE LOGIN [corp\accounts-group] FROM WINDOWS [WITH DEFAULT_DATABASE=database]
```
# Mapping T-SQL group logins with AD security group
You need to explicitly provision T-SQL Windows Group Login for each AD security group that requires access to the database server. An AD user, who is part of at least one provisioned AD security group, will get access to the database server.
**Note**
This T-SQL login can no longer authenticate using a password based authentication.
For example, accounts-group is a security group in AD and if you would like to provision this security group in Babelfish, you must use the format [corp\$1accounts-group].
+ AD Security Group : accounts-group
+ TSQL Login : [corp\$1accounts-group]
+ Equivalent PG role for given TSQL Login : accounts-group@CORP.EXAMPLE.COM
Admin can now proceed to create the mapping between AD security group and T-SQL login from PostgreSQL endpoint via following psql command. For more information on the function usage, see [Using functions from the `pg_ad_mapping` extension](AD.Security.Groups.md#AD.Security.Groups.functions).
**Note**
T-SQL login should be specified in login\$1name@FQDN format while adding the mapping. Weights are ignored when connecting through TDS endpoint. For more information about usage of weights, see [Connecting to Babelfish via PostgreSQL endpoint on the PostgreSQL port](babelfish-kerberos-securityad-connect-pgendpoint.md).
```
postgres=>select pgadmap_set_mapping('accounts-group', 'accounts-group@CORP.EXAMPLE.COM', , );
```
For information on retrieving SID of AD security group, see [Retrieving Active Directory Group SID in PowerShell](AD.Security.Groups.md#AD.Security.Groups.retrieving).
The following table shows a sample mapping from AD security groups to T-SQL logins:
| AD Security Groups | TSQL Logins | Equivalent PG role for given TSQL Login | 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)
```
# Connecting to Babelfish via TDS endpoint
In the following example, user1 is member of accounts-group and sales-group, user2 is member of accounts-group and dev-group.
| Username | AD Security Groups membership |
| --- | --- |
| user1 | accounts-group, sales-group |
| user2 | accounts-group, dev-group |
Connect to Babelfish database server using sqlcmd utility. You can verify if an user (user1 in this example) was authenticated using Kerberos by following the example below:
```
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)
```
In this example, user1 will inherit the privileges of accounts-group and sales-group. You can verify the group membership using `sys.login_token` system view.
```
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)
```
## Auditing and Logging
To determine the AD security principal identity, use the following commands:
```
1> select suser_name();
2> GO
suser_name
----------
corp\user1
(1 rows affected)
```
Currently, AD user identity isn't visible in the logs. You can turn on the `log_connections` parameter to log DB session establishment. For more information, see [log\$1connections](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/log-connections.html). The output includes the AD user identity as principal as shown in the following example. The backend PID associated with this output can then help attribute actions back to the actual AD user.
```
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)
```
# Utilizing privileges of AD security group membership
## Inheriting server-level privileges
AD users that are members of given AD security group will inherit server-level privileges granted to the mapped Windows group login. For example, consider the `accounts-group` AD security group, that is granted membership to the `sysadmin` server role on the Babelfish. You can inherit the server-level privileges using the following command:
```
1> ALTER SERVER ROLE sysadmin ADD MEMBER [corp\accounts-group];
```
Consequently, any Active Directory user who is a member of the `accounts-group` AD security group will inherit the server-level privileges associated with the `sysadmin` role. This means that a user like `corp\user1`, being a member of `accounts-group`, will now have the ability to perform server-level operations within Babelfish.
**Note**
To perform server-level DDLs, Windows login for individual AD user must exist. For more information, see [Limitations](babelfish-kerberos-securityad-limitations.md).
## Inheriting database-level privileges
To grant the database level privileges, a database user has to be created and mapped with Windows group login. AD users which are members of given AD security group will inherit database-level privileges granted to that database user. In the following example, you can see how database level privileges for Windows group [corp\$1accounts-group] are assigned.
```
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
```
Create a database user [corp\$1sales-group] for Windows group login [corp\$1accounts-group]. To perform this step, connect through TDS endpoint using login who is a member of sysadmin.
```
1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group];
2> GO
```
Now, connect as AD user user1 to check access of table t1. Since we have not yet granted the database level privileges, it will result in permission denied error.
```
1> SELECT * FROM dbo.t1;
2> GO
Msg 33557097, Level 16, State 1, Server db-inst, Line 1
permission denied for table t1
```
Grant SELECT on table t1 to database user [corp\$1accounts-group]. To perform this step, connect through TDS endpoint using login who is member of sysadmin.
```
1> GRANT SELECT ON dbo.t1 TO [corp\accounts-group];
2> GO
```
Connect as AD user user1 to validate the access.
```
1> SELECT * FROM dbo.t1;
2> GO
a
-----------
(0 rows affected)
```
# Handling DDL Statement behavior based on default or explicit schema
When using an AD authenticated session, the default schema for the current session is determined by the following conditions:
+ If an individual database user exists, the user's default schema is considered as current session’s default schema.
+ If the default schema for a group database user exists, the group database user's default schema is considered as current session’s default schema with the smallest principal id.
## Understanding CREATE DDL statement behavior
If there is no explicit schema specified in the CREATE DDL statement then object creation will take place in the default schema of current session. If the schema can't be determined whether default or explicit, then the DDL statement will throw following 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**
Windows group user [corp\$1accounts-group] have NULL default schema and AD user user1 is trying to perform the DDL without specifying the schema explicitly. Since individual windows login and user doesn’t exist for user1, it will get the database level privileges of Windows group user [corp\$1accounts-group] only.
```
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.
```
Individual windows login and user doesn’t exist for AD user user1
**Example : Default schema exists for Windows group users**
Create Windows group user for [corp\$1accounts-group] login with default schema using 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)
```
Try creating object without specifying schema explicitly using AD user user1. Table t2 will be created in default schema of [corp\$1accounts-group] Windows group user Owner of this object will be same as owner of schema 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)
```
Individual windows login and user doesn’t exist for AD user user1
**Example : Individual database user also exists for an AD user**
If an individual database user also exists for an AD user then the objects will always be created in the schema associated with individual database user. If the schema doesn’t exist for the database user then dbo schema will be used. Create individual windows login and database user for AD user user1. Connect through TDS endpoint using a sysadmin login
```
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)
```
Connect using AD user user1 and try creating object without specifying schema explicitly. Table t2 will be created in schema sch1. Also note that owner of this object will be same as owner of schema 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
+ Dump/Restore utility doesn’t support dumping the pg\$1ad\$1mapping extension mappings. You will need to recreate those mappings after restore.
+ Blue-Green deployment isn't supported for Babelfish and Aurora PostgreSQL instances with `pg_ad_mapping`.
+ Implicit schema creation is not supported. DDL statements that requires implicit schema creation isn't supported.
+ Server-level DDLs ALTER AUTHORIZATION ON DATABASE , CREATE DATABASE, CREATE LOGIN, ALTER LOGIN, ALTER SERVER ROLE, ALTER DATABASE are not supported in a Group AD authenticated session when individual Windows login doesn’t exist, only group Windows login exists. To workaround this limitation, It is recommended to perform these operations in a password authenticated session or create individual Windows login.
+ Implicit user creation isn't supported. Ideal T-SQL behavior [not yet supported in Babelfish]; In some cases like DDL and access-control statements like GRANT/REVOKE where AD user’s name is specified in the command but it doesn’t exist in database then database user named as AD user get implicitly created.
+ For DDLs in PL/pgSQL Procedures or Functions which are created from PSQL endpoint and gets executed from TDS endpoint in Group AD authenticated session:
+ ALTER/DROP statements will be supported.
+ CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE FUNCTION/PROC, CREATE TYPE, CREATE SEQUENCE, CREATE TRIGGER, SELECT INTO, CREATE FULLTEXT INDEX , CREATE UNIQUE INDEX will throw an error if schema is not provided explicitly and default schema is null for current session.
+ CREATE DATABASE , CREATE EXTENSION and all other CREATE statements for PG(not in T-SQL) specific objects CREATE subscription, CREATE tablespace, CREATE policy, CREATE conversion will not be supported.
+ DDLs from PostgreSQL endpoint is not supported in Group AD authenticated session. As a workaround, you can always connect using master user or any other user using password based authentication mechanism.
+ System objects like SUSER\$1SID(), IS\$1SRVROLEMEMBER(), IS\$1MEMBER(), sys.dm\$1exec\$1sessions has following limitations.
+ SUSER\$1SID() won’t return the SID when AD User or AD Security Group is supplied.
+ IS\$1SRVROLEMEMBER() won’t consider the role membership if current AD user is inheriting the server role membership from any Windows group login’s server role membership.
+ IS\$1MEMBER() will return false for any Windows Group related query.
+ sys.dm\$1exec\$1sessions won’t show expected values login\$1name, nt\$1user\$1name columns.
# Connecting to Babelfish via PostgreSQL endpoint on the PostgreSQL port
You can utilize group logins created from the TDS port to connect through PostgreSQL port as well. To connect through PostgreSQL port, you need to specify the AD user's name in the format `` from the PostgreSQL client applications. You can't use the `` format.
PostgreSQL uses case-sensitive comparisons by default for usernames. For Aurora PostgreSQL to interpret Kerberos usernames as case-insensitive, you must set the krb\$1caseins\$1users parameter as true in the custom Babelfish cluster parameter group. This parameter is set to false by default. For more information, see [Configuring your Aurora PostgreSQL DB cluster for case-insensitive user names](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins.set-case-insentive).
## Behavior differences between T-SQL and PostgreSQL endpoints when an AD user is part of multiple groups
Consider that AD user user1 is part of two AD security groups [corp\$1accounts-group] and [corp\$1sales-group] and DB admin has set the user mapping in following way.
```
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)
```
If the user is connecting from the T-SQL endpoint then during the authorization, it will inherit the privileges from all the associated T-SQL logins. In this example user1 will inherit the union of privileges from both the T-SQL group login and weights will be ignored. This is inline with the standard T-SQL behavior.
However if same user connects from the PostgreSQL endpoint then it can inherit privileges from only one associated T-SQL login with the highest weight. If the two T-SQL group login were assigned same weight then AD user will inherit the privileges of the T-SQL login corresponding to the mapping that was added most recently. For the PostgreSQL, the recommendation is to specify weights that reflect the relative permissions/privileges of individual DB roles to avoid the ambiguity. In below example, user1 connected through PSQL endpoint and inherited only sales-groups privileges.
```
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)
```