UNIXでのEDQの実行
サーバーがUNIX上で実行されている場合、ADのアカウントを使用して受入れ資格証明を設定する必要があります。これは、Kerberosのキー表(keytab)から読み取られた暗号化アカウント・パスワードを使用して、リクエストを検証します。有効なキー表を設定することは、UNIXでSSOを構成するために不可欠な手順です。
keytabとは
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アカウント名は、常に$で終わります)。
既存のツールを使用したkeytabの作成
通常の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を使用したkeytabの作成
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を作成し、パスワードを既知の値に設定して、管理者パスワードの入力を求めます。
UNIX Kerberos構成の確認
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暗号化
デフォルトでは、Javaランタイム環境に強度の高い暗号のサポートは付属していません。たとえば、256ビットの鍵を持つAESはサポートされません。Active DirectoryおよびKerberosでは、暗号の完全なセットがサポートされ、キー表にはJavaでサポートされないエントリが含まれる可能性があります。この場合、現在の場所で可能であれば、JCE Unlimited Strength Jurisdiction Policy Filesをインストールする必要があります。
login.propertiesの変更
この例では、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でアプリケーションを使用するための権限を持っている必要があります。