＊本記事は「Red Hat Enterprise Linux Blog」に掲載された記事を翻訳したものです
原著：「I Really Can’t Rename My Hosts!」
執筆：Dmitri Pal
翻訳：ソリューションアーキテクト 森若 和雄
こんにちは！今回は、アイデンティティ管理上の複雑な問題を解決するために何ができるかのアイデアを見ていきましょう。
アイデンティティ管理 (Identity Management, IdM) の利用が増えるにつれて、特にいくつかのシステムはLinuxを利用していてユーザーアカウントはActive Directory (AD) 上にあるような、混在環境におけるホストのリネームについての質問が目につくようになりました。以下が、典型的な顧客からの要件です：
- Active Directoryに格納されたクレデンシャルでLinuxホストにアクセスしたい
- Active Directoryに格納されたユーザーアカウントがLinuxホストにアクセスする権限を集中管理したい
- Active Directoryに格納されたユーザーアカウントの権限昇格 (sudo) を集中管理したい
- Linuxシステムのautomount mapを集中管理したい
- パスワードを都度入力せずに (SSOで) Linuxホスト間を行ったり来たりしたい
- Linuxホストをリネームしたくない。今はActive Directory DNSドメインに属していて、ミッションクリティカルなアプリケーションが動作していて…… リネームはできない。
- コスト効率がよく、LinuxシステムをActive Directory環境に統合するために追加の費用がかからないソリューションが欲しい
先に進む前に、まず用語を確認しておきましょう。シングルサインオン (SSO) とは、一度認証されたユーザーが別のシステムやリソースにアクセスする際に、再度認証を要求されないことを意味します。これはシングルアカウントと同じではありません。実際のところ、今回の記事で扱う全てのソリューションは、Active Directoryに格納された1つのユーザーアカウントが存在すると仮定しています。しかし、これだけではSSOではありません。ユーザーが一度パスワードを要求 (通常はワークステーションへのログイン時) されたら、他のシステムへアクセスするためにパスワードを入力するよう要求されないことではじめてSSOが実現します。なおかつここではエンタープライズのSSOについて、このような機能を提供するKerberosと呼ばれる技術を扱います。KerberosはWindowsとLinuxのどちらでも実装されています。
さて、SSOという用語が明確になったので、次に上で列挙した要件が実現可能か見ていきましょう。
以下の図は現在の状態を示しています。
これらの要件をどうやって満たすかを考えるため、もう少し詳しくいくつかの方式を見てみましょう。
オプション1 – サードパーティソフトウェアを利用する
このソリューションはコスト効率だけは例外として、上記のほとんど全てを満たします。この方式ではLinuxシステム管理機能も含め、全てをActive Directoryに格納します。これは望ましい場合もそうでない場合もあります。サードパーティソフトウェアの利用についてはこちらの記事をご覧ください。このようなソリューションで必要となるコストは、たいていの場合他のオプションを検討したくなるほどのものです。ひき続き見ていきましょう……。
オプション2 – 直接統合
直接統合については、過去の記事で触れています。SSSDによる基本的なGPOサポートによりアクセス制御ができるものの、直接統合の主な制限はsudoやautomountのようなポリシーが管理できない点にあります。これは要件 #3, #4 を実現できません。
オプション3 – IdMとの間接統合
IdMによるソリューションは過去の記事で紹介したように多くの利点がありますが、この特定のケースではSSOの要件 (要件の5番) でホスト名にまつわる問題がでてきます。ホストへのKerberosを利用したSSOを活用するには、ホストはActive Directoryのドメインではなく、IdMによって管理されるDNSドメインに含まれる必要があります (つまりホスト名をリネームする必要があります)。
もし、ホストをどうしてもリネームできないのであれば、KerberosベースのSSOアプローチは動作しません。「ADドメイン内にいるIdMホスト」というものはクライアントを混乱させてしまいます。クライアントは、IdMホストについてのKerberosチケットをIdMではなくADにリクエストします。それらのホストはIdMに参加していてKerberosプリンシパルはIDMのレルムに存在するため、ADはKerberosプリンシパルを解決できません。
この問題については、こちらのドキュメントでより詳しく説明しています。
行き詰まりでしょうか？ そうとは限りません。検討できる2つのオプションがあります。
オプション3a – IdMとの間接統合をおこないホストを除外する
Active Directoryは(訳注: Routing name suffix を利用して) 外部ホストを指定することができます。これは数台のホストだけをリネームできない場合には、ADに対してそれらのホストは別のドメインに所属しているものだと伝える方法があるということを意味します。この設定により、Active Directoryは外部のドメインコントローラ (この場合はIdM) にそれらの名前解決を委ねます。
しかしながら、この方法はほんとうにわずかなホスト数の場合にのみ利用可能です。(専門家によると) 数十のホストが必要になると、Active Directoryのパフォーマンスが劣化しはじめます。これはおそらく誰もが最も避けたいところでしょう。
オプション3b – IdMとの間接統合をおこないSSHでのSSOを行う
別のアプローチとして、Kerberosベースの認証をSSHベースのSSOで補完 (または完全におきかえ) することです。次の2つの図は、どのようにこれを達成するかを示しています。
LinuxホストはIdMに参加しますが、KerberosをSSOに使いません。この場合は名前をそのままにできます。最初に認証した後はユーザーがユーザー名とパスワードを再度聞かれずに済むという要件を満たしたい場合、SSHキーをADユーザーに発行することができます。Windowsワークステーションから踏み台ホストへのアクセスはKerberos SSOを利用します。そして他のシステムへSSH鍵認証で接続します。IdMはユーザーおよびホストのSSH公開鍵管理を提供し、これらの配布を非常にシンプルにします。
もしくは、Kerberos SSOをこれらのホストについては利用せず (Kerberos SSOはIdMドメイン内の他のホストとその上で実行されるサービスについては動作します)、一連の認証をSSH鍵認証で行うこともできます。
SSH鍵認証は、正式には「シングルサインオン」ではないことにご注意ください。これは鍵ベースの認証方式です。これは鍵のペア、秘密鍵と公開鍵を使います。秘密鍵はsshツールで生成されユーザーのワークステーションに格納され、公開鍵はIdMにアップロードできIdMが全ての管理ホストで必要に応じて利用できるようにします。厳密には「シングルサインオン」ではないのですが、ホストへのアクセス時にパスワードを聞かれずに済みます。これを考えに入れると、多くの場合SSOの要件は再調整または完全に削除できます。
もしこれで要件を満たせるのであれば、以下が必要な手順の概要になります。
- IdMをインストールする
- Active Directoryとtrustを構成する
- ホストをリネームせずにIdMに接続する
- (必要であれば) 踏み台ホストをIdMドメイン内に作成する
- (必要であれば) アクセス制御、automount、権限昇格ポリシーを設定する
- (ワークステーション用に) SSH鍵を生成して、公開鍵をIdM管理者と共有する。IdM管理者は公開鍵をIdMにアップロードする
- ワークステーションからのSSHは鍵を使って直接か、踏み台ホストを経由して接続するようにする
そうすると…… よし！全ての要件が満たされました。
この記事が、皆さんのお役に立てば幸いです。
