概要

通常のローカル認証(shadowパスワード)認証のサーバーを、ログインとsudoをldap認証に切り替え、sshdもパスワード認証から公開鍵認証のみに変更してみる
(OSの再起動なしで挑戦する)

本編

事前に確認

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を使用しており、その設定では

nsswitch.conf

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サーバー導入が可能とも言える

既存のローカル認証サーバーをldap認証への切り替えに挑戦してみる

概要

本編

事前に確認

管理サーバーからitamaeを実行して構築する

ldapサーバーのログインユーザーにローカル認証のユーザーを追加する

挙動確認

まとめ