• [アーティクル]

相互運用

Active Directory を使用して Linux クライアントを認証する

Gil Kirkpatrick

 

概要:

  • Windows と Linux における認証のしくみ
  • Samba と Winbind を使用する
  • 実装戦略
  • Linux と Active Directory の統合の詳細

目次

Windows 認証
Linux 認証
Samba と Winbind
3 つの認証戦略
実装計画
適切なソフトウェアを見つける
Samba をビルドする
Linux ネットワークを構成する
Linux の時刻同期を構成する
PAM と NSS を構成する
Samba をインストールして構成する
ID マッピングに関する問題
ドメインに参加してログインする
正常に機能しない場合
正常に機能するようになったら
サードパーティ製のソリューション

共和党員と民主党員、歯磨き粉とオレンジ ジュース、Linux と Windows など、どうしても混ざらないものがあります。私がこれまでに関わったどの IT 企業も 2 つに分かれていました。つまり、Windows チームと Linux チームです。互いに争っているわけではありませんが、協力し合っていないことは確かです。実際、この 2 つのグループどうしの不適切な関わりを避けるために、床に黄色い線を引いている企業もあります。

私自身は Windows 志向で、確かに Linux 志向の同僚をからかってきましたが、全員が高品質でコスト効率の良い IT サービスを組織に提供するという同じ目標を持っています。これを実現する方法の 1 つは、Active Directory のような中核となるソフトウェア インフラストラクチャを共有することです。ほぼすべての IT 組織が、Active Directory を使用して、認証サービスを Windows デスクトップと Windows サーバーに提供しています。Linux 環境用に別の認証インフラストラクチャ (および別のユーザー名とパスワードのセット) を管理するのではなく、Active Directory を使用して Linux コンピュータも管理できたら便利ではないでしょうか。私はそう思います。そこで、この記事ではその方法を紹介します。

Windows 認証

かなり以前から Windows には統合ネットワーク認証およびシングル サインオン システムが付属しています。Windows 2000 が登場する前は、Windows NT ドメイン コントローラ (DC) が NT LAN Manager (NTLM) プロトコルを使用して Windows クライアントに認証サービスを提供していました。NTLM のセキュリティは、当初考えられていたほど強固ではありませんでしたが、ネットワーク上の複数のサーバー間で重複するユーザー アカウントをメンテナンスする必要がなくなるので、非常に役立ちました。

Windows 2000 以降、マイクロソフトは NTLM から Active Directory とその統合 Kerberos 認証サービスに移行しました。Kerberos のセキュリティは NTLM よりも強固であると見なされ、スケーラビリティの面でも優れていました。また、Kerberos は既に Linux システムと UNIX システムで使用されている業界標準でもあったので、これらのプラットフォームと Windows を統合する試みが始まりました。

Linux 認証

Linux (および Linux 上で実行される GNU ツールとライブラリ) は、もともと 1 つの認証メカニズムを念頭に置いて構築されませんでした。このため、通常 Linux アプリケーション開発者は、独自の認証スキームを作成していました。この作業は、/etc/passwd (Linux ユーザー資格情報の保持に従来使用されるテキスト ファイル) 内の名前とパスワード ハッシュを参照するか、まったく異なる (独立した) メカニズムを提供することによって、なんとか成功していました。

ただし、その結果、大量の認証メカニズムが生まれ、手に負えない状態になってしまいました。1995 年、Sun は Pluggable Authentication Modules (PAM) というメカニズムを提案しました。PAM は、すべてのアプリケーション開発者が使用できる認証 API の共通セットと共に、管理者によって構成されるバックエンドを提供することによって、複数の "プラグ可能な" 認証スキームの使用を可能にしました。PAM API を認証に使用し、Name Server Switch (NSS) API をユーザー情報の参照に使用することによって、Linux アプリケーション開発者は記述するコードの量を抑えることができ、Linux 管理者は認証プロセスを一元的に構成および管理できました。

ほとんどの Linux ディストリビューションには、LDAP ディレクトリに対する認証や Kerberos を使用した認証をサポートするモジュールなど、複数の PAM 認証モジュールが付属しています。このようなモジュールを使用して Active Directory 認証を行うこともできますが、いくつかの重大な制限があります。これについては後から説明します。

Samba と Winbind を使用する

Samba は、Windows 環境と Linux 環境の統合を提供することを目指す、オープンソース プロジェクトです。Samba には、Linux コンピュータから Windows ファイル サービスや印刷サービスへのアクセスを可能にするコンポーネントや、Windows NT 4.0 DC をエミュレートして Linux ベースのサービスを提供するコンポーネントが含まれます。Linux コンピュータは、Samba クライアント コンポーネントを通じて、Windows NT と Active Directory の DC によって提供される Windows 認証サービスを使用できます。

このプロジェクトで提供される、最も興味深い Samba コンポーネントは、Winbind です。Winbind は、Samba クライアント上で実行されるデーモン (Windows 用語では "サービス") で、Linux コンピュータ上で実行される PAM および NSS と、DC 上で実行される Active Directory との間で通信が発生したときに、そのプロキシとして機能します。具体的には、Winbind は Kerberos を使用して Active Directory 認証を行い、LDAP を使用してユーザーとグループの情報を取得します。Winbind は、他にも Active Directory の DCLOCATOR と同様のアルゴリズムを使用して DCを検索する機能や、RPC を使用して DC と通信することによって Active Directory パスワードをリセットする機能などのサービスを提供します。

