アイデンティティ管理（4）直接統合オプションの概要

＊本記事は「Red Hat Enterprise Linux Blog」に掲載された記事を翻訳したものです
原著：「Overview of Direct Integration Options」
執筆：Dmitri Pal
翻訳：ソリューションアーキテクト 森若 和雄

前回の記事（アイデンティティ管理（3）：統合における着眼点） でも触れたように、LinuxシステムをActive Directory（AD）に接続するには複数の方法があります。これを念頭に、以下の選択肢を見てみましょう。

• レガシーな統合手法：（比較的古い）ネイティブのLinuxツールを使ってLDAPサーバー（ADなど）に接続する手法です。
• 昔ながらの統合手法：Samba winbindによる手法です。
• サードパーティ製品による統合手法：（プロプライエタリな）商用ソフトウェアによる手法です。
• 現代的な統合手法：SSSDによる手法です。

レガシーな統合手法

レガシーな統合手法（上図）では、LinuxシステムはADにLDAPでアイデンティティ情報を参照し、LDAPまたはKerberosで認証を行います。これは基本的なユーザー認証をうまく解決します。しかしこの手法には以下のような大きな欠点があります：

• 1つのLDAP名前空間またはKerberosドメインだけが設定できる。これは近年の、複数のドメインやフォレストに分散しているユーザー群を管理する際には大きな制限となる。
• これらのツールを安全な方法で設定することは非常に難しいので、高い権限をもつ管理者のパスワードが各システムからアクセス可能な形で保存されがち。
• アイデンティティ情報にキャッシュがなく、中央のサーバーとの接続が切れるとシステムが稼動（ほとんど何も）できなくなる。
• クライアントは非標準のAD拡張を利用できない。これは低いパフォーマンスと高いネットワーク負荷につながる。
• クライアントが同じドメイン内の他のADインスタンスを発見してフェイルオーバすることが簡単ではない。
• このセットアップではADの中にLinux用のアイデンティティ属性（POSIX属性）を保存し、管理する必要がある。
• ポリシーは集中管理されない。

最終的に、レガシーな統合手法については無償であるという以外にはあまり利点がありません。ここ数年このオプションを使ってADと連携しているシステムを見ていないのも驚くには値しないでしょう。

昔ながらの統合手法

昔ながらの統合手法（上図）では、Samba winbindを利用します。この手法は、基本的なレガシーな統合手法と比較して大きな利点があります：

• winbindはADに接続することを前提としており、WindowsのネイティブプロトコルとLDAPのプロトコル拡張を利用できる。
• ドメインとフォレストを理解するだけでなく、ドメイン間、フォレスト間の信頼関係も扱える。

• DNSによるサーバー検出を利用できる。
• ADドメインコントローラのインスタンスが利用できなくなると別のサーバーにフェイルオーバできる。
• ADのオブジェクト識別子（SID）または（拡張が導入された）ADに保存されたPOSIX属性にもとづいて、完全にアイデンティティ情報をマッピングできる。
• Samba FSおよびCIFSクライアントとよく統合されている。
• 接続のセキュリティが高い。クライアントシステムとそのシステムに発行されたKerberos鍵に基いている。

Samba winbindは上記の利点があり、レガシーな統合手法に比べれば進んでいますが、いくつかの制限があります：

• ポリシーは（まだ）集中管理されておらず、他の方法で配布される必要がある。
• レガシーな統合手法では任意のLDAPおよびKerberosサーバー実装に接続できるのに対して、Samba winbind はADにしか接続できない。

総合的に見て、Samba winbindは10年以上にわたって十分なレベルの統合を実現する目的を果たし、Linuxを現代的なデータセンタに導入する推進力となってきました。

サードパーティ製品による統合手法

サードパーティ製品による統合手法（上図）では、伝統的な統合手法（Samba winbind）ができること全てが利用できるのに加えて、いくつかの大きな利点があります：

• サードパーティ製品のクライアント管理コンソールは多くの場合Windowsクライアントと同じ管理インタフェースでクライアントシステムと関連するポリシーの集中管理が可能。
• ホストベースアクセスコントロール（HBAC）やユーザーの権限昇格（sudo）の集中管理が可能。これはグループポリシーオブジェクト（GPO）という、Windowsクライアントのポリシー集中管理と同じ仕組みで実現されている。
• クライアントのインストールと設定は通常ヒューマンエラーが入る可能性のある設定手順ではなく、シンプルなコマンドである。

上記の利点の他にもサードパーティ製品による統合手法は、先進的な機能を持っています。多くの場合には必要となりませんが、商用ソフトウェアとオープンソースソフトウェアの差別化要因になっています。

サードパーティ製品による統合手法は便利で成熟していますが、現代的な統合手法（下記参照）に地歩を奪われています。これはネイティブではなく、基盤となるLinux OSの一部ではないためです。とはいうものの、Linuxに限らないさまざまなOSにまたがって、一貫性のある先進的な機能を必要としている企業はこの手法を継続して利用していくでしょう。

