Active Directory(AD)の各種ディレクトリ情報の取得はLDAPにより行なわれています。ADのドメインコントローラ(DC)は、LDAPのディレクトリサーバとしても機能しています。
標準の構成では、LDAPへアクセスする際の認証はKerberos(もしくはNTLM)により行なわれるため、Linuxなどで実装されている、いわゆるLDAP認証を行うことはできません。しかし、DCにSFU(Services for UNIX)もしくはSUA(Subsystem for UNIX-based Applications)を追加することにより、LDAPのuserPassword属性相当の属性にパスワード情報が書き込まれるようになるため、ADのDCを用いてLDAP認証を実現し、認証を統合することが可能です。
図1 SFU(SUA)によるLDAP認証の統合
なお、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以降
無償
以下、IPアドレスが192.168.135.111のDCが存在するW2K8AD1.LOCALというADドメインでLinuxマシンの認証を行う場合を例に、具体的な設定例を示します。
SUAのNISサーバ機能のインストール
表1 の通り、Windows Server 2003 R2以降では、NISサーバ機能はSUAの1コンポーネントという位置づけになっています。そのためインストールについては非常に簡単です。
インストールの詳細手順については、「 第2回「SUAのNIS機能による認証統合」 」の「SUAのNISサーバ機能のインストール」と同一ですのでここでは省略します。NISサーバとして一通り動作することを確認しておいた方がよいでしょう。
ただし、以下のLDAP認証を行う上ではNISが動作している必要はありません。NISサーバとして動作させる必要がない場合は、動作確認を終えたら「NISサーバー」サービスを停止しておいた方がセキュリティ面からもよいでしょう。
上記と並行して、LinuxマシンがADのLDAPディレクトリへアクセスする際に用いるユーザを作成します。Linux/UNIXで動作する一般的なLDAPサーバは、認証を行うためにLDAPディレクトリにアクセスする場合は匿名によるアクセスを許可する設定にしておくのが一般的ですが、ADの場合、本来の認証はKerberosやNTLMであることもあって、匿名によるアクセスが許可されているのはディレクトリのごく一部に限られているためです。
ユーザ名は何でも構いませんが、ここではUsersコンテナの下に図2 のようにcn=LDAP Proxyというユーザを作成した場合を例に取って説明を進めます。このユーザのパスワードは後述するようにLinux側の設定ファイルに平文で書き込まれます。そのため、ユーザの権限は最低限にするように注意してください。最低でも「Domain Guests」グループに所属させた上で、対話的ログオンは許可しない設定を行うことをお薦めします。
図2 ユーザの作成
続いて、Linuxサーバで参照したいADドメインのユーザごとに、Linux固有の属性の設定が必要になります。「 Active Directoryユーザとコンピュータ」からユーザのプロパティを開き、図3 のように「UNIX属性」タブを選択します。このタブは「NISサーバー」をインストールしていないと表示されません。
図3 「 UNIX属性」タブ
UNIX属性の詳細や設定方法については、「 第2回「SUAのNIS機能による認証統合」 」の「UNIX属性の設定」を参照してください。
Linuxサーバでのインストールと基本設定
引き続き、Linuxサーバ側の設定に移ります。
最近のLinuxディストリビューションでは、LDAP認証の機能はデフォルトでインストールされている場合がほとんどだと思います。必要なパッケージの名称を表2 に示しますので、未インストールの場合はパッケージを適宜インストールしてください。
表2 LDAP認証に必要なパッケージ
ディストリビューション
パッケージ
CentOS
nss_ldap
Debian
libpam-ldap/libnss-ldap
可能な限り、インターネットから最新版のパッケージを入手、インストールすることをお勧めします。
CentOS 5.2の場合、インストール完了後に、以下のようにauthconfigコマンドにオプションを付けて実行することで、必要なファイルが適切に変更されます。
# authconfig --enableldap --enableldapauth --ldapserver=192.168.135.111 --ldapbasedn=dc=w2k8ad1,dc=local --update
具体的には、/etc/ldap.conf、/etc/pam.d/system-auth、/etc/nsswitch.confといったファイルが更新されます。
ldap.confファイルの設定変更
引き続きLDAPの設定ファイルである/etc/ldap.confファイルを編集します。デフォルトの設定ファイルには、英語ですが多くのコメントや設定例が記載されています。このファイルをカスタマイズすることをお薦めします。
リスト1に設定例を示します。
リスト1 ldap.confの設定例
# Your LDAP server. Must be resolvable without using LDAP.
# Multiple hosts may be specified, each separated by a
# space. How long nss_ldap takes to failover depends on
# whether your LDAP client library supports configurable
# network or connect timeouts (see bind_timelimit).
host 192.168.135.111
# The distinguished name of the search base.
base dc=w2k8ad1,dc=local
...
# The distinguished name to bind to the server with.
# Optional: default is to bind anonymously.
binddn cn=administrator,cn=users,dc=w2k8ad1,dc=local
# The credentials to bind with.
# Optional: default is no credential.
bindpw password
...
# The search scope.
#scope sub
#scope one
#scope base
#ssl no
...
# Services for UNIX 3.5 mappings
#nss_map_objectclass posixAccount User
#nss_map_objectclass shadowAccount User
#nss_map_attribute uid msSFU30Name
#nss_map_attribute uniqueMember msSFU30PosixMember
#nss_map_attribute userPassword msSFU30Password
#nss_map_attribute homeDirectory msSFU30HomeDirectory
#nss_map_attribute homeDirectory msSFUHomeDirectory
#nss_map_objectclass posixGroup Group
#pam_login_attribute msSFU30Name
#pam_filter objectclass=User
#pam_password ad
...
# RFC 2307 (AD) mappings
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User
pam_password ad
「host」には、ユーザ情報を検索するDCのホスト名やIPアドレスを設定します。
「base」には、ユーザ情報を検索する際の基準となるDNを設定します。設定例ではAD全体が検索対象となりますが、たとえばLinuxマシンが認証に用いるユーザは必ず「UnixUsers」というOU配下にあるといった場合は、
base ou=UnixUsers,dc=w2k8ad1,dc=local
のように設定することで無駄な検索を省くことができます。
「binddn」および「bindpw」には、ADのLDAPディレクトリにアクセスする際に用いるDNのDN名とパスワードを設定します。先ほど作成したユーザを指定してください。前述の通りパスワードは平文で書き込む必要があります。またldap.confのパーミッションは644など、一般ユーザが読み取り可能にしておく必要がありますので、事実上ユーザのパスワードを全員に公開している状態となります。
「scope」は、デフォルト値「sub」のままにしておきます。それ以外の値が設定されている場合は「sub」に直してください[1] 。
「ssl」についても同様に
ssl no
にしておきます。
「nss_map_objectclass posixAccount」から「pam_password ad」までの各行は、主にLinux側の属性とADの属性の対応付けを行う設定です。CentOSデフォルトのldap.confファイルではで、いくつかのLDAPプロダクトについての設定例が示されています。SUAを用いている場合は、
# RFC 2307 (AD) mappings
行以下の設定を、SFU 3.0/3.5を用いている場合は、
# Services for UNIX 3.5 mappings
行以下の設定を用います。デフォルトではコメントアウトされていますので、必要な箇所のコメントを外してください。設定例ではSUAを用いる場合の設定を示しました。
そのほか、タイムアウト値を変更する等細かい設定も可能です。詳細はldap.confのマニュアルページなどを参照してください。
ログインとトラブルシューティング
ここまでの設定を行ったら、実際にLinuxマシンにログインできることを確認してみましょう。図4 にログインを行った際の実行例を示します。
図4 実際にログインを行った際の実行例
$ telnet 192.168.135.146
Trying 192.168.135.146...
Connected to 192.168.135.146.
Escape character is '^]'.
CentOS release 5.2 (Final)
Kernel 2.6.18-92.el5 on an i686
login: nis1
Password:
Last login: Sat Apr 18 17:07:01 from localhost.localdomain
No directory /home/nis1!
Logging in with home = "/".
-bash-3.2$ id
uid=10101(nis1) gid=10001 groups=10001
ホームディレクトリが作成されていない、グループ名が解決されていないといった問題がありますが、これらはそれぞれ第3回「SUAのNIS機能による認証統合[2] 」 で解説したpam_mkhomedirモジュールの設定、UNIX属性のGIDもしくはグループ名に対応するグループの作成により、解決できます。AD側でユーザが無効となっている場合や「ユーザーは次回ログオン時にパスワード変更が必要」が有効になっている場合はログインに失敗します。
また、ここまでの設定ではLinux上でパスワードの変更を行うことはできません。パスワードの設定変更を行うには、第3回で解説したSUAのパスワード同期機能を用いるか、TLSによる接続が可能なようにADおよびLinux側を構成する必要があります。
詳細については、以下の技術情報などを参照してください[2] 。
(1)サードパーティのCAを利用する場合
How to enable LDAP over SSL with a third-party certification authority
(2) ADのエンタープライズCAを利用する場合
『LDAP Super Expert』 p.165「LinuxクライアントからActive Directory LDAPのパスワードを変更する方法」
匿名認証によるADへのアクセス
前述したように、ADのデフォルトではLDAPディレクトリへのアクセスに際しては認証が必須ですが、匿名による認証を許可することも可能です。これはWindows 2000までの設定と同一です。
Windows Server 2003以降で認証を許可する場合は図5 のようにdSHeuristics属性の値を変更する必要があります。具体的な方法については「Windows Server 2003 のドメイン コントローラでは Active Directory に対する匿名の LDAP 操作が無効になっている」 などを参照してください。
図5 dSHeuristics属性の変更
匿名認証を許可したら、引き続き、アクセスを許可したいオブジェクトのアクセス許可を変更します。オブジェクト毎にアクセス許可を設定するのは管理が大変なので、運用上はLDAP認証で使用するユーザをどこかのコンテナに集めてしまい、該当のコンテナに対してアクセス許可を付与してしまうのがよいでしょう。
以下、「 ou=NIS1,dc=w2k8ad1,dc=local」配下のユーザへのアクセスを許可する場合を例に取って説明します。サーバーマネージャ(もしくはActive Directory ユーザーとコンピュータ)で「拡張機能」をチェックした上で、NIS1コンテナのプロパティを開き、「 セキュリティ」タブを選択します(図6 ) 。
図6
ここでANONYMOUS LOGONに「読み取り」アクセス許可を付与した上で、「 詳細設定」ボタンを押して詳細設定画面を開き、適用先を「このオブジェクトとすべての子オブジェクト」に変更します(図7 ) 。
図7
該当コンテナの配下に位置するユーザは、ldap.confを編集して匿名認証を有効にした状態でもLinux側から参照することが可能となっているはずです[3] 。
この設定を行うことで、ldap.confで「binddn」および「bindpw」を設定する必要がなくなりセキュリティ上の問題が1つ解決されます。一方でLDAPディレクトリ全体に対する匿名アクセスが可能になるという別のセキュリティ問題が発生するという点には留意してください。
まとめ
ここまで説明したように、Active Directoryを用いてLDAP認証を行うことにより、認証の統合が可能です。mkhomedirモジュールと連携させることで、Linuxサーバでのユーザ管理の手間をかなり低減することも可能です。Windows側の設定は前2回で解説したNISによる認証とほとんど一緒ですので、そこそこ簡単だと思います。
ただし、Linux側の設定については、LDAPの知識がないと環境に応じた設定やトラブルシューティングは難しいと思います。特にPAM周りは、authconfigコマンドで対応できないような複雑な設置が必要となった場合に、適切な設定を行うのはかなり困難です。また、ここまでの設定では、Linuxサーバでパスワードを変更することができません。Linux側からパスワードの変更を可能とするには、平文のLDAPではなく、TLSによる通信を行うように構成する必要がありますが、これはかなり面倒です。さらにLDAPによる通信を行うには、パスワードを平文で設定ファイルに書き込んでおくか、匿名でのアクセスを許可する必要があり、セキュリティ的には決してお薦めできないのが実状です。これらを総合すると、LDAP認証を行うことはあまりお薦めとは言えないのが筆者の見解です。
次回はSambaによる認証統合について、まずは基本的な構成を取り上げる予定です。
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/