SFU 3.0によるUNIXとWindowsの認証の連携

目　次

１．SFUの紹介　▼

２．SFUのインストール　▼

３．パスワード同期　▼

3.1．WindowsからUNIXへのパスワード同期　▼

3.1.1．Windows側の設定

3.1.2．UNIX側のインストール

3.1.3．動作の確認

3.1.4．トラブルシューティング

3.2．UNIXからWindowsへのパスワード同期　▼

3.2.1．Windows側の設定

3.2.2．UNIX側の設定

3.2.3．動作の確認

3.3．本格的な設定　▼

3.3.1．パスワード同期を行なうユーザの指定

3.3.1.1．UNIX側での制御

3.3.1.2．Windows側での制御

3.3.1.3．暗号キーの変更

3.3.1.4．NISサーバとの連携

４．NISサーバ機能　▼

4.1．NISの概要　▼

4.2．NISサーバのインストール　▼

4.3．NISマップの作成　▼

4.3.1．GUIからのNISマップの操作

4.3.2．パスワードの移行について

4.3.3．既存のNISサーバからのNISマップの移行

4.3.4．動作確認

4.4．NISサーバの運用　▼

4.4.1．パスワードの暗号化形式

4.4.2．スレーブサーバの追加と構成

4.4.3．パスワードの変更

５．まとめ　▼

６．参考情報　▼

７．注記・補足　▼

SFUの紹介　▲

　最初にSFUについて簡単に紹介しておきましょう。
　SFUはWindows NT/2000/XPに対応したプロダクトで、表１のような機能を提供します。

　これらの機能を大別すると
　　(1) NFS認証ツール
　　(2) 認証
　　(3) Interix
　　(4) その他

になります。
　SFU 3.0の目玉としては、従来は別製品で日本では発売されていなかったInterixになるかと思いますが、ここでは認証の連携という観点に基づき、SFUの認証機能にスポットをあてて説明していきます。
　この他SFUについての情報は、マイクロソフト社の「Services for UNIX ホーム」などから入手してください。

　同ページからは120日間使用可能な評価版の入手も可能になっていますし、本誌付録CD-ROMにも収録しております。
　評価版については機能制限などはありませんので、興味のある方は是非使ってみてください。

SFUのインストール　▲

　SFUのインストール自体は非常に簡単で、ウィザードに従っていけばよいだけです。
　途中に図１のようにインストールする機能を選択する画面がありますので、ここで必要な機能を選択してインストールもしくはアンインストールします。

図１：SFUコンポーネントの選択(Windows 2000のDCの例)

Windows 2000/XP Professionalなどでは「パスワード同期」がデフォルトでインストールされないので、明示的にインストールすること。

