付録

付録 A: このドキュメントで使用される資料

実際のユーザーソースがないため、サンプルではダミーの UserDetailsService が使用されています。

public class DummyUserDetailsService implements UserDetailsService {

    @Override
    public UserDetails loadUserByUsername(String username)
            throws UsernameNotFoundException {
        return new User(username, "notUsed", true, true, true, true,
                AuthorityUtils.createAuthorityList("ROLE_USER"));
    }

}

付録 B: ケルベロスへの短期集中コース

通常、認証プロセスには 3 つの当事者が関与します。

drawio kerb cc1

1 つ目は client です。これはクライアントコンピューターであることもありますが、ほとんどのシナリオでは、コンピューターに座ってリソースにアクセスしようとしている実際のユーザーです。次に、resource ユーザーがアクセスしようとしています。この例では、Web サーバーです。

次に、Key Distribution Center または KDC があります。Windows 環境の場合、これは Domain Controller になります。KDC はすべてを実際に統合するものであり、環境内で最も重要なコンポーネントです。このため、単一障害点ともみなされます。

最初に Kerberos 環境がセットアップされ、ドメインユーザープリンシパルがデータベースに作成されると、暗号化キーも作成されます。これらの暗号化キーは共有シークレット (ユーザーパスワードなど) に基づいており、実際のパスワードがクリアテキストで保存されることはありません。事実上、KDC は独自のキーとドメインユーザー用の他のキーを持っています。

興味深いことに、認証プロセス中に resource と KDC の間に通信はありません。

drawio kerb cc2

クライアントが resource で自身を認証したい場合は、まず KDC と通信する必要があります。Client は、暗号化された部分と暗号化されていない部分を含む特別なパッケージを作成します。非暗号化部分にはユーザーに関する情報が含まれ、暗号化部分にはプロトコルの一部であるその他の情報が含まれます。Client は独自のキーを使用してパッケージデータを暗号化します。

KDC はクライアントからこの認証パッケージを受信すると、暗号化されていない部分からこの client が誰であると主張しているかを確認し、その情報に基づいて、データベースにすでにある client 復号化キーを使用します。この復号化が成功すると、KDC は、この client が自分が主張しているものであることを認識します。

KDC がクライアントに返すのは、KDC 独自の秘密キーで署名された Ticket Granting Ticket と呼ばれるチケットです。後で client がこのチケットを送り返すと、復号化を試みることができ、その操作が成功すると、それが最初に自分自身が署名して client に渡したチケットであることがわかります。

drawio kerb cc3

クライアントがサービス認証に使用できるチケットを取得したい場合、TGT が KDC に送信され、KDC はサービス独自のキーを使用してサービスチケットに署名します。これは、client と service 間の信頼が作成される瞬間です。このサービスチケットには、service 自体のみが復号化できるデータが含まれています。

drawio kerb cc4

client がサービスで認証を行う際、以前受信したサービスチケットをサービスに送信します。すると、そのサービスは、この人物について何も知らないが、認証チケットを渡されたと考えます。service が次に実行できることは、そのチケットの暗号化解除を試みることです。その操作が成功した場合、私の資格情報を知っている相手は KDC のみであり、彼を信頼しているため、このクライアントが彼が主張するクライアントであるとも信頼できます。

付録 C: Kerberos 環境のセットアップ

Kerberos 環境の本番セットアップの実行はこのドキュメントの範囲外ですが、この付録では、開発に必要なコンポーネントのセットアップを開始するためのいくつかのヘルプを提供します。

MIT Kerberos のセットアップ

最初のアクションは、新しいレルムとデータベースをセットアップすることです。

# kdb5_util create -s -r EXAMPLE.ORG
Loading random data
Initializing database '/var/lib/krb5kdc/principal' for realm 'EXAMPLE.ORG',
master key name 'K/[email protected] (英語)  '
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key:
Re-enter KDC database master key to verify:

kadmin コマンドを使用して Kerberos 環境を管理できますが、データベースに管理者ユーザーが存在しないため、まだ使用できません。

