Title: Microsoft ActiveDirectory を使用した Kerberos 認証用に TeamPage を設定する手順
TeamPage は、バージョン 6.2.66 以降で、RFC4559 に概説されている標準メカニズムを介して、ユーザー認証に Kerberos をサポートしています。
この記事では、Microsoft Active Directory (AD) で定義されたユーザーアカウントに Kerberos 認証を使用するための TeamPage の設定方法について説明します。
また、TeamPage の一般的な Active Directory 設定について解説した DocJp92: Active Directory 設定 もご確認ください。
はじめに
ユーザー管理のために AD に接続する場合、TeamPage は NTLMv1 をそのままサポートします。より安全な NTLMv2 を使用するためには、追加料金が必要な 「Jespa」プラグイン を導入する必要があります。TeamPageは、オンプレミス AD の代わりに Azure AD への接続もサポートしています。
しかし、まだオンプレミス AD を使用しているのであれば、NTLMv1 と NTLMv2 のどちらよりも Kerberos の方が安全です。実際、多くの企業組織において AD 環境で NTLM を廃止しています。Kerberos を使用するその他の利点として、以下のようなものが挙げられます。
- 最新の強力な暗号化標準をサポートしています。
- TeamPage と AD サービスの間でユーザを認証するための通信が不要です。
- Windows 環境で広く標準サポートされ、Linux と MacOS の両方でいくつかの追加設定手順でサポートされます。
以下、AD 環境で定義されているユーザーに対して Kerberos 認証を使用するように TeamPage サーバーを設定する方法について説明します。
AD の構成
サービスプリンシパル名（SPN）にバインドできる AD のアカウントを設定する必要があります。以下の手順では、Active Directory Admin Center と Windows PowerShell を使用できるように、AD 環境内の少なくとも1つのドメインコントローラー（DC）への管理者アクセス権の両方が必要です。
以下の手順で設定したアカウント名やパスワードなどの詳細は、「TeamPage の設定」セクションですべて必要になるため、メモしておいてください。また、この手順と並行して、そのセクションの指示に従うこともできます。
あなたの組織のポリシーに従いつつ TeamPage の認証が正しく実行されるように、以下の手順を実行してください。
1. 新しいサービスアカウントを作成します。Kerberos 認証を設定する TeamPage サーバーを識別できるものを使用することを推奨します。この例では、TeamPage 開発サーバー用に「teampagedev」を選択します。本番サーバーには「teampagepro」を、テストサーバーには「teampagetest」を選択できます。使用するパスワードをメモしておきます。（パスワードマネージャなど安全な場所に保存するのが理想的です）
パスワードオプションとその他の暗号化オプションを開き、[その他のパスワードオプション] > [パスワードの有効期限なし] を選択できるようにしてください。事実上、これはサービス用のアカウントのためです。そして、[その他の暗号化オプション] > [このアカウントで Kerberos AES 128/256 ビット暗号化をサポートする] を選択します。
(これらの AES 暗号化タイプを有効にしておく理由は、Java の将来のバージョンで古い安全性の低い暗号化タイプがサポートされなくなる可能性があるからです。今この設定をしておくことで、将来の Java の暗号化タイプのサポート変更に備えておきましょう。）
2. Windows Server 環境が現在および将来の強力な暗号化タイプをサポートしていることを確認します。
[Windows の設定] の検索欄に「グループ 」と入力し、[グループ ポリシーの編集] を選択し、ローカル グループ ポリシー エディターを起動します。
左ペインで [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [セキュリティ オプション] を開き、[ネットワーク セキュリティ: Kerberos で許可する暗号化の種類を構成する] と書かれた設定を見つけます。
少なくとも [AES128] および [AES256] のチェックボックスをオンする必要があります。また、[将来使用する暗号化の種類] チェックボックスをオンに変更し、その他の弱い暗号化タイプのチェックボックスをオフにすると良いでしょう。
TeamPage からの受信接続用に SPN を登録する
SPN についての詳細は learn.microsoft.c… を参照してください。
この例では、TeamPage サーバーは、ホスト「tp.example.jp」で動作しており、ドメインは「example.jp」です。したがって、SPN は「HTTP/tp.example.jp@EXAMPLE.JP」となります。@記号に続くドメインは、すべて大文字で表記します。
管理者モードで起動した PowerShell で setspn コマンドを使います。
- setspn -L ... 指定されたアカウントに登録された SPN を一覧表示します。
- setspn -A ... 指定されたアカウントに SPN を追加します。
- setspn -D ... 指定されたアカウントから SPN を削除します。
次の例では、ユーザーアカウント「teampageadmin」の SPN を一覧表示し、新しい SPN を追加し、再度一覧表示して確認しています。
PS C:\Users\Administrator> setspn -L teampageadmin
次の項目に登録されている CN=teampageadmin,CN=Users,DC=example,DC=jp:
PS C:\Users\Administrator> setspn -A HTTP/tp.example.jp@EXAMPLE.JP teampageadmin
ドメイン DC=example,DC=jp を確認しています
CN=teampageadmin,CN=Users,DC=example,DC=jp の ServicePrincipalNames を登録しています
HTTP/tp.example.jp@EXAMPLE.JP
更新されたオブジェクト
PS C:\Users\Administrator> setspn -L teampageadmin
次の項目に登録されている CN=teampageadmin,CN=Users,DC=example,DC=jp:
HTTP/tp.example.jp@EXAMPLE.JP
下図は、実際に PowerShell で実行したときのスクリーンショットです。
PS C:\Users\Administrator> setspn -L teampagedev
Registered ServicePrincipalNames for CN=teampagedev,CN=Users,DC=tractionsoftware,DC=com:
PS C:\Users\Administrator> setspn -A HTTP/funzone.tractionsoftware.com@TRACTIONSOFTWARE.COM teampagedev
Checking domain DC=tractionsoftware,DC=com
Registering ServicePrincipalNames for CN=teampagedev,CN=Users,DC=tractionsoftware,DC=com
HTTP/funzone.tractionsoftware.com@TRACTIONSOFTWARE.COM
Updated object
PS C:\Users\Administrator> setspn -L teampagedev
Registered ServicePrincipalNames for CN=teampagedev,CN=Users,DC=tractionsoftware,DC=com:
HTTP/funzone.tractionsoftware.com@TRACTIONSOFTWARE.COM
Kerberos 認証要求の複合化に使用する keytab ファイルの作成
TeamPage がユーザーのブラウザーからの Kerberos 認証チャレンジ応答を復号化するために使用する keytab ファイルを作成します。
SPN がユーザー名になります。 上記でユーザー アカウントに設定したのと同じパスワードを使用します。
PowerShell で ktpass コマンドを使用して、この SPN バインディングを「teampageadmin」ユーザー アカウントに作成します。 SPN とユーザー アカウントの名前に加えて、次のものを選択する必要があります。
ketpass コマンドについての詳細は learn.microsoft.c… を参照してください。
・ 使用するターゲット DC (または、-target オプションを省略して、ktpass にデフォルトの動作を使用させることもできます。これにより、プリンシパル名に基づいて DC が自動的に選択されます)
・ 暗号化のタイプ。 「AES256-SHA1」を使用することを強くお勧めします。これは、Windows と現在 TeamPage が実行されているすべてのバージョンの Java の両方でサポートされている堅牢なオプションです。
・出力ファイル。 適切でわかりやすい名前と .keytab の拡張子を選択することをお勧めします。 この例では、「teampageadmin.aes256.keytab」というファイルをデスクトップに保存するように指定しています。
プリンシパル タイプ (-ptype) は「KRB5_NT_PRINCIPAL」である必要があります。
これらすべてのパラメータに適切な引数を指定したコマンドの例を次に示します。
ktpass -princ HTTP/tp.example.jp@EXAMPLE.JP -mapuser teampageadmin -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass myPasswd123 -target ad.example.jp -out c:\Users\Administrator\Desktop\teampageadmin.aes256.keytab
backup
ktpass -princ HTTP/funzone.tractionsoftware.com@TRACTIONSOFTWARE.COM -mapuser teampagedev -crypto AES256-SHA1 -ptype KRB5_NT_PRINCIPAL -pass sledge-oldy-PHOSGENE -target WIN-G53K0E0GRBO.tractionsoftware.com -out c:\Users\Administrator\teampagedev.aes256.keytab
このコマンドを実行すると、次のような結果が表示されます。
Using legacy password setting method
Successfully mapped HTTP/tp.example.jp to teampageadmin.
Key created.
Output keytab to c:\Users\Administrator\Desktop\teampageadmin.aes256.keytab:
Keytab version: 0x502
keysize 80 HTTP/tp.example.jp@EXAMPLE.JP ptype 1 (KRB5_NT_PRINCIPAL) vno 3 etype 0x12 (AES256-SHA1) keylength 32 (0xa866350fea731898fa0c97f19cc08aa133751fe97dca00d77c3430dae82cc1b9)
下図は、実際に PowerShell で実行したときのスクリーンショットです。
keytab ファイルの設置
作成した keytab ファイルを TeamPage のホスト（ここでは「tp.example.jp」）にコピーし、適当なフォルダに設置します。
ここでは、TeamPage がインストールされている「server」フォルダ下の「settings」フォルダに設置することにしますが、他のフォルダでも構いません。（後に TeamPage の Kerberos 設定でファイルの設置場所（パス）を指定します）
TeamPage でのユーザー ディレクトリの設定
TeamPage のサーバーセットアップから、TeamPage が Active Directory サーバーと Kerberos で連携してユーザー認証を行うように設定します。
ユーザー ディレクトリの設定画面の表示
サーバーセットアップ > 一般 > 現在のジャーナル ページに移動し、[ユーザー ディレクトリの変更] ボタンをクリックします。
「ユーザー ディレクトリ選択」画面が表示されるので、[新規...] をクリックします。
「ユーザー ディレクトリの設定」画面が表示されます。
説明の記入およびビジターの設定
[説明] 欄にこの設定に関する説明を記入してください。日付や Kerberos 認証用の設定である旨を記入することを推奨します。
[ビジターのログインを許可] 設定で、ビジターのログインを許可するかどうかも選択してください。
Active Directory サーバーに関する設定
「Active Directory サーバー」設定セクションで、ドメイン コントローラー、LDAP 検索ポイント、その他の基本的な AD 接続と検索設定を設定します。
上図の例では、単一の DC に FQDN を使用することを選択しました。 AD 環境でリクエストをさまざまな DC にルーティングする方法として、ルート ドメインを使用することを選択できます。
この例では、ユーザー アカウントがそのドメインに属しているため、[既定のドメイン] 欄は「example.jp」としています。
[LDAP 検索ポイント] には、TeamPage がユーザーとグループを検索するために使用するクエリの範囲を絞り込むための DN コンポーネントが含まれている必要があります。
TeamPage によって作成された LDAP クエリの接続を保護するために、可能であれば暗号化された LDAPS (SSL/TLS) を選択することをお勧めします。（上図の例では、暗号化しない LDAP を使用しています）
TeamPage がすべてのユーザーを検索して見つけられるように、グローバル カタログ ポートを使用する必要があるかどうかも考慮する必要があります。
ポート番号は、通常、LDAP の場合は 3268、暗号化した LDAPS の場合は 3269 になります。
[認証の種類] 設定は、特に LDAP クエリ接続を指します。 現在利用可能なオプションは、[なし] (匿名アクセス) と [簡易] (ユーザー名 + パスワード) です。 (将来的には、ここで Kerberos もサポートされる可能性があります。) TeamPage が AD に対して LDAP クエリを実行できるように AD アカウントが設定されていると仮定して、[簡易] を選択し、表示される [アカウント] と [パスワード] 欄にユーザー名とパスワードを入力します。
認証に関する設定
「認証」設定セクションでユーザー認証に関する設定を行います。
[ログイン方法] ドロップダウンリストで「Kerberos」を選択します。
[Kerberos キータブ ファイル] には keytab ファイルのパスを記入します。
絶対パス (例: D:\Traction\TeamPage\teampageadmin.aes256.keytab) で記入するか、TeamPage がインストールされた「server」フォルダーに対する相対パス (例: settings\teampageadmin.aes256.keytab) を記入してください。
[TeamPage SPN サーバー名] には、上記で作成した SPN の、サービス アカウント名のみを参照する部分を入力します。
この例では、完全な SPN は「HTTP/tp.example.jp@EXAMPLE.JP」であるため、「tp.example.jp」と入力します。
空白のままにすると、TeamPage はホスト コンピューターの正規のホスト名に基づいた既定値を使用しようとしますが、Windows 環境に関する限り、これはホスト名と一致しない可能性があるため、正しいホスト名を入力することを強く推奨します。
[Kerberos レルム] の値はドメインと同じです。すべて大文字で入力した SPN の一部です。 この例では「EXAMPLE.JP」です。
[Kerberos サーバー パスワード] には、コマンド ラインで SPN に設定されるパスワードを入力します。これは、Java の JAAS システムが keytab ファイルを使用するために必要になります。
その他の設定については、既定値を使用できますが、調整が必要な設定があるかどうかを確認してください。例えば、ユーザー アカウントを検索するときに既定値以外のフィルターを使用したり、TeamPage で AD ユーザーとグループ プリンシパルのメタデータのローカル キャッシュを通常よりも頻繁に更新したり、頻度を減らしたりすることができます。
[名前を付けて保存] 欄にわかりやすい設定名を入力し、すぐ右側の [保存] ボタンをクリックします。
設定画面上部に保存した名前が反映されたことを確認します。
ユーザーやグループの検索テスト
重要!! この時点で、TeamPage から Active Directory のユーザーとグループの検索テストを行います。
設定画面下部の [保存] ボタンの横の [テスト] ボタンをクリックし、「ユーザー ディレクトリのテスト」画面を表示します。
ユーザーやグループの名前を入力して [ルックアップのテスト] ボタンをクリックして、ユーザーやグループを正しく検索できるかどうかを確認してください。
特に、TeamPage 内で権限設定を行う管理者グループ（通常「サーバー管理者」グループ）が検索できることを確認してください。
テストが失敗する場合は、テスト ダイアログを閉じて、設定を見直し、再度保存し、期待どおりの検索結果が得られるまでテストを行います。
テストが成功することを確認したら [閉じる] ボタンをクリックして「ユーザー ディレクトリのテスト」画面を閉じます。
TeamPage ユーザーを AD ユーザーに紐づけ（プリンシパルの移行）
元の「ユーザー ディレクトリの選択」画面の [ユーザーディレクトリ] ドロップダウンリストで、今新しく作成した設定が選択されていることを確認します。
TeamPage の標準のユーザー ディレクトリからこの新しい AD 構成に移行する場合、[プリンシパルの移行（トグル動作）] チェックボックスをオンにします。
このチェックボックスをオンにして [次へ] をクリックすると、「プリンシパルの移行」画面が表示されます。
この画面では、TeamPage のユーザーアカウントと Active Directory のユーザーアカウントの紐づけを確認できます。
TeamPage のユーザー名から推測された Active Directory のユーザーアカウントが見つかった場合、[新しいエンコーディング] 欄が黄色くなり、新しいエンコーディング情報が自動的に挿入されます。
問題があると思われるユーザーアカウントは赤く表示されます。
上図の例では、2 番目のユーザー「takashi」が赤く表示されており、[新しいエンコーディング] 欄には traction:u:2 と表示されています。この「traction:u:N」は、TeamPage の標準ユーザーディレクトリ上のプリンシパル情報を表しています。
つまり、TeamPage のユーザー「takashi」に紐づけるべき Active Directory ユーザーアカウントが見つからず、元の（TeamPage ユーザーとしての）プリンシパル情報が表示されたままの状態になっています。
このアカウントは、Active Directory のユーザーアカウントと紐づけず、Active Directory サーバーでトラブルが発生してユーザーの認証ができない（つまり、誰も TeamPage にログインできない）ような事態に備えて、Active Directory のユーザーアカウントととは紐づけず、このまま維持します。そのため、[新しいエンコーディング] の値は traction:u:2 のままにします。
重要!! この「takashi」のように、Active Directory 認証が正しく機能しない場合など、TeamPage の標準認証機能に戻す必要が生じる場合に備えて、Active Directory アカウントに紐付けない、TeamPage 専用のサーバー管理者アカウントを用意するようにしてください。
3 番目のユーザー「sano」も赤く表示されており、[新しいエンコーディング] 欄には traction:u:3 と表示されています。
ユーザー「sano」の [ルックアップ] をクリックして Active Directory のユーザーアカウントを検索すると、「佐野 浩」の他に「佐野川 希美」というアカウントが見つかりました。
正しい方（ここでは「佐野 浩」）をクリックして、TeamPage のユーザーアカウント「sano」を Active Directory の「佐野 浩」に紐づけることを TeamPage に教えます。
ユーザー「sano」の [新しいエンコーディング] に Active Directory の「佐野 浩」のプリンシパル情報が反映されました。
念のため、ユーザー「sanokawa」の [新しいエンコーディング] にも「佐野川 希美」の正しいプリンシパル情報が反映されていることを確認します。
紐づけ情報に問題がないことを確認したら、ページ下部の [完了] ボタンをクリックします。TeamPage は再起動します。
ログファイルやコンソール画面※には、TeamPage のユーザーアカウントのプリンシパルを Active Directory のものに移行した記録が表示されます。
※ コンソール画面は、TeamPage をサービスではなくアプリケーションとして動作している場合に表示されます。
すべてが正しく設定されていれば、ユーザーはプロンプトなしでブラウザーから TeamPage にログインできるはずです (「シームレス SSO」)。ただし、一部のブラウザーでは追加の構成が必要な場合があります。
Windows ユーザーと Kerberos チケット
AD ドメインに参加している Windows コンピューターのユーザーは、システムが TeamPage に送信するチケットを生成するために必要な「チケット許可チケット」(TGT) を取得および更新するために、特にするべきことはありません。
MacOS ユーザーと Kerebros チケット
MacOS のユーザーは、システムが TGT を自動的に取得および更新できる方法でドメインに参加していない限り、kinit コマンド ライン ツールを使用する必要があります。 追加の手順が必要になる場合があります。
- kinit がドメインに使用する KDC を識別できるように、/etc/krb5.conf ファイルを更新して正しい設定を組み込む必要があります。 この例では、win-g53k0e0grbo.tractionsoftware.com にある KDC として機能する DC を使用すると、krb5.conf ファイルは次のようになります。
[libdefaults]
default_realm = FUNZONE.TRACTIONSOFTWARE.COM
allow_weak_crypto = false
[realms]
FUNZONE.TRACTIONSOFTWARE.COM = {
kdc = WIN-G53K0E0GRBO.tractionsoftware.com
}
[domain_realm]
.win-g53k0e0grbo.tractionsoftware.com = WIN-G53K0E0GRBO.TRACTIONSOFTWARE.COM
win-g53k0e0grbo.tractionsoftware.com = WIN-G53K0E0GRBO.TRACTIONSOFTWARE.COM
.tractionsoftware.com = WIN-G53K0E0GRBO.TRACTIONSOFTWARE.COM
tractionsoftware.com = WIN-G53K0E0GRBO.TRACTIONSOFTWARE.COM
[appdefaults]
pam = {
debug = true
ticket_lifetime = 86400
renew_lifetime = 86400
forwardable = true
krb4_convert = false
}
- KDC が見つかるように DNS を適切に設定する必要があります。Mac コンピュータがドメインに参加していない場合は、追加の手順が必要になる場合があります。
この例では、「shep」のアカウント パスワードはファイル ~/krb.pass に保存されているため、コマンド ラインに入力する必要はありません。 --password-file 引数を省略した場合、ユーザーにパスワードの入力を求めるプロンプトを表示されます。
funzone (shep) ~ → kinit --password-file=./krb.pass --verbose shep@TRACTIONSOFTWARE.COM ✘ [1]
Placing tickets for 'shep@TRACTIONSOFTWARE.COM' in cache 'API:619284E9-DA92-43B2-BFCE-73A7CE819BBB'
funzone (shep) ~ → klist
Credentials cache: API:619284E9-DA92-43B2-BFCE-73A7CE819BBB
Principal: shep@TRACTIONSOFTWARE.COM
Issued Expires Principal
Jul 24 18:59:38 2023 Jul 25 04:59:38 2023 krbtgt/TRACTIONSOFTWARE.COM@TRACTIONSOFTWARE.COM
最初の TGT が取得された後は、kinit コマンドからユーザーを省略できます。
klist コマンドを使用すると、TGT および TGT で取得したチケットを含むチケットを一覧表示できます。
kdestroy コマンドを使用すると、TGT を含むすべてのチケットをクリアできます。（注意して使用してください）
ブラウザのサポート
すべての主要なブラウザーは、「シームレス SSO」による Kerberos 認証をサポートしています。
- IE11 または Windows 10 以降の最新バージョンの Edge では、コンピューターがドメインに参加している場合、ユーザーは ID やパスワードの入力なしで、管理者が追加の設定を行うことなく、TeamPage にログインできます。
- Firefox では、TeamPage サーバーのアドレスを「network.negotiate-auth.trusted-uris」設定に追加する必要があります。 これは「about:config」ページから行うことができますが、場合によっては、社内のすべてのコンピューターにこの設定を適用する方法を利用できます。詳細については、このページを参照してください。
- Windows 上の Chrome では、Chrome ポリシー エディタを使用して Kerberos を有効にする必要がある場合があります。 詳細については、このページを参照してください。
MacOS では、ユーザーまたは管理者は次のようなコマンドを使用して、Chrome が 1 つ以上のドメインに対して Kerberos を使用できるようにすることができます。
defaults write com.google.Chrome AuthServerAllowlist funzone.tractionsoftware.com
defaults write com.google.Chrome AuthNegotiateDelegateAllowlist funzone.tractionsoftware.com
- MacOS 上の Safari では、ユーザーが kinit を使用して適切なドメインの TGT を取得している限り、追加の設定は必要ありません。
