RDS for Oracle の Kerberos 認証
いつからかはわかりませんが、RDS for Oracle の Kerberos 認証が、アジアパシフィック(東京)リージョンでもサポートされるようになっているようです。オンプレ Oracle であれば普通にやっていた OS 認証ですが、運用負荷を少しでも軽減するためには RDS でも OS 認証できることが望ましいです。
やりたいこと
以下によると RDS の Kerberos 認証を利用するためのディレクトリに AD Connector は使えないようです。
注記
AD Connector アプリケーション互換性ポリシー
Amazon RDS はAWS管理対象の Microsoft AD のみであり、AD Connector とは互換性がありません。詳細については、「AWS FAQAWS Directory Service」ページの Microsoft AD のセクションを参照してください。
これが何を意味するかというと、既に AD ドメインを持っている企業の場合、既存 AD ドメインをマネージドサービスである MS AD ドメインにすべて移管してしまうか、既存 AD ドメインをMS AD ドメインと信頼関係を作成した上で連携させるか、の二択を迫られるということです。MS AD はマネージドサービスであるが故に、グループポリシー配布等でもそれなりに自由度が制限されるようですので、既存 AD を使いこなしているような企業の場合は、実質的に選択肢としては後者しかなさそうです。勿論、MS AD そのものにコストがかかりますから「RDS で Kerberos 認証は利用しない」という選択肢もあると思います。運用負荷とコストとの兼ね合いになろうかと思います。
で、今回はその「既存 AD を利用した RDS for Oracle による Kerberos 認証」を試してみたいと思います。
まず、既存 AD ドメインは以下の記事で書いたものを利用しています。
次に、MS AD ドメインを立てて、既存 AD ドメインとの信頼関係を作成する方法については以下の記事に書いています。
その上で、以下の記事では既存 AD のドメインユーザ「yamada.taro@mydom.local」を利用して WorkSpace を作成してます。
最後に、それらと同一VPC上に RDS for Oracle を作成しています。
今回の記事の内容を検証するためには準備として上記はすべてやっておく必要があります。これらを利用して、WorkSpace に既存 AD ドメインユーザ「yamada.taro@mydom.local」でログインした状態で、SQL Developer を利用して、ユーザ名とパスワードを省略して RDS for Oracle に接続できるようにしてみます。
尚、SQL Developer は以下の記事のように Oracle Instant Client を使ってセットアップしたものを利用していますが、勿論 SQL Developer でなくても RDS に接続できさえずれば作業も確認も可能です。
RDS のデータベース認証オプションの変更
AWS コンソールで作業します。「RDS for Oracle の Kerberos 認証」で作成したインスタンス「ORCL」を選択し「変更」を実行します。

データベース認証オプションを「パスワードと Kerberos 認証」としてください。ディレクトリは「AWS Microsoft AD と既存 AD との信頼関係」で作成したドメイン「awsdom.local」を選択します。

「続行」して変更点を確認し「変更のスケジューリング」を「すぐに適用」を選択した上で「DB インスタンスを変更」を実行します。

インスタンスのステータスが「変更中」から「利用可能」になれば変更完了です。ですが、以下の通りユーザガイドに以下の記述があったので、念のため再起動しています。
(ほんとうに必要だったかどうかは確認してません、、、)
重要
ステップ 6: Oracle DB インスタンスを作成または変更する
Kerberos 認証を有効化するために DB インスタンスを変更する場合、変更後 DB インスタンスを再起動します。
Kerberos 認証ユーザの登録
次にデータベースに対して Kerberos 認証させるユーザを登録します。WorkSpace から RDS for Oracle に接続できるようにしていると思いますので、そちらから SQL Developer で admin で接続して作業します。
作業としては一般的な Oracle の OS 認証と同じです。ユーザ名には初期化パラメータである OS_AUTHENT_PREFIX (デフォルトOPS$)を接頭語につけるのですが、RDS for Oracle では NULL になっていました。

登録すべきユーザは、既存 AD ドメイン(mydom.local)に登録しているドメインユーザ “yamada.taro" です。RDS に admin で接続の上、以下の通りユーザ登録を行い、接続権限を与えます。
CREATE USER "YAMADA.TARO@MYDOM.LOCAL" IDENTIFIED EXTERNALLY;
GRANT CREATE SESSION TO "YAMADA.TARO@MYDOM.LOCAL";
Oracle クライアント環境の設定
次に Kerberos 認証ができるようにクライアント側の設定を行います。WorksSpaces 内での作業です。
まず、krb5.ini というファイルを準備します。既存 AD ドメインが「mydom.local」、既存 AD サーバは「mydc.mydom.local」、MS AD ドメインが「awsdom.local」です。
ここはユーザーガイドの「ステップ 8: Oracle クライアントを設定する」記載の通りです。
[libdefaults]
default_realm = mydom.local
[realms]
awsdom.local = {
kdc = awsdom.local
admin_server = awsdom.local
}
mydom.local = {
kdc = mydc.mydom.local
admin_server = mydc.mydom.local
}
[domain_realm]
.awsdom.local = awsdom.local
awsdom.local = awsdom.local
.mydom.local = mydom.local
mydom.local = mydom.local
次に、sqlnet.ora に Kerberos 認証を行うということと、krb5.ini の場所を指す定義を記載します。
ただし ユーザーガイド には、 AUTHENTICATION_SERVICES と KERBEROS5_CONF の記載しかありません。
しかし、実際は KERBEROS5_CC_NAME と KERBEROS5_CONF_MIT の定義がないと「ORA-12638: 資格証明の取出しに失敗しました」のエラーになります。正直、理由はよくわかりません。KERBEROS5_CONF_MIT に至っては、リファレンス にもありませんが設定しないとダメです。もしかしたら、Oracle 12c の Bug の回避策の可能性もあるので RDS for Oracle のバージョンが変われば不要になるのかもしれません。
とりあえずこういうものだと思ってください。
SQLNET.AUTHENTICATION_SERVICES=(KERBEROS5PRE,KERBEROS5)
SQLNET.KERBEROS5_CONF=c:\tools\sqldeveloper\krb5.ini
SQLNET.KERBEROS5_CC_NAME=OSMSFT://
SQLNET.KERBEROS5_CONF_MIT=TRUE
尚、sqldeveloper.bat は以下の通りですから 環境変数 TNS_ADMIN が指す c:\tools\sqldeveloper 配下の sqlnet.ora を修正するようにしてください。
@echo off
set top=%~dp0
set path=%top%\instantclient_19_12;%path%
set tns_admin=%top%
start %top%\sqldeveloper.exe
これで準備完了です。
Kerberos 認証で RDS for Oracle に接続する
いわゆる OS 認証ですから、OS(Windows)にログインしているユーザであれば、データベース認証のときに再度ユーザ名、パスワードを入力する必要がないはずです。
この WorkSpace の Windows に「yamada.taro@mydom.local」でログインした状態で、sqldeveloper.bat を起動し、接続情報に以下のように設定の上、「接続」してみます。

接続に成功したら以下の SQL で、このセッションのユーザ名を確認しましょう。
SELECT SYS_CONTEXT('USERENV','SESSION_USER') FROM DUAL;
セッションユーザが「yamada.taro@mydom.local」であることが確認できました。
素晴らしいですね。OS のユーザでシングルサインオンで接続できました。

ディスカッション
コメント一覧
まだ、コメントがありません