この付録では、KerberosおよびActive Directoryと連携するようにEDQを構成する方法について説明します。次の項で構成されています。
login.propertiesを使用したEDQとActive Directoryの統合(第5章「EDQでの外部ユーザー管理(LDAP)の直接構成」を参照)は、ユーザーがWindowsにログインすると、EDQに再度ログインする必要がなくなるシングル・サインオン(SSO)をサポートするように構成できます。これは、WebLogicとTomcatの両方でサポートされます。
SSOを有効にするには、EDQサーバーを設定して、クライアントPCからのKerberos認証を有効にする必要があります。この認証は、標準のGSSAPIトークン交換メカニズム(RFC 4121)を使用して実現します。クライアントは、ドメイン・コントローラ(DC)に接続して、サーバー・アプリケーションが提供するサービスに対するアクセスをリクエストします。DCからのレスポンスは、クライアントによってサーバーに送信されるトークンにエンコードされます。サーバーは、このトークンを検証し、クライアントに送信するための別のトークンを生成します。トークン交換は、クライアントとサーバーがセキュアなコンテキストを確立するまで継続できます。実際には、いずれの方向についても、この交換で2つ以上のトークンが必要になることはありません。
起動時に、サーバー・アプリケーションは、セキュリティ・コンテキストの半分を初期化するために使用する受入れ資格証明を設定します。
EDQアプリケーション・サーバーが、ローカル・システム・アカウントを使用してドメイン内のWindowsサーバーで実行されている場合、構成は非常に簡単になります。EDQは、受入れ資格証明を処理し、ユーザー・ルックアップでADに接続するために、システム・アカウントを使用します。
この構成のEXAMPLE.COMのlogin.propertiesは、次のとおりです。
# EXAMPLE.COM LDAP integration # ---------------------------- realms = internal, ad ldap.prof.useprimarygroup = false clientcreds = true ad.realm = EXAMPLE.COM ad.auth = ldap ad.auth.bindmethod = simple ad.auth.binddn = search: dn ad.ldap.profile = adsldap ad.ldap.prof.defaultusergroup = edqusers ad.ldap.prof.groupsearchfilter = (cn=edq*)
'clientcreds'設定は、Kerberos資格証明が現在のユーザーのキャッシュ(この場合はローカル・システム・アカウント)から取得されることを示します。これらの資格証明は、Active Directoryに接続し、受入れGSSAPIコンテキストを設定するために使用されます。
Active Directoryドメインのメンバーであるサーバーは、通常、DNSルックアップでドメイン・コントローラを使用します。この場合、EDQでは、自動的にLDAPサーバーのアドレスが決定されます。ドメイン・コントローラの一部が遠隔地に存在するなどの理由によりアドレスを固定する場合、次のようにldap.serverプロパティを使用します。
ad.ldap.server = dc1.example.com
サーバーがUNIX上で実行されている場合、ADのアカウントを使用して受入れ資格証明を設定する必要があります。これは、Kerberosのキー表(keytab)から読み取られた暗号化アカウント・パスワードを使用して、リクエストを検証します。有効なキー表を設定することは、UNIXでSSOを構成するために不可欠な手順です。
Kerberosのキー表には、1つ以上のKerberosプリンシパルの暗号化パスワードが含まれます。DCでは、通常、異なる複数の暗号化アルゴリズム(DES3、AES、RC4など)がサポートされ、プリンシパルのエントリには、これらの各アルゴリズムの鍵が含まれます。クライアントは、DCとの通信に使用できる最適なアルゴリズムを選択します。
GSSAPIを使用してリクエストされるサービスは、サービス・プリンシパル名(SPN)によって識別されます。通常、これは、マシンのホスト名における特定のサービス・タイプに対する参照です。サービス・タイプの例は、HOST (sshなどの一般的なアクセスに対応)、HTTP (ブラウザからのSSOに対応)およびLDAP (ADドメイン・コントローラなどのLDAPサーバーに対応)です。SPNは、通常、次のように表示されます。
service/hostname
次に例を示します。
HOST/testserver.example.com
keytabの各エントリには、キー・バージョン番号(KVNO)も含まれます。このバージョン番号は、DCでプリンシパルのパスワードが変更されるたびに増分されます。認証が成功するには、keytabに正しいKVNOが含まれる必要があります。
ほとんどのUNIXシステムで、システムのKerberos keytabのデフォルトの場所は次のとおりです。
/etc/krb5.keytab
JavaのKerberos実装では、keytabのデフォルトの場所はないため、次のようにloign.propertiesで設定する必要があります。
keytab = path to keytab
絶対パスではない場合、これはlogin.propertiesを含むsecurityフォルダを基準とする相対パスです。
klistコマンドを使用すると、keytabの内容をリストできます。
klist –k [file] klist –ke [file] klist –keK [file]
keytabがデフォルトの場所にない場合、ファイル名を指定できます。最初の書式ではプリンシパルのみがリストされ、2番目の書式では暗号化アルゴリズムも追加され、3番目の書式では16進数でのキー値も追加されます。
次に、klist -keによる出力例を示します。
Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 5 ALTAIR$@EXAMPLE.COM (des-cbc-crc) 5 ALTAIR$@EXAMPLE.COM (des-cbc-md5) 5 ALTAIR$@EXAMPLE.COM (des3-cbc-sha1) 5 ALTAIR$@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 5 ALTAIR$@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 5 ALTAIR$@EXAMPLE.COM (arcfour-hmac) 5 HOST/altair@EXAMPLE.COM (des-cbc-crc) 5 HOST/altair@EXAMPLE.COM (des-cbc-md5) 5 HOST/altair@EXAMPLE.COM (des3-cbc-sha1) 5 HOST/altair@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 5 HOST/altair@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 5 HOST/altair@EXAMPLE.COM (arcfour-hmac) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des-cbc-crc) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des-cbc-md5) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (des3-cbc-sha1) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (aes128-cts-hmac-sha1-96) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (aes256-cts-hmac-sha1-96) 5 HOST/altair.EXAMPLE.COM@EXAMPLE.COM (arcfour-hmac)
標準のKerberosドメイン・コントローラ(KDC)を使用する通常のKerberosシステムでは、各SPNは、異なるパスワードを持つ個別のプリンシパルです。Active Directoryでは、SPNは、原則としてADのservicePrincipalName LDAP属性の値として格納される単一アカウントの別名です。ADでコンピュータ・アカウントが作成されると、HOSTサービスのSPNが自動的に作成されます。IISやSQLserverなどの追加サービスがサーバーにインストールされている場合、追加のSPNがアカウントに追加されます。
WindowsのsetspnコマンドをADサーバーで実行して、アカウントのSPNを管理できます。次に例を示します。
setspn -A HTTP/altair.example.com altair$
最初のコマンドでは、altairのマシン・アカウントにHTTP SPNを追加しています。(コンピュータのWindowsアカウント名は、常に$で終わります)。
通常のKerberosシステムでは、Kerberos管理ツールkadminのktaddサブコマンドを使用してkeytabエントリを作成します。ADではKerberos管理サーバーが提供されないため、他のアプローチが必要です。
keytabには、アカウントの暗号化パスワードが含まれるため、メソッドごとにアカウントのパスワードを前もって把握しておくか、アカウント・パスワードを変更する権限とともにそれを実行する必要があります。
使用するメソッドは、システム構成によって異なります。既存のオプションには次のものがあります。
Samba: システムがSambaスイートを使用するADに登録されている場合、net ads keytabコマンドを使用して、keytabを作成および更新できます。Sambaはアカウントのパスワードを設定してそれを秘密の場所に格納しているため、このような動作になります。
ktpass: Windowsのktpassコマンドは、AD管理者がkeytabエントリを生成するために実行できます。他に代替方法がある場合は、このコマンドを使用しないでください。これは複雑で、信頼性を保証しながら使用することが非常に困難です。これにより、アカウントのパスワードが更新されるため、前のkeytabはすべて使用できなくなります。
msktutil: これは、keytabの管理に使用できるUNIX用のオープン・ソース・アプリケーションです。
winktabは、ADでアカウントのkeytabを作成するために使用できるJavaアプリケーションです。これは、ADに接続して、アカウントのKVNOを決定し、アカウントに関連付けられたSPNを決定します。これを管理者アカウントで実行すると、アカウント・パスワードをランダム値にリセットできます(または、アカウント・パスワードをコマンドに指定できます)。
winktabは、ADサーバーに接続可能な任意のシステムで実行できます。
マシン・アカウントのkeytabを作成してパスワードをランダム値にリセットするには、次のようにします。
java -jar stuff.jar winktab -o ktfile -domain DOMAIN -server adserver -user aduser -pw adpw -tls machinename To create a keytab for a machine account using a known password: java -jar stuff.jar winktab -o ktfile -accpw accpw -domain DOMAIN -server adserver -user aduser -pw adpw [-tls] machinename
パラメータは次のとおりです。
ktfile: keytabはこのファイルに書き込まれます
accpw: マシンまたはユーザー・アカウントのパスワード。単一ダッシュ(-)を使用すると、コマンドにより、echoなしでパスワードの入力を求められます
DOMAIN: ADドメイン名
adserver: ドメインのADサーバーのホスト名またはIPアドレス
aduser、adpw: 問合せでサーバーへの接続に使用されるADアカウントのユーザー名とパスワード。ユーザー名の形式は次のとおりです。
user@DOMAIN
またはSHORTDOMAIN\user
パスワードとして単一ダッシュ(-)が指定されると、コマンドにより、echoなしでその入力を求められます。
アカウント・パスワードが固定(-setpwを使用)またはランダム(-setpwおよび-accpwを省略)に設定されている場合、ユーザーは管理者権限を持っている必要があります。
machinename: コンピュータ・アカウントの名前。内部ADアカウント名は、machinename$です。内部ADアカウント名は、sAMAccountName LDAP属性に格納されます。
ADサーバーで認証接続が要求される場合、-tlsスイッチを使用します。アカウント・パスワードがリセットされる場合はWindowsで暗号化された接続が必要になるため、パスワードがランダム値または既知の値にリセットされる場合、-tlsを使用する必要があります。
次に、わかりやすく複数の行に分割したドメインEXAMPLE.COMの例を示します。
java -jar stuff.jar winktab -o altair.keytab -setpw altair \ -domain EXAMPLE.COM -server dc1.example.com \ -user "example\Admin" -tls altair
マシン・アカウントのkeytabを作成し、パスワードを既知の値に設定して、管理者パスワードの入力を求めます。
kinitなどのコマンドやJavaランタイムで使用されるKerberos構成は、通常、/etc/krb5.confに格納されているグローバル構成ファイルから読み取られます。これには、ドメイン・コントローラに対する参照およびDNSとKerberosドメイン間のマッピングが含まれます。次に、ドメインEXAMPLE.COMの例を示します。
[logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = EXAMPLE.COM dns_lookup_realm = false dns_lookup_kdc = false ticket_lifetime = 24h renew_lifetime = 7d forwardable = yes [realms] EXAMPLE.COM = { kdc = dc1.example.com:88 } [domain_realm] .example.com = EXAMPLE.COM example.com = EXAMPLE.COM
[realms]セクションには、各ドメインのホストまたはIP別のKDCがリストされ、[domain_realm]セクションには、DNSホスト名とKerberosドメインのマッピングが含まれます。
krb5.confは、ターゲット・ドメインの構成に応じて確認および調整する必要があります。/etcのファイルを更新できない場合、ファイルを他の場所に格納し、システム・プロパティを通じてJavaランタイムにその場所を指示します。これを行うには、EDQローカル構成ディレクトリのjvm.propertieファイルを編集または作成し、次の行を追加します。
java.security.krb5.conf = absolute path to modified krb5.conf
デフォルトでは、Javaランタイム環境に強度の高い暗号のサポートは付属していません。たとえば、256ビットの鍵を持つAESはサポートされません。Active DirectoryおよびKerberosでは、暗号の完全なセットがサポートされ、キー表にはJavaでサポートされないエントリが含まれる可能性があります。この場合、現在の場所で可能であれば、JCE Unlimited Strength Jurisdiction Policy Filesをインストールする必要があります。
この例では、EDQを実行しているサーバーがaltair.example.comであるとします。
グローバル設定:
realms = internal, ad spn = HOST/altair.example.com@EXAMPLE.COM keytab = /etc/krb5.keytab ldap.prof.useprimarygroup = false
'spn'プロパティでは、GSSAPI受入れコンテキストで使用するサービス・プリンシパルを設定します。ここに示されている値はデフォルトで、UNIXサーバーのDNSドメインがADドメインと同じ場合は省略できます。UNIXサーバーが別個のDNSドメインに存在することがあり、その場合'spn'プロパティは必須です。
'keytab'プロパティでは、Kerberosのキー表の場所を設定します。Javaではデフォルトでこれが標準の場所に設定されないため、このプロパティは常に必須です。
LDAPサーバー設定:
ad.ldap.server = dc1.example.com ad.ldap.spn = "ALTAIR$@EXAMPLE.COM"
Active Directoryへの接続に使用するサーバー名とKerberosプリンシパルを設定します。プリンシパルは、実際のマシン・アカウント名を含むキー表エントリである必要があります。前述のとおり、DNSから決定できる場合は、サーバーを省略できます。
まとめると次のようになります。
これが、Active DirectoryとKerberos統合の例で使用される完全なlogin.propertiesです。
# EXAMPLE.COM LDAP integration with Kerberos realms = internal, ad spn = HOST/altair.example.com@EXAMPLE.COM ldap.prof.useprimarygroup = false keytab = /etc/krb5.keytab ad.realm = EXAMPLE.COM ad.label = Example, Inc. Active directory ad.ldap.server = dc1.example.com ad.ldap.spn = "ALTAIR$@EXAMPLE.COM" ad.ldap.security = tls ad.auth = ldap ad.auth.bindmethod = simple ad.auth.binddn = search: dn ad.ldap.profile = adsldap ad.ldap.prof.defaultusergroup = edqusers ad.ldap.prof.groupsearchfilter = (cn=edq*)
このlogin.propertiesが適切に配置されると、EXAMPLE.COMドメインのWindowsユーザーは、追加の資格証明を提供せずにEDQアプリケーションにログインできます。当然、ユーザーは、EDQでアプリケーションを使用するための権限を持っている必要があります。
Kerberos統合に必要な共有ライブラリ(wingss.dllおよびlibunuxgss.so)は、edq.war
ファイル内に含まれます。EDQは共有ライブラリの場所を判別して正しいバージョンを自動的にロードできるため、ほとんどのインストールではこれで十分です。
ただし、この自動ロードはすべてのJavaランタイム環境(JRE)で動作するわけではなく、特にIBM JREでは動作しません。このようなインストールでは、ライブラリを付属のkerberos-gss.zip
ファイルから抽出し、ディスク上の既知の場所にコピーする必要があります。さらに、JREで検出できるように、次の環境変数に場所を追加する必要があります。
LD_LIBRARY_PATH (Linux、Solaris)
LIBPATH (AIX)
PATH (Windows)
EDQインストールに付属するnative/Kerberos-gss.zip
アーカイブを調査して、それに次のファイルが含まれることを確認します。
aix/ppc/libunixgss.a
aix/ppc64/libunixgss.a
linux/amd64/libunixgss.so
linux/i386/libunixgss.so
win32/amd64/wingss.dll
win32/x86/wingss.dll
EDQサーバーが実行されているOSの関連ライブラリを抽出し、EDQを実行しているユーザーがアクセスできるディスク上の場所にそれをコピーします。この場所は、JREでライブラリを検出できるように、前述の環境変数に追加する必要があります。