　認証機能に関連するのは「パスワード同期」と「NISサーバー」になりますので、適宜この二つのコンポーネントをインストールするようにしてください。ただし「NISサーバー」はWindows 2000のDCでのみインストール可能です。また後述しますが、NISサーバ機能はActive Directoryのスキーマを拡張します。拡張されたスキーマは元に戻せませんので、実環境への導入にあたっては充分注意してください。
　なおインストールするプロダクトによっては、図２のような画面が現れて、LGPLの確認が表示されます。マイクロソフト社製のプロダクトでこうした表示が行なわれるというのは、やはり何ともいえないモノがありますね(^_^;;

図２：LGPLに関する注意の表示

　それでは、以下各機能について順番に説明していきましょう。

パスワード同期　▲

　パスワード同期をインストールすることで、Windows側でパスワードが変更された際に、それをUNIX側のパスワードに反映させることや、逆にUNIX側のパスワードの変更に同期してWindows側のパスワードの変更を行なうことが可能となりますので、WindowsとUNIXとでパスワードの一元管理が可能となります。
　ただしコラム１にも書きましたが、残念なことに対応プラットフォームがかなり限られていますので注意してください。
　また、Active Directoryドメインとパスワードを同期させたい場合は、ドメイン内の全てのDCにパスワード同期をインストールする必要があるので、注意してください。

注01：

ソースからコンパイルして確認しました。

注02：

当初Red Hat Linux 7.1で動作すると書いてあるんだから、当然7.3でも動くだろうと安易に考えて一晩はまってしまったことはヒミツです。なおUNIXやらWindowsへのパスワード同期はRed Hat Linux 7.3でも動作しました。

WindowsからUNIXへのパスワード同期　▲

　最初にWindowsからUNIXへのパスワード同期の設定を行なってみましょう。
　まずは最低限必要な設定のみを示します。

Windows側の設定

　SFUのインストール時に「パスワード同期」コンポーネントをインストールしていると、「Services for UNIX の管理」アプレットに図３のような「パスワード同期」画面が表示されます。

図３：パスワード同期の設定画面

　「Windows を実行するコンピュータから……」のチェックボックスにチェックが入っていることを確認してください。また必須ではありませんが、トラブル発生時の便を考慮すると、ある程度安定稼働するまでは図３下の「詳細なログを有効にする」にチェックを行なっておいた方がよいでしょう。
　最低限行なわないといけない設定は、「詳細設定」タブを押すと現れる図４の画面から同期先のUNIXマシンのIPアドレスやホスト名を設定することだけです。

図４：パスワード同期の詳細設定画面

UNIX側のインストール

　UNIX側はCD-ROMのunix/bins以下にあるssod.<プラットフォーム名>というバイナリを利用します。プラットフォーム名については表２を参照してください。適切なバイナリを選択のうえ、名前をssodに変更して/usr/local/bin(もしくは/usr/bin)にコピーします。ファイルに実行権をつけるのを忘れないようにしてください。
　同時に設定ファイルのテンプレートであるsso.cfgファイルを/etc/sso.confという名前でコピーします。このファイルは改行コードがUNIX形式である必要がありますので、ftpで転送する場合はバイナリモードで行なうなど、扱いに注意してください。
　UNIXの場合ファイルの大文字と小文字を区別しますので、普段使い慣れていない方は注意してください。また、sso.confにはWindowsと通信する時のパスワードが平文で格納されますので、root以外からファイルの内容が読みとられないようにする必要があります。Red Hat Linux 7.1でのインストール例を図５に示します。

　UNIX側の設定は/etc/sso.confファイルで行ないます。最低限必要な設定は

と書いてある行をコメントにして、その下に認証同期元のWindowsマシンのIPアドレスを

のように設定することだけです。デフォルトでは互いに「6677/TCP」に対して通信を行ないますので、間にファイアウォールなどが入っている場合は、通信可能なように設定しておいてください。
　最後にssodを起動します。単に実行してもよいのですが、念のため-vオプションをつけて図６のように端末に詳細な設定情報を出力させた方がよいでしょう。なおssodを停止させる場合は、KILLコマンドで行なってください(注03)。

注03：

筆者の環境だけかも知れませんが、kill -KILLでないと終了してくれません。

動作の確認

　それでは実際に動作を確認してみましょう。UNIXマシンに存在するのと同じ名前のアカウントをWindowsマシン側にも作成した上で、Windowsマシン上でパスワードを変更します。パスワード同期が正しく動作していれば、パスワード変更後、UNIXマシンに対してftpなどで接続し、先ほどWindows側で変更したパスワードを入力することで、ログインが可能な筈です。

トラブルシューティング

　コラム1でも書きましたが、パスワード同期はサポートされるUNIX側のバージョンがかなり制限されています。トラブルが発生した場合は原因切り分けのため、マイクロソフト社がサポートしているやや古いバージョンのOSで確認することを強く推奨します。
　その他はまりやすい要因としては、UNIX側のパスワードポリシーに合致しないパスワード変更を行なった場合が考えられます。これについてはイベントログやsyslogへの出力を確認することである程度の切り分けはできると思います。また切り分け策としてUNIX上でそのアカウントがロックアウトされていないことや、UNIX上でそのアカウントのパスワードをWindows側で設定したパスワードに変更できることの確認などを行なうのもよいでしょう。
　エラーが発生した場合は、まずイベントログを確認してください。「詳細なログを有効にする」がチェックしていれば、図７のように詳細な情報が出力されている筈です。

図７：イベントログに出力されるエラーの例

　イベントID4098が同期処理の開始、4097が同期成功を意味するメッセージになります。
　イベントID8224は、アカウントが無効になっているなど、8243はパスワードが短過ぎる、8196は同期失敗を示すメッセージになっています。なおデフォルトでは30秒間をおいて３回試行を行なうので、エラーも通常3回ずつ同じものが出力されます(注04)。
　併せてUNIX側のsyslogにもDAEMONファシリティで図８のようなログが記録されます。

　これらの情報から切り分けを行なっていってください。

注04：

この設定はssod.confの「SYNC_DELAYパラメータ」と「SYNC_RETRIESパラメータ」とで変更できます。

UNIXからWindowsへのパスワード同期　▲

　次はUNIXからWindowsへのパスワード同期の設定をおこなってみましょう。

Windows側の設定

　基本的にはWindowsからUNIXへの同期の設定と同様ですが、図２の「パスワード同期」画面で、「UNIX を実行するコンピュータから……」の方にチェックが入っていることを確認した上で、同期元UNIXマシンを図３の画面から追加します。

UNIX側の設定

　UNIX側では、PAMの設定が必要になります。unix/binsディレクトリにあるpam_sso.<アーキテクチャ名(注05)>というファイルを/lib/security/pam_sso.so.1(Solarisの場合は/usr/lib/security/pam_sso.so.1)という名前でコピーした上で、PAMの設定ファイルの設定を行ないます。図９にはRed Hat Linux 7.1の場合の例、図10にSolarisの場合の例を示します。なおhp-uxの場合もSolarisとほぼ同様です。詳細はドキュメントを参照してください。

注05：

アーキテクチャ名については表２を参照してください。

動作の確認

　UNIX上でpasswdコマンドを使ってUNIXアカウントのパスワードを変更してみましょう。passwdコマンド起動時には認証元のWindowsマシンへ何らかの問い合わせを行なっているようで少し時間がかかりますが、最終的にはパスワードの変更ができる筈です。できなかった場合は、前述したようにsyslogやイベントログを用いて原因の切り分けを行なってください。

本格的な設定　▲

　ここまで、必要最低限の設定について説明しましたが、実際の環境で使っていくにあたって行なっておくべき設定について説明します。

パスワード同期を行なうユーザの指定

　ここまでの設定では、基本的にUNIX上に存在する全てのアカウントについてパスワードの変更が可能となっていますが、現実的にはシステムが使っているアカウントなどについてはパスワード同期の対象から外したいと思います。以下その方法について説明します。

UNIX側での制御

　UNIX側で制御を行なう場合は、SYNC_USERSパラメータを使います。デフォルトでは

となっているため、全てのユーザのパスワードが同期されます。例えばmonyoとnorikoを許可し、marikoを許可しないといった場合は、以下のように指定します。

　SYNC_USERSに含まれていないアカウントや-が指定されたアカウント(注06)のパスワード同期は無効になり、片側のパスワードのみが変更されます。
　基本的にrootやbin、admなどシステムが使っているアカウントは同期対象に含めるべきではないでしょう。

注06：

＋と−が両方指定されたアカウントのパスワード同期も無効になります。

Windows側での制御

　Windows側では、PasswordPropAllowおよびPasswordPropDenyというグループのメンバを構成することで、パスワード同期を有効にするユーザを制御することが可能です。PasswordPropDenyにはパスワード同期を無効にするユーザやグループを、PasswordPropAllowにはパスワード同期を有効にするアカウントをそれぞれ含めます。
　デフォルトではPasswordPropDenyグループのみが作成され、Administratorやその他Administrator権限のあるアカウントがメンバとして自動的に追加されています。PasswordPropAllowグループは作成されていませんが、この場合、全てのアカウントがメンバとして含まれるのと同様の動作になります。
　なお両方のグループに含まれるアカウントのパスワード同期は無効になります。

暗号キーの変更

　デフォルトの暗号キーは既知のもののため、実際に運用を行なう際には必ず変更するようにしてください。変更する場合は、Windows側で図３の画面から「新しいキー」ボタンを押して新しいキーを取得して適用した上で、同期対象のUNIXマシン上においても、値を/etc/sso.confファイル中のENCRYPT_KEYパラメータに設定する必要があります。

NISサーバとの連携

　同期対象のUNIX上でNISマスタサーバが動作しており、NIS上のユーザのパスワードを同期させたい場合は、/etc/sso.confにUSE_NIS=1という指定をいれた上で、NIS_UPDATE_PATHの値を適切に設定するようにしてください。
なお、これ以外にもssod.confには幾つか設定可能なパラメータがありますので、興味のある方はドキュメントやソースを参照してください。

NISサーバ機能　▲

　次にSFUのNISサーバ機能について説明しましょう。
　NISサーバ機能とは、図11のようにActive Directoryの各DCを(注07)、UNIXで一般的なディレクトリサービスであるNISのサーバとして動作させるようにする機能です。NISはユーザ認証に必要なパスワード情報も一元管理できるため(注08)、SFUのNISサーバ機能を使ってWindowsドメインのユーザ情報をNIS経由で取得できるようにすることで、UNIXマシンの認証をWindowsドメインで統合することが可能になります。

図11：NISサーバ機能の動作概要

注07：

ライセンス上はドメイン内のいずれかのサーバがSFUのライセンスを保持していれば、その他のDCにNISサーバのインストールが可能となっています。詳細はSFUのEULAを参照してください。

注08：

というより、それが最大のニーズだというはなしもあります。

NISの概要　▲

　最初にNISについて簡単に説明しておきましょう。
　NISを一言でいうと、UNIXマシンの/etc以下の幾つかのファイルの内容を一元管理するディレクトリサービスの一種です。NISはNTドメインなどと同様シングルマスタ構成をとっており、マスタを保持しているサーバをNISマスタ、マスタの複製を保持しているサーバをNISスレーブと呼びます。NISクライアントはNISサーバ(マスタ、スレーブどちらでも可)に接続して、各種情報を受け取ります。
　どのNISサーバに接続しているかを確認するコマンドがypwhich図12で、実際に各種情報を取得するコマンドがypcat図13になります。この他のコマンドについては、NISのドキュメントなどを参照してください。

　セキュリティ面での脆弱性(注09)などが指摘されているNISですが、後継としてSun Microsystems社がリリースしたNIS+がセキュリティの向上や大規模環境への対応を行なった結果非常に複雑となり、他プラットフォームへの移植が進まなかったことなどもあって普及しなかったため(注10)、UNIXマシンのディレクトリサービスとしては、今でもげ根気で用いられています。
　なお、本記事はNISの機能解説が主眼ではないため、NISについての説明はこの辺りにしておきます。NISの詳細については、別途各種ドキュメントやWebサイトなどを参照してください。

注09：

NISが設計された当時の環境を考えればやむを得ない点もあります。

注10：

NTドメインからActive Directoryへの移行が進まない現状と同じジレンマではないかと思っています。

NISサーバのインストール　▲

　それでは、以下実際にインストールを行なっていきましょう。Windows側で必要なのは図４の画面での「NISサーバ」コンポーネントのインストールになります。繰返しになりますが、NISサーバをインストールするとActive Directoryのスキーマが拡張されます。Active Directoryの仕様上一度拡張したスキーマは元に戻せませんので、充分注意してください。
　NISサーバでは、複数のNISドメインを扱えますが、デフォルトでWindowsドメインのNetBIOS名と同じ名前のNISドメインが作成されていますので、基本的に設定を変更する必要はないでしょう。ただし、UNIX側のパスワード形式がmd5のみの場合は、デフォルトの設定がcryptになっているため、設定の変更が必要です(注11)。

注11：

詳細については後述します。

NISマップの作成　▲

　NISサーバのインストールが完了したら、次はNISマップの作成を行ないます。NISマップの作成は基本的に図14のようにnismapというコマンドで行ないます。この作業はGUIでは行なえません。

　-eに続いてNISのマップ形式に整形したエントリを記述してください。-aオプションでNISドメイン名を指定し、最後に追加対象のマップ名を指定します。図14以外の例を幾つか図15に示します。

　nismapコマンドではこの他エントリの修正、削除など様々な操作が行なえます。また、nismapコマンドを使って独自のNISマップを追加することも可能です。これらの詳細はSFUのヘルプを参照してください。

GUIからのNISマップの操作

　一部のNISマップについては、Active Directory上の既存のオブジェクトと対応づけがされているためGUIによる追加も可能になっています。
　NISサーバをインストールすると、図16のように、Active Directoryユーザとコンピュータからユーザ(passwdマップ)、グループ(groupマップ)、コンピュータ(hostsマップ)の各オブジェクトのプロパティを表示した際に「UNIX属性」というタブが現れます。ので、ここからアカウント関連の設定を行なったり、「NISドメイン」を設定することで、NISドメインに所属していなかったオブジェクトを対応するNISマップに追加することも可能になっています。

図16：ユーザのUNIX属性タブ

NISドメインが「<なし>」の場合、そのアカウントはNIS経由で参照できない。

　nismapコマンドを使ってこれらのマップのエントリを追加した場合は、自動的にActive Directory側にも対応するオブジェクトが作成されるか、すでに存在している場合はUNIX属性の値が設定されます。なおすでにUNIX属性が設定されているオブジェクトを追加しようとした場合は競合が発生します。競合発生時の対処などについてはドキュメントを参照してください。

パスワードの移行について

　パスワードについては特殊な扱いがされます。
　o nismapで追加したアカウントがすでにActive Directoryに存在していた場合、Windowsのパスワードは更新されません。従って、passwdマップのパスワードとWindowsのパスワードが異なることになります。
　o nismapで追加したアカウントがActive Directoryに存在していなかった場合、Window NISマップの両パスワードはランダムな文字列に設定されます。従って、実際にログオンを行なう前に、一度パスワードを変更することが必要になります。

既存のNISサーバからのNISマップの移行

　既存のNISサーバから直接NISマップを移行することも可能です。
　nis2adコマンドを利用することもできますし、メニューにある「NIS サーバの移行」ウィザードを使うことも可能です。詳細はドキュメントを参照してください。

動作確認

　一通りエントリの追加が終了したら、既存のNISクライアント(注12)からログオンしてみましょう。うまく移行ができていれば図17のようにidコマンド、ypwhichやypcatコマンドなどが機能する筈です。NISクライアントからみるとUNIXで構築したNISサーバとみわけがつきません。

注12：

NISクライアントの構成方法についてはOSによって多少異なる点もありますので、ここでは説明しません。
別途ドキュメントなどを参照してください。

NISサーバの運用　▲

　基本的な日常管理はUNIXベースのNISサーバと同様です。ここではSFUのNISサーバー機能に特有の注意点について記載します。

パスワードの暗号化形式

　デフォルトではパスワードの暗号化形式はcryptになっていますが、最近のLinuxなどではより暗号強度が高いmd5がデフォルトで用いられることが多いと思います。このためSFUでも暗号形式をmd5にすることが可能です。暗号化形式の変更は図18の画面にある「UNIXパスワードの暗号化の方法」で行ないます。

図18：NISドメインの「マップ」画面

もっとも大半の商用UNIXなどはcryptを使っていますので、基本的にはcryptのままでよいでしょう。md5を利用しているのはLinuxやFreeBSDなどになりますが、これらのOSでもcrypt形式を利用できます。NISを利用する場合パスワードの暗号化形式は揃える必要がありますので(注13)、LinuxやFreeBSD側の設定をcryptに変更する必要があるかも知れません。

注13：

最近のLinuxなどではmd5の設定にしていても、crypt形式のパスワードを扱えますので、この場合暗号化形式が異なっていても相互運用が可能です。

スレーブサーバの追加と構成

　NISサーバをインストールした場合、Active Directoryの残りのDCには自動的にNISマップが複製されますので、SFUのNISサーバ機能をインストールすることで(注14)NISスレーブサーバとして機能することが可能になります。
　UNIXマシンをNISスレーブにする場合は、図19の画面でNISサーバを追加する必要があります。

図19：NISドメインの「NISサーバー」画面

ここではmayuというUNIXマシンが追加されています。

　NISマップの更新を伝達する間隔は図20で指定する他、図18の「伝達」ボタンにより手動で行なうことも可能です。またnisadminコマンドとyppushというコマンドラインツールも用意されています。

図20：NISドメイン画面

注14：

NISスレーブサーバ用途のインストールにはSFUのライセンスは不要です。

パスワードの変更

　パスワードの変更については、注意が必要です。
　Windows側のアカウントのパスワードを変更した場合、そのパスワードはWindows側とNISマップの両方に反映されます。しかしNIS経由でパスワードを変更した場合、そのパスワードはNISマップにのみ適用されます。つまりWindows側とNISマップのパスワードが同期しなくなります。またnismap modコマンドでNISマップに格納されたパスワードを直接変更することはできないようになっています。
　UNIX側から両方のパスワードを変更したい場合は、前述したパスワード同期機能を設定してUNIX側のパスワードを変更すると同時にWindows側のパスワードも変更するようにしてください。

まとめ　▲

　以上、簡単ではありますが、SFUのもつ認証機能について説明しました。
　Windowsドメインが存在している環境にUNIXマシンを導入する場合、認証の統合が問題となるケースは多いと思います。その際の解決策としてWinbindとともにSFUも選択肢の一つに挙げられるのではないかと思います。
　本記事が認証の統合を検討している皆様の参考になれば幸いです。

参考情報　▲

●Services for UNIX ホーム：
http://www.microsoft.com/japan/windows/sfu/previous/

●Microsoft(R) Windows(R) Services for UNIX Version 3.0 日本語版、12月6日の発売に向け、本日より評価版の提供を開始：
http://www.microsoft.com/japan/presspass/releases02/111402sfu.asp

●@IT：製品レビュー Microsoft Windows Services for UNIX 3.0 日本語版：
http://www.atmarkit.co.jp/fwin2k/productreview/sfu30/sfu30_01.html

●@IT：製品レビュー Windows Services for UNIX 2.0：
http://www.atmarkit.co.jp/fwin2k/productreview/serviceforunix/serviceforunix_01.html

注記・補足　▲

1. 2004.04.07　HTMLレベルの整形、図の作成を行いました。
2. 2004.04.12　２回目のHTMLレベルの整形、図の修正を行いました。
3. 2004.05.08　３回目のHTMLレベルの整形の修正を行いました。
4. 本文書は、UNIX USER 2003 年 04 月号の『特別企画』に掲載された『Services for UNIX 3.0 による認証の連携』の草稿をにゃお様の方で HTML 化して掲載しているものです。