現代的な統合手法

現代的な統合手法（下図）はSSSDとよばれるコンポーネントにもとづいたものです。SSSDはSystems Security Services Daemonの略で、コアLinux OSに含まれる連携して動作するサービス群からなり、Linuxシステムに認証、アイデンティティ情報の参照、アクセス制御の機能を提供します。SSSDはAD、FreeIPA（Red Hat Enteprise Linux または CentOSでは “Identity Management（IdM）” として知られます）、Samba DCまたは標準的なLDAPおよびKerberosサーバーと相互運用性があります。

最近のバージョンのLinuxは”realmd”というコンポーネントを含んでいます。このコンポーネントはSSSDの設定をおこないます。DNSに問いあわせて中央のアイデンティティサーバーを検出します。realmdはSSSDを AD、FreeIPAまたはMIT Kerberosと連携するようインストールおよび設定でき、これはサードパーティ製品による統合と同じくらいスムーズかつ簡単です。

Samba winbindと比較すると、SSSDはwinbindでできることのほとんどが可能です。唯一の大きな制限としては（古い）NTLMプロトコルのサポートがあります。 現在の標準に照らすとNTLMはもはやセキュアではないため、SSSDはこのプロトコルを実装していません。企業内でのNTLMの利用を停止するのはセキュリティ上のベストプラクティスです。しかし歴史的な理由か環境の複雑さのため難しいという組織もあるかと思われます。

追記すると、最近までSSSDはSamba FSおよびCIFSクライアントとの統合ができていませんでしたが、最新版のSSSD  では対応済みです。Samba winbindの現代的な機能に加えてSSSDはSamba winbindには直接関係しない以下の機能を持っています：

• ADで管理されているグループポリシーオブジェクト（GPO）をダウンロードしてホストベースアクセスコントロール（HBAC）ポリシーとして適用する。
• 先に触れたようにSSSDはADだけでなく他のアイデンティティ情報源とも相互運用性がある。SSSDはDNSのエージングと清掃をサポートしています（たとえばサーバーの削除や更新に対応するDNSエントリを検出します）。
• SSSDはD-Busとよばれるローカルのメッセージバスにアイデンティティについてのインタフェースを公開しています。このインタフェースにより、Linux OS上で動作しているアプリケーションをADやFreeIPA（IdM）とうまく統合できます。

SSSDは活発に開発されており、Docker、Cockpit、GSS Proxyなどの新しいコンポーネントとの統合もロードマップに含まれています。商用のソリューションと比較すると、SSSDによる直接統合はいくつかの制限がありますが、多くの制限についてはこのトピックの次の回で間接統合とともにご紹介します。以下に、4つの直接統合オプションについてわかりやすい比較表を記載しておきます。

直接統合手法のまとめ

カテゴリ	機能	レガシー（LDAP/KRB）	昔ながら（Winbind）	サードパーティ	現代的（SSSD）
認証	Kerberosによる認証	Yes	Yes	Yes	Yes
	LDAPによる認証	Yes	Yes	Yes	Yes
	複数ADドメインのサポート	No	Yes	Yes	Yes
	ADフォレストのサポート	No	Yes	Yes	Yes
	AD/FreeIPA（IdM）の混在環境サポート	No	No	No	Yes
セキュリティ	セキュアな設定が簡単	No	No	Yes	Yes
	中央サーバーへのアクセスするためにシステムはアイデンティティ情報とキーを利用する	No	Yes	Yes	Yes
	NTLMサポート	No	Yes	Vendor specific	No
アイデンティティ情報の参照とマッピング	ADにPOSIX属性の拡張が必要（SFU/IMU）	Yes	No	Vendor specific	No
	AD SIDのダイナミックなマッピングが可能	No	Yes	Vendor specific	Yes
	AD特有の拡張とプロトコルを活用できる	No	Yes	Vendor specific	Yes
DNS	AD DNSのエージングと清掃に対応	No	No	Vendor specific	Yes
	ADサイトのサポート	No	Yes	Vendor specific	Yes
ファイル共有	Samba FSの統合	No	Yes	Vendor specific	Yes
	CIFSクライアントの統合	No	Yes	Vendor specific	Yes
ポリシー	GPOによるホストベースアクセスコントロールの集中管理	No	No	Yes	Yes
ホスト上の他サービスおよびアプリケーションとの統合	SSH, sudo, automountのようなコアユーティリティとの統合	No	No	Vendor specific	Yes
	ローカルメッセージバス経由の拡張アイデンティティインタフェース	No	No	No	Yes
	アプリケーション向けの機能拡張	No	No	No	Yes
ユーザーエクスペリエンス	簡単なインストール	No	No	Yes	Yes
コスト		Free	Free	5000円〜1万円/クライアント	Free