root@neo:/etc/krb5kdc# kadmin
Authenticating as principal root/[email protected] (英語)   with password.
kadmin: Client not found in Kerberos database while initializing
kadmin interface

kadmin.local コマンドを使用して作成してみましょう。

root@neo:/etc/krb5kdc# kadmin.local
Authenticating as principal root/[email protected] (英語)   with password.

kadmin.local:  listprincs
K/[email protected] (英語)  
kadmin/[email protected] (英語)  
kadmin/[email protected] (英語)  
kadmin/[email protected] (英語)  
krbtgt/[email protected] (英語)  

kadmin.local:  addprinc root/[email protected] (英語)  
WARNING: no policy specified for root/[email protected] (英語)  ; defaulting to
no policy
Enter password for principal "root/[email protected] (英語)  ":
Re-enter password for principal "root/[email protected] (英語)  ":
Principal "root/[email protected] (英語)  " created.

次に、kadm5.acl ファイルを変更して管理者を有効にし、Kerberos サービスを再起動します。

# cat /etc/krb5kdc/kadm5.acl
# This file Is the access control list for krb5 administration.
*/admin *

これで、以前に作成した root/admin プリンシパルで kadmin を使用できるようになりました。最初のユーザー user1 を作成しましょう。

kadmin:  addprinc user1
WARNING: no policy specified for [email protected] (英語)  ; defaulting to no
policy
Enter password for principal "[email protected] (英語)  ":
Re-enter password for principal "[email protected] (英語)  ":
Principal "[email protected] (英語)  " created.

2 番目のユーザー user2 を作成し、キータブファイルをエクスポートしましょう。

kadmin:  addprinc user2
WARNING: no policy specified for [email protected] (英語)  ; defaulting to no
policy
Enter password for principal "[email protected] (英語)  ":
Re-enter password for principal "[email protected] (英語)  ":
Principal "[email protected] (英語)  " created.

kadmin:  ktadd -k /tmp/user2.keytab [email protected] (英語)  
Entry for principal [email protected] (英語)   with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] (英語)   with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] (英語)   with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/user2.keytab.
Entry for principal [email protected] (英語)   with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/tmp/user2.keytab.

Tomcat のサービスチケットを作成し、資格情報を tomcat.keytab という名前のキータブファイルにエクスポートしてみましょう。

kadmin:  addprinc -randkey HTTP/[email protected] (英語)  
WARNING: no policy specified for HTTP/[email protected] (英語)  ;
defaulting to no policy
Principal "HTTP/[email protected] (英語)  " created.

kadmin:  ktadd -k /tmp/tomcat.keytab HTTP/[email protected] (英語)  
Entry for principal HTTP/[email protected] (英語)   with kvno 2, encryption type aes256-cts-hmac-sha1-96 added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] (英語)   with kvno 2, encryption type arcfour-hmac added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] (英語)   with kvno 2, encryption type des3-cbc-sha1 added to keytab WRFILE:/tmp/tomcat2.keytab.
Entry for principal HTTP/[email protected] (英語)   with kvno 2, encryption type des-cbc-crc added to keytab WRFILE:/tmp/tomcat2.keytab.

Windows ドメインコントローラーのセットアップ

これは Windows Server 2012 R2 を使用してテストされました

インターネットには、Windows AD のセットアップに関する優れた記事やビデオがたくさんありますが、ラックスペース (英語) とマイクロソフトテックネット (英語) の 2 つは非常に便利です。

  • 通常のドメインコントローラーと Active Directory のセットアップが完了しました。

  • DNS ドメイン example.org と Windows ドメイン EXAMPLE を使用しました。

  • user1、user2、user3、tomcat などのさまざまなドメインユーザーを作成し、パスワードを Password# に設定しました。

最終的には、問題が発生しないように、VM のすべての IP を AD の DNS サーバーに追加しました。

Name: WIN-EKBO0EQ7TS7.example.org
Address: 172.16.101.135

Name: win8vm.example.org
Address: 172.16.101.136

