前回 説明したように、Active Directory(AD)の認証はKerberosにより行われています。Active DirectoryのドメインはKerberosでいうところの「レルム(realm) 」に相当し、ADのドメインコントローラ(DC)は、Kerberos的にはKDCとして機能しています。
今回紹介するpam_krb5 は、Linuxマシンの認証を外部のKDCにより行えるようにするPAMモジュールです。KDCとしてADのDCを指定することで、Linuxマシンの認証がADに統合されます。
図1 pam_krb5によるパスワードの統合
以下、具体的に設定方法を説明します。
pam_krb5のインストール
通常のLinuxディストリビューションであれば、pam_krb5はパッケージ化されているはずです。必要なパッケージの名称を表1に示します。これらのパッケージを適宜インストールしてください。
表1 pam_krb5の利用に必要なパッケージ名
ディストリビューション
パッケージ名
CentOS
pam_krb5
Debian
libpam-krb5
可能な限り、インターネットから最新版のパッケージを入手、インストールすることをお勧めします。
以下、IPアドレスが192.168.135.223で、w2003r2srv3というホスト名のDCが存在する、W2003R2AD3.LOCALというADドメインでLinuxマシンの認証を行う場合を例に、設定例を示します。
pam_krb5の設定
インストールが完了したら、引き続き設定を行います。
CentOS 5.2の場合、以下のようにauthconfigコマンドにオプションを付けて実行することで、必要なファイルが適切に変更されます。
# authconfig --enablekrb5 --krb5kdc=192.168.135.223 --krb5realm=W2003R2AD3.LOCAL --update
ここでは、KDCをIPアドレスで指定していますが、適切に名前解決が行える環境では、もちろん名前で指定しても構いません。このコマンドにより、Kerberos関連の設定を行う/etc/krb5.confファイルにリスト1のような設定が追加されます。
リスト1 /etc/krb5.confの設定例(追加部分)
[libdefaults]
default_realm = W2003R2AD3.LOCAL
...
[realms]
...
W2003R2AD3.LOCAL = {
kdc = 192.168.135.223
}
EXAMPLE.COM = {
...
[domain_realm]
...
.w2003r2ad3.local = W2003R2AD3.LOCAL
w2003r2ad3.local = W2003R2AD3.LOCAL
また、PAMの設定ファイルである/etc/pam.d/system-authにも、リスト2のようにpam_krb5関連の設定が追加されます。
リスト2 /etc/pam.d/system-authの設定(pam_krb5関連部分)
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_krb5.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_krb5.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_krb5.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quietuse_uid
session required pam_unix.so
session optional pam_krb5.so
Debianの場合は、/etc/krb5.confに手作業でリスト1相当の設定を行った上で、最低限/etc/pam.d/common-authファイルに対し、手作業でpam_krb5のエントリを追加します。通常の環境ではリスト3のようにすればよいでしょう。
リスト3 /etc/pam.d/common-authへの追加
auth required pam_krb5.so minimum_uid=1000
auth required pam_unix.so nullok_secure
パスワード同期も行いたい場合は、/etc/pam.d/common-passwordファイルにリスト4のようなエントリを追加します。
リスト4 /etc/pam.d/common-passwordへの追加
password sufficient pam_krb5.so minimum_uid=1000
password required pam_unix.so nullok obscure min=4 max=8 md5
minimum_uidオプションを「minimum_uid=1000」のように設定することで、uidが1000未満のユーザに対しては、本モジュールが無効化されます。このため、rootなどシステム上重要なユーザの認証がADで行われ、意図せずLinuxマシンへのログインが可能となってしまうといった事態を防ぐことができません。このオプション自体はCentOSでも有効ですが、CentOSではpam_succeed_ifモジュールなどにより、同様の機能が実現されているため、特にオプションを付加する必要はありません。
この他、上記設定例では、認証先のADとしてkrb5.confの先頭付近に記述されているデフォルトのレルム(ADドメインに相当する概念)が用いられます。
リスト5 krb5.confに記述されているデフォルトのレルム
[libdefaults]
default_realm = W2003R2AD3.LOCAL
デフォルト以外のレルムで認証したい場合は、pam_krb5モジュールのオプションに「realm=W2003R2AD3.LOCAL」のようにして明示的に認証先のレルムを指定する必要があります。
その他、Kerberos認証を行う上では、kdcと時刻が同期されている必要があります。ntpなどを用いてkdc(DC)と常時時刻同期が行われるように構成してください。
pam_krb5の動作確認:ログインとトラブルシューティング
ここまでの設定を行ったら、実際にLinuxマシンにログインできることを確認してみましょう。
最初にLinuxマシン上でユーザを作成します。
ここでは仮にkrb5-01という名前だと仮定します。このユーザにはパスワードを設定する必要はありません。たとえば
# useradd -m krb5-01
のようにして、ユーザを作成しておけばよいでしょう。ついで、AD上で同名のユーザを作成し、こちらはパスワードを割り当てます。
ここで、sshやtelnetなどを用いて、Linuxマシンへkrb5-01としてログインを行ってください。正しく構成されていれば、パスワードとしてAD側で設定したパスワードを用いてログインが行えるはずです。
ログインできない理由で一番大きい理由は時刻同期の問題でしょう。PAMの設定で
auth sufficient pam_krb5.so use_first_pass debug
のように「debug」オプションを付加することによって、syslog(CentOSの場合は/var/log/secure、Debianの場合は/var/log/auth.log)に詳細なログが出力されますので、参考にしてください。時刻同期に問題が発生している場合は、以下のように「Clock skew too great」というエラーが出力されます。
Dec 29 00:40:53 localhost login: pam_krb5[2435]: authentication fails for 'krb5-01' (krb5-01@W2003R2AD3.LOCAL): Authentication failure (Clock skew too great)
AD側でユーザが無効となっている場合は、以下のように「Client credentials have been revoked」というエラーが出力されます。
Jan 12 19:53:19 localhost sshd[5616]: pam_krb5[5616]: authenticating 'krb5-01@W2003R2AD3.LOCAL' to 'krbtgt/W2003R2AD3.LOCAL@W2003R2AD3.LOCAL'
Jan 12 19:53:19 localhost sshd[5616]: pam_krb5[5616]: krb5_get_init_creds_password(krbtgt/W2003R2AD3.LOCAL@W2003R2AD3.LOCAL) returned -1765328366 (Clients credentials have been revoked)
Jan 12 19:53:19 localhost sshd[5616]: pam_krb5[5616]: got result -1765328366 (Clients credentials have been revoked)
AD側で「ユーザーは次回ログオン時にパスワード変更が必要」が有効になっている際にsshでログインしたところ、以下のようにパスワードが期限切れである旨のメッセージが出力されますが、ログインは成功し、パスワードは強制的に同じものが再設定されます。一方、telnetでログインしようとしたところ、パスワードの再設定を促すプロンプトが表示されました。パスワード有効期限切れの際の挙動については、最終的には各プロダクトの実装に依存するところがあると考えられます。
[root@localhost # ssh localhost -l krb5-01
krb5-01@localhost's password:
Password expired. You must change it now.
Last login: Mon Jan 12 23:01:08 2009 from localhost.localdomain
[krb5-01@localhost$
pam_krb5の動作確認:パスワード変更
引き続き、パスワード変更に付いても確認してみましょう。
問題なく設定が行えており、パスワードも適切だった場合は、普段のパスワード変更と同様に、以下のようにしてADのパスワードが変更されます。
[krb5-01@localhost $ passwd
Changing password for user krb5-01.
Changing password for krb5-01
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
ただし、Windows Server 2003以降ではパスワードの制約が非常に厳しくなっています。設定内容については「Default Domain Policy」中のアカウントポリシーで確認ができます(図2 ) 。
図2 Windows Server 2003のパスワードポリシー設定
「パスワードは、複雑さの要件を満たす必要がある」の設定が有効になっていると(デフォルト有効) 、かなり複雑なパスワードが強制されます。また、パスワード変更禁止期間を設定していると、数日に1度しかパスワードを変更できませんので、検証などで1日に何度もパスワードを変更することができません。これらの制約に該当すると、パスワード変更は失敗しますが、エラーからはそれがわかりにくいので注意してください。以下にエラー時の出力例を示します。
[krb5-01@localhost$ passwd
Changing password for user krb5-01.
Changing password for krb5-01
(current) UNIX password:
New UNIX password:
Retype new UNIX password:
Soft error: Password change rejected ()
passwd: Authentication token manipulation error
これらの点を勘案すると、pam_krb5のパスワード変更機能は動作するものの、一般ユーザが利用するのは少々敷居が高いかもしれません。
まとめ
ここまで説明した通り、pam_krb5を用いることで比較的簡単にパスワードの統合を実現することが可能です。ユーザの作成、削除はLinuxマシン側で行う必要がありますが、Linuxマシンへのログインを許可したいユーザを各Linuxマシン毎に指定することが可能になるため、長所として捉えることもできます。ただし、パスワードの変更機能については制限事項が多いため、パスワード変更はAD上から行ってもらう運用にしたほうが無用のトラブルを避けられそうです。
次回はSFUのNIS機能について取り上げる予定です。
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/