Winbind によって、単純に Kerberos と PAM を併用するだけでは解決できないいくつかの問題が解決されます。具体的には、Winbind は PAM Kerberos モジュールと同じ方法で認証を行うように DC をハードコーディングするのではなく、Microsoft DC LOCATOR モジュールに近い方法で DNS ロケータ レコードを検索することによって DC を選択します。

3 つの認証戦略

Linux コンピュータ上で LDAP、Kerberos、および Winbind を使用できる場合、Linux コンピュータで Active Directory を認証に使用するための実装戦略は 3 つあります。

LDAP 認証を使用する Active Directory を認証に使用する方法として、最も簡単ではあるが満足度の低い方法は、LDAP 認証を使用するように PAM を構成することです (図 1 参照)。Active Directory は LDAPv3 サービスですが、Windows クライアントは LDAP ではなく (NTLM にフォールバックして) Kerberos を認証に使用します。

LDAP 認証 (LDAP バインドと呼ばれます) は、ネットワークを経由してユーザー名とパスワードをクリア テキストで渡します。これは安全性の低い方法で、ほとんどの用途に使用できません。

fig01.gif

図 1 LDAP を使用した Active Directory 認証 (画像をクリックすると拡大表示されます)

クリア テキストで資格情報が渡されることによって発生するリスクを緩和する唯一の方法は、SSL などを使用してクライアントと Active Directory との間で発生する通信を暗号化することです。これは確かに実現可能ですが、追加作業として、DC と Linux コンピュータの両方で SSL 証明書を管理することが必要になります。また、PAM LDAP モジュールを使用する場合、リセットされたパスワードや期限切れのパスワードは変更できません。

LDAP と Kerberos を使用する Linux 認証に Active Directory を使用するもう 1 つの戦略は、Kerberos 認証と NSS を使用し、LDAP を使用してユーザーとグループの情報を参照するように PAM を構成することです (図 2 参照)。この方法では、Linux の標準機能が使用され、比較的強固なセキュリティを確保できるというメリットが提供されます。ただし、Active Directory DC によって公開される DNS Service Location (SRV) レコードが使用されないので、認証に使用する一連の DC を指定する必要があります。また、有効期限が切れる Active Directory パスワードを直感的に管理できる手段も提供されず、最近になるまで、適切なグループ メンバシップを検索することもできませんでした。

fig02.gif

図 2 LDAP と Kerberos を使用した Active Directory 認証 (画像をクリックすると拡大表示されます)

Winbind を使用する Linux 認証に Active Directory を使用する 3 つ目の方法は、Winbind デーモンを呼び出すように PAM と NSS を構成することです。Winbind は、LDAP、Kerberos、RPC の中から最適なものを使用して、PAM と NSS のさまざまな要求を、対応する Active Directory 呼び出しに変換します。図 3 は、この方法を示しています。

fig03.gif

図 3 Winbind を使用した Active Directory 認証 (画像をクリックすると拡大表示されます)

実装計画

この記事で紹介する Linux と Active Directory の統合プロジェクトでは、Active Directory との統合が強化された Red Hat Enterprise Linux 5 (RHEL5) の Winbind を使用することにしました。RHEL5 は商用 Red Hat Linux ディストリビューションの最新バージョンで、企業のデータセンターでよく使用されています。

基本的に、RHEL5 を Active Directory に対して認証するには、次の 5 つの手順を実行する必要があります。

  1. 適切な Samba とその他の依存コンポーネントを探してダウンロードします。
  2. Samba をビルドします。
  3. Samba をインストールして構成します。
  4. Linux (PAM と NSS) を構成します。
  5. Active Directory を構成します。

以降のいくつかのセクションでは、上記の手順について詳しく説明します。

適切なソフトウェアを見つける

Linux と Windows で最も大きく異なる点の 1 つは、Linux が 1 つの小さなオペレーティング システム カーネルと、別途ダウンロードしてインストールできる膨大な数のコンポーネントで構成されていることです。このため、特定の作業用にかなり最適化された Linux 構成を作成できますが、サーバーの構成と管理が非常に複雑になります。ディストリビューションが異なると、管理方法も異なります。Red Hat (およびその非商用バージョンの Fedora) では、Red Hat Package Manager (RPM) を使用して、これらのコンポーネントをインストールおよび管理します。

Red Hat の Linux コンポーネントは、2 つの形式で提供されます。RPM ファイルには、コンポーネント バージョン、Linux ディストリビューション、および CPU アーキテクチャの特定の組み合わせ用にコンパイルおよびビルドされたバイナリ ファイルが含まれます。したがって、たとえば Intel x86 アーキテクチャ CPU 上で実行される Fedora 10 用にビルドされた、Common UNIX Printing System (CUPS) 1.3.8-5 をダウンロードしてインストールできます。10 種類前後の CPU アーキテクチャ、100 種類を超える Linux ディストリビューション、および数千種類のパッケージとバージョンが存在することを考えると、選択肢として信じられない数のバイナリ RPM が提供されることがわかります。

一方、ソース RPM ファイルには、該当するパッケージの実際のソース コードが含まれます。必要な作業は、ソースをダウンロードしてインストールし、ビルド オプションを構成し、ユーザーが自分でバイナリをコンパイルおよびリンクすることです。独自のオペレーティング システム コンポーネントをビルドするという考えは、Windows のインストール CD に収録されたコンポーネントをインストールすることに慣れている Windows 志向のユーザーにとっては気の遠くなるような話ですが、パッケージ マネージャを使用することによって、ほとんど苦労せず、驚くほど確実にこの作業を行うことができます。Samba グループは、かなりの頻度で更新プログラムやセキュリティ更新プログラムをリリースしています。たとえば、2008 年の 7 月と 8 月だけでも、Samba 3.2 は 4 回リリースされ、合計で 100 個のバグとセキュリティ修正プログラムが提供されています。この記事のプロジェクトでは、安定している最新のバージョンである Samba 3.0.31 のソースをダウンロードしました。