Name: neo.example.org
Address: 172.16.101.1

サービスプリンシパル名 (SPN) は HTTP と、Tomcat サーブレットコンテナーが実行されるサーバー名 neo.example.org を使用して設定する必要があります。これは tomcat ドメインユーザーで使用され、その keytab はサービス資格情報として使用されます。

PS C:\> setspn -A HTTP/neo.example.org tomcat

keytab ファイルをエクスポートし、Tomcat を実行している Linux サーバーにコピーしました。

PS C:\> ktpass /out c:\tomcat.keytab /mapuser [email protected] (英語)   /princ HTTP/[email protected] (英語)   /pass Password# /ptype KRB5_NT_PRINCIPAL /crypto All
 Targeting domain controller: WIN-EKBO0EQ7TS7.example.org
 Using legacy password setting method
 Successfully mapped HTTP/neo.example.org to tomcat.

付録 D: トラブルシューティング

この付録では、エラーと問題のトラブルシューティングに関する一般的な情報を提供します。

環境と構成が正しく設定されていると思われる場合は、再確認し、明らかな間違いや型ミスがないか他の人にチェックしてもらいます。Kerberos セットアップは一般に非常に脆弱で、問題がどこにあるのかをデバッグするのは必ずしも簡単ではありません。

復号化する適切な型のキーが見つかりません 
GSSException: Failure unspecified at GSS-API level (Mechanism level:
Invalid argument (400) - Cannot find key of appropriate type to
decrypt AP REP - RC4 with HMAC)

キー型が見つからないことを示す異常エラーが表示された場合、これは 2 つの異なる使用例で発生します。まず、JVM が適切な暗号化型をサポートしていないか、krb5.conf ファイルで無効になっている可能性があります。

default_tkt_enctypes = rc4-hmac
default_tgs_enctypes = rc4-hmac

2 番目のケースは、同じエラーが発生するため、あまり目立たず、追跡するのが困難です。この特定の GSSException は、単純に必要な暗号化キーがない場合にもスローされます。その場合、Kerberos サーバーの構成ミスまたはプリンシパルの単純な型ミスが原因である可能性があります。

間違った Kerberos 構成を使用する

​

ほとんどのシステムでは、すべてのコマンドとライブラリは、デフォルトの場所または JDK などの特別な場所から Kerberos 構成を検索します。特に UNIX システムから Windows ドメインに対して MIT Kerberos を使用するためのデフォルト設定がすでに設定されている可能性があるため、混同しやすいです。

これは、ldapsearch が Kerberos 認証を使用して Windows AD にクエリを実行しようとした場合に何が起こるかを示す具体的な例です。

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
  additional info: SASL(-1): generic failure: GSSAPI Error:
  Unspecified GSS failure.  Minor code may provide more information
  (No Kerberos credentials available)

これは見た目が良くありません。以下に示すように、有効な Kerberos チケットを持っていないことを単純に示しています。

$ klist
klist: Credentials cache file '/tmp/krb5cc_1000' not found

Linux 上で実行される Tomcat で使用するために、Windows AD からエクスポートした keytab ファイルがすでにあります。これを使用して Windows AD で認証してみましょう。

通常、システムプロパティを介してネイティブ Linux コマンドおよび JVM で使用できる専用の構成ファイルを作成できます。

$ cat krb5.ini
[libdefaults]
default_realm = EXAMPLE.ORG
default_keytab_name = /tmp/tomcat.keytab
forwardable=true

[realms]
EXAMPLE.ORG = {
  kdc = WIN-EKBO0EQ7TS7.example.org:88
}

[domain_realm]
example.org=EXAMPLE.ORG
.example.org=EXAMPLE.ORG

その設定とキータブを使用して、初期認証情報を取得しましょう。

$ env KRB5_CONFIG=/path/to/krb5.ini kinit -kt tomcat.keytab HTTP/[email protected] (英語)  

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected] (英語)  

Valid starting     Expires            Service principal
26/03/15 09:04:37  26/03/15 19:04:37  krbtgt/[email protected] (英語)  
  renew until 27/03/15 09:04:37

