Active Directory(AD)にSFU(Services for UNIX)もしくはSUA(Subsystem for UNIX-based Applications)を追加することにより、ADのドメインコントローラをLinuxにおける伝統的なディレクトリサービスであるNISのサーバとして機能させることが可能です。
ADをNISサーバとして機能させた上で、各LinuxマシンをNISクライアントして構成することにより、Linuxマシンの認証がADに統合されます。
図1 SFU(SUA)のNISサーバによる認証の統合
なお、NISサーバ機能を提供する形態は表1のように変遷しており、無償/有償の別や名称が変わっていますが、基本的な提供機能は変更ありません。以降ではWindows Server 2008のSUAを例に設定方法を説明しますが、基本的にはSFU 3.0をインストールしたWindows 2000 Server以降において、ほぼ同等の設定で同様の機能が実現します。
表1 UNIX連携機能の推移
プロダクト名称
OS同梱?
有償/無償
SFU 3.0
NO
有償
SFU 3.5
NO
無償
SUA
Windows Server 2003R2以降
無償
以下、具体的に設定方法を説明します。
SUAのNISサーバ機能のインストール
表1の通り、Windows Server 2003 R2以降では、NISサーバ機能はSUAの1コンポーネントという位置づけになっています。そのためインストールについては非常に簡単です。
Windows Server 2008の場合は、図2 のようにサーバー マネージャの「役割サービスの追加」から「NIS サーバー」 、「 パスワード同期」 、「 管理ツール」役割サービスをインストールしてください。なお「NISサーバー」はADに依存していますので、事前にADを適切に構築しておく必要があります。
図2 SUAのインストール
再起動後、インストールが完了すると、スタートメニューの管理ツール中に図3 のような「UNIX用 Microsoft ID管理」というMMCスナップイン(以下管理GUIと呼称)が追加されます[1] 。
図3 「 UNIX用 Microsoft ID管理」スナップインの画面
複数のDCに「NISサーバー」をインストールした場合、全てのサーバがNISサーバとして機能します[2] 。単にNISサーバとして機能させたいサーバについては、「 管理ツール」のインストールを行わず、別サーバの管理GUIから管理を行うことも可能です。
以下、IPアドレスが192.168.135.111のDCが存在するW2K8AD1.LOCAL(NetBIOS名W2K8AD1)というADドメインでLinuxマシンの認証を行う場合を例に、設定例を示します。
「NISサーバー」の設定
NISとは、本来UNIX(Linux)マシンの/etc以下にある、認証情報を格納したファイルを含む各種設定ファイルを一元管理するための機構です。ただし、ここでは認証情報の統合に限って説明を行います。
最初に管理GUIを起動し、「 NISサーバー」を展開してADのNetBIOSドメイン名のコンテナ(図3 では「w2k8ad1」 )を開きます[3] 。ついで、このコンテナのプロパティを開き、図4 の画面から「UNIXパスワードの暗号化」を開き、暗号化形式として伝統的なcrypt(デフォルト値)もしくはより強力でLinuxやFreeBSDなどでサポートされているmd5のいずれかを選択します。
[3] このコンテナは、実際にはNISドメイン名を示します。NISドメイン名のデフォルトはADのNetBIOS名を小文字にしたものが用いられます。任意のNISドメイン名を付与することも可能ですが、ここでは扱いません。
図4 暗号化形式の選択
認証統合の対象がLinuxサーバのみの場合は、より強力なmd5に変更すればよいでしょう。SolarisなどさまざまなUNIXサーバの認証を統合したい場合は、cryptのままにしておくのが無難です[4] 。
ついで、図5 の管理GUIの「パスワード同期」のプロパティから「構成」タブを選択し、「 Windows から NIS(Active Directory)へのパスワード同期」の「有効にする」チェックボックスをチェックします。
図5 「 パスワード同期」プロパティ
これで、「 NISサーバー」の最低限の設定は完了です。
UNIX属性の設定
続いて、Linuxサーバで参照したいADドメインのユーザごとに、Linux固有の属性の設定が必要になります。「 Active Directoryユーザとコンピュータ」からユーザのプロパティを開き、図6 の「UNIX属性」タブを選択します。このタブは「NISサーバー」をインストールしていないと表示されません。
図6 「 UNIX属性」タブ。左は未入力時。右は属性を入力した例。
「NIS ドメイン」フィールドを「」以外にすることで、UNIX属性が有効となります。そのほかの各フィールドにも適切な値を入力して、Linux用のユーザ情報を作成します。各フィールドの意味については表2を参照してください。
表2 UNIX属性
フィールド名
意味
NISドメイン
所属するNISドメインを選択します。値が「」の場合、そのユーザはLinux上で有効化されません。
UID
ユーザのUID
ログイン シェル
ユーザのログインシェル
ホーム ディレクトリ
ユーザのホームディレクトリ
プライマリ グループ名/GID
このユーザのプライマリグループ名もしくはGID
各用語の意味についてはLinuxのドキュメントも適宜参照してください。
設定の確認
設定した内容は、図7 のようにypcatコマンドで確認できます。
図7 ypcatコマンドの実行例
C:\Users\Administrator>ypcat -d w2k8ad1 passwd
nis1:$1$B92ed...$hA1rW1sqb884St7mc3P/e0:10001:10001::/home/nis1:/bin/tcsh
UNIX属性の設定はnismapコマンドで行うことも可能です。図8 に実行例を示します。
図8 nismapコマンドの実行例
-eに続き、Linuxの/etc/passwdファイルの書式で設定を行います。ただし、ここで設定したパスワードはAD側には反映されません。改めてAD側でパスワードの設定を行うことで、UNIX属性側(NIS)の設定に反映されます。バッチ処理でパスワード設定を行いたい場合は、nismapコマンドに引き続きnet userコマンドでパスワードの設定を行うとよいでしょう。
この段階では、パスワードの同期に関して、基本的にAD→UNIX属性の一方通行となります。注意してください。
Linuxサーバでのインストールと設定
最近のLinuxディストリビューションでは、NISクライアント機能は別途インストールする必要があるでしょう。必要なパッケージの名称を表3に示します。これらのパッケージを適宜インストールしてください。
表3 NISクライアントに必要なパッケージ
ディストリビューション
必要なパッケージ名
CentOS
ypbind, yp-tools
Debian
nis
可能な限り、インターネットから最新版のパッケージを入手、インストールすることをお勧めします。インストールと並行して、CentOS 5.2の場合、以下のようにauthconfigコマンドにオプションを付けて実行することで、必要なファイルが適切に変更されます。
# authconfig --enablenis --nisdomain=w2k8ad1 --nisserver=192.168.135.111 --update
具体的には、/etc/yp.conf、/etc/sysconfig/network、/etc/nsswitch.confといったファイルが更新されます。最後に、
# chkconfig ypbind on
のようにしてypbindが自動起動するようにします[5] 。
# service ypbind start
上記のように入力して、ypbindを起動させた上で、図9 のようにypcatコマンドを用いて、先ほどの図7と同様の情報を取得できれば、設定が完了です。
図9 ypcatコマンドの実行例
$ ypcat passwd
nis1:$1$B92ed...$hA1rW1sqb884St7mc3P/e0:10001:10001::/home/nis1:/bin/bash
同様に、getent passwdコマンドで認証情報を確認すると、元々Linux上で定義され、/etc/passwdファイルに記載されているユーザに加え、UNIX属性を有効化したユーザが、該当のLinuxサーバ上で有効なユーザとして表示されることが確認できます。
図10 getent passwdコマンドの実行結果
$ getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
krb5-01:x:501:501::/home/krb5-01:/bin/bash
rpc:x:32:32:Portmapper RPC user:/:/sbin/nologin
nis1:$1$jrko5zzz$L9To9vjw5c/KqQlF3uiz41:10001:10001::/home/nis1:/bin/bash
ログインとトラブルシューティング
ここまでの設定を行ったら、実際にLinuxマシンにログインできることを確認してみましょう。図11 にログインを行った際の実行例を示します。
図11 実際にログインを行った際の実行例
$ telnet localhost
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
CentOS release 5.2 (Final)
Kernel 2.6.18-92.el5 on an i686
login: nis1
Password:
Last login: Tue Jan 13 01:57:34 from localhost
No directory /home/nis1!
Logging in with home = "/".
id: cannot find name for user ID 10001
-bash-3.2$ id nis1
uid=10001 gid=10001 groups=4294967295 context=user_u:system_r:unconfined_t
ホームディレクトリを作成していなかったり、割り当てたGIDに対応するグループが作成されていなかったりするため、若干エラーがでていますが、認証統合自体は問題なく実施できています。
なお、AD側でユーザが無効となっている場合や「ユーザーは次回ログオン時にパスワード変更が必要」が有効になっている場合でも、Linux上では問題なくログインができてしまいます。これは仕様という整理になっています。Linuxサーバへのログインを抑止したい場合は、シェルを無効なものに変更してください。
GIDに関するエラーを抑止するには、Linux側であらかじめUNIX属性のGIDもしくはグループ名に対応するグループを作成してください[6] 。
ホームディレクトリについては、原則としてUNIX属性で指定したディレクトリをあらかじめ作成しておく必要があります。
まとめ
ここまで説明したように、SUAの「NISサーバー」を用いることで認証統合が可能です。設定の難易度についても、それほど高くはないと思います。特にLinux側でそれほど複雑な設定が必要ないので、Windowsサーバの管理スキルは高いがLinuxは最低限しか知らないという方にとっては有用かもしれません。
ただし、NISの通信はまったく暗号化されずにネットワーク上を流れますので、そもそも暗号化されて格納されているパスワードはともかく、それ以外の情報はパケットキャプチャなどで容易に参照できてしまう点には留意してください。
また、ここまでの設定では、Linuxサーバでパスワードを変更した場合、AD側のパスワードとの整合性が崩れてしまう他、ホームディレクトリをLinuxサーバ側で手動で作成しないといけないという問題もあります。これらを解消する設定として、次回はmkhomedirモジュールによるホームディレクトリの自動生成と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/