なぜコンパイル済みのバイナリ セットではなく、Samba のソースをダウンロードしたのでしょうか。最初は、もちろんバイナリ セットを使用しようとしましたが、数時間にわたるデバッグの結果、ダウンロードしたバイナリが、Active Directory 認証をサポートするための適切なオプションを指定してビルドされていないことがわかりました。具体的には、Active Directory での Linux ID マッピングをサポートするコードが既定のビルドで無効になっていたので、適切なビルド オプションを指定して Samba をビルドし直す必要がありました。ID マッピングの詳細については、この後説明します。

Linux はもともと小さなカーネルですが、Red Hat Enterprise ディストリビューションは、多くのパッケージがプレインストールされた状態で提供されます。これによって、最初から完全に機能するオペレーティング システムを使用できるので、通常は作業が簡単になりますが、プレインストールされているパッケージが、後からインストールされたソフトウェアと競合する場合があります。

私は Red Hat をインストールするときに、Samba をインストールしませんでした (通常は、Samba が既定でインストールされます)。理由は、より新しいバージョンを使用したかったからです。ただし、新しいバージョンの Samba を使用するには、既にインストールされているその他のライブラリとユーティリティの新しいバージョンも必要です。このような依存関係に関する問題はかなり厄介ですが、RPM を使用すると簡単に解決できます。

バイナリ RPM パッケージをホストする Web サイトは多数存在します。私が使用したのは、rpm.pbone.net で提供されている PBONE というパッケージです (これを使用した理由は、単に最初に見つけたからです)。このパッケージでは便利なパッケージ検索機能が提供され、私が使用する CPU アーキテクチャ (i386) とオペレーティング システム ディストリビューション (Red Hat Enterprise Linux 5/Fedora 7 および 8) に必要なバイナリがすべて揃っていました。

Samba の最新バージョン 3.0 (さらに新しい 3.2 バージョン ツリーも提供されていますが、私はまだ試していません) をビルドしてインストールするには、図 4 で挙げたパッケージをダウンロードして更新する必要がありました。これらのパッケージは Fedora Core (fc) ディストリビューションを対象としていることに注意してください。Red Hat は Fedora と同じソースを基盤とし、Fedora との完全な互換性を提供します。Fedora Core 7 以降のバージョン用にビルドされたパッケージは、RHEL5 上でも変更を加えることなく実行できます。ダウンロードした RPM ファイルは、/usr/src/redhat/RPMS ディレクトリに保存しました。

図 4 Samba 3.0.31 のビルドとインストールに必要なパッケージ

samba-3.031-0.fc8.src.rpm Samba 3.0.31 ソース RPM
gnutls1.6.3-3.fc7.i386 GNU トランスポート層セキュリティ (TLS) ライブラリ
gnutils-devel-1.6.3-3.fc7.i386 GNU TLS 開発ファイル
popt-1.12-3.fc8.i386 ライブラリを解析するコマンドライン引数
popt-devel-1.12-3.fc8.i386 開発ファイルを解析するコマンドライン引数
cups-libs-1.2.12-11.fc7.i386 Common UNIX Printing System ライブラリ
cups-devel-1.2.12-11.fc7.i386 Common UNIX Printing System 開発ファイル
cups-1.2.12.11.fc7.i386 Common UNIX Printing System バイナリ

Samba をビルドする

Samba をビルドするには、まず適切なソース RPM をダウンロードします。私は Samba 3.0.31 のソース RPM を PBONE サイトからダウンロードしました。次に、ダウンロードしたソース RPM ファイルを /usr/src/redhat/SRPMS に保存します。これは、ビルド プロセス中に使用されるソース RPM 用の標準ディレクトリです。

ターミナル セッション (Windows 用語では "コマンドライン ウィンドウ") を開き、SRPMS フォルダに移動します。その後、コマンドを使用してソース パッケージをインストールします (図 5 参照)。

fig05.gif

図 5 Samba のソース RPM のインストール (画像をクリックすると拡大表示されます)

"user mockbuild does not exist—using root" (ユーザー mockbuild は存在しません - root を使用します) というエラー警告が表示されても、心配は要りません。このエラーは、Mock ビルド ユーティリティがインストールされていないことを示しています。これらのユーティリティがなくても、ビルド プロセスは実行できます。

次に /usr/src/redhat/SPECS ディレクトリに移動し、SAMBA.SPEC ファイルを編集します。このファイルには、Samba ビルド オプションが含まれています。"CFLAGS=" で始まる行を検索し、"--with-shared-modules=idmap_ad,idmap_rid" というオプションが指定されていることを確認します。このオプションを指定すると、Linux の UID (一意識別子) を正しく Active Directory 用に変換するコードがビルド プロセスに組み込まれます。図 6 は、このオプションを示しています。

fig06.gif

図 6 with-shared-modules ビルド オプション (画像をクリックすると拡大表示されます)

次に、Samba を正しくビルドしてインストールできるように、コンピュータ上の一部のライブラリを更新することが必要になる場合があります。更新が必要かどうかは、インストールしたライブラリのバージョンによって決まります。今回は、rpm --install コマンドを使用して、図 4 で挙げたパッケージをインストールする必要がありました。場合によっては、--force オプションを使用して、依存関係に関するいくつかの問題を回避する必要が生じることもあります。

