Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
8
Help us understand the problem. What are the problem?

More than 3 years have passed since last update.

@hirotaka-tajiri

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

概要

通常のローカル認証(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を使用しており、その設定では

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

Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
8
Help us understand the problem. What are the problem?