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