LDAP/LDAPでrootアカウント管理

LDAPでrootアカウント管理

rootのパスワードもLDAPで一括管理したくなってきたので試行錯誤しながらやってみました。

構築部分は
このへんとか見ながらやったので割愛します。
エントリの作成とUNIXログインに関しては

rootユーザーのエントリも作成した体で行きます。

で、まずはパスワード認証時にローカルファイルを優先して参照してしまっているので順番変えました。
/etc/nsswitch.confを編集
passwd:     files sss ldap
shadow:     files sss ldap
↓
passwd:     ldap files sss
shadow:     ldap files sss

この状態で su - すると /var/log/secure に下記のエラー。
pam_succeed_if(su-l:auth): requirement "uid >= 1000" not met by user "root"
または直接sshログインしようとすると下記のエラー。
pam_succeed_if(sshd:auth): requirement "uid >= 1000" not met by user "root"
見たまんま、uidが1000以上の場合でなければsshでのログインやsuができないということ。
しかし今回はrootアカウント(パスワード)もLDAPで管理したいという主旨なのでこれでは困ります。

どうやらpamが悪さしているようなので確認。
とりあえず先に出ているエラーの方の /etc/pam.d/su-l を確認してみます。(auth部分のみ)
auth            include         su
authはsuを参照している模様
/etc/pam.d/suはこんな感じ。(auth部分のみ)
auth            sufficient      pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth           sufficient      pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth           required        pam_wheel.so use_uid
auth            substack        system-auth
auth            include         postlogin
一番上の行はrootアカウントの場合認証OKだが、今回は一般ユーザーなので該当しない。
コメント飛ばして次の行は、system-authを参照しているようなのでそちらを確認。

/etc/pam.d/system-authはこんな感じ。(略)
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
一番上は環境変数の読み込みなので特に問題無くスルー。
次はunixの標準認証で、今回は/etc/passwdにUNIXアカウントが無いのでNGだが、sufficientなので次を確認。
で、ここでついにuidが1000以上でなければだめという条件が書かれているが、どうやらpam_succeed_if.soでの評価はsuで切り替わった後のuidが判断される模様。
rootのuidは0なのでここの条件にマッチせずに弾かれているという状態のようだ。
なので、↓の例のようにこの行をコメントするか、4行目のldapを使っている行と入れ替えれば無事LDAPパスワードでログイン、またはsuできるようになる。
auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
#auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so use_first_pass
auth        required      pam_deny.so
なお、この状態だとローカルアカウントとldapアカウントどちらでも認証が通る状態になってしまうので、ldap認証のみにしたい場合はauthconfigでshadowパスワードを無効にするか、ファイルを以下の様にする。(2行目もコメントした上で、4行目の引数を try_first_pass にする)
auth        required      pam_env.so
#auth        sufficient    pam_unix.so nullok try_first_pass
#auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_ldap.so try_first_pass
auth        required      pam_deny.so
ただしこれだと今度はldapサーバーに接続できない場合にログインできないということになるので、ssh鍵によるパスワード無しでのrootログインを有効にしておくのがベター。
念の為ssh鍵にはパスフレーズをかけておき、AllowUsers で接続元の制限をかけておくことを推奨。

そうすると今度はsshdが落ちた時やネットワークが落ちた時など、sshログインできない時にどうするのかという問題が出てくる。
その場合はコンソールで直接繋いでログインするので、/etc/pam.d/login でローカルアカウントを参照するように変更しておく。
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       substack     system-auth
auth       include      postlogin
↓
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       sufficient   pam_unix.so nullok try_first_pass
auth       substack     system-auth
auth       include      postlogin
この状態だとコンソールでの直接ログインの場合はローカルアカウントとldapアカウント両方で認証可能。
sshやsuはldapアカウントのみで認証可能ということになる。

厳密にはローカルのrootアカウント(パスワード)が残ってしまうことにはなるが、このパスワードはコンソールでの直接ログイン時にしか使われることがないので気にしないか、もしそれも気になるというのであればcapistranoやchefを使って変更するような手順を確立した方が良さそう。
そもそもldapで管理しないで最初からcapistranoやchefを使ってやればこんな面倒なことしなくていいのではということもありますが・・・

ちなみにPAM周りはいろいろ試してみたがいまいち説明がつかない動きが見受けられるのであまり細かい説明には言及しないことにする。
とりあえず今回はこういうものだと思って下さい。

  • 最終更新:2016-01-25 11:06:20

このWIKIを編集するにはパスワード入力が必要です

認証パスワード