Windows AD に対して単純なクエリを実行するとどうなるかを見てみましょう。

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
  additional info: SASL(-1): generic failure: GSSAPI Error:
  Unspecified GSS failure.  Minor code may provide more information
  (KDC returned error string: PROCESS_TGS)

これは、単に ldapsearch が混乱しており、単に間違った構成を使用していることが原因である可能性があります。kinit の場合と同様に、KRB5_CONFIG 環境変数を介して、ldapsearch に別の構成を使用するように指示できます。KRB5_TRACE=/dev/stderr を使用して、ネイティブライブラリの動作に関するより詳細な出力を取得することもできます。

$ env KRB5_CONFIG=/path/to/krb5.ini ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org -b "dc=example,dc=org"

$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: HTTP/[email protected] (英語)  

Valid starting     Expires            Service principal
26/03/15 09:11:03  26/03/15 19:11:03  krbtgt/[email protected] (英語)  
  renew until 27/03/15 09:11:03
  26/03/15 09:11:44  26/03/15 19:11:03
  ldap/[email protected] (英語)  
    renew until 27/03/15 09:11:03

上記では、kerberos チケットを確認することで、クエリが成功した場合に何が起こったかを確認できます。これで、KerberosLdapContextSource を使用する場合など、さらにクエリコマンドを試すことができます。

$ ldapsearch -H ldap://WIN-EKBO0EQ7TS7.example.org \
-b "dc=example,dc=org" \
"(| ([email protected] (英語)  )
([email protected] (英語)  ))" \
dn

...
# test user, example.org
dn: CN=test user,DC=example,DC=org

付録 E: Spnego ネゴシエーション用にブラウザーを構成する

Firefox

次の手順を実行して、Firefox ブラウザーが Spnego 認証を実行できるようにします。

  • Firefox を開きます。

  • アドレスフィールドに概要: 設定と入力します。

  • フィルター / 検索に "negotiate" と入力します。

  • パラメーター network.negotiate-auth.trusted-uris がデフォルトの https:// に設定されている可能性がありますが、これは機能しません。一般に、Kerberos 委譲が必要な場合は、このパラメーターをサーバーアドレスに置き換える必要があります。

  • すべての通信には https を使用することをお勧めします。

Chrome

Google Chrome を使用する場合は、通常、Chrome がネゴシエートするホワイトリストサーバーの順序にコマンドラインパラメーターを設定する必要があります。

  • Windows マシン上 (クライアント): Chrome は Internet Explorer と構成を共有するため、すべての変更が IE に適用された場合 (E.3 に従って)、コマンドラインパラメーターを介して何も渡す必要はありません。

  • Linux/Mac OS マシン (クライアント) の場合: コマンドラインパラメーター --auth-negotiate-delegate-whitelist は、Kerberos 委譲が必要な場合にのみ使用してください (それ以外の場合は、このパラメーターを設定しないでください)。

  • すべての通信には https を使用することをお勧めします。

--auth-server-whitelist="*.example.com"
--auth-negotiate-delegate-whitelist="*.example.com"

Chrome のアドレスバーに "クローム: //policy/" と入力すると、どのポリシーが有効になっているかを確認できます。

Linux では、Chrome は /etc/opt/chrome/policies/managed ディレクトリからポリシーファイルも読み取ります。

mypolicy.json
{
  "AuthServerWhitelist" : "*.example.org",
  "AuthNegotiateDelegateWhitelist" : "*.example.org",
  "DisableAuthNegotiateCnameLookup" : true,
  "EnableAuthNegotiatePort" : true
}

インターネットエクスプローラー

Internet Explorer ブラウザーが Spnego 認証を実行できるようにするには、次の手順を実行します。

  • Internet Explorer を開きます。

  • "ツール> インターネットオプション> セキュリティ " タブをクリックします。

  • ローカルイントラネットセクションで、サーバーをリストに追加するなどして、サーバーが信頼されていることを確認します。