第14章 Identity Management

IdM API が拡張されて API コマンドの複数のバージョンが有効になった場合でも、ユーザーは既存のツールとスクリプトを使用できます。これらの機能拡張により、コマンドの動作が互換性のない方法で変更されることはありません。これには次の利点があります。

たとえば、一方が機能の新しいオプションを導入した新しいバージョンを使用している場合でも、サーバーとの通信は可能です。

SSSD を使用してローカルファイルからユーザーおよびグループ情報を取得するには、次のコマンドを実行します。

新しいレルムには、新しい設定テンプレートを使用することを推奨します。テンプレートは、すでにデプロイされているレルムには影響しません。テンプレートに従ってレルムの設定をアップグレードすることを計画している場合は、次の点を考慮してください。

マスターキーをアップグレードするには、KDC 設定の設定を変更するだけでは不十分です。MIT Kerberos のドキュメント に記載されているプロセスに従います。

AES HMAC SHA-2 ファミリーをキー暗号化のサポートされているタイプに追加しても、KDC 内の既存のエントリーに影響しないため、常に安全です。キーは、新しいプリンシパルを作成するとき、または認証情報を更新するときのみに生成されます。この新しいタイプのキーは、既存のキーに基づいて生成できないことに注意してください。これらの新しい暗号化タイプを特定のプリンシパルで使用できるようにするには、認証情報を更新する必要があります。つまり、サービスプリンシパルのキータブも更新する必要があります。

プリンシパルが AES HMAC SHA-2 キーを備えてはならない唯一のケースは、Active Directory (AD) クロスレルム ticket-granting ticket (TGT) のものです。AD は RFC8009 を実装していないため、AES HMAC SHA-2 暗号化タイプファミリーを使用しません。したがって、AES HMAC SHA-2 で暗号化されたクロスレルム TGT を使用するクロスレルム TGS-REQ は失敗します。MIT Kerberos クライアントが AD に対して AES HMAC SHA-2 を 使用しないようにする最善の方法は、AD クロスレルムプリンシパルに AES HMAC SHA-2 キーを提供しないことです。これを行うには、AD ですべてサポートされているキー暗号化タイプの明示的なリストを使用して、クロスレルム TGT エントリーを作成してください。

  kadmin.local <<EOF
  add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[MIT realm]@[AD realm]
  add_principal +requires_preauth -e aes256-cts-hmac-sha1-96,aes128-cts-hmac-sha1-96 -pw [password] krbtgt/[AD realm]@[MIT realm]
  EOF

MIT Kerboros クライアントが AES HMAC SHA-2 暗号化タイプを使用するようにするには、これらの暗号化タイプをクライアントと KDC 設定の両方で permitted に設定する必要もあります。RHEL では、この設定は crypto-policy システムによって管理されます。たとえば、RHEL 9 では、DEFAULT 暗号化ポリシーを使用するホストは AES HMAC SHA-2 および AES HMAC SHA-1 で暗号化されたチケットを許可しますが、FIPS 暗号化ポリシーを使用するホストは AES HMAC SHA-2 のみを受け入れます。

以前のシリアル化の動作を有効にするには、環境変数 SSS_LOCKFREE を NO に設定します。