Active DirectoryとLinuxの認証を統合しよう【2017年版】

第3回pam_krb5による認証連携[1]

第2回で説明したように、Active Directoryの認証は主としてKerberosによって行われています。Active DirectoryのドメインはKerberosでいうところの「レルム(realm⁠⁠」に相当し、 DC(ドメインコントローラ)は、Kerberos的にはKDCとして機能しています。

今回紹介するpam_krb5は、Linuxサーバの認証を外部のKDCにより簡易に行えるようにするPAMモジュールです。KDCとしてADのDCを指定することで、Linuxサーバの認証をADに統合することができます。

今回は、IPアドレスが172.16.2.10で、WIN2K16DC-04というコンピュータ名のWindows Server 2016が稼働するDCが存在する、addom11.ad.localというADドメインでLinuxサーバの認証を行う場合を例に、設定例を示します。Linuxディストリビューションとしては、RHEL系の代表としてCentOS 7.3、Debian/Ubuntu系の代表としてUbuntu 16.04LTSを使っています。

pam_krb5のインストールと基本的な設定

はじめに、インストールととりあえず動作させるまでの設定を紹介しましょう。各ディストリビューションで必要なパッケージの名称を表1に示します。まずは、これらのパッケージをインストールしてください。

表1 pam_krb5の利用に必要なパッケージの名称
ディストリビューションパッケージ名
RHEL系pam_krb5
Debian/Ubuntu系libpam-krb5

パッケージのインストールが完了したら、引き続き設定を行います。

基本的な設定

CentOS 7.3では、次のようにauthconfigを実行することで、必要なファイルが適切に変更されます。

# authconfig --enablekrb5 --krb5kdc=172.16.2.10 --krb5realm=ADDOM11.AD.LOCAL --update

krb5realmに続くレルム名としては、ADドメインのFQDNを必ず大文字で指定します。ここではKDCをIPアドレスで指定しましたが、名前解決が可能な環境では名前で指定しても構いません。このコマンドにより/etc/krb5.confがリスト1のように設定されます。

リスト1 /etc/krb5.confの設定例(CentOS 7.3)
# Configuration snippets may be placed in this directory as well
includedir /etc/krb5.conf.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 rdns = false
 default_ccache_name = KEYRING:persistent:%{uid}

 default_realm = ADDOM11.AD.LOCAL  ← これ以降の行を追加

[realms]
 ADDOM11.AD.LOCAL = {
  kdc = 172.16.2.10
 }

[domain_realm]
 addom11.ad.local = ADDOM11.AD.LOCAL
 .addom11.ad.local = ADDOM11.AD.LOCAL

加えて、PAMの設定ファイルである/etc/pam.d/system-authにも、リスト2のような設定が追加されます。

リスト2 /etc/pam.d/system-authの設定例(CentOS 7.3)
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid ≶= 1000 quiet_success
auth        sufficient    pam_krb5.so use_first_pass ←追加
auth        required      pam_deny.so

account     required      pam_unix.so broken_shadow
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     [default=bad success=ok user_unknown=ignore] pam_krb5.so ←追加
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1
password    sufficient    pam_unix.so sha512 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     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_krb5.so ←追加

Ubuntuの場合は、/etc/krb5.confに手作業でリスト1相当の設定を行います。Ubuntu 16.04LTSで筆者が確認した限り、PAMについてはリスト2相当の設定が行われていましたが、それ以外のUbuntu/Debian系ディストリビューションを使っている場合は、/etc/pam.confや/etc/pam.d配下を確認して設定が行われているかを確認してください。

これに加えて、RHEL系、Ubuntu/Debian系ともに、Kerberos認証を行う上でDCとLinuxサーバ間で時刻が同期されていることが必要です。DCはデフォルトでNTPサーバとしても機能していますので、必要に応じてLinuxサーバ側でNTPクライアントの設定を行うなどして、DCとの時刻同期の設定を行ってください。

認証連携の動作確認

ここまでの設定を行ったら、実際にLinuxサーバにログインできることを確認してみましょう。pam_krb5で実現されるのは認証連携のみですので、連携対象のユーザはあらかじめLinuxサーバ上で作成しておく必要があります

ユーザは、たとえば

# useradd -m aduser01

のようにして作成してください。Linuxサーバ上でパスワードを設定する必要はありません。ついで、AD上で同じ名前のユーザを作成します。こちらはパスワードを適宜設定してください。

設定が完了したら、sshなどを用いてLinuxサーバにaduser01として接続し、パスワードとしてAD上で設定したものを入力してください。正しく構成されていれば、ふつうにログインできるはずです。

パスワード変更の動作確認

引き続きパスワード変更も確認してみましょう。各所の設定を適切に行っていれば、次のように、あっけなくパスワードの変更ができるはずです。

$ passwd
Changing password for user aduser01.
Changing password for aduser01.
(current) UNIX password: ←現在のActive Directoryのパスワードを入力
New password:            ←新しいパスワードを入力
Retype new password:     ←新しいパスワードを再入力
passwd: all authentication tokens updated successfully.

ただし、Active Directory側の設定がデフォルトのままの場合、テストユーザなどで動作を確認しようとすると、おそらくは次のようなメッセージが表示されてパスワード変更が失敗するはずです。

$ passwd
Changing password for user aduser01.
Changing password for aduser01.
(current) UNIX password:
New password:
Retype new password:
Password change rejected: Password change rejected ()

passwd: Authentication token manipulation error

メッセージからは非常に分かり辛いのですが、Active Directoryではセキュリティの観点で、一度パスワードを変更したユーザは1日間パスワードの変更ができない仕様になっているため、検証などで短時間に何度もパスワードを変更することができません。

図1 ⁠アカウント ポリシー」の設定
図1 「アカウント ポリシー」の設定
パスワードの変更禁止期間を0日(即時変更可能)に変更している

図1「アカウント ポリシー」の設定で、⁠パスワードの変更禁止期間」を1日から0日に変更することで回避することはできますが、実運用でこの設定を有効にしている場合は、メッセージから原因がわかりにくいという点を認識しておく必要があります。

なお、⁠アカウント ポリシー」についてはADドメイン全体の設定となりますので注意してください。

まとめ

今回は、ひとまず動作させることを優先して、細かい設定の説明は省いてきました。次回は細かい動作や設定について紹介していきます。

おすすめ記事

記事・ニュース一覧