Active DirectoryとLinuxの認証を統合しよう

第0回認証統合の概要とSamba

最近の企業ネットワークにおいて、Active Directoryが存在していない環境というのは、まず考えられません。Active Directoryにより、Windowsサーバにアクセスする際のユーザ名やパスワードについての一元管理が実現されます。一般のユーザはあたりまえのように、この恩恵を享受していることが多いと思います。一方、Linuxも企業ネットワークの中で着実に地歩を固めつつあると言えます。結果として、大半の企業ネットワークはWindowsとLinuxの混在環境になっているというのが昨今の実状と思われます。

こうした場合に管理者が直面する課題の1つは、せっかくActive Directory(以下ADと呼びます)によりWindows環境では認証の一元管理が実現しているにもかかわらず、Linuxマシンは個々に認証を行わざるを得ないという点です。

本年第一弾として始まる本連載では、この課題を解決する方法について具体的に解説していく予定です。今回はこれに先立ち、認証統合の概要をざっと見て行きましょう。

認証統合を検討する前に

認証統合にあたっては、幾つか留意すべき点があります。まずはこれを押さえておきましょう。

(1)パスワードの統合と認証統合

一般的にWindows環境で認証を行う場合、ユーザ名とパスワードの情報が必要です。ADとLinuxの認証を統合する場合は、パスワードのみ統合する方式と、ユーザの統合も含めて実現する方法があります。

パスワードのみ統合した場合、ユーザ自体はLinux上で作成しておく必要があります。ただし、そのユーザのパスワードについては、Active Directoryに存在する(通常)同名のユーザのものを用いることになります。

図1
図1

一方、認証統合を行った場合は、Linux上で明示的にユーザの作成や削除を行う必要はなく、ADに存在するユーザは自動的にLinux側で認識される形となります。

図2
図2

(2)クライアントアクセスライセンス(CAL)について

現在、マイクロソフトはサーバに「アクセス」する「デバイス」にはCALが必要であると言っています[1]⁠。そのため、Active DirectoryのDCとして稼働しているWindowsサーバにアクセスするLinuxサーバについても、基本的にCALの対象となります。

図3 CALが必要なケース
図3 CALが必要なケース

また、⁠マルチプレキシング」という概念により、間接的にWindowsサーバにアクセスするデバイスやユーザについてもCALの対象となっています。このため、Linuxマシンの認証をADで行う場合、そのLinuxマシンにアクセスするユーザやデバイスにはCALが必要となる点に留意してください。

統合認証の方式

それでは、ADとLinuxを統合して認証するための方式を紹介していきましょう。

pam_krb5によるパスワードの統合

ADの認証は、Kerberosプロトコルにより行われています。このため、ADのドメインコントローラ(DC)は、Kerberosプロトコル的にはKDCとして機能していると言えます。

pam_krb5は、Linuxマシンの認証を外部のKDCにより行えるようにするPAMモジュールです。KDCとしてADのDCを指定することで、Linuxマシンの認証をActive Directoryに統合できます。

図4 pam_krb5によるパスワードの統合
図4 pam_krb5によるパスワードの統合

この方法は手軽である半面、パスワードのみの統合であるため、ユーザの作成/削除自体はLinuxマシンで別途行う必要があります。

SFU(SUA)のNIS機能による認証統合

SFU[2]は、Windows Server 2000以降で動作する無償のプロダクトであり、Windows Server 2003 R2以降ではOSに同梱されました。

SFUの機能の1つにNISサーバ機能があり、ADのDCをUNIX系OSの古いディレクトリサービスであるNISのサーバとして動作させることができます。これにより、認証を統合することが可能です。

図5 NIS機能による認証統合
図5 NIS機能による認証統合

この方法は比較的簡単な設定で実現できますが、NIS自体がセキュリティ機能の欠如により、昨今では過去のものとなりつつあります。こうした状況を考えると、積極的に使用を推奨すべきものではないでしょう。

SFUのUNIX属性によるLDAPを用いた認証統合

ADはLDAPサーバとしても機能します。このため、Linuxマシンの認証を外部のLDAPサーバにより行うように設定を行い、AD側でも適切な設定を行うことで、Linuxマシンの認証をADに統合できます。

図6 SFU+LDAPによる認証統合
図6 SFU+LDAPによる認証統合

これにより、ある程度セキュアな形で認証の統合が可能となります。ただし、pam_ldapやnss_ldapといったLinuxの認証モジュールを適切に設定する必要がある他、LDAP通信のセキュリティを確保するためには、さらにさまざなな設定が必要であり、かなり難易度は高いと言えます。

SambaのWinbind機構による認証統合

SambaはLinuxをWindowsサーバとして機能させるオープンソースのプロダクトです。Sambaを用いることで、LinuxマシンをWindowsマシンと同様の機構でADのメンバサーバとして稼働させることができます。これにより、パスワードの統合が実現します。

さらにWinbind機構を有効化することで、AD上のユーザやグループをLinuxサーバ上で使用することが可能となるため、認証の統合が実現できます。

この方式を行う際は、Sambaの各種パラメータやモジュールの設定を適切に行う必要があります。このため決して容易とは言えませんが、設定がSamba上で閉じている分、前述したLDAPを用いた認証統合よりはわかりやすいでしょう。

図7 Samba+Winbindによる認証統合
図7 Samba+Winbindによる認証統合

まとめ

ここで紹介したした方式のメリット、デメリットを表1に簡単にまとめました。次回からの連載では、これらの方式について具体的な設定方法などを説明していきます。

連携方式の比較
方式 認証統合 Windows追加コンポーネント Linux追加コンポーネント 設定の難易度
pam_krb5 パスワードのみ なし pam_krb5 容易
SFU+NIS 認証統合 SFU(SUA) NIS 中程度
SFU+LDAP 認証統合 SFU(SUA) LDAP 至難
Samba パスワードのみ なし Samba 中程度
Samba+Winbind 認証統合 なし Samba+Winbind 難しい
 設定によってはSFU(SUA)が必要


Active Directoryに関する技術情報:
Microsoft TechNet Active Directory TechCenter
URL:http://technet.microsoft.com/ja-jp/activedirectory/default.aspx
Microsoft Active Directory 機能概要ページ
URL:http://www.microsoft.com/japan/ad/

おすすめ記事

記事・ニュース一覧