nss_ldapを使用している時にLDAPサーバが落ちているとログインに時間がかかる。
ちなみにその時のログはこんな感じ。
sshd[29123]: nss_ldap: failed to bind to LDAP server ldap://xxx: Can't contact LDAP server
sshd[29123]: nss_ldap: could not search LDAP server - Server is unavailable
でこいつを回避するには設定ファイルなどでは無理なのでnss_ldapのソースを修正し、
リコンパイル、再インストールという作業が発生してしまう。
ちなみにソースの修正箇所は以下。
ldap-nss.h
#define LDAP_NSS_TRIES 5 /* number of sleeping reconnect attempts */
#define LDAP_NSS_SLEEPTIME 4 /* seconds to sleep; doubled until max */
#define LDAP_NSS_MAXSLEEPTIME 64 /* maximum seconds to sleep */
#define LDAP_NSS_MAXCONNTRIES 2 /* reconnect attempts before sleeping */
こいつらを適正値に変更してあげればよい。
でその後に、
./configrue
make
make installl
これで再インストール完了。
簡単だけど面倒な作業でした。
以上。
ちなみにその時のログはこんな感じ。
sshd[29123]: nss_ldap: failed to bind to LDAP server ldap://xxx: Can't contact LDAP server
sshd[29123]: nss_ldap: could not search LDAP server - Server is unavailable
でこいつを回避するには設定ファイルなどでは無理なのでnss_ldapのソースを修正し、
リコンパイル、再インストールという作業が発生してしまう。
ちなみにソースの修正箇所は以下。
ldap-nss.h
#define LDAP_NSS_TRIES 5 /* number of sleeping reconnect attempts */
#define LDAP_NSS_SLEEPTIME 4 /* seconds to sleep; doubled until max */
#define LDAP_NSS_MAXSLEEPTIME 64 /* maximum seconds to sleep */
#define LDAP_NSS_MAXCONNTRIES 2 /* reconnect attempts before sleeping */
こいつらを適正値に変更してあげればよい。
でその後に、
./configrue
make
make installl
これで再インストール完了。
簡単だけど面倒な作業でした。
以上。
 | LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
スポンサーサイト
0
6主にNW機器の認証もLDAPに任せたい、
って時によくあるRADIUSとの連携について纏めてみます。
ちなみにLDAPは既に構築済みで正常に動作しているものとします。
RADIUSについてはFreeRADIUSを使用しました。
では順を追って説明。
①. FreeRADIUSのインストール。
# cd /usr/local/src/
# tar zxvf freeradius-1.1.7.tar.gz
# cd ./freeradius-1.1.7
# ./configure --prefix=/usr/local/radius ← ここはお好みで
# make
# make install
以上でインストールの完了。
まず、LDAPと連携させる前にローカルユーザーとの連携が可能か確認。
今回インストールしたFreeRADIUSはデフォルトでローカルUnixユーザーを
見に行く設定になっている為、RADIUS側の設定は不要でした。
②. ローカルアカウントにtestユーザーを追加する。
# uesradd test
# passwd test
--------------------------------------------------------------------------
Changing password for user test.
New UNIX password: ← testと入力
BAD PASSWORD: it is too short
Retype new UNIX password: ← testと入力
passwd: all authentication tokens updated successfully.
--------------------------------------------------------------------------
③. RADIUSをデバックモードにて起動。
# radiusd -X -A
--------------------------------------------------------------------------------
～以上省略
Module: Loaded radutmp
radutmp: filename = "/usr/local/radius/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Ready to process requests.
---------------------------------------------------------------------------------
正常に起動したことを確認。
③. 別のコンソールから、radtestコマンドを使用して認証が通るか確認する。
# radtest test test localhost 1 testing123
オプション説明
[user名] 認証を行うユーザー名
[password] 対応するパスワード
[server名] 問い合わせるサーバ名
[nas-port-number] NASポート番号
[secret] 共有鍵
--------------------------------------------------------------------------------------
Sending Access-Request of id 118 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "test"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=118, length=20
--------------------------------------------------------------------------------------
Access-Acceptパケットが返ってきて、認証が通ったことを確認。
ちなみに、サーバ側のデバックログでは以下のように表示される。
---------------------------------------------------------------------------
～以上省略
Sending Access-Accept of id 118 to 127.0.0.1 port 32770
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 118 with timestamp 473bf3ce
Nothing to do. Sleeping until we see a request.
----------------------------------------------------------------------------
④. radtestで認証に失敗した場合を確認する。
# radtest test password localhost 1 testing123
-----------------------------------------------------------------------------------
Sending Access-Request of id 251 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "passwd"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=251, length=20
----------------------------------------------------------------------------------
パスワードが間違っているため、Access-Rejectパケットが返ってきて、認証が
失敗している事を確認。サーバ側のデバッグログでは以下のように表示される。
------------------------------------------------------------------------
～以上省略
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 251 to 127.0.0.1 port 32770
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 251 with timestamp 473bf4fd
Nothing to do. Sleeping until we see a request.
-------------------------------------------------------------------------
以上でローカルアカウントのRADIUS認証の確認は完了である。
次に、RADIUSがLDAPユーザーを見に行くように設定をする。
⑤. radius.confをLDAP対応のため、以下のように編集する。
LDAPサーバ周りの設定は各環境によって違うので適当に合わせる。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
～以上省略
ldap {
server = "LDAPサーバのIP"
identity = "cn=Manager,dc=my-domain,dc=com"
password = secret
basedn = "dc=my-domain,dc=com"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
start_tls = yes
tls_cacertdir = /etc/openldap/cacerts/
～途中省略
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
unix
Auth-Type LDAP { ← コメントアウトを外す
ldap ← コメントアウトを外す
} ← コメントアウトを外す
eap
}
～以下省略
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑥. usersを以下のように編集し、LDAP認証をデフォルトに変更。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DEFAULT Auth-Type = LDAP ← Systemから変更
Fall-Through = 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑦. clients.confを以下のように編集しclientの属するセグメントからのアクセスを許可する。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
client クライアントの属するネットワークアドレス/24{
secret = testing123 ← 共有鍵
shortname = localhost ← ログファイルの中で使う名称
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑧. slapdをデバックモードで立ち上げ。
# slapd -d 1
⑨. RADIUSをデバックモードで再起動。
# Ctrl-Cで先程立ち上げたRADIUSをストップ
# radiusd -X -A
⑩. radtestでLDAPユーザーの認証が通るか確認。
# radtest testUser password LDAPサーバのIP 1 testing123
-------------------------------------------------------------------------------------------
Sending Access-Request of id 118 to RADIUS(LDAP)サーバのIP port 1812
User-Name = "testUser"
User-Password = "password"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Accept packet from host RADIUS(LDAP)サーバのIP:1812, id=118, length=20
-------------------------------------------------------------------------------------------
Access-Acceptパケットが返ってきて、認証が通ったことを確認。
ちなみに、サーバ側のデバッグログも確認しておくと、認証の流れがよく分かるかと。
radiusdがradtestによって認証依頼を受けると、radiusdからslapdへの検索がかかる。
また、StartTLSも有効にしているため、SSL証明書のやり取りも見れるはず。
ログの量が多いため載せてないすがが、一度確認しておくといいかも。
以上で、RADIUSとLDAPの連携が完了。
ここからはNW機器側の設定。
ちなみに検証に使用したスイッチはCiscoのCatalyst3560Gである。
スイッチ側は初期化状態(startup-configなし)の状態から始める。
⑪. コンフィグモードでRADIUSクライアントとしての設定を行う。
Switch(config)#aaa new-model
Switch(config)#aaa authentication login default group radius local
Switch(config)#radius-server host RADIUS(LDAP)サーバのIP auth-port 1812 acct-port 1813
Switch(config)#radius-server key testing123 ← 共有鍵
＃認証ポートとアカウティングポートは、明示的に指定
⑫. 念の為、通信に失敗した場合に備えてローカルユーザー(管理者権限で）を作成しておく。
Switch(config)#username test privilege 15 password test
⑬. 一度ログアウトし、LDAPユーザーでログイン可能かどうか確認してみる。
User Access Verification
Username: testUser
Password: ← passwordと入力
Switch>
正常にログイン出来ることを確認できた。
ちなみにですが、RADIUSとの疎通が可能な状態では作成したローカルユーザーは
ログイン出来ません。RADIUSとの通信が出来ない緊急時のみ使用可能です。
って時によくあるRADIUSとの連携について纏めてみます。
ちなみにLDAPは既に構築済みで正常に動作しているものとします。
RADIUSについてはFreeRADIUSを使用しました。
では順を追って説明。
①. FreeRADIUSのインストール。
# cd /usr/local/src/
# tar zxvf freeradius-1.1.7.tar.gz
# cd ./freeradius-1.1.7
# ./configure --prefix=/usr/local/radius ← ここはお好みで
# make
# make install
以上でインストールの完了。
まず、LDAPと連携させる前にローカルユーザーとの連携が可能か確認。
今回インストールしたFreeRADIUSはデフォルトでローカルUnixユーザーを
見に行く設定になっている為、RADIUS側の設定は不要でした。
②. ローカルアカウントにtestユーザーを追加する。
# uesradd test
# passwd test
--------------------------------------------------------------------------
Changing password for user test.
New UNIX password: ← testと入力
BAD PASSWORD: it is too short
Retype new UNIX password: ← testと入力
passwd: all authentication tokens updated successfully.
--------------------------------------------------------------------------
③. RADIUSをデバックモードにて起動。
# radiusd -X -A
--------------------------------------------------------------------------------
～以上省略
Module: Loaded radutmp
radutmp: filename = "/usr/local/radius/var/log/radius/radutmp"
radutmp: username = "%{User-Name}"
radutmp: case_sensitive = yes
radutmp: check_with_nas = yes
radutmp: perm = 384
radutmp: callerid = yes
Module: Instantiated radutmp (radutmp)
Listening on authentication *:1812
Listening on accounting *:1813
Ready to process requests.
---------------------------------------------------------------------------------
正常に起動したことを確認。
③. 別のコンソールから、radtestコマンドを使用して認証が通るか確認する。
# radtest test test localhost 1 testing123
オプション説明
[user名] 認証を行うユーザー名
[password] 対応するパスワード
[server名] 問い合わせるサーバ名
[nas-port-number] NASポート番号
[secret] 共有鍵
--------------------------------------------------------------------------------------
Sending Access-Request of id 118 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "test"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=118, length=20
--------------------------------------------------------------------------------------
Access-Acceptパケットが返ってきて、認証が通ったことを確認。
ちなみに、サーバ側のデバックログでは以下のように表示される。
---------------------------------------------------------------------------
～以上省略
Sending Access-Accept of id 118 to 127.0.0.1 port 32770
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 6 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 118 with timestamp 473bf3ce
Nothing to do. Sleeping until we see a request.
----------------------------------------------------------------------------
④. radtestで認証に失敗した場合を確認する。
# radtest test password localhost 1 testing123
-----------------------------------------------------------------------------------
Sending Access-Request of id 251 to 127.0.0.1 port 1812
User-Name = "test"
User-Password = "passwd"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Reject packet from host 127.0.0.1:1812, id=251, length=20
----------------------------------------------------------------------------------
パスワードが間違っているため、Access-Rejectパケットが返ってきて、認証が
失敗している事を確認。サーバ側のデバッグログでは以下のように表示される。
------------------------------------------------------------------------
～以上省略
auth: Failed to validate the user.
Delaying request 0 for 1 seconds
Finished request 0
Going to the next request
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Waking up in 1 seconds...
--- Walking the entire request list ---
Sending Access-Reject of id 251 to 127.0.0.1 port 32770
Waking up in 4 seconds...
--- Walking the entire request list ---
Cleaning up request 0 ID 251 with timestamp 473bf4fd
Nothing to do. Sleeping until we see a request.
-------------------------------------------------------------------------
以上でローカルアカウントのRADIUS認証の確認は完了である。
次に、RADIUSがLDAPユーザーを見に行くように設定をする。
⑤. radius.confをLDAP対応のため、以下のように編集する。
LDAPサーバ周りの設定は各環境によって違うので適当に合わせる。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
～以上省略
ldap {
server = "LDAPサーバのIP"
identity = "cn=Manager,dc=my-domain,dc=com"
password = secret
basedn = "dc=my-domain,dc=com"
filter = "(uid=%{Stripped-User-Name:-%{User-Name}})"
start_tls = yes
tls_cacertdir = /etc/openldap/cacerts/
～途中省略
authenticate {
Auth-Type PAP {
pap
}
Auth-Type CHAP {
chap
}
Auth-Type MS-CHAP {
mschap
}
unix
Auth-Type LDAP { ← コメントアウトを外す
ldap ← コメントアウトを外す
} ← コメントアウトを外す
eap
}
～以下省略
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑥. usersを以下のように編集し、LDAP認証をデフォルトに変更。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
DEFAULT Auth-Type = LDAP ← Systemから変更
Fall-Through = 1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑦. clients.confを以下のように編集しclientの属するセグメントからのアクセスを許可する。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
client クライアントの属するネットワークアドレス/24{
secret = testing123 ← 共有鍵
shortname = localhost ← ログファイルの中で使う名称
}
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑧. slapdをデバックモードで立ち上げ。
# slapd -d 1
⑨. RADIUSをデバックモードで再起動。
# Ctrl-Cで先程立ち上げたRADIUSをストップ
# radiusd -X -A
⑩. radtestでLDAPユーザーの認証が通るか確認。
# radtest testUser password LDAPサーバのIP 1 testing123
-------------------------------------------------------------------------------------------
Sending Access-Request of id 118 to RADIUS(LDAP)サーバのIP port 1812
User-Name = "testUser"
User-Password = "password"
NAS-IP-Address = 255.255.255.255
NAS-Port = 1
rad_recv: Access-Accept packet from host RADIUS(LDAP)サーバのIP:1812, id=118, length=20
-------------------------------------------------------------------------------------------
Access-Acceptパケットが返ってきて、認証が通ったことを確認。
ちなみに、サーバ側のデバッグログも確認しておくと、認証の流れがよく分かるかと。
radiusdがradtestによって認証依頼を受けると、radiusdからslapdへの検索がかかる。
また、StartTLSも有効にしているため、SSL証明書のやり取りも見れるはず。
ログの量が多いため載せてないすがが、一度確認しておくといいかも。
以上で、RADIUSとLDAPの連携が完了。
ここからはNW機器側の設定。
ちなみに検証に使用したスイッチはCiscoのCatalyst3560Gである。
スイッチ側は初期化状態(startup-configなし)の状態から始める。
⑪. コンフィグモードでRADIUSクライアントとしての設定を行う。
Switch(config)#aaa new-model
Switch(config)#aaa authentication login default group radius local
Switch(config)#radius-server host RADIUS(LDAP)サーバのIP auth-port 1812 acct-port 1813
Switch(config)#radius-server key testing123 ← 共有鍵
＃認証ポートとアカウティングポートは、明示的に指定
⑫. 念の為、通信に失敗した場合に備えてローカルユーザー(管理者権限で）を作成しておく。
Switch(config)#username test privilege 15 password test
⑬. 一度ログアウトし、LDAPユーザーでログイン可能かどうか確認してみる。
User Access Verification
Username: testUser
Password: ← passwordと入力
Switch>
正常にログイン出来ることを確認できた。
ちなみにですが、RADIUSとの疎通が可能な状態では作成したローカルユーザーは
ログイン出来ません。RADIUSとの通信が出来ない緊急時のみ使用可能です。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
LDAPのアクセスコントールは分かりづらいので設定を纏めてみる。
今回例として、開発部と営業部という仮のグループを作成してみます。
それぞれ専用サーバを保有していて、自部署のサーバにはログイン可能だが
相手のサーバにはログイン不可、といった形のどこにでもありがちな構成です。
実際の設定の前に、自部署サーバ ～ LDAPサーバ間の認証の流れを確認。
1. 自部署サーバにログインする際、個人のアカウントとパスワードを入力
2. 認証情報を入力された自部署サーバは、認証情報をLDAPサーバへ問合
3. LDAPサーバは受け取った認証情報を元に自身が保持しているデータを検索
4. LDAPサーバが検索結果を自部署サーバへ返す
5. 返された結果を元に、自部署サーバが実際の認証処理を行う
簡単に確認すると以上。
ここで今回重要なのが2.で、 認証情報をLDAPサーバへ問合せる際に、
問合せそのものにも権限が必要になるためここで一度認証が発生します。
この問合せの認証時に使用されるのは自部署サーバのログイン時に
入力した値ではなく、認証DN(binddn)で指定されているものが使用されます。
認証DNは/etc/ldap.confで指定出来ます。
/etc/ldap.confに、binddnとbindpwというパラメータがあり、
ここで問合せの認証時に使用するDNを指定します。
ちなみに設定していないとanonymous(匿名)でのアクセスです。
今回、ACLで制御するのはこの問合せ時の認証DNに対してになります。
お互いの認証DNは自部署のディレクトリツリーはアクセス可能だが、
相手部署のディレクトリツリーに対してはアクセス出来ないよう設定します。
上記実現の為、それぞれの認証DNにはプロキシユーザーを作成します。
プロキシユーザーは問合せ専用の認証DNとして使用し、部署毎に1DN作成します。
それでは実際にやってみましょう。
まず、開発部と営業部のグループ、テストユーザ、プロキシユーザーの作成から。
①. 以下のldifファイル(acl_test.ldif)を用意。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: ou=dev,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: dev
dn: uid=devproxy,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword: devproxy
loginShell: /bin/bash
dn: uid=devUser,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devUser
uid: devUser
uidNumber: 10011
gidNumber: 10011
homeDirectory: /home/devUser
userPassword: devUser
loginShell: /bin/bash
dn: ou=sal,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: sal
dn: uid=salproxy,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salproxy
uid: salproxy
uidNumber: 20001
gidNumber: 20001
homeDirectory: /home/salproxy
userPassword: salproxy
loginShell: /bin/bash
dn: uid=salUser,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salUser
uid: salUser
uidNumber: 20011
gidNumber: 20011
homeDirectory: /home/salUser
userPassword: salUser
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
②. ldapaddで登録。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
acl_test.ldif
----------------------------------------------------------------------------------
adding new entry "ou=dev,dc=my-domain,dc=com"
adding new entry "uid=devproxy,ou=dev,dc=my-domain,dc=com"
adding new entry "uid=devUser,ou=dev,dc=my-domain,dc=com"
adding new entry "ou=sal,dc=my-domain,dc=com"
adding new entry "uid=salproxy,ou=sal,dc=my-domain,dc=com"
adding new entry "uid=salUser,ou=sal,dc=my-domain,dc=com"
-----------------------------------------------------------------------------------
③. それぞれ追加したプロキシユーザーで、全てのエントリが検索可能である事を確認。
＃ldapクライアントコマンドでは「-D」オプションによって認証DNの指定が可能。
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=devproxy,ou=dev,dc=my-domain,dc=com" -w devproxy
-----------------------------
～以上省略
# numResponses: 16
# numEntries: 15
-----------------------------
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=salproxy,ou=sal,dc=my-domain,dc=com" -w salproxy
-----------------------------
～以上省略
# numResponses: 16
# numEntries: 15
-----------------------------
問題ないことを確認。
現状ACLが何もかかっていない状態なので、
全てのエントリがどの認証ユーザーからでも確認出来るはずです。
次に本題のACLの設定。
⑥. slapd.confへ以下の内容を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
access to attr=userPassword
by * auth
access to dn.subtree="ou=dev,dc=my-domain,dc=com"
by dn.base="uid=devproxy,ou=dev,dc=my-domain,dc=com" read
by * none
access to dn.subtree="ou=sal,dc=my-domain,dc=com"
by dn.base="uid=salproxy,ou=sal,dc=my-domain,dc=com" read
by * none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
設定した項目について、順に確認してみます。
前提としてACLは上から順に評価され、マッチした項目については以後の評価はされません。
一番目の項目はuserPassword属性についてのもので、全てのユーザーに認証の
権限のみを与えています。userPassword属性には個別にアクセス権を与えておかないと、
Invalid credentialsのエラーで弾かれてしまい、以降のACLが効かなくなってしまいます。
次の項目はACLの範囲として、dn.subtreeに"ou=dev,dc=my-domain,dc=com"を
指定しています。これは"ou=dev,dc=my-domain,dc=com"自身とその配下に存在する
全てのエントリが適用範囲という事になります。
ちなみにdn.childrenとした場合は"ou=dev,dc=my-domain,dc=com"は含まれず、
"ou=dev,dc=my-domain,dc=com"配下のエントリのみが適用範囲になります。
次に、実際に権限を与えるオブジェクトですが、今回ACL用に作成したプロキシユーザーへ
dn.baseでread権限を与えており、その他のユーザーについては何も権限を与えない設定。
salグループも同様です。
以上を纏めると、まずpassword属性については誰でも認証要求は可能。
次に"ou=dev,dc=my-domain,dc=com"以下に対するアクセスについてですが、
代理ユーザーであるxxxproxyのみがread可能で、その他のDNは拒否されます。
salグループについても代理ユーザーが異なるだけで同じ設定です。
ちなみにrootdnについては当然ACLの範疇外なのでいつでも全てのエントリにアクセス可能
では実際に確認してみましょう。
⑦. それぞれのプロキシユーザーでldapsearch。
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=devproxy,ou=dev,dc=my-domain,dc=com" -w devproxy
------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# dev, my-domain.com
dn: ou=dev,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: dev
# devproxy, dev, my-domain.com
dn: uid=devproxy,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword:: ZGV2cHJveHk=
loginShell: /bin/bash
# devUser, dev, my-domain.com
dn: uid=devUser,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devUser
uid: devUser
uidNumber: 10011
gidNumber: 10011
homeDirectory: /home/devUser
loginShell: /bin/bash
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
------------------------------------------------------------------
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=salproxy,ou=sal,dc=my-domain,dc=com" -w salproxy
------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base with scope sub
# filter: (objectclass=*)
# requesting: ALL
#
# sal, my-domain.com
dn: ou=sal,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: sal
# salproxy, sal, my-domain.com
dn: uid=salproxy,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salproxy
uid: salproxy
uidNumber: 20001
gidNumber: 20001
homeDirectory: /home/salproxy
userPassword:: c2FscHJveHk=
loginShell: /bin/bash
# salUser, sal, my-domain.com
dn: uid=salUser,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salUser
uid: salUser
uidNumber: 20011
gidNumber: 20011
homeDirectory: /home/salUser
loginShell: /bin/bash
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
------------------------------------------------------------------
それぞれ自部署のユーザーしか見えない事を確認出来ました。
最後にクライアント(自部署サーバ)側の設定を行う。
⑧. それぞれ/etc/ldap.confの以下の部分を編集。
開発部サーバ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
binddn uid=devproxy,ou=dev,dc=my-domain,dc=com
bindpw devproxy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
営業部サーバ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
binddn uid=salproxy,ou=sal,dc=my-domain,dc=com
bindpw salproxy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上。
今回例として、開発部と営業部という仮のグループを作成してみます。
それぞれ専用サーバを保有していて、自部署のサーバにはログイン可能だが
相手のサーバにはログイン不可、といった形のどこにでもありがちな構成です。
実際の設定の前に、自部署サーバ ～ LDAPサーバ間の認証の流れを確認。
1. 自部署サーバにログインする際、個人のアカウントとパスワードを入力
2. 認証情報を入力された自部署サーバは、認証情報をLDAPサーバへ問合
3. LDAPサーバは受け取った認証情報を元に自身が保持しているデータを検索
4. LDAPサーバが検索結果を自部署サーバへ返す
5. 返された結果を元に、自部署サーバが実際の認証処理を行う
簡単に確認すると以上。
ここで今回重要なのが2.で、 認証情報をLDAPサーバへ問合せる際に、
問合せそのものにも権限が必要になるためここで一度認証が発生します。
この問合せの認証時に使用されるのは自部署サーバのログイン時に
入力した値ではなく、認証DN(binddn)で指定されているものが使用されます。
認証DNは/etc/ldap.confで指定出来ます。
/etc/ldap.confに、binddnとbindpwというパラメータがあり、
ここで問合せの認証時に使用するDNを指定します。
ちなみに設定していないとanonymous(匿名)でのアクセスです。
今回、ACLで制御するのはこの問合せ時の認証DNに対してになります。
お互いの認証DNは自部署のディレクトリツリーはアクセス可能だが、
相手部署のディレクトリツリーに対してはアクセス出来ないよう設定します。
上記実現の為、それぞれの認証DNにはプロキシユーザーを作成します。
プロキシユーザーは問合せ専用の認証DNとして使用し、部署毎に1DN作成します。
それでは実際にやってみましょう。
まず、開発部と営業部のグループ、テストユーザ、プロキシユーザーの作成から。
①. 以下のldifファイル(acl_test.ldif)を用意。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: ou=dev,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: dev
dn: uid=devproxy,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword: devproxy
loginShell: /bin/bash
dn: uid=devUser,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devUser
uid: devUser
uidNumber: 10011
gidNumber: 10011
homeDirectory: /home/devUser
userPassword: devUser
loginShell: /bin/bash
dn: ou=sal,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: sal
dn: uid=salproxy,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salproxy
uid: salproxy
uidNumber: 20001
gidNumber: 20001
homeDirectory: /home/salproxy
userPassword: salproxy
loginShell: /bin/bash
dn: uid=salUser,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salUser
uid: salUser
uidNumber: 20011
gidNumber: 20011
homeDirectory: /home/salUser
userPassword: salUser
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
②. ldapaddで登録。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
acl_test.ldif
----------------------------------------------------------------------------------
adding new entry "ou=dev,dc=my-domain,dc=com"
adding new entry "uid=devproxy,ou=dev,dc=my-domain,dc=com"
adding new entry "uid=devUser,ou=dev,dc=my-domain,dc=com"
adding new entry "ou=sal,dc=my-domain,dc=com"
adding new entry "uid=salproxy,ou=sal,dc=my-domain,dc=com"
adding new entry "uid=salUser,ou=sal,dc=my-domain,dc=com"
-----------------------------------------------------------------------------------
③. それぞれ追加したプロキシユーザーで、全てのエントリが検索可能である事を確認。
＃ldapクライアントコマンドでは「-D」オプションによって認証DNの指定が可能。
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=devproxy,ou=dev,dc=my-domain,dc=com" -w devproxy
-----------------------------
～以上省略
# numResponses: 16
# numEntries: 15
-----------------------------
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=salproxy,ou=sal,dc=my-domain,dc=com" -w salproxy
-----------------------------
～以上省略
# numResponses: 16
# numEntries: 15
-----------------------------
問題ないことを確認。
現状ACLが何もかかっていない状態なので、
全てのエントリがどの認証ユーザーからでも確認出来るはずです。
次に本題のACLの設定。
⑥. slapd.confへ以下の内容を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
access to attr=userPassword
by * auth
access to dn.subtree="ou=dev,dc=my-domain,dc=com"
by dn.base="uid=devproxy,ou=dev,dc=my-domain,dc=com" read
by * none
access to dn.subtree="ou=sal,dc=my-domain,dc=com"
by dn.base="uid=salproxy,ou=sal,dc=my-domain,dc=com" read
by * none
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
設定した項目について、順に確認してみます。
前提としてACLは上から順に評価され、マッチした項目については以後の評価はされません。
一番目の項目はuserPassword属性についてのもので、全てのユーザーに認証の
権限のみを与えています。userPassword属性には個別にアクセス権を与えておかないと、
Invalid credentialsのエラーで弾かれてしまい、以降のACLが効かなくなってしまいます。
次の項目はACLの範囲として、dn.subtreeに"ou=dev,dc=my-domain,dc=com"を
指定しています。これは"ou=dev,dc=my-domain,dc=com"自身とその配下に存在する
全てのエントリが適用範囲という事になります。
ちなみにdn.childrenとした場合は"ou=dev,dc=my-domain,dc=com"は含まれず、
"ou=dev,dc=my-domain,dc=com"配下のエントリのみが適用範囲になります。
次に、実際に権限を与えるオブジェクトですが、今回ACL用に作成したプロキシユーザーへ
dn.baseでread権限を与えており、その他のユーザーについては何も権限を与えない設定。
salグループも同様です。
以上を纏めると、まずpassword属性については誰でも認証要求は可能。
次に"ou=dev,dc=my-domain,dc=com"以下に対するアクセスについてですが、
代理ユーザーであるxxxproxyのみがread可能で、その他のDNは拒否されます。
salグループについても代理ユーザーが異なるだけで同じ設定です。
ちなみにrootdnについては当然ACLの範疇外なのでいつでも全てのエントリにアクセス可能
では実際に確認してみましょう。
⑦. それぞれのプロキシユーザーでldapsearch。
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=devproxy,ou=dev,dc=my-domain,dc=com" -w devproxy
------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base
# filter: (objectclass=*)
# requesting: ALL
#
# dev, my-domain.com
dn: ou=dev,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: dev
# devproxy, dev, my-domain.com
dn: uid=devproxy,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword:: ZGV2cHJveHk=
loginShell: /bin/bash
# devUser, dev, my-domain.com
dn: uid=devUser,ou=dev,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: devUser
uid: devUser
uidNumber: 10011
gidNumber: 10011
homeDirectory: /home/devUser
loginShell: /bin/bash
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
------------------------------------------------------------------
# ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D "uid=salproxy,ou=sal,dc=my-domain,dc=com" -w salproxy
------------------------------------------------------------------
# extended LDIF
#
# LDAPv3
# base
# filter: (objectclass=*)
# requesting: ALL
#
# sal, my-domain.com
dn: ou=sal,dc=my-domain,dc=com
objectClass: organizationalUnit
ou: sal
# salproxy, sal, my-domain.com
dn: uid=salproxy,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salproxy
uid: salproxy
uidNumber: 20001
gidNumber: 20001
homeDirectory: /home/salproxy
userPassword:: c2FscHJveHk=
loginShell: /bin/bash
# salUser, sal, my-domain.com
dn: uid=salUser,ou=sal,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: salUser
uid: salUser
uidNumber: 20011
gidNumber: 20011
homeDirectory: /home/salUser
loginShell: /bin/bash
# search result
search: 3
result: 0 Success
# numResponses: 4
# numEntries: 3
------------------------------------------------------------------
それぞれ自部署のユーザーしか見えない事を確認出来ました。
最後にクライアント(自部署サーバ)側の設定を行う。
⑧. それぞれ/etc/ldap.confの以下の部分を編集。
開発部サーバ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
binddn uid=devproxy,ou=dev,dc=my-domain,dc=com
bindpw devproxy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
営業部サーバ
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
binddn uid=salproxy,ou=sal,dc=my-domain,dc=com
bindpw salproxy
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
sync replicationについて機能概要を纏めてみます。
ちなみに現行のOpenLDAPにはsync replication(以下syncrepl)と、
Ver2.2系まで主流であったslurpdという二つの複製手段が存在します。
違いは以下のような感じです。
slurpdとは、スレーブ側の複製専用のサービスのことです。
複製方法の流れとしては、マスターで更新が発生した際にslapdが更新情報をslapd.logと
いうログファイルに書き出します。これを複製サーバのslurpdが定期的に読み出し、更新が
ある場合は自分自身のslapdに適用し同期しているといった流れです。
ただslurpdにはいくつかの欠点があります。
まずslapd.logには更新情報しか書き出されないので、運用を始める前に予め
マスターとスレーブ間でデータの内容を一致させてあげなければいけません。
次に、マスターとスレーブ間で常に正しく同期されているかの保障がありません。
例えば、あるエントリの同期に失敗したとします。
失敗したこのエントリについてはリジェクトファイルというものに書き出されますが、
その後自動でこのファイルを再読み込みなどはしないので、
矛盾が発生した場合は手動でエントリを追加する事になります。
次は、新しい機能であるsyncreplについて。
syncreplでは、slurpdでいうマスターに相当するサーバを「プロバイダ」、
スレーブに相当するサーバを「コンシューマ」と呼びます。
slurpdと違い、複製の初期動作はコンシューマ側から発生する事になっていて、
コンシューマ側から予め設定されている指定に基づき、プロバイダ側へ検索を行います。
また、前回の複製からの変更情報を知る手立てとして、syncreplはcookieを使ってます。
プロバイダは複製が終ると、その度にCSNの現時点の最大値をcookieで返します。
CSNとはエントリそれぞれに存在するURL変更順番号の値の事で、プロバイダで
新規追加や既存エントリの更新が行われた際、現在の値よりも大きな値に変更されます。
コンシューマは複製時に検索条件と共に前回取得したcookie値を通知する事で、
プロバイダで通知されたcookie値よりも大きなCSNを持つエントリを複製すべきエントリ
として返す事が出来る、という仕組みです。
纏めると複製処理の流れは以下ような感じ。
1. コンシューマから検索条件と共に前回の複製時に受け取ったcookie値(CSN)を
プロバイダへ通知し、同期依頼をかける。
2. 同期依頼を受け取ったプロバイダは検索条件にマッチしたエントリを順に調べ、
通知されたcookieの値と現在のエントリのCSNを比較。
3. プロバイダは現在のエントリのCSNが通知されたcookie値よりも大きかったエン
トリを複製するエントリとしてコンシューマに応答。
4. 複製するエントリを受け取ったコンシューマは、自身のエントリをアップデート。
以上がsyncreplによる基本的な複製処理。
また、syncreplには二つの動作モードが存在し、以下の様な特徴がある。
□ refreshOnlyモード
コンシューマから、定期的に同期依頼をかける。
プロバイダで上記の流れに沿った複製処理が行われ、
更新すべきエントリを返す場合に、このモードは存在メッセージというものも同時に返す。
存在メッセージとは、削除されたエントリを識別するためのものです。
通常の変更であればCSNでエントリの更新が可能だが、
エントリそのものが存在しなくなった場合CSNも削除されてしまう。
その場合、CSNだけでは削除には対応しきれない。
そこで、存在メッセージを返すようにしています。
このメッセージには変更されていない全てのエントリのUUIDを保持していて、
プロバイダから返されたUUIDの集合をコンシューマは自分のエントリのUUIDと比較して、
プロバイダから返されたUUIDの集合に存在していない(削除すべきエントリ)を見つける。
但しデメリットとして、コンシューマ側からの同期依頼は定期的なものになるため、
実際に変更がコンシューマに反映されるまでタイムラグが生じてしまう。
□ refreshAndPersistモード
このモードは基本原理で説明した動作では少し異なり、始めに同期依頼を発行。
その後、一連の複製処理が行われ同期すべきエントリをプロバイダから返された後でも、
接続を切断せずに維持し続けるのである。
その間プロバイダ側に変更が発生すると、プロバイダからコンシューマへ即時通知する。
但しデメリットとして、接続を維持し続けるのにプロバイダに負荷がかかる。
また、バックエンドとしてLDBMを使用している場合、
syncreplがデータベースをロックしてしまうためこのモードが制限されている。
以上がモードの説明になります。
機能概要としては以上。
ちなみに現行のOpenLDAPにはsync replication(以下syncrepl)と、
Ver2.2系まで主流であったslurpdという二つの複製手段が存在します。
違いは以下のような感じです。
slurpdとは、スレーブ側の複製専用のサービスのことです。
複製方法の流れとしては、マスターで更新が発生した際にslapdが更新情報をslapd.logと
いうログファイルに書き出します。これを複製サーバのslurpdが定期的に読み出し、更新が
ある場合は自分自身のslapdに適用し同期しているといった流れです。
ただslurpdにはいくつかの欠点があります。
まずslapd.logには更新情報しか書き出されないので、運用を始める前に予め
マスターとスレーブ間でデータの内容を一致させてあげなければいけません。
次に、マスターとスレーブ間で常に正しく同期されているかの保障がありません。
例えば、あるエントリの同期に失敗したとします。
失敗したこのエントリについてはリジェクトファイルというものに書き出されますが、
その後自動でこのファイルを再読み込みなどはしないので、
矛盾が発生した場合は手動でエントリを追加する事になります。
次は、新しい機能であるsyncreplについて。
syncreplでは、slurpdでいうマスターに相当するサーバを「プロバイダ」、
スレーブに相当するサーバを「コンシューマ」と呼びます。
slurpdと違い、複製の初期動作はコンシューマ側から発生する事になっていて、
コンシューマ側から予め設定されている指定に基づき、プロバイダ側へ検索を行います。
また、前回の複製からの変更情報を知る手立てとして、syncreplはcookieを使ってます。
プロバイダは複製が終ると、その度にCSNの現時点の最大値をcookieで返します。
CSNとはエントリそれぞれに存在するURL変更順番号の値の事で、プロバイダで
新規追加や既存エントリの更新が行われた際、現在の値よりも大きな値に変更されます。
コンシューマは複製時に検索条件と共に前回取得したcookie値を通知する事で、
プロバイダで通知されたcookie値よりも大きなCSNを持つエントリを複製すべきエントリ
として返す事が出来る、という仕組みです。
纏めると複製処理の流れは以下ような感じ。
1. コンシューマから検索条件と共に前回の複製時に受け取ったcookie値(CSN)を
プロバイダへ通知し、同期依頼をかける。
2. 同期依頼を受け取ったプロバイダは検索条件にマッチしたエントリを順に調べ、
通知されたcookieの値と現在のエントリのCSNを比較。
3. プロバイダは現在のエントリのCSNが通知されたcookie値よりも大きかったエン
トリを複製するエントリとしてコンシューマに応答。
4. 複製するエントリを受け取ったコンシューマは、自身のエントリをアップデート。
以上がsyncreplによる基本的な複製処理。
また、syncreplには二つの動作モードが存在し、以下の様な特徴がある。
□ refreshOnlyモード
コンシューマから、定期的に同期依頼をかける。
プロバイダで上記の流れに沿った複製処理が行われ、
更新すべきエントリを返す場合に、このモードは存在メッセージというものも同時に返す。
存在メッセージとは、削除されたエントリを識別するためのものです。
通常の変更であればCSNでエントリの更新が可能だが、
エントリそのものが存在しなくなった場合CSNも削除されてしまう。
その場合、CSNだけでは削除には対応しきれない。
そこで、存在メッセージを返すようにしています。
このメッセージには変更されていない全てのエントリのUUIDを保持していて、
プロバイダから返されたUUIDの集合をコンシューマは自分のエントリのUUIDと比較して、
プロバイダから返されたUUIDの集合に存在していない(削除すべきエントリ)を見つける。
但しデメリットとして、コンシューマ側からの同期依頼は定期的なものになるため、
実際に変更がコンシューマに反映されるまでタイムラグが生じてしまう。
□ refreshAndPersistモード
このモードは基本原理で説明した動作では少し異なり、始めに同期依頼を発行。
その後、一連の複製処理が行われ同期すべきエントリをプロバイダから返された後でも、
接続を切断せずに維持し続けるのである。
その間プロバイダ側に変更が発生すると、プロバイダからコンシューマへ即時通知する。
但しデメリットとして、接続を維持し続けるのにプロバイダに負荷がかかる。
また、バックエンドとしてLDBMを使用している場合、
syncreplがデータベースをロックしてしまうためこのモードが制限されている。
以上がモードの説明になります。
機能概要としては以上。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
今回はOpenSSHの公開鍵をLDAPで管理してみます。
通常の鍵認証の場合はまず公開鍵と秘密鍵を作成し、ログイン対象
サーバのホームディレクトリに公開鍵を置いてあげなければいけません。
数台であれば手間ではないですが、大規模なシステムでは非常に面倒。
また、新規にユーザーを追加する場合も全台に鍵を追加しなければならない。
そこで、公開鍵をLDAPで管理させログイン時にユーザ情報と一緒に鍵も読み出すようにする。
そうすれば対象サーバが増えようが新規ユーザー追加しようがそのサーバが
LDAPに対応してさえいれば一度の登録で全て事が済んでしまいます。
但しパッケージで入っているOpenSSHは公開鍵認証のLDAP化をサポートしていないので、
lpkパッチを当てたソースからインストールする事にします。
①. OpenSSHのインストール。
# tar zxvf openssh-4.6p1.tar.tar
# cd openssh-4.6p1.tar.tar
# patch -p2 < ../openssh-lpk-4.6p1-0.3.9.patch
# ./configure --prefix=/usr/local/ssh/ --with-ldap=/usr/local/ldap/lib/ --with-
pam --without-zlib-version-check
# make
# make install
以上でインストールの完了。
インストールしたOpenSSHが正常に動作するか確認。
②. 既存のsshdのストップ。
# /etc/init.d/sshd stop
③. 新規のsshdのスタート。
# /usr/local/ssh/sbin/sshd
④. プロセスの確認。
# ps aux | grep -i sshd
------------------------------------------------------------------------------------------
root 26872 0.4 0.0 5252 1028 ? Ss 15:27 0:00 /usr/local/ssh/sbin/sshd
------------------------------------------------------------------------------------------
⑤. 実際にログイン可能か確認する前に、テストユーザーの作成
# useradd testUser01
# passwd testUser01
⑥. 実際にログイン可能かsshで確認。
# ssh -l testUser01 localhost
------------------------------------------------------------------------------------------
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
testUser01@localhost's password:
[testUser01@localhost ~]
------------------------------------------------------------------------------------------
新sshdでログインできる事を確認。
次に、鍵をLDAPに登録する前にホームディレクトリに置く
通常通りの方式で鍵認証が出来るかどうか確認。
⑦. 鍵の作成。(パスフレーズを求められる)
# su - testUser01
# ssh-keygen -t rsa
-----------------------------------------------------------------------------------------
Generating public/private rsa key pair.
Enter file in which to save the key (/home/testUser01/.ssh/id_rsa):
Created directory '/home/testUser01/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/testUser01/.ssh/id_rsa.
Your public key has been saved in /home/testUser01/.ssh/id_rsa.pub.
The key fingerprint is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx testUser01@xxxxxxx
------------------------------------------------------------------------------------------
これで、/home/testUser01/.ssh/配下に、
id_rsa(秘密鍵)、id_rsa.pub(公開鍵)が作成される。
⑦. 公開鍵をサーバのホームディレクトリにコピー。
＃今回はクライアントとサーバを同じサーバとしているので単にリネーム
# cp id_rsa.pub /home/testUser01/.ssh/authorized_keys2
⑧. sshで確認。(パスフレーズを求められる)
# ssh localhost
------------------------------------------------------------------------
Enter passphrase for key '/home/testUser01/.ssh/id_rsa':
[testUser01@localhost ~]#
------------------------------------------------------------------------
公開鍵認証になっている事を確認。
次にLDAPへの登録。
まず、LDAPに公開鍵を登録する為にopenssh-lpk_openldap.schemaを読み込ませる。
このスキーマは、opensshのソースにパッチをあてると作成される。
⑨. スキーマファイルのコピー。
# cp -rp /usr/local/src/openssh-4.6p1/openssh-
lpk_openldap.schema /usr/local/ldap/etc/openldap/schema/
⑩. スキーマを読み込むようにslapd.confの編集。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/openssh-
lpk_openldap.shcema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑪. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad
次にtestUser01をLDAPに登録する。この時公開鍵も一緒に登録する。
⑫. 以下のldif(testUser01.ldif)ファイルを用意。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser01,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
objectClass: ldapPublickey
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword: devproxy
loginShell: /bin/bash
sshPublicKey: xxxxxxxxxxxxxxxxxxxxxxxxxxx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sshPublickey属性には先程コピーしたauthorized_keys2の中身をまるまるコピペする。
この時改行などが含まれないように注意。
⑬. testUser01.ldifをldapadd。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
testUser01.ldif
---------------------------------------------------------------------------
adding new entry "uid=testUser01,dc=my-domain,dc=com"
---------------------------------------------------------------------------
最後に、OpenSSHにLDAP関連の設定を行う。
⑭. /usr/local/ssh/etc/sshd_configへ以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UseLPK yes
LpkLdapConf /etc/ldap.conf
LpkServers ldap://LDAPサーバのIP/
LpkUserDN dc=my-domain,dc=com
LpkBindDN cn=Manager,dc=my-domain,dc=com
LpkBindPw secret
LpkForceTLS yes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上で設定は全て完了。
⑱. ローカルのtestUser01の削除
# userdel -r testUser01
ホームディレクトリごと削除する。
これで公開鍵はLDAPにのみ存在している。
さて、ここから動作確認です。
秘密鍵をwindows PCに退避させたのでそのままwindowsから確認してみます。
Tera Termを立ち上げ、LDAPサーバに対してSSH。
SSH Authenticationのポップアップが表示されたら、「Use RSA/DSA key to log in」に
チェックを入れ、「Private key file」に秘密鍵のrsaファイルを指定してあげます。
後はユーザー名にtestUser01、パスワードに設定したパスフレーズを入力すればOK。
以上で、正常にログイン出来ます。
ちなみにさっきローカルのユーザ消す時にホームディレクトリも一緒に消したので、
ログイン時にホームディレクトリが存在しないというエラーは表示されました。
ちょっとだけ補足：
最後の動作確認についてですが、puttyを使う場合はちょっとやり方が違います。
puttyはputty形式の鍵しか受け付けないため、ssh-keygenで作った鍵は使えません。
PuTTYgenを使用して作成した鍵を新たに登録する事になります。
PuTTYgenはWinSCPに付属でついているのでまずWinSCPをインストールします。
WinSCPをインストールすると、Key Toolsという中にPuTTYgenがあるのでそれを起動します。
「Generate」ボタンをクリックすると鍵の生成が始まるので、タスクバーが
すべて埋まるまで「Key」の枠中でマウスカーソルをひたすら動かします。
作成後にはパスフレーズを入力し、秘密鍵を「Save private key」から保存。
次に、公開鍵の中身が表示されているので、それをメモ帳などにコピペする。
この際、改行がされてないか注意。
後はコピペした公開鍵を上記と同じ手順でLDAPに登録すれば完了です。
通常の鍵認証の場合はまず公開鍵と秘密鍵を作成し、ログイン対象
サーバのホームディレクトリに公開鍵を置いてあげなければいけません。
数台であれば手間ではないですが、大規模なシステムでは非常に面倒。
また、新規にユーザーを追加する場合も全台に鍵を追加しなければならない。
そこで、公開鍵をLDAPで管理させログイン時にユーザ情報と一緒に鍵も読み出すようにする。
そうすれば対象サーバが増えようが新規ユーザー追加しようがそのサーバが
LDAPに対応してさえいれば一度の登録で全て事が済んでしまいます。
但しパッケージで入っているOpenSSHは公開鍵認証のLDAP化をサポートしていないので、
lpkパッチを当てたソースからインストールする事にします。
①. OpenSSHのインストール。
# tar zxvf openssh-4.6p1.tar.tar
# cd openssh-4.6p1.tar.tar
# patch -p2 < ../openssh-lpk-4.6p1-0.3.9.patch
# ./configure --prefix=/usr/local/ssh/ --with-ldap=/usr/local/ldap/lib/ --with-
pam --without-zlib-version-check
# make
# make install
以上でインストールの完了。
インストールしたOpenSSHが正常に動作するか確認。
②. 既存のsshdのストップ。
# /etc/init.d/sshd stop
③. 新規のsshdのスタート。
# /usr/local/ssh/sbin/sshd
④. プロセスの確認。
# ps aux | grep -i sshd
------------------------------------------------------------------------------------------
root 26872 0.4 0.0 5252 1028 ? Ss 15:27 0:00 /usr/local/ssh/sbin/sshd
------------------------------------------------------------------------------------------
⑤. 実際にログイン可能か確認する前に、テストユーザーの作成
# useradd testUser01
# passwd testUser01
⑥. 実際にログイン可能かsshで確認。
# ssh -l testUser01 localhost
------------------------------------------------------------------------------------------
The authenticity of host 'localhost (127.0.0.1)' can't be established.
RSA key fingerprint is xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (RSA) to the list of known hosts.
testUser01@localhost's password:
[testUser01@localhost ~]
------------------------------------------------------------------------------------------
新sshdでログインできる事を確認。
次に、鍵をLDAPに登録する前にホームディレクトリに置く
通常通りの方式で鍵認証が出来るかどうか確認。
⑦. 鍵の作成。(パスフレーズを求められる)
# su - testUser01
# ssh-keygen -t rsa
-----------------------------------------------------------------------------------------
Generating public/private rsa key pair.
Enter file in which to save the key (/home/testUser01/.ssh/id_rsa):
Created directory '/home/testUser01/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/testUser01/.ssh/id_rsa.
Your public key has been saved in /home/testUser01/.ssh/id_rsa.pub.
The key fingerprint is:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx testUser01@xxxxxxx
------------------------------------------------------------------------------------------
これで、/home/testUser01/.ssh/配下に、
id_rsa(秘密鍵)、id_rsa.pub(公開鍵)が作成される。
⑦. 公開鍵をサーバのホームディレクトリにコピー。
＃今回はクライアントとサーバを同じサーバとしているので単にリネーム
# cp id_rsa.pub /home/testUser01/.ssh/authorized_keys2
⑧. sshで確認。(パスフレーズを求められる)
# ssh localhost
------------------------------------------------------------------------
Enter passphrase for key '/home/testUser01/.ssh/id_rsa':
[testUser01@localhost ~]#
------------------------------------------------------------------------
公開鍵認証になっている事を確認。
次にLDAPへの登録。
まず、LDAPに公開鍵を登録する為にopenssh-lpk_openldap.schemaを読み込ませる。
このスキーマは、opensshのソースにパッチをあてると作成される。
⑨. スキーマファイルのコピー。
# cp -rp /usr/local/src/openssh-4.6p1/openssh-
lpk_openldap.schema /usr/local/ldap/etc/openldap/schema/
⑩. スキーマを読み込むようにslapd.confの編集。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/openssh-
lpk_openldap.shcema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑪. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad
次にtestUser01をLDAPに登録する。この時公開鍵も一緒に登録する。
⑫. 以下のldif(testUser01.ldif)ファイルを用意。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser01,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
objectClass: ldapPublickey
cn: devproxy
uid: devproxy
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/devproxy
userPassword: devproxy
loginShell: /bin/bash
sshPublicKey: xxxxxxxxxxxxxxxxxxxxxxxxxxx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sshPublickey属性には先程コピーしたauthorized_keys2の中身をまるまるコピペする。
この時改行などが含まれないように注意。
⑬. testUser01.ldifをldapadd。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
testUser01.ldif
---------------------------------------------------------------------------
adding new entry "uid=testUser01,dc=my-domain,dc=com"
---------------------------------------------------------------------------
最後に、OpenSSHにLDAP関連の設定を行う。
⑭. /usr/local/ssh/etc/sshd_configへ以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
UseLPK yes
LpkLdapConf /etc/ldap.conf
LpkServers ldap://LDAPサーバのIP/
LpkUserDN dc=my-domain,dc=com
LpkBindDN cn=Manager,dc=my-domain,dc=com
LpkBindPw secret
LpkForceTLS yes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上で設定は全て完了。
⑱. ローカルのtestUser01の削除
# userdel -r testUser01
ホームディレクトリごと削除する。
これで公開鍵はLDAPにのみ存在している。
さて、ここから動作確認です。
秘密鍵をwindows PCに退避させたのでそのままwindowsから確認してみます。
Tera Termを立ち上げ、LDAPサーバに対してSSH。
SSH Authenticationのポップアップが表示されたら、「Use RSA/DSA key to log in」に
チェックを入れ、「Private key file」に秘密鍵のrsaファイルを指定してあげます。
後はユーザー名にtestUser01、パスワードに設定したパスフレーズを入力すればOK。
以上で、正常にログイン出来ます。
ちなみにさっきローカルのユーザ消す時にホームディレクトリも一緒に消したので、
ログイン時にホームディレクトリが存在しないというエラーは表示されました。
ちょっとだけ補足：
最後の動作確認についてですが、puttyを使う場合はちょっとやり方が違います。
puttyはputty形式の鍵しか受け付けないため、ssh-keygenで作った鍵は使えません。
PuTTYgenを使用して作成した鍵を新たに登録する事になります。
PuTTYgenはWinSCPに付属でついているのでまずWinSCPをインストールします。
WinSCPをインストールすると、Key Toolsという中にPuTTYgenがあるのでそれを起動します。
「Generate」ボタンをクリックすると鍵の生成が始まるので、タスクバーが
すべて埋まるまで「Key」の枠中でマウスカーソルをひたすら動かします。
作成後にはパスフレーズを入力し、秘密鍵を「Save private key」から保存。
次に、公開鍵の中身が表示されているので、それをメモ帳などにコピペする。
この際、改行がされてないか注意。
後はコピペした公開鍵を上記と同じ手順でLDAPに登録すれば完了です。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