Samba をビルドするには、/usr/src/redhat ディレクトリに移動し、rpmbuild –bb SPECS/samba.spec コマンドを実行します (図 7 参照)。このプロセスによって、新しい samba-3.0.31-0.i386 RPM ファイルが /usr/src/redhat/RPMS ディレクトリ内に生成されます。今回のプロジェクトでは、後ほどこの RPM ファイルをインストールします。

fig07.gif

図 7 Samba バイナリ RPM の作成 (画像をクリックすると拡大表示されます)

Linux ネットワークを構成する

Active Directory 認証を行うには、Linux コンピュータが DC と通信できるようにする必要があります。これを実現するには、3 つのネットワーク設定を構成します。

まず、Linux コンピュータのネットワーク インターフェイスを正しく構成することが重要です。これを行うには、動的ホスト構成プロトコル (DHCP) を使用するか、ifconfig コマンドを使用して適切な IP アドレスとネットマスクを割り当てます。RHEL5 で、[System] (システム) メニューの [Administration] (管理) をクリックし、[Network] (ネットワーク) をクリックしてネットワークを構成します (図 8 参照)。

fig08.gif

図 8 ネットワークの構成 (画像をクリックすると拡大表示されます)

次に、DC と同じ DNS ネーム サーバーを使用するように、Linux コンピュータの DNS リゾルバを構成します。Active Directory に統合された DNS を使用することを前提として考えると、この DC に該当するのは、ほとんどの場合、Linux コンピュータを参加させるドメイン内の DC です。DNS リゾルバを構成するには、ネットワークの構成時に使用したネットワーク構成ユーティリティの [DNS] タブを使用します (図 9 参照)。

fig09.gif

図 9 プライマリ DNS リゾルバの設定 (画像をクリックすると拡大表示されます)

上記の手順を完了したら、最後はドメイン内での Linux コンピュータの名前に合わせてホスト名を設定します。ネットワーク構成アプリケーションを使用してホスト名を設定できる場合でも、必ずホスト名が適切に設定されるとは限りません。

そこで、/etc/hosts ファイルを直接編集し、localhost.localdomain エントリの下に <IP アドレス> <FQDN> <ホスト名> の形式でエントリを追加します ("10.7.5.2 rhel5.linuxauth.local linuxauth" など)。この作業を行わなかった場合、Linux コンピュータをドメインに参加させた後、ディレクトリ内に適切でないコンピュータ オブジェクトが作成されます。

Linux の時刻同期を構成する

Kerberos プロトコルは、時刻を比較的小さな差に収まるように同期する認証システムに依存しています。Active Directory では、既定で最大 5 分間の差が許容されます。Linux のシステム時計と DC のシステム時計の差をこの範囲内に収めるために、DC のネットワーク タイム プロトコル (NTP) を使用するように Linux システムを構成します。

次に、Linux サーバー上で、[System] (システム) メニューの [Administration] (管理) から [Date & Time] (日付と時刻) ユーティリティを実行し、[Network Time Protocol] (ネットワーク タイム プロトコル) タブをクリックします。[Enable Network Time Protocol] (ネットワーク タイム プロトコルを有効にする) チェック ボックスをオンにし、ネットワーク タイム ソースとして使用する DC の IP アドレスを追加します。通常、この DC には、ドメイン内でプライマリ ドメイン コントローラ (PDC) エミュレータの Flexible Single Master Operations (FSMO) の役割を割り当てられた DC が該当します。図 10 は、Linux のネットワーク タイム ソースを設定する方法の例を示しています。

fig10.gif

図 10 ネットワーク タイム プロトコルの構成 (画像をクリックすると拡大表示されます)

PAM と NSS を構成する

PAM と NSS は、デスクトップなどの Linux アプリケーションと Winbind をつなぐ役割を果たします。他の多くの Linux サービスと同様、PAM と NSS の構成にはテキスト ファイルを使用します。まず、PAM を構成する方法について説明します。

PAM は、PAM を使用するアプリケーションに 4 つの認証関連機能を提供します。認証機能を使用すると、そのアプリケーションを使用しているユーザーを特定できます。アカウント機能は、ログイン時間の制限など、認証以外の要素にも関連するアカウント管理機能を提供します。パスワード機能は、パスワードの要求および管理メカニズムを提供します。セッション機能は、各ユーザーに割り当てられたディレクトリへのログの記録やファイルの作成など、アプリケーションのユーザーに関連する構成タスクと廃棄タスクを実行します。

Red Hat で使用される PAM の構成ファイルは、/etc/pam.d ディレクトリに格納されます。このディレクトリには、PAM を認証に使用する各アプリケーション専用のテキスト ファイルが格納されます。たとえば、/etc/pam.d/gdm というファイルには、Red Hat で提供される既定のウィンドウ環境である Gnome デスクトップ マネージャ (GDM) 用の PAM 構成が記述されます。各 PAM 構成ファイルには複数の行が記述され、各行で PAM 認証プロセスの要素が定義されます。図 11 は、GDM 用の PAM 構成ファイルの内容を示しています。

fig11.gif

図 11 Gnome デスクトップ マネージャ用の PAM 構成ファイル (画像をクリックすると拡大表示されます)

