# Babelfish용 Active Directory 보안 그룹을 사용하여 Kerberos 인증 설정
Babelfish 버전 4.2.0부터 Active Directory 보안 그룹을 사용하여 Babelfish에 대한 Kerberos 인증을 설정할 수 있습니다. Active Directory를 사용하여 Kerberos 인증을 설정하려면 완료해야 하는 사전 조건은 다음과 같습니다.
+ [Babelfish를 사용하는 Kerberos 인증](babelfish-active-directory.md)에 언급된 모든 단계를 따라야 합니다.
+ DB 인스턴스가 Active Directory와 연결되어 있는지 확인합니다. 콘솔에서 또는 [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 명령을 실행하여 도메인 구성원 자격 상태를 보고 확인할 수 있습니다.
DB 인스턴스의 상태가 kerberos를 지원해야 합니다. 도메인 구성원 자격 이해에 대한 자세한 내용은 [도메인 멤버십 이해](postgresql-kerberos-managing.md#postgresql-kerberos-managing.understanding) 섹션을 참조하세요.
+ 다음 쿼리를 사용하여 NetBIOS 도메인 이름과 DNS 도메인 이름 간의 매핑을 확인합니다.
```
SELECT netbios_domain_name, fq_domain_name FROM babelfish_domain_mapping;
```
+ 계속 진행하기 전에 개별 로그인을 사용한 Kerberos 인증이 예상대로 작동하는지 확인합니다. Active Directory 사용자로서 Kerberos 인증을 사용한 연결이 성공해야 합니다. 문제가 발생하는 경우 [자주 발생하는 오류](babelfish-active-directory.md#babelfish-active-directory-errors) 섹션을 참조하세요.
## pg\$1ad\$1mapping 확장 설정
[pg\$1ad\$1mapping 확장 설정](AD.Security.Groups.md#AD.Security.Groups.Setup)에 언급된 모든 단계를 따라야 합니다. 확장 프로그램이 설치되었는지 확인하려면 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)
```
## 그룹 로그인 관리
[로그인 관리](babelfish-active-directory.md#babelfish-active-directory-login-managing)에 설명된 단계에 따라 그룹 로그인을 생성합니다. 필수는 아니지만, 유지 관리가 용이하도록 로그인 이름을 Active Directory(AD) 보안 그룹 이름과 동일하게 사용하는 것이 좋습니다. 예제:
```
CREATE LOGIN [corp\accounts-group] FROM WINDOWS [WITH DEFAULT_DATABASE=database]
```
# T-SQL 그룹 로그인과 AD 보안 그룹 매핑
데이터베이스 서버에 대한 액세스가 필요한 각 AD 보안 그룹에 대해 T-SQL Windows 그룹 로그인을 명시적으로 프로비저닝해야 합니다. 하나 이상의 프로비저닝된 AD 보안 그룹에 속하는 AD 사용자는 데이터베이스 서버에 액세스할 수 있습니다.
**참고**
이 T-SQL 로그인은 더 이상 암호 기반 인증을 사용하여 인증할 수 없습니다.
예를 들어, accounts-group은 AD의 보안 그룹이며 Babelfish에서 이 보안 그룹을 프로비저닝하려는 경우 [corp\$1accounts-group] 형식을 사용해야 합니다.
+ AD 보안 그룹: accounts-group
+ TSQL 로그인: [corp\$1accounts-group]
+ 지정된 TSQL 로그인에 해당하는 PG 역할: accounts-group@CORP.EXAMPLE.COM
이제 관리자는 다음 psql 명령을 통해 PostgreSQL 엔드포인트에서 AD 보안 그룹과 T-SQL 로그인 간의 매핑을 생성할 수 있습니다. 함수 사용에 대한 자세한 내용은 [`pg_ad_mapping` 확장의 함수 사용](AD.Security.Groups.md#AD.Security.Groups.functions) 섹션을 참조하세요.
**참고**
매핑을 추가할 때 T-SQL 로그인을 login\$1name@FQDN 형식으로 지정해야 합니다. TDS 엔드포인트를 통해 연결할 때는 가중치가 무시됩니다. 가중치 사용에 대한 자세한 내용은 [PostgreSQL 포트의 PostgreSQL 엔드포인트를 통해 Babelfish에 연결](babelfish-kerberos-securityad-connect-pgendpoint.md) 섹션을 참조하세요.
```
postgres=>select pgadmap_set_mapping('accounts-group', 'accounts-group@CORP.EXAMPLE.COM', , );
```
AD 보안 그룹의 SID 검색에 대한 자세한 내용은 [PowerShell에서 Active Directory 그룹 SID 검색](AD.Security.Groups.md#AD.Security.Groups.retrieving) 섹션을 참조하세요.
다음 표에는 AD 보안 그룹에서 T-SQL 로그인으로의 샘플 매핑이 나와 있습니다.
| AD 보안 그룹 | TSQL 로그인 | 지정된 TSQL 로그인에 해당하는 PG 역할 | 가중치 |
| --- | --- | --- | --- |
| 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)
```
# TDS 엔드포인트를 통해 Babelfish에 연결
다음 예제에서 user1은 accounts-group 및 sales-group의 구성원이고, user2는 accounts-group 및 dev-group의 구성원입니다.
| 사용자 이름 | AD 보안 그룹 구성원 자격 |
| --- | --- |
| user1 | accounts-group, sales-group |
| user2 | accounts-group, dev-group |
sqlcmd 유틸리티를 사용하여 Babelfish 데이터베이스 서버에 연결합니다. 아래 예제에 따라 사용자(이 예제에서는 user1)가 Kerberos를 사용하여 인증되었는지 확인할 수 있습니다.
```
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)
```
이 예제에서 user1은 accounts-group 및 sales-group의 권한을 상속합니다. `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)
```
## 감사 및 로깅
AD 보안 주체 ID를 확인하려면 아래 명령을 사용하세요.
```
1> select suser_name();
2> GO
suser_name
----------
corp\user1
(1 rows affected)
```
현재로서는 AD 사용자 ID가 로그에 표시되지 않습니다. `log_connections` 파라미터를 설정하여 DB 세션 설정을 로깅할 수 있습니다. 자세한 내용은 [log\$1connections](https://docs.aws.amazon.com/prescriptive-guidance/latest/tuning-postgresql-parameters/log-connections.html)를 참조하세요. 다음 예제와 같이 출력에 AD 사용자 ID가 보안 주체로 포함됩니다. 이 출력과 관련된 백엔드 PID는 실제 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)
```
# AD 보안 그룹 구성원 자격 권한 활용
## 서버 수준 권한 상속
지정된 AD 보안 그룹의 구성원인 AD 사용자는 매핑된 Windows 그룹 로그인에 부여된 서버 수준 권한을 상속합니다. Babelfish의 `sysadmin` 서버 역할에 대한 구성원 자격이 부여된 `accounts-group` AD 보안 그룹을 예로 들어 보겠습니다. 다음 명령을 사용하여 서버 수준 권한을 상속할 수 있습니다.
```
1> ALTER SERVER ROLE sysadmin ADD MEMBER [corp\accounts-group];
```
따라서 `accounts-group` AD 보안 그룹의 구성원인 Active Directory 사용자는 `sysadmin` 역할과 관련된 서버 수준 권한을 상속받게 됩니다. 즉, `accounts-group`의 구성원인 `corp\user1`과 같은 사용자도 이제 Babelfish 내에서 서버 수준 작업을 수행할 수 있습니다.
**참고**
서버 수준 DDL을 수행하려면 개별 AD 사용자에 대한 Windows 로그인이 있어야 합니다. 자세한 내용은 [제한 사항](babelfish-kerberos-securityad-limitations.md) 섹션을 참조하세요.
## 데이터베이스 수준 권한 상속
데이터베이스 수준 권한을 부여하려면 Windows 그룹 로그인으로 데이터베이스 사용자를 만들고 매핑해야 합니다. 지정된 AD 보안 그룹의 구성원인 AD 사용자는 해당 데이터베이스 사용자에게 부여된 데이터베이스 수준 권한을 상속합니다. 다음 예제에서는 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
```
Windows 그룹 로그인 [corp\$1accounts-group]을 위한 데이터베이스 사용자 [corp\$1sales-group]을 생성합니다. 이 단계를 수행하려면 sysadmin의 구성원인 로그인을 사용하여 TDS 엔드포인트를 통해 연결하세요.
```
1> CREATE USER [corp\accounts-group] FOR LOGIN [corp\accounts-group];
2> GO
```
이제 AD 사용자 user1으로 연결하여 표 t1의 액세스 권한을 확인합니다. 아직 데이터베이스 수준 권한을 부여하지 않았으므로, 권한 거부 오류가 발생합니다.
```
1> SELECT * FROM dbo.t1;
2> GO
Msg 33557097, Level 16, State 1, Server db-inst, Line 1
permission denied for table t1
```
데이터베이스 사용자 [corp\$1accounts-group]에게 표 t1의 SELECT 권한을 부여하세요. 이 단계를 수행하려면 sysadmin의 구성원인 로그인을 사용하여 TDS 엔드포인트를 통해 연결하세요.
```
1> GRANT SELECT ON dbo.t1 TO [corp\accounts-group];
2> GO
```
AD 사용자 user1으로 연결하여 액세스를 검증합니다.
```
1> SELECT * FROM dbo.t1;
2> GO
a
-----------
(0 rows affected)
```
# 기본 또는 명시적 스키마를 기반으로 DDL 문 동작 처리
AD 인증 세션을 사용하는 경우 현재 세션의 기본 스키마는 다음 조건에 따라 결정됩니다.
+ 개별 데이터베이스 사용자가 있는 경우 사용자의 기본 스키마가 현재 세션의 기본 스키마로 간주됩니다.
+ 그룹 데이터베이스 사용자의 기본 스키마가 있는 경우 그룹 데이터베이스 사용자의 기본 스키마는 보안 주체 ID가 최소인 현재 세션의 기본 스키마로 간주됩니다.
## CREATE DDL 문 동작에 대한 이해
CREATE DDL 문에 명시적 스키마가 지정되지 않은 경우 현재 세션의 기본 스키마에서 객체 생성이 수행됩니다. 스키마가 기본값으로든 명시적으로든 확인할 수 없는 경우 DDL 문에서 다음 오류가 발생합니다.
```
"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 : Windows 그룹 사용자의 기본 스키마가 존재하지 않습니다.**
Windows 그룹 사용자 [corp\$1accounts-group]의 기본 스키마가 NULL이고 AD 사용자 user1이 스키마를 명시적으로 지정하지 않고 DDL을 수행하려고 합니다. user1에는 개별 Windows 로그인 및 사용자가 존재하지 않으므로, 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.
```
AD 사용자 user1에는 개별 Windows 로그인 및 사용자가 존재하지 않습니다.
**Example : Windows 그룹 사용자의 기본 스키마가 있습니다.**
sysadmin을 사용하여 기본 스키마를 통해 [corp\$1accounts-group] 로그인용 Windows 그룹 사용자를 생성합니다.
```
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)
```
AD 사용자 user1을 사용하여 스키마를 명시적으로 지정하지 않고 객체를 만들어 보세요. 표 t2는 [corp\$1accounts-group] Windows 그룹 사용자의 기본 스키마에서 생성됩니다. 이 객체의 소유자는 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)
```
AD 사용자 user1에는 개별 Windows 로그인 및 사용자가 존재하지 않습니다.
**Example : AD 사용자에 대해 개별 데이터베이스 사용자도 있습니다.**
AD 사용자에 대해 개별 데이터베이스 사용자도 존재하는 경우 객체는 항상 개별 데이터베이스 사용자와 연결된 스키마에 생성됩니다. 데이터베이스 사용자에 대한 스키마가 없는 경우 dbo 스키마가 사용됩니다. AD 사용자 user1을 위한 개별 Windows 로그인 및 데이터베이스 사용자를 생성합니다. sysadmin 로그인을 사용하여 TDS 엔드포인트를 통해 연결
```
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)
```
AD 사용자 user1을 사용하여 연결하고, 스키마를 명시적으로 지정하지 않고 객체를 만들어 보세요. 표 t2는 스키마 sch1에 생성됩니다. 또한 이 객체의 소유자는 스키마 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)
```
# 제한 사항
+ Dump/Restore 유틸리티는 pg\$1ad\$1mapping 확장 매핑 덤프를 지원하지 않습니다. 복원 후에는 이러한 매핑을 다시 생성해야 합니다.
+ `pg_ad_mapping`을 사용하는 Babelfish 및 Aurora PostgreSQL 인스턴스에는 블루-그린 배포가 지원되지 않습니다.
+ 암시적 스키마 생성은 지원되지 않습니다. 암시적 스키마 생성이 필요한 DDL 문은 지원되지 않습니다.
+ 서버 수준의 DDL인 ALTER AUTHORIZATION ALTER AUTHORIZATION ON DATABASE , CREATE DATABASE, CREATE LOGIN, ALTER LOGIN, ALTER SERVER ROLE, ALTER DATABASE는 개별 Windows 로그인이 없고 그룹 Windows 로그인만 있는 경우 그룹 AD 인증 세션에서 지원되지 않습니다. 이 제한을 해결하려면 암호로 인증된 세션에서 이러한 작업을 수행하거나 개별 Windows 로그인을 생성하는 것이 좋습니다.
+ 암시적 사용자 생성은 지원되지 않습니다. 이상적인 T-SQL 동작 [Babelfish에서는 아직 지원되지 않음]: DDL 및 GRANT/REVOKE와 같은 액세스 제어문의 경우 AD 사용자의 이름이 명령에 지정되어 있지만, 데이터베이스에 존재하지 않는다면 AD 사용자로 명명된 데이터베이스 사용자가 암시적으로 생성됩니다.
+ PSQL 엔드포인트에서 생성되고 그룹 AD 인증 세션의 TDS 엔드포인트에서 실행되는 PL/pgSQL 프로시저 또는 함수의 DDL인 경우:
+ ALTER/DROP 문이 지원됩니다.
+ 스키마가 명시적으로 제공되지 않고 기본 스키마가 현재 세션에 대해 null인 경우 CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE FUNCTION/PROC, CREATE TYPE, CREATE SEQUENCE, CREATE TRIGGER, SELECT INTO, CREATE FULLTEXT INDEX, CREATE UNIQUE INDEX에서 오류가 발생합니다.
+ CREATE DATABASE , CREATE EXTENSION 및 PG(T-SQL에 없음) 특정 객체용 기타 모든 CREATE 문(CREATE SUBSCRIPTION, CREATE TABLESPACE, CREATE POLICY, CREATE CONVERSION)은 지원되지 않습니다.
+ PostgreSQL 엔드포인트의 DDL은 그룹 AD 인증 세션에서 지원되지 않습니다. 해결 방법으로 언제든지 마스터 사용자 또는 암호 기반 인증 메커니즘을 사용하는 다른 사용자로 연결할 수 있습니다.
+ SUSER\$1SID(), IS\$1SRVROLEMEMBER(), IS\$1MEMBER(), sys.dm\$1exec\$1sessions와 같은 시스템 객체에는 다음과 같은 제한이 있습니다.
+ AD 사용자 또는 AD 보안 그룹이 제공된 경우 SUSER\$1SID()는 SID를 반환하지 않습니다.
+ 현재 AD 사용자가 Windows 그룹 로그인의 서버 역할 구성원 자격으로부터 서버 역할 구성원 자격을 상속받는 경우 IS\$1SRVROLEMEMBER()는 역할 구성원 자격을 고려하지 않습니다.
+ IS\$1MEMBER()는 모든 Windows 그룹 관련 쿼리에 대해 false를 반환합니다.
+ sys.dm\$1exec\$1sessions에는 예상 값 login\$1name, nt\$1user\$1name 열이 표시되지 않습니다.
# PostgreSQL 포트의 PostgreSQL 엔드포인트를 통해 Babelfish에 연결
TDS 포트에서 생성된 그룹 로그인을 활용하여 PostgreSQL 포트를 통해 연결할 수도 있습니다. PostgreSQL 포트를 통해 연결하려면 PostgreSQL 클라이언트 애플리케이션의 `` 형식으로 AD 사용자 이름을 지정해야 합니다. `` 형식은 사용할 수 없습니다.
PostgreSQL은 기본적으로 사용자 이름에 대소문자를 구분하는 비교를 사용합니다. Aurora PostgreSQL이 Kerberos 사용자 이름을 대소문자를 구분하지 않는 것으로 해석하려면 사용자 지정 Babelfish 클러스터 파라미터 그룹에서 krb\$1caseins\$1users 파라미터를 true로 설정해야 합니다. 이 파라미터는 기본적으로 false로 설정되어 있습니다. 자세한 내용은 [대소문자를 구분하지 않는 사용자 이름을 위해 Aurora PostgreSQL DB 클러스터 구성](postgresql-kerberos-setting-up.md#postgresql-kerberos-setting-up.create-logins.set-case-insentive) 섹션을 참조하세요.
## AD 사용자가 여러 그룹에 속해 있는 경우 T-SQL과 PostgreSQL 엔드포인트 간의 동작 차이
AD 사용자 user1이 2개의 AD 보안 그룹 [corp\$1accounts-group] 및 [corp\$1sales-group]의 일부이고 DB 관리자가 다음과 같은 방식으로 사용자 매핑을 설정했다고 가정해 보겠습니다.
```
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)
```
사용자가 T-SQL 엔드포인트에서 연결하는 경우 권한 부여 중에 연결된 모든 T-SQL 로그인의 권한이 상속됩니다. 이 예제에서 user1은 T-SQL 그룹 로그인 모두의 권한 통합을 상속하며 가중치는 무시됩니다. 이는 표준 T-SQL 동작과 일치합니다.
그러나 동일한 사용자가 PostgreSQL 엔드포인트에서 연결하는 경우 가중치가 가장 높은 하나의 관련 T-SQL 로그인에서만 권한을 상속할 수 있습니다. 두 T-SQL 그룹 로그인에 동일한 가중치가 할당되면 AD 사용자는 가장 최근에 추가된 매핑에 해당하는 T-SQL 로그인의 권한을 상속받습니다. PostgreSQL의 경우 모호성을 피하려면 개별 DB 역할의 상대적 허가/권한을 반영하는 가중치를 지정하는 것이 좋습니다. 아래 예제에서 user1은 PSQL 엔드포인트를 통해 연결했고 sales-groups 권한만 상속했습니다.
```
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)
```