概要
通常のローカル認証(shadowパスワード)認証のサーバーを、ログインとsudoをldap認証に切り替え、sshdもパスワード認証から公開鍵認証のみに変更してみる
(OSの再起動なしで挑戦する)
本編
基本的にitamaeで作業を行いレシピはgithubに上げてある
事前に確認
ldap認証済みのサーバー側
# ldap認証のユーザー
$ id ldusr01
#=>uid=20001(ldusr01) gid=20001(ldapgroup) groups=20001(ldapgroup)
# 接続テスト
$ ssh -i id_ldusr01_ed25519 ldusr01@localhost
#=> ログインOK
# ローカル認証のユーザー
$ id localuser
id: localuser: no such user
ローカル認証サーバー側
# ldap認証のユーザー
$ id ldusr01
#=>id: ldusr01: no such user
# ローカル認証のユーザー
$ id localuser
#=> uid=1001(localuser) gid=1001(localuser) groups=1001(localuser)
# 接続テスト
$ ssh localuser@localhost
> localuser@192.168.56.xxx’s password:
#=> ログインOK
管理サーバーからitamaeを実行して構築する
ldap認証の設定の追加
(管理サーバーでitamaeを実行する)
itamae ssh -u xxx -h 192.168.56.xxx -i id_rsa_xxx ldap_client.rb
sshdをパスワード認証から公開鍵認証のみに変更する
itamae ssh -u xxx -h 192.168.56.xxx -i id_rsa_xxx sshd.rb
ここまで、再起動はしていない
ldapサーバーのログインユーザーにローカル認証のユーザーを追加する
これだと、ldap認証のみのサーバーでは、既存サーバーのローカル認証ユーザーでも、ローカルにユーザー追加なしで、ldap認証できるようになる。
ただ、既存のサーバーに関しては、ローカルにないユーザーはldap認証が可能になるが、既存ユーザーに関してはローカルファイルとldapに共に存在するので
どういう挙動になるか確認する必要がある
挙動確認
ldap認証設定追加済みローカル認証サーバー
# ldap認証のユーザー
$ id ldusr01
#=>uid=20001(ldusr01) gid=20001(ldapgroup) groups=20001(ldapgroup)
#
# ローカルにないユーザーなのでldap認証でidがひける
# ローカル認証のユーザー
$ id localuser
#=> uid=1001(localuser) gid=1001(localuser) groups=1001(localuser)
#
# ローカルユーザーなので既存データーでidがひける
# (ldapサーバーの登録データではuid/gidが違うのでどちらのデータか判別できる)
外部サーバーよりldap認証設定追加済みローカル認証サーバーへ向けてsshでの接続テストをする
(ローカルユーザーに関しては、ldapサーバーにデータ追加したのみ)
# ldap認証ユーザー
$ ssh -i id_ldusr01_ed25519 ldusr01@192.168.56.xxx
#=> ログインOK
#
# ローカルにないユーザーなのでldap認証の鍵認証でログイン可能
# ローカル認証ユーザー
$ ssh -i id_localuser localuser@192.168.56.xxx
#=> ログインOK
#
# ldapサーバーに追加したのみで、ローカルにauthorized_keysファイルの追加は行なっていないが、鍵認証でログイン可能になっている
# また、ここで記載はしていないが、sshd_configの設定でパスワード認証をnoにしているので、パスワード認証でのログインはできなくなっている
sudoldap認証設定追加済みローカル認証サーバーでの動作確認
(ldapサーバーにldusr01とlocaluserのsudoの実行の許可を設定しておく)
# ldusr01(ldap認証のみのユーザー)でのsudoのテスト
$ sudo su -
[sudo] password for ldusr01:
#=> ldapサーバーに登録したパスワードでのsuがOK
# localuser(ローカルユーザー)でのsudoのテスト
$ sudo su -
[sudo] password for localuser:
#=> ldapサーバーに登録したパスワードとローカルのshadowファイルの登録パスワードの両方でのsuがOK
まとめ
この件で、CentOS7系でのldap認証で、nsswitchを使用しており、その設定では
passwd: files sss
shadow: files sss
group: files sss
sudoers: files sss
となっており、検索順がfiles sssとしているので、まずローカルファイルを検索して、なければldapサーバーに検索にいく。これは、今回の検証でのテストでのidの挙動で、ldusr01についての挙動とlocaluserについてのローカルファイルにあるのでldapサーバーでデータで上書きされていなという挙動と一致している。
また、sshの挙動でローカルauthorized_keysファイルがない場合に、ldapサーバーのデータを検索するという挙動とも一致している。
group/shadowの設定が別なので、idでは検索に行かないが、ssh側では検索にいくのも納得できる。
次に、sudoに関してsudoers/password/shadowもnsswitchを使用する設定になっており、検索順がfiles sssとしている。ローカルにパスワード設定がないldusr01でldapサーバー登録パスワードでsudoが可能な挙動に関して特に考慮の必要は全くないが、ローカルにパスワードがあるlocaluserに関しては、ローカルとldapの登録パスワードのどちらでもsudoが可能になっている、これは、まずshadowパスワードを検索・認証し、それで認証できないとldapサーバーで検索・認証を再度行うためこういう挙動になると思われるので、sudoに関しては若干注意が必要な挙動をすると言える
また、再起動をせずに導入が可能だし、sshdのパスワード認証をnoに設定しなければ、(通常のローカルパスワード認証)＋(ldap登録の公開鍵認証)が可能なので、公開鍵の集中管理用のみとしてldapサーバー導入が可能とも言える