PAM 構成ファイル内の各エントリは、<管理グループ> <制御> <モジュール> <パラメータ> という形式で記述されます。<管理グループ> (auth、account、password、または session) は、各構成エントリが関連する機能に対応しています。制御キーワード (図 12 参照) は、PAM に各構成エントリの処理方法を指示するために使用します。構成ファイルの 3 列目は、/lib/security ディレクトリにある PAM 共有ライブラリの名前です。共有ライブラリには、Windows の DLL と同様、動的に読み込むことができる実行可能コードが含まれます。モジュール名の後の文字列は、PAM から共有ライブラリに渡されるパラメータです。

図 12 PAM の制御キーワード

キーワード 説明
Required モジュールが成功した場合、PAM はその管理グループの残りのエントリの評価を続行し、それらの結果は、残りのモジュールの結果によって決定されます。モジュールが失敗した場合、PAM は評価を続行しますが、呼び出し元のアプリケーションに失敗を返します。
Requisite モジュールが成功した場合、PAM はその管理グループのエントリの評価を続行します。モジュールが失敗した場合、PAM は呼び出し元のアプリケーションに制御を返し、それ以上の処理を行いません。
Sufficient モジュールが成功した場合、PAM は呼び出し元のアプリケーションに成功を返します。モジュールが失敗した場合、PAM は評価を続行しますが、結果は後続のモジュールによって決定されます。
Optional PAM は、モジュールがその管理グループに指定された唯一のモジュールでない限り、そのモジュールの結果を無視します。
Include PAM は、参照先の PAM 構成ファイルの内容を組み込み、これに含まれるエントリを処理します。

各管理グループには、複数のエントリが指定されます。PAM は、指定されたモジュールを呼び出して、これらのエントリを順番に処理します。呼び出されたモジュールは、成功または失敗のいずれかを返し、PAM は制御キーワードに従って処理を行います。

GDM 用の PAM 構成ファイルでは、すべての管理グループに system-auth が指定されます。これは、PAM が GDM の既定の認証動作をどのように確立するかを表しています。system-auth を変更すると、PAM 構成に system-auth ファイルが指定されているすべてのアプリケーションの認証動作を変更できます。図 13 は、既定の system-auth ファイルを示しています。

fig13.gif

図 13 PAM の system-auth ファイル (画像をクリックすると拡大表示されます)

Name Service Switch (NSS) モジュールは、PAM が認証に関する詳細を隠す場合とほぼ同じ方法で、システム データの格納に関する詳細をアプリケーション開発者から隠します。管理者は、NSS を使用すると、システム データベースの格納方法を指定できます。具体的には、ユーザー名とパスワードに関する情報の格納方法を指定できます。ここでは、Winbind を使用して Active Directory 内のユーザー情報をアプリケーションから参照できるようにする必要があるので、NSS 構成ファイルを変更して、この情報を公開します。

Red Hat には、PAM と NSS を構成するための小型のグラフィカル アプレットである system-config-authentication が付属しています。このアプレットを使用すると、system-auth ファイルと nss.conf ファイルに加える必要があるほとんどの変更 (すべてではありません) を実装できます。

system-config-authentication アプリケーションを実行すると、図 14 のようなダイアログ ボックスが表示されます。Winbind のオプションを、[User Information] (ユーザー情報) タブ (ここで nss.conf ファイルを構成します) と [Authentication] (認証) タブ (ここで system-auth ファイルを構成します) の両方でオンにします。

fig14_L.gif

図 14 system-config-authentication のダイアログ ボックス

[Configure Winbind] (Winbind の構成) ボタンをクリックして、図 15 のようなダイアログ ボックスを表示します。ユーザーを認証するドメインの名前を [Winbind Domain] (Winbind ドメイン) フィールドに入力し、セキュリティ モデルとして [ads] を選択します。Active Directory ドメインの DNS ドメイン名を [Winbind ADS Realm] (Winbind ADS 領域) フィールドに入力します。[Winbind Domain Controllers] (Winbind ドメイン コントローラ) フィールドに、この Linux システムで認証に使用する DC の名前かアスタリスクを入力し、Winbind によって DNS SRV レコードが照会され、DC が選択されるようにします。

fig15.gif

図 15 Winbind の構成ダイアログ ボックス

Active Directory ユーザーが使用する、適切な既定のコマンド シェルを選択します。ここでは BASH (Bourne-again Shell) を選択しました。この時点では、[Join Domain] (ドメインに参加) ボタンはクリックしないでください。ドメインへのコンピュータの参加は、後ほど行います。

Winbind をサポートするように /etc/pam.d/system-auth ファイルを変更したら、このファイルをもう 1 か所変更する必要があります。Linux ユーザーがログインする場合、そのユーザーにはホーム ディレクトリが必要です。このホーム ディレクトリには、Windows レジストリと同様、さまざまなユーザー固有の設定や構成項目が含まれます。問題は、Active Directory 内にユーザーを作成するので、Linux によって自動的にユーザーのホーム ディレクトリが作成されないことです。さいわい、セッション構成の一環としてこの操作を行うように、PAM を構成できます。

/etc/pam.d/system-auth ファイルを開き、下にスクロールして、session セクションの最後の行の前に "session optional map_mkhomedir.so skel=/etc/skel umask=0644" という行を挿入します (図 16 参照)。この行によって、ユーザーのホーム ディレクトリが存在しない場合にそのホーム ディレクトリを作成するように、PAM が構成されます。この構成では、/etc/skel ディレクトリが "スケルトン" (つまりテンプレート) として使用され、新しいフォルダに権限マスク 0644 (所有者には読み取りと書き込み、プライマリ グループには読み取り、その他のユーザーには読み取り) が割り当てられます。

fig16.gif

図 16 ユーザーのホーム ディレクトリの作成 (画像をクリックすると拡大表示されます)

Samba をインストールして構成する

上記で作成した Samba バイナリをインストールするには、/usr/src/redhat/RPMS ディレクトリに移動します。rpmbuild コマンドによって作成されるすべての RPM ファイルは、このディレクトリに格納されます。ここで思い出す必要があるのは、Samba には Linux クライアントが Windows (または Samba) ファイル共有にアクセスするためのバイナリと、Linux システムが Windows ファイル サーバー、Windows プリンタ サーバー、および Windows NT 4.0 DC として機能するためのバイナリが含まれていることです。

Linux を Active Directory に対して認証する場合、これらすべてのファイルを用意する必要はありません。実際に必要なファイルは、Samba 共通ファイルと Samba クライアント バイナリのみです。便利なことに、これらのファイルは 2 つの RPM ファイルに分けられています。これら 2 つのファイルは、samba-client-3.0.31-0.i386.rpm と samba-common-3.0.31-0.i386.rpm です。rpm --install コマンドを使用して、これらの RPM ファイルをインストールします。このコマンドは、rpm --install samba-common-3.0.31-0.i386.rpm のように使用します (–common RPM ファイルを先にインストールする必要があることに注意してください)。

Samba クライアント バイナリをインストールしたら、Winbind で Active Directory を使用した正しい認証処理が行われるように、既定の Samba 構成を変更する必要があります。すべての Samba 構成情報 (クライアントとサーバーの両方) は、smb.conf テキスト ファイルに記述されています。既定では、このファイルは /etc/samba ディレクトリにあります。smb.conf に指定できる構成オプションの数は非常に多いので、この記事では各オプションの内容に関する説明は省略します。smb.conf の詳細については、samba.org Web サイトと Linux の man ページを参照してください。

まず、Active Directory を認証に使用するように Winbind を構成します。smb.conf で、セキュリティ モデルを "ads" に設定します。この設定は既に system-config-authentication ユーティリティによって行われていますが、念のため確認することをお勧めします。次に、smb.conf ファイルを編集します。Domain Member Options という名前のセクションを検索します。"security" で始まる行を検索し、これが "security = ads" になっていることを確認します。次の構成手順では、Winbind が Windows セキュリティ プリンシパル (ユーザーとグループなど) を Linux ID にどのようにマップするかを定義します。これについては、次のセクションで少し詳しく説明します。

ID マッピングに関する問題

まだお伝えしていませんでしたが、Active Directory に対して Linux ユーザーを認証する場合、1 つ大きな問題があります。それは、ユーザーとグループの UID に関する問題です。内部的には、Linux も Windows もユーザーの参照にはユーザー名を使用せず、一意の内部 ID を使用します。Windows で使用されるセキュリティ識別子 (SID) は、Windows ドメイン内の各ユーザーを一意に識別する可変長の構造です。SID には一意のドメイン識別子も含まれているので、Windows は異なるドメインのユーザーを識別できます。

Linux のスキームはこれよりもはるかに単純です。Linux コンピュータでは、ユーザーごとに単純な 32 ビット整数値の UID が割り当てられます。ただし、UID の範囲はそのコンピュータ内に限定されます。ある Linux コンピュータ上で UID 436 を割り当てられたユーザーが、別の Linux コンピュータ上で UID 436 を割り当てられたユーザーと一致する保証はありません。したがって、ユーザーはアクセスする必要がある各コンピュータにログインする必要があります。これは明らかに望ましい状況ではありません。

通常、Linux ネットワークの管理者は、Network Information System (NIS) または共有 LDAP ディレクトリを使用してネットワーク認証を提供することによって、この問題に対処しています。ネットワーク認証システムはユーザーの UID を提供し、この認証システムを使用するすべての Linux コンピュータが同じユーザー ID とグループ ID を共有します。今回は、Active Directory を使用して一意のユーザー ID とグループ ID を提供します。

この問題に対処するために使用できる方法は、2 つあります。1 つ目の (最も簡単に思いつく) 方法は、各ユーザーとグループの UID を作成して、その ID を専用の Active Directory オブジェクトにそれぞれ格納することです。この方法を使用すると、Winbind がユーザーを認証するときに、そのユーザーの UID を参照して、これをユーザーの内部 ID として Linux に提供できるようになります。Winbind では、このスキームが Active Directory ID マッピング (idmap_ad) と呼ばれます。図 17 は、Active Directory ID マッピングのプロセスを示しています。

fig17.gif

図 17 Active Directory ID マッピング (画像をクリックすると拡大表示されます)

Active Directory ID マッピングの唯一の欠点は、すべてのユーザーとグループに ID が割り当てられ、それらの ID がフォレスト内ですべて一意になるようなメカニズムを用意する必要があることです。詳細については、補足記事「Active Directory で Active Directory ID マッピングを構成する」を参照してください。

さいわい、管理オーバーヘッドがはるかに小さい ID マッピングが他に存在します。Windows SID は、ドメイン内のユーザーだけでなく、ドメイン自体も一意に識別することを思い出してください。ドメイン内のユーザーを一意に識別する SID の部分は相対識別子 (RID) と呼ばれ、実はこの ID は 32 ビット整数値です。したがって、Winbind は、ユーザーのログイン時に SID から RID を抽出した後、この RID を一意の内部 UID として使用できます。Winbind では、この方法は RID マッピング (idmap_rid) と呼ばれます。図 18 は、実際の RID マッピングのしくみを示しています。

fig18.gif

図 18 RID マッピング (画像をクリックすると拡大表示されます)

RID マッピングには管理オーバーヘッドが発生しないというメリットがありますが、複数ドメイン環境ではこのマッピング形式を使用できません。これは、異なるドメインのユーザーに同じ RID 値が使用される可能性があるからです。ただし、Active Directory ドメインが 1 つのみの場合は、RID マッピングを使用するとよいでしょう。

Winbind ID マッピングを構成する場合も、/etc/samba/smb.conf ファイルを編集します。Active Directory マッピングを使用する場合は "idmap backend = ad" という行を追加し、RID マッピングを使用する場合は "idmap backend = rid" という行を追加します。このとき、ファイル内の他の行でマッピングが指定されていないことを確認してください。

Winbind 用に smb.conf ファイルに追加する構成オプションが他にもいくつかあります。各ユーザーのログイン時にホーム ディレクトリを作成するように PAM を構成しましたが、Winbind にそのホーム ディレクトリの名前を通知する必要があります。それには、"template homedir = /home/%U" という行を smb.conf に追加します (図 19 参照)。これにより、Active Directory を使用して認証する各ユーザーのホーム ディレクトリが /home/<ユーザー名> であることが Winbind に通知されます。/home ディレクトリはあらかじめ作成しておいてください。

fig19.gif

図 19 ホーム ディレクトリの名前の指定 (画像をクリックすると拡大表示されます)

ドメインに参加してログインする

ネットワーク、PAM、NSS、および Samba Winbind をすべて正しく構成できたので、次は Linux コンピュータをドメインに参加させます。これを行うには、Samba の net コマンドを使用します。シェル プロンプトで、"net ads join –U <管理者名>" を実行します。<管理者名> は、コンピュータをドメインに参加させることができる特権を持つアカウントの名前に置き換えます。

net コマンドを実行すると、ユーザーのパスワードが要求されます。すべての処理が正しく完了すると、コンピュータがドメインに参加します。新しく作成されたコンピュータ アカウントは、Active Directory ユーザーとコンピュータを使用して確認できます。

wbinfo という Winbind テスト ツールを使用して、参加状態をテストできます。wbinfo –t を実行すると、コンピュータとドメインとの間の信頼関係がテストされます。また、wbinfo –u を実行するとドメイン内のすべてのユーザーが表示され、wbinfo –g を実行するとすべてのグループが表示されます。

Linux コンピュータをドメインに参加させることができたら、Active Directory ユーザー アカウントとパスワードを使用してログインを試行します。Linux コンピュータからログオフし、Active Directory ユーザー名を使用してログインします。すべての処理が正しく完了すると、ログインが成功します。

Active Directory で Active Directory ID マッピングを構成する

この情報は、Active Directory ID マッピングを使用する場合のみ適用されます。RID マッピングを使用する場合、この補足記事には目を通さなくてもかまいません。

Red Hat サーバーへの Active Directory アカウントを使用したログインを開始する前に、Active Directory 自体にいくつかの変更を加える必要があります。まず、Winbind がユーザー情報の格納に使用する属性を Active Directory スキーマで提供する必要があります。Windows Server 2003 R2 を実行する場合、現在のスキーマをそのまま使用できます。それよりも前のバージョンの Active Directory スキーマを使用する場合は、Microsoft Services for UNIX (SFU) パッケージを使用してスキーマを拡張する必要があります。

詳細については、TechNet の Services for UNIX に関するページを参照してください。SFU には、Microsoft 管理コンソール (MMC) の "Active Directory ユーザーとコンピュータ" スナップインで使用できる追加のプロパティ ページも含まれます。このページを使用して、Linux に必要なユーザー ID とグループ ID の情報を管理できます。

スキーマを正しく構成したら、Linux コンピュータにログインする可能性があるすべてのユーザー (およびこれらのユーザーが属するグループ) の Linux ID を提供する必要があります。つまり、Linux コンピュータにログインする可能性があるユーザーとグループの uidNumber 属性と gidNumber 属性の値を定義する必要があります。ただし、これらの属性には次のような要件があることに注意してください。

  1. Linux では、認証するすべてのユーザーに UID が割り当てられている必要があります。ユーザー情報は Active Directory 内で管理されるので、Linux コンピュータにログインするすべてのユーザー アカウントが一意の uidNumber 属性を保持している必要があります。uidNumber にどの値を使用するかは重要ではありませんが、Linux コンピュータにログインする可能性があるすべてのユーザー間で、その値が一意である必要があります。
  2. 各 Linux ユーザーには既定のグループ ID も割り当てる必要があります。このため、Linux コンピュータにログインする各 Active Directory ユーザーは、gidNumber 属性の値も保持している必要があります。この値はユーザー間で一意である必要はありませんが、グループを一意に識別できる必要があります。
  3. Active Directory 内のすべてのグループの gidNumber 属性に一意の値が設定されている必要があります。厳密には、グループの gidNumber に値が設定されていなくてもかまいませんが、Winbind がユーザーを認証する場合、そのユーザーが属しているすべてのグループに一意の gidNumber 値が割り当てられている必要があります。おそらく最も簡単なのは、すべてのグループに一意の gidNumber 値を設定しておくことです。
  4. Winbind では、Active Directory 内で参照されるすべてのユーザーが Domain Users グループに属していることが前提となるので、Domain Users グループの gidNumber 属性にも値が設定されている必要があります。

正常に機能しない場合

Winbind を使用して Active Directory 認証を行うように Linux コンピュータを構成することは、簡単な作業ではありません。多くの要素を構成する必要があるので、誤りが発生することもよくあります。また、Linux も Samba もバージョン間で若干の違いがあるので、状況はさらに複雑になります。ただし、現状を確認するために参照できる場所がいくつかあります。

1 つは、/var/log/messages にある Linux システム ログ ファイルです。Samba は、ファイルの欠落や構成の誤りなど、重大なイベントに関するメッセージをこのファイルに記録します。システム ログ ファイルの他に、Samba と Winbind のログ ファイルも存在します。/var/log/samba にあるこれらのファイルを参照して、追加情報を確認できます。

Winbind のスタートアップ スクリプトを変更してデバッグ レベルを設定することによって、Winbind が記録するログ メッセージの詳細度 (および量) を上げることができます。/etc/init.d/winbind シェル スクリプトを編集し、winbindd コマンドに "-d 5" を追加します。これにより、デバッグ レベルが 5 に変更され (設定できる値は 1 ～ 10 です)、Winbind からより詳細なエラー メッセージが生成されます。

Winbind が DC と通信する段階になったら、Netmon 3.1 などのネットワーク パケット キャプチャ ユーティリティを実行できます。これにより、Winbind が実行しようとしている操作を正確に分析できます。また、DC 上の Windows セキュリティ ログを調べることもできます。このログには、認証の試行状況が記録されます。

正常に機能するようになったら

すべての要素が正しく機能するようになったら、Active Directory 内で管理されている資格情報を使用して Linux システムにログインできます。この状態は、ローカルの Linux コンピュータで ID を管理したり、NIS などの脆弱なシステムを使用する場合に比べて、はるかに優れています。また、Active Directory という単一の ID ストアでユーザーを一元管理できます。

ただし、真に役立つソリューションとしては、まだいくつか不足していることがあります。まず、適切なテクニカル サポートを受けることができる保証がないことです。ほとんどの Linux 組織は Active Directory に関する知識があまりなく、Linux コミュニティから得ることができるサポートは、自分の投稿を読んだ人物と、その人物の気分に左右されます。

また、Samba では移行ツールや展開ツールが提供されません。既存の Linux アカウントにユーザー ID とアクセス許可が関連付けられている場合、Active Directory への移行時に、手動でこれらの UID を維持する必要があります。

また、現在対応が進められていますが、最も重要な Active Directory アプリケーションの 1 つであるグループ ポリシーが Samba では使用できません。Samba を使用して Linux システムを Active Directory に参加させることはできますが、グループ ポリシーを使用してそのシステムを管理することはできません。

サードパーティ製のソリューション

Active Directory を使用して Linux コンピュータを認証するのは明らかに良いことですが、Samba の Winbind を使用して独自のソリューションを展開する作業は、どうしようもないほど苦痛ではないにしても、かなり面倒です。革新的なソフトウェア ベンダによって使いやすいソリューションが提供されているのではないかとお考えの皆さん、その考えは間違っていません。

この記事で説明した操作を行うことができる、インストールも操作も簡単な製品を開発した商用ソフトウェア ベンダが 4 社あります。この 4 社は、よく使用される Linux、UNIX、および Apple Macintosh のバージョンのほぼすべてに対応するコードと移行ツールを提供しているほか、グループ ポリシーを使用して Linux コンピュータを管理する作業のサポートも提供しています。

この 4 社とは、Centrify、Likewise Software、Quest Software、および Symark です。これら 4 社は、さまざまな Linux ディストリビューションを対象に、類似した機能 (グループ ポリシーを使用した管理を含む) を提供しています。最近、Likewise Software は同社の実装を Likewise Open という名前でオープン ソース化しました。ただし、グループ ポリシー コンポーネントは商用製品のままです。Likewise Open は、いくつかの主要な Linux ディストリビューションで提供される予定です (公表してしまうと、この記事の執筆中に、私が勤務する NetPro は Quest Software によって買収されました)。

商用製品を利用できる場合、Samba と Winbind を使用して独自の認証システムを構築することに意味はあるでしょうか。統合ソフトウェアの購入費が予算に含まれていない場合、オープン ソースである Samba を使用すればその費用が無料になるというメリットがあります。また、ソース コードをすべて入手できることも魅力的なメリットになり得ます。ただし、既存の Linux コンピュータとその既存の UID を移行しなければならないことは、非常に厄介な問題です。

一方、インストールと実装にかかる時間を節約したい場合や、既存の Linux コンピュータを移行する必要がある場合、または疑問に対して信頼できる答えを提示してもらいたい場合は、商用ソリューションの 1 つを検討してみるとよいでしょう。グループ ポリシーの管理が必要な場合は、商用ソリューションが唯一の選択肢になります。

ただし、どちらの方法を選択するとしても、Linux 認証を Active Directory と統合することによって、複数のユーザー アカウントを管理する手間が省かれ、システムのセキュリティが強化され、一元的に管理および監査できる ID ストアが提供されます。このような大きなメリットを知ったら、もう試してみるしかないでしょう。

Gil Kirkpatrick は 30 年におよぶキャリアの中で、多くのすばらしい商用ソフトウェア製品を設計および開発してきました。彼は Directory Experts Conference (現在は The Experts Conference) の発起人でもあります。また、彼は『Active Directory Programming』の著者であり、Windows IT Pro と TechNet Magazine にも頻繁に寄稿しています。現在は NetPro (最近 Quest Software の一部になりました) で Expert-in-Residence を務め、さまざまなセキュリティ、ID、およびマーケティング プロジェクトのコンサルティングを提供するだけでなく、世界中のテクノロジ セミナーやカンファレンスで講演を行っています。