赤帽基盤部


*本記事は「Red Hat Enterprise Linux Blog」に掲載された記事を翻訳したものです
原著:「Active Directory and Identity Management (IdM) Trusts – Exactly Where Are My Users?
執筆:Dmitri Pal
翻訳:ソリューションアーキテクト 森若 和雄

アイデンティティ管理についてのコラムの第6回です。ここで今一度、過去の記事を振り返ってみましょう。本連載の第1回では、現在の企業システムにおける相互運用性に関連した課題の概要を示しました。第2回では、LinuxシステムとActive Directoryの相互運用上のギャップがどのようなものか、今までどのように取り組まれてきたか、そして現在どのような選択肢があるのかについて見ました。第3回では、さまざまな統合手法を評価するための基準について概説しました。そして最新の第4回第5回では、それぞれ直接統合と間接統合について触れました。

間接統合(つまり信頼関係によるアプローチ)について掘り下げると、よく2つの大きな質問が出てきます。それは「ユーザー情報はどこにあるのか?」と「認証が本当に行われるのはどこか?」です。同期によるソリューションとは異なり、信頼関係によるアプローチでは、どこであれユーザーエントリーとそのパスワードが保存されている場所で認証が行われます。もしADユーザーが認証をしようとすると、アクセスしようとしているリソースに関係なくユーザーは所属しているADドメインで認証されます。これは、クライアントソフトウェア(たとえばSSSD)が十分に賢く(システム自体はIdMのメンバーであっても)そのユーザがADに保存されていると認識できることで実現されています。このシナリオでは、SSSDはユーザー認証のためにADと直接やりとりを行います。

注意点として、IdMは最新版のSSSDを持たないレガシーなLinuxおよびUNIXシステムにも対応する必要があります。LinuxおよびUNIXのレガシーなクライアントを統合するニーズに対応するため、IdMはアイデンティティ情報をキャッシュしてプロキシサーバーとして振舞います。実際にはIdMサーバー上で特別な設定のSSSDを使って、ADから情報を収集し認証を実施します。互換性ツリーとよばれる形でデータを公開します。

内部でどのようなことが行われているかをさらに学習したい方には、FreeIPAのスライドがここにありますので参考にしてみてください。

最後に、上述の機能はIdMの一部で、Red Hat Enterprise Linux 7の一部として利用できることに触れておきます。より詳しくは、カスタマーポータルからドキュメントが閲覧できますので、ぜひご覧ください。