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化まで書かれていているのが非常に役立つ。 |
今回はOpenLDAP Ver2.3からの機能であるppolicyオーバーレイを使用して、
LDAPのみで完結するパスワードポリシーを適用してみます。
Ver2.3系からppolicy用にppolicy.schemaという新しいスキーマが用意されており、
このスキーマを使用するとpwdPolicyというオブジェクトクラスを使用出来るようになります。
始めにパスワードポリシールールのエントリを追加。
これにはユーザー毎に個別のポリシーを作る方法と、
デフォルトのポリシーを作成して全ユーザーに適用する方法があります。
今回はデフォルトのポリシーのみを作成し、それを全ユーザーに適用してみます。
まずは、デフォルトのパスワードポリシーを作成。
①. デフォルトポリシールールを記述した、以下のldifファイル(ppolicy.ldif)を作成。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
dn: cn=default,ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword ← パスワードを格納属性の名前
pwdLockout: TRUE ← アカウントロックの有無
pwdMaxFailure: 3 ← アカウントロックまでの失敗回数
pwdLockoutDuration: 300 ← アカウントロック後、解除までの秒数
pwdCheckQuality: 2 ← パスワード構文チェック
pwdMinLength: 5 ← 最小パスワード文字数
pwdSafeModify: TRUE ← パスワード変更時、変更前パスワードの必要性
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pwdPolicyの属性はこの他にも存在するが、とりあえず以上。
オブジェクトクラスにdeviceというものを指定しているが、
これはpwdPolicyがAUXILISRY(補助クラス)であるために
これのみではエントリの追加が出来ないため。
エントリには必ずSTRUCTURAL(構造化クラス)が必要です。
そこで何か適当なSTRUCTURALオブジェクトを加えています。
必ずしもdeviceを指定する必要はないのですが、deviceは
MUST属性がcnだけなので余計な属性をつける必要ないのでこれにしました。
②. ldapaddで追加。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f ppolicy.ldif
-------------------------------------------------------------------------------------
adding new entry "ou=policies,dc=my-domain,dc=com"
adding new entry "cn=default,ou=policies,dc=my-domain,dc=com"
-------------------------------------------------------------------------------------
③. ldapsearchで検索。
# ldapsearch -x -ZZ -H ldap://LDAPサーバのIP/ -b 'dc=my-domain,dc=com'
---------------------------------------------------------------
# policies, my-domain.com
dn: ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
# standard, policies, my-domain.com
dn: cn=default,ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 300
pwdCheckQuality: 2
pwdMinLength: 5
pwdSafeModify: TRUE
# search result
search: 3
result: 0 Success
# numResponses: 10
# numEntries: 9
---------------------------------------------------------------
問題ない事を確認。
次に、サーバ側の設定。
④. slapd.confへ、以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/ppolicy.schema
～途中省略
database bdb
～途中省略
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=my-domain,dc=com"
(デフォルトポリシーの指定)
ppolicy_use_lockout
(アカウントがロックされている場合のエラー通知)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑤. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad -h ldap://LDAPサーバのIP or (ホスト名)/
以上で設定は完了。
次にldapsearch使ってアカウントロックの動作確認をしてみます。
但し、クライアントも当然Ver2.3以降のものを使用してください。
それ以下だとppolicyに未対応です。
⑥. ldapsearchがppolicyに対応しているか確認。
# /usr/local/ldap/bin/ldapsearch -h
--------------------------------------------------------------------------------------
～以上省略
-e [!][=] general extensions (! indicates criticality)
[!]assert= (an RFC 2254 Filter)
[!]authzid= ("dn:" or "u:")
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=] (a comma-separated attribute list)
[!]preread[=] (a comma-separated attribute list)
abandon, cancel (SIGINT sends abandon/cancel; not really controls)
～以下省略
--------------------------------------------------------------------------------------
対応していない場合、「-e」の拡張オプションにppolicyが表示されません。
⑦. ldapsearchのバインド時に、わざと失敗しアカウントをロックさせてみる。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w missmatch -e ppolicy
-------------------------------------------
ldap_bind: Invalid credentials (49)
-------------------------------------------
上記を連続して四回繰り返す。
pwdMaxFailureで３を指定しているが、３回目まで失敗が許されるという意味で
実際にアカウントがロックされるのは４回目を失敗したときになります。
⑧. 正規のパスワードでldapsearch。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w password -e ppolicy
----------------------------------------------------------------
ldap_bind: Invalid credentials (49); Account locked
----------------------------------------------------------------
Account lockedの表示がされてますね。
⑨. sshで実際にログインできない事を確認してみる。
# ssh -l testUser localhost
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied, please try again.
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied, please try again.
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied (publickey,gssapi-with-mic,password).
ログインできない事を確認。
pwdLockoutDurationで300(5分)を指定しているため、
一度アカウントがロックされると5分間はこのまま。
⑩．５分後、再度正規のパスワードでldapsearch。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w password -e ppolicy
--------------------------
～以上省略
# search result
search: 3
result: 0 Success
# numResponses: 10
# numEntries: 9
--------------------------
アカウントロックが解除され、正常に検索結果が取得できている。
次に、パスワード変更に関する動作確認。
その前にtestUser自身にuserPassword属性の変更を許可させるため、
ACLの設定を変更しておきます。
⑪. slapd.confに以下を追記。
~~~~~~~~~~~~~~~~~~~
access to attr=userPassword
by self write
by * auth
access to *
by self write
by * auth
~~~~~~~~~~~~~~~~~~~
⑫. slapdを再起動しておく。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad -h ldap://LDAPサーバのIP or (ホスト名)/
ここから動作確認。
今回パスワード関連で設定しているのは最小文字列数、
変更前に旧パスワードの入力と、パスワード構文チェックの三つである。
まずは、変更前旧パスワードの入力について確認。
⑪. ldappasswdを使用してパスワードの変更を行ってみる。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w password -S -e ppolicy
--------------------------------------------------------------------------------------------
New password: ← testUserと入力
Re-enter new password: ← testUserと入力
Result: Insufficient access (50)
Additional info: Must supply old password to be changed as well as new one
--------------------------------------------------------------------------------------------
変更前に旧パスワードの入力がないため、パスワードの変更に失敗してます。
ちなみにldappasswdはパスワード変更したいエントリでバインドし、
「-S」オプションは新パスワード入力のプロンプトを表示させます。
⑫. 旧パスワード入力を求め「-A」オプションをつけ、再度ldappasswd。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w password -A -S -e ppolicy
----------------------------------------------------------
Old password: ← passwordと入力
Re-enter old password: ← passwordと入力
New password: ← testUserと入力
Re-enter new password: ← testUserと入力
Result: Success (0)
----------------------------------------------------------
パスワード変更が正常に行われました。
⑬. 実際にsshで新パスワードでログインできるか確認。
# ssh -l testUser localhost
-----------------------------------------------------------------
testUser@localhost's password: ← testUserと入力
Last login: Wed Nov 7 15:26:13 2007 from ldap-client
-----------------------------------------------------------------
新パスワードでログインできることを確認。
次に、最小文字列に対する動作確認。
⑭. ldappasswdにてパスワード変更。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w testUser -A -S -e ppolicy
---------------------------------------------------------------------
Old password: ← testUserと入力
Re-enter old password: ← testUserと入力
New password: ← testと入力
Re-enter new password: ← testと入力
Result: Constraint violation (19)
Additional info: Password fails quality checking policy
--------------------------------------------------------------------
新パスワード文字列がpwdMinLengthで指定した５文字以下なので変更に失敗。
⑮. 再度、ldappasswd。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w testUser -A -S -e ppolicy
---------------------------------------------------------
Old password: ← testUserと入力
Re-enter old password: ← testUserと入力
New password: ← passwordと入力
Re-enter new password: ← passwordと入力
Result: Success (0)
---------------------------------------------------------
新パスワード文字列がpwdMinLengthで指定した５文字以上なので変更に成功。
これで動作確認は完了。
最後にちょっとだけ補足：
pwdPolicyでは今回設定したもの以外にパスワードの有効期限などの設定も可能。
但し、パスワードポリシーの使用には現状制限があり、ver2.3(ppolicyに対応した)
ldapクライアントコマンドを使用しなければ、応答制御が解析できないらしいです。
なので、nss_ldapをつかうsshやsuではPermission deniedやincorrect passwordと
表示されるだけで、アカウントがロックされているという事を知る術がありません。。
LDAPのみで完結するパスワードポリシーを適用してみます。
Ver2.3系からppolicy用にppolicy.schemaという新しいスキーマが用意されており、
このスキーマを使用するとpwdPolicyというオブジェクトクラスを使用出来るようになります。
始めにパスワードポリシールールのエントリを追加。
これにはユーザー毎に個別のポリシーを作る方法と、
デフォルトのポリシーを作成して全ユーザーに適用する方法があります。
今回はデフォルトのポリシーのみを作成し、それを全ユーザーに適用してみます。
まずは、デフォルトのパスワードポリシーを作成。
①. デフォルトポリシールールを記述した、以下のldifファイル(ppolicy.ldif)を作成。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
dn: cn=default,ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword ← パスワードを格納属性の名前
pwdLockout: TRUE ← アカウントロックの有無
pwdMaxFailure: 3 ← アカウントロックまでの失敗回数
pwdLockoutDuration: 300 ← アカウントロック後、解除までの秒数
pwdCheckQuality: 2 ← パスワード構文チェック
pwdMinLength: 5 ← 最小パスワード文字数
pwdSafeModify: TRUE ← パスワード変更時、変更前パスワードの必要性
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
pwdPolicyの属性はこの他にも存在するが、とりあえず以上。
オブジェクトクラスにdeviceというものを指定しているが、
これはpwdPolicyがAUXILISRY(補助クラス)であるために
これのみではエントリの追加が出来ないため。
エントリには必ずSTRUCTURAL(構造化クラス)が必要です。
そこで何か適当なSTRUCTURALオブジェクトを加えています。
必ずしもdeviceを指定する必要はないのですが、deviceは
MUST属性がcnだけなので余計な属性をつける必要ないのでこれにしました。
②. ldapaddで追加。
# ldapadd -x -ZZ -D "cn=Manager,dc=my-domain,dc=com" -w secret -f ppolicy.ldif
-------------------------------------------------------------------------------------
adding new entry "ou=policies,dc=my-domain,dc=com"
adding new entry "cn=default,ou=policies,dc=my-domain,dc=com"
-------------------------------------------------------------------------------------
③. ldapsearchで検索。
# ldapsearch -x -ZZ -H ldap://LDAPサーバのIP/ -b 'dc=my-domain,dc=com'
---------------------------------------------------------------
# policies, my-domain.com
dn: ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: organizationalUnit
ou: policies
# standard, policies, my-domain.com
dn: cn=default,ou=policies,dc=my-domain,dc=com
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: userPassword
pwdLockout: TRUE
pwdMaxFailure: 3
pwdLockoutDuration: 300
pwdCheckQuality: 2
pwdMinLength: 5
pwdSafeModify: TRUE
# search result
search: 3
result: 0 Success
# numResponses: 10
# numEntries: 9
---------------------------------------------------------------
問題ない事を確認。
次に、サーバ側の設定。
④. slapd.confへ、以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/ppolicy.schema
～途中省略
database bdb
～途中省略
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=my-domain,dc=com"
(デフォルトポリシーの指定)
ppolicy_use_lockout
(アカウントがロックされている場合のエラー通知)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑤. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad -h ldap://LDAPサーバのIP or (ホスト名)/
以上で設定は完了。
次にldapsearch使ってアカウントロックの動作確認をしてみます。
但し、クライアントも当然Ver2.3以降のものを使用してください。
それ以下だとppolicyに未対応です。
⑥. ldapsearchがppolicyに対応しているか確認。
# /usr/local/ldap/bin/ldapsearch -h
--------------------------------------------------------------------------------------
～以上省略
-e [!]
[!]assert=
[!]authzid=
[!]manageDSAit
[!]noop
ppolicy
[!]postread[=
[!]preread[=
abandon, cancel (SIGINT sends abandon/cancel; not really controls)
～以下省略
--------------------------------------------------------------------------------------
対応していない場合、「-e」の拡張オプションにppolicyが表示されません。
⑦. ldapsearchのバインド時に、わざと失敗しアカウントをロックさせてみる。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w missmatch -e ppolicy
-------------------------------------------
ldap_bind: Invalid credentials (49)
-------------------------------------------
上記を連続して四回繰り返す。
pwdMaxFailureで３を指定しているが、３回目まで失敗が許されるという意味で
実際にアカウントがロックされるのは４回目を失敗したときになります。
⑧. 正規のパスワードでldapsearch。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w password -e ppolicy
----------------------------------------------------------------
ldap_bind: Invalid credentials (49); Account locked
----------------------------------------------------------------
Account lockedの表示がされてますね。
⑨. sshで実際にログインできない事を確認してみる。
# ssh -l testUser localhost
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied, please try again.
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied, please try again.
testUser@localhost's password: ← 正規のパスワードを入力
Permission denied (publickey,gssapi-with-mic,password).
ログインできない事を確認。
pwdLockoutDurationで300(5分)を指定しているため、
一度アカウントがロックされると5分間はこのまま。
⑩．５分後、再度正規のパスワードでldapsearch。
# /usr/local/ldap/bin/ldapsearch -x -ZZ -b 'dc=my-domain,dc=com' -D \
"uid=testUser,dc=my-domain,dc=com" -w password -e ppolicy
--------------------------
～以上省略
# search result
search: 3
result: 0 Success
# numResponses: 10
# numEntries: 9
--------------------------
アカウントロックが解除され、正常に検索結果が取得できている。
次に、パスワード変更に関する動作確認。
その前にtestUser自身にuserPassword属性の変更を許可させるため、
ACLの設定を変更しておきます。
⑪. slapd.confに以下を追記。
~~~~~~~~~~~~~~~~~~~
access to attr=userPassword
by self write
by * auth
access to *
by self write
by * auth
~~~~~~~~~~~~~~~~~~~
⑫. slapdを再起動しておく。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad -h ldap://LDAPサーバのIP or (ホスト名)/
ここから動作確認。
今回パスワード関連で設定しているのは最小文字列数、
変更前に旧パスワードの入力と、パスワード構文チェックの三つである。
まずは、変更前旧パスワードの入力について確認。
⑪. ldappasswdを使用してパスワードの変更を行ってみる。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w password -S -e ppolicy
--------------------------------------------------------------------------------------------
New password: ← testUserと入力
Re-enter new password: ← testUserと入力
Result: Insufficient access (50)
Additional info: Must supply old password to be changed as well as new one
--------------------------------------------------------------------------------------------
変更前に旧パスワードの入力がないため、パスワードの変更に失敗してます。
ちなみにldappasswdはパスワード変更したいエントリでバインドし、
「-S」オプションは新パスワード入力のプロンプトを表示させます。
⑫. 旧パスワード入力を求め「-A」オプションをつけ、再度ldappasswd。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w password -A -S -e ppolicy
----------------------------------------------------------
Old password: ← passwordと入力
Re-enter old password: ← passwordと入力
New password: ← testUserと入力
Re-enter new password: ← testUserと入力
Result: Success (0)
----------------------------------------------------------
パスワード変更が正常に行われました。
⑬. 実際にsshで新パスワードでログインできるか確認。
# ssh -l testUser localhost
-----------------------------------------------------------------
testUser@localhost's password: ← testUserと入力
Last login: Wed Nov 7 15:26:13 2007 from ldap-client
-----------------------------------------------------------------
新パスワードでログインできることを確認。
次に、最小文字列に対する動作確認。
⑭. ldappasswdにてパスワード変更。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w testUser -A -S -e ppolicy
---------------------------------------------------------------------
Old password: ← testUserと入力
Re-enter old password: ← testUserと入力
New password: ← testと入力
Re-enter new password: ← testと入力
Result: Constraint violation (19)
Additional info: Password fails quality checking policy
--------------------------------------------------------------------
新パスワード文字列がpwdMinLengthで指定した５文字以下なので変更に失敗。
⑮. 再度、ldappasswd。
# /usr/local/ldap/bin/ldappasswd -x -ZZ -D "uid=testUser,dc=my-domain,dc=com" -w testUser -A -S -e ppolicy
---------------------------------------------------------
Old password: ← testUserと入力
Re-enter old password: ← testUserと入力
New password: ← passwordと入力
Re-enter new password: ← passwordと入力
Result: Success (0)
---------------------------------------------------------
新パスワード文字列がpwdMinLengthで指定した５文字以上なので変更に成功。
これで動作確認は完了。
最後にちょっとだけ補足：
pwdPolicyでは今回設定したもの以外にパスワードの有効期限などの設定も可能。
但し、パスワードポリシーの使用には現状制限があり、ver2.3(ppolicyに対応した)
ldapクライアントコマンドを使用しなければ、応答制御が解析できないらしいです。
なので、nss_ldapをつかうsshやsuではPermission deniedやincorrect passwordと
表示されるだけで、アカウントがロックされているという事を知る術がありません。。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
今回はautofs + NFS + LDAPを使用してホームディレクトリの一元管理化を行います。
LDAPの設定は全て済んでいて正常に動作しているものとします。
また、NFSはLDAPサーバ上に構築します。
まず、手動でNFSをマウント出来るように設定。
①. NFSサーバの/etc/exportsに以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home *(rw) ← アクセス制限なし(かける場合は"許可するIP/ネットマスク")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
②. 以下サービスを順に再起動。ついでに自動起動の設定。
# /etc/init.d/portmap restart
# /etc/init.d/nfslock restart
# /etc/init.d/nfs restart
# chkconfig --level 345 portmap on
# chkconfig --level 345 nfslock on
# chkconfig --level 345 nfs on
③. testUserのホームディレクトリを作成。
# mkdir /home/testUser
# cp -rp /etc/skel/.bash* /home/testUser/ ←環境変数系のファイルコピー
# chown -R testUser /home/testUser
④. クライアント側でNFS mountしてみる。
# mount -t nfs "NFSサーバのIP":/home/testUser /home/
⑤. mountコマンドで確認。
# mount
------------------------------------------------------------------------------------------
"サーバのIP":/home/testUser/ on /home type nfs (rw,addr="サーバのIP")
------------------------------------------------------------------------------------------
手動でNFSマウント出来ることを確認。以上で、NFSサーバの設定は完了。
次に、autofsの設定。
但しソースからOpenLdapをインストールしているとautofs.schemaが
存在していないので適当にどっかから引っ張ってくる。
ちなみに僕はopenldap-serverのrpmを一度インストールして、
autofs.schemaをコピーしました。コピー後rpmは削除します。
⑧. autofs.schemaを読み込むようにslapd.confへ以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/autofs.schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑨. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/etc/openldap/slapd.pid`
# /usr/local/ldap/libexec/slpad
⑩. 次に、autofs情報をLDAPに入れ込むために以下のldifファイル(autofs.ldif)を作成。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn:ou=auto.master,dc=my-domain,dc=com ← auto.masterの情報
ou: auto.master
objectClass: top
objectClass: automountMap
dn: cn=/home,ou=auto.master,dc=my-domain,dc=com
objectClass: top
objectClass: automount
automountInformation: ldap:ou=auto.home,dc=my-domain,dc=com
cn: /home
dn: ou=auto.home,dc=my-domain,dc=com ← auto.homeの情報
ou: auto.home
objectClass: top
objectClass: organizationalUnit
dn: cn=/,ou=auto.home,dc=my-domain,dc=com
objectClass: top
objectClass: automount
description: generic home directory
automountInformation: -rw,fstype=nfs,soft,intr "LDAPサーバのIP":/home/&
cn: /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑪. ldapaddで登録。
# ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f autofs.ldif
----------------------------------------------------------------------------------------
adding new entry "ou=auto.master,dc=my-domain,dc=com"
adding new entry "cn=/home,ou=auto.master,dc=my-domain,dc=com"
adding new entry "ou=auto.home,dc=my-domain,dc=com"
adding new entry "cn=/,ou=auto.home,dc=my-domain,dc=com"
----------------------------------------------------------------------------------------
以上でautofsの設定も完了。動作確認をしてみる。
⑫. クライアントからsuもしくはssh(自分宛)でtestUserになり、mountコマンド実行。
＃クライアント側でautofsのサービス再起動、もしくはリロードしてから
# mount
--------------------------------------------------------------------------------------------
"サーバのIP":/home/testUser on /home/testUser ～ ,intr,addr="サーバのIP)
--------------------------------------------------------------------------------------------
正常にNFS + automountされている事を確認。
これでLDAPユーザでログインすると、サーバからNFS経由でautmountしてくれる。
新規にユーザ追加した場合はLDAPサーバ上でホームディレクトリ作成するだけでOK。
LDAPの設定は全て済んでいて正常に動作しているものとします。
また、NFSはLDAPサーバ上に構築します。
まず、手動でNFSをマウント出来るように設定。
①. NFSサーバの/etc/exportsに以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home *(rw) ← アクセス制限なし(かける場合は"許可するIP/ネットマスク")
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
②. 以下サービスを順に再起動。ついでに自動起動の設定。
# /etc/init.d/portmap restart
# /etc/init.d/nfslock restart
# /etc/init.d/nfs restart
# chkconfig --level 345 portmap on
# chkconfig --level 345 nfslock on
# chkconfig --level 345 nfs on
③. testUserのホームディレクトリを作成。
# mkdir /home/testUser
# cp -rp /etc/skel/.bash* /home/testUser/ ←環境変数系のファイルコピー
# chown -R testUser /home/testUser
④. クライアント側でNFS mountしてみる。
# mount -t nfs "NFSサーバのIP":/home/testUser /home/
⑤. mountコマンドで確認。
# mount
------------------------------------------------------------------------------------------
"サーバのIP":/home/testUser/ on /home type nfs (rw,addr="サーバのIP")
------------------------------------------------------------------------------------------
手動でNFSマウント出来ることを確認。以上で、NFSサーバの設定は完了。
次に、autofsの設定。
但しソースからOpenLdapをインストールしているとautofs.schemaが
存在していないので適当にどっかから引っ張ってくる。
ちなみに僕はopenldap-serverのrpmを一度インストールして、
autofs.schemaをコピーしました。コピー後rpmは削除します。
⑧. autofs.schemaを読み込むようにslapd.confへ以下を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
include /usr/local/ldap/etc/openldap/schema/autofs.schema
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑨. slapdの再起動。
# kill -HUP `cat /usr/local/ldap/etc/openldap/slapd.pid`
# /usr/local/ldap/libexec/slpad
⑩. 次に、autofs情報をLDAPに入れ込むために以下のldifファイル(autofs.ldif)を作成。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn:ou=auto.master,dc=my-domain,dc=com ← auto.masterの情報
ou: auto.master
objectClass: top
objectClass: automountMap
dn: cn=/home,ou=auto.master,dc=my-domain,dc=com
objectClass: top
objectClass: automount
automountInformation: ldap:ou=auto.home,dc=my-domain,dc=com
cn: /home
dn: ou=auto.home,dc=my-domain,dc=com ← auto.homeの情報
ou: auto.home
objectClass: top
objectClass: organizationalUnit
dn: cn=/,ou=auto.home,dc=my-domain,dc=com
objectClass: top
objectClass: automount
description: generic home directory
automountInformation: -rw,fstype=nfs,soft,intr "LDAPサーバのIP":/home/&
cn: /
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⑪. ldapaddで登録。
# ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f autofs.ldif
----------------------------------------------------------------------------------------
adding new entry "ou=auto.master,dc=my-domain,dc=com"
adding new entry "cn=/home,ou=auto.master,dc=my-domain,dc=com"
adding new entry "ou=auto.home,dc=my-domain,dc=com"
adding new entry "cn=/,ou=auto.home,dc=my-domain,dc=com"
----------------------------------------------------------------------------------------
以上でautofsの設定も完了。動作確認をしてみる。
⑫. クライアントからsuもしくはssh(自分宛)でtestUserになり、mountコマンド実行。
＃クライアント側でautofsのサービス再起動、もしくはリロードしてから
# mount
--------------------------------------------------------------------------------------------
"サーバのIP":/home/testUser on /home/testUser ～ ,intr,addr="サーバのIP)
--------------------------------------------------------------------------------------------
正常にNFS + automountされている事を確認。
これでLDAPユーザでログインすると、サーバからNFS経由でautmountしてくれる。
新規にユーザ追加した場合はLDAPサーバ上でホームディレクトリ作成するだけでOK。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
最近ESX3.0とVC2.0で運用していたシステムに新たにESX3.5を追加する事になりました。
VC2.0ではESX3.5と通信が出来ないのでVC2.5にあげる必要があります。
アップデート自体は問題なく終了、しかし既存のESX3.0Hostとの通信が出来てない模様。
仕方なく手動でconnectして見た所、下記のエラーポップアップが。
Failed to install the VirtualCenter Agent service
どうやらESX3.0のVCAgentとVC2.5はそのままでは通信が出来なくて、
ESX3.0のVCAgentをアップデートしなければならなかったらしい。
しかし、本来であればESX3.0からVC2.5への初回の
通信で自動的にVCAgentがアップデートされるはず。
アップデートされなかった原因はどうやらバグらしい。
修正パッチも出ていたようですが、
今回は手動でVCAgentをアップデートしました。
以下手順を覚え書き。
①. VCサーバ上にアップデートモジュールがあるのでそれをESXへコピー。(/tmpにでも)
C:\Program Files\VMware\Infrastructure\VirtualCenter Server\upgrade\
vpx-upgrade-esx-6-linux-64192
(ちなみにバージョンはいくつかあるので環境に合わせてください)
②. mgmt-vmwareとvmware-vpxaサービスの停止。
# /etc/init.d/mgmt-vmware stop
# /etc/init.d/vmware-vpxa stop
(この時、GuestOSの自動起動は切っておかなければGuestOSのrebootが発生します)
VMware Knowledgebase Document
③. VCAgentのアップグレードモジュールをインストール。
# sh vpx-upgrade-esx-6-linux-64192
# rpm -Uvh vpx-upgrade-installer/VMware-vpxa-2.5.0-64192.i386.rpm
④. /var/log/vmware/vpxa.log辺りで正常にインストールされているか確認。
⑤. mgmt-vmwareとvmware-vpxaサービスの起動。
# /etc/init.d/mgmt-vmware start
# /etc/init.d/vmware-vpxa start
⑥. VCからホストを再登録して完了。
以上です。
ちなみに③もバグで、こっちも修正パッチが出てました。
VC2.0ではESX3.5と通信が出来ないのでVC2.5にあげる必要があります。
アップデート自体は問題なく終了、しかし既存のESX3.0Hostとの通信が出来てない模様。
仕方なく手動でconnectして見た所、下記のエラーポップアップが。
Failed to install the VirtualCenter Agent service
どうやらESX3.0のVCAgentとVC2.5はそのままでは通信が出来なくて、
ESX3.0のVCAgentをアップデートしなければならなかったらしい。
しかし、本来であればESX3.0からVC2.5への初回の
通信で自動的にVCAgentがアップデートされるはず。
アップデートされなかった原因はどうやらバグらしい。
修正パッチも出ていたようですが、
今回は手動でVCAgentをアップデートしました。
以下手順を覚え書き。
①. VCサーバ上にアップデートモジュールがあるのでそれをESXへコピー。(/tmpにでも)
C:\Program Files\VMware\Infrastructure\VirtualCenter Server\upgrade\
vpx-upgrade-esx-6-linux-64192
(ちなみにバージョンはいくつかあるので環境に合わせてください)
②. mgmt-vmwareとvmware-vpxaサービスの停止。
# /etc/init.d/mgmt-vmware stop
# /etc/init.d/vmware-vpxa stop
(この時、GuestOSの自動起動は切っておかなければGuestOSのrebootが発生します)
VMware Knowledgebase Document
③. VCAgentのアップグレードモジュールをインストール。
# sh vpx-upgrade-esx-6-linux-64192
# rpm -Uvh vpx-upgrade-installer/VMware-vpxa-2.5.0-64192.i386.rpm
④. /var/log/vmware/vpxa.log辺りで正常にインストールされているか確認。
⑤. mgmt-vmwareとvmware-vpxaサービスの起動。
# /etc/init.d/mgmt-vmware start
# /etc/init.d/vmware-vpxa start
⑥. VCからホストを再登録して完了。
以上です。
ちなみに③もバグで、こっちも修正パッチが出てました。
以前に機能概要を纏めてみたsyncreplですが、今回は実際に設定してみます。
ちなみにモードはrefreshAndPersistで行います。
まずはプロバイダ側の設定。
slapdをプロバイダとして動作させるのに、syncproveを有効にします。
①. slapd.confのBDBデータベースディレクティブへ、以下の内容を追記。
~~~~~~~~~~~
overlay syncprov
~~~~~~~~~~~
他にオプションとしてセッショログの指定やメモリ上で管理しているCSNを
データベースに書き出すタイミングなども指定できるが今回は特に指定しません。
②. slapdを再起動する。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad
次に、コンシューマ側の設定。
コンシューマ側のサーバはプロバイダ側のサーバと同じ環境で構築してあるものとする。
但し、エントリについては初期同期によって作成されるため、データは空で構いません。
③. slapd.confのBDBデータベースディレクティブへ、以下の内容を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
syncrepl rid=001 ← IDを指定。0以上3桁以内。
provider=ldap://LDAPサーバのIP:389 ← プロバイダのURI
type=refreshAndPersist ← モード
searchbase="dc=my-domain,dc=com" ← 検索ベース
filter="(objectClass=*)" ← 検索フィルタ
scope=sub ← 検索スコープ
attrs="*" ← 取得する属性
schemachecking=off ← 複製エントリのスキーマチェック
bindmethod=simple ← バインド時の認証方法
binddn="cn=Manager,dc=my-domain,dc=com" ← バインドDN
credentials=secret ← バインドDNのパスワード
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上でコンシューマ側の設定も完了。
この中で必須なのは"rid"と"provider"のみであるが、一般的な設定をしてみました。
また、tlsやsaslなどを使用している場合はそれ用の設定が必用になります。
④. コンシューマ側のslapdを起動する。
# /usr/local/ldap/libexec/slapd
refreshAndPersistモードの場合、コンシューマを起動した時点ですぐに初期同期が発生。
プロバイダに大量のエントリが存在している場合は同期に時間がかかるため、
slurpdの時のように予めプロバイダ側のエントリをslapcatなどで抜き出し、
コンシューマ側にslapaddしておくなどした方が早いです。
⑤. コンシューマとプロバイダのエントリが同期されているか、ldapsearchで調べてみる。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
プロバイダとコンシューマでエントリ数が一致しています。
正常に同期されていることを確認できました。
以上で初期同期が完了です。
次に、プロバイダ側でエントリの追加、更新、削除を行い、
コンシューマへ即時反映されていることを確認してみる。
まずは追加。
⑥. 以下のldifファイル(replicatest1.ldif)を用意し、ldapadd。
~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword: password
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
replicatest1.ldif
------------------------------------------------------------------------
adding new entry "uid=testUser2,dc=my-domain,dc=com"
------------------------------------------------------------------------
⑦. ldapsearchでプロバイダ、コンシューマ共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
追加したエントリが正常に同期されている事を確認。
次に、エントリが更新された場合。
⑧. 先程のldifファイル(replicatest1.ldif)のgid部分を編集し、ldapmodify。
~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10002
homeDirectory: /home/testUser2
userPassword: password
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ldapmodify -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
replicatest1.ldif
------------------------------------------------------------------------
modifying entry "uid=testUser2,dc=my-domain,dc=com"
------------------------------------------------------------------------
⑨. ldapsearchでプロバイダ、コンシューマに共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10002
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
gidがプロバイダ、コンシューマ共に変更されている事を確認。
これで変更についても正常に同期される事を確認出来ましたね。
最後に、エントリの削除。
⑩. 先程作成したtestUser2をldapdelete。
# ldapdelete -x uid=testUser2,dc=my-domain,dc=com -D \
"cn=Manager,dc=my-domain,dc=com" -w secret
⑪. プロバイダ、コンシューマ共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
プロバイダ、コンシューマ共にエントリ数が一つ減っています。
削除についても正常に同期される事を確認出来ました。
以上でsync replicationについての設定は完了です。
ちなみにモードはrefreshAndPersistで行います。
まずはプロバイダ側の設定。
slapdをプロバイダとして動作させるのに、syncproveを有効にします。
①. slapd.confのBDBデータベースディレクティブへ、以下の内容を追記。
~~~~~~~~~~~
overlay syncprov
~~~~~~~~~~~
他にオプションとしてセッショログの指定やメモリ上で管理しているCSNを
データベースに書き出すタイミングなども指定できるが今回は特に指定しません。
②. slapdを再起動する。
# kill -HUP `cat /usr/local/ldap/var/run/slapd.pid`
# /usr/local/ldap/libexec/slpad
次に、コンシューマ側の設定。
コンシューマ側のサーバはプロバイダ側のサーバと同じ環境で構築してあるものとする。
但し、エントリについては初期同期によって作成されるため、データは空で構いません。
③. slapd.confのBDBデータベースディレクティブへ、以下の内容を追記。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
syncrepl rid=001 ← IDを指定。0以上3桁以内。
provider=ldap://LDAPサーバのIP:389 ← プロバイダのURI
type=refreshAndPersist ← モード
searchbase="dc=my-domain,dc=com" ← 検索ベース
filter="(objectClass=*)" ← 検索フィルタ
scope=sub ← 検索スコープ
attrs="*" ← 取得する属性
schemachecking=off ← 複製エントリのスキーマチェック
bindmethod=simple ← バインド時の認証方法
binddn="cn=Manager,dc=my-domain,dc=com" ← バインドDN
credentials=secret ← バインドDNのパスワード
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
以上でコンシューマ側の設定も完了。
この中で必須なのは"rid"と"provider"のみであるが、一般的な設定をしてみました。
また、tlsやsaslなどを使用している場合はそれ用の設定が必用になります。
④. コンシューマ側のslapdを起動する。
# /usr/local/ldap/libexec/slapd
refreshAndPersistモードの場合、コンシューマを起動した時点ですぐに初期同期が発生。
プロバイダに大量のエントリが存在している場合は同期に時間がかかるため、
slurpdの時のように予めプロバイダ側のエントリをslapcatなどで抜き出し、
コンシューマ側にslapaddしておくなどした方が早いです。
⑤. コンシューマとプロバイダのエントリが同期されているか、ldapsearchで調べてみる。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
プロバイダとコンシューマでエントリ数が一致しています。
正常に同期されていることを確認できました。
以上で初期同期が完了です。
次に、プロバイダ側でエントリの追加、更新、削除を行い、
コンシューマへ即時反映されていることを確認してみる。
まずは追加。
⑥. 以下のldifファイル(replicatest1.ldif)を用意し、ldapadd。
~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword: password
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ldapadd -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
replicatest1.ldif
------------------------------------------------------------------------
adding new entry "uid=testUser2,dc=my-domain,dc=com"
------------------------------------------------------------------------
⑦. ldapsearchでプロバイダ、コンシューマ共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
追加したエントリが正常に同期されている事を確認。
次に、エントリが更新された場合。
⑧. 先程のldifファイル(replicatest1.ldif)のgid部分を編集し、ldapmodify。
~~~~~~~~~~~~~~~~~~~~~~~~~~~
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10002
homeDirectory: /home/testUser2
userPassword: password
loginShell: /bin/bash
~~~~~~~~~~~~~~~~~~~~~~~~~~~
# ldapmodify -x -D "cn=Manager,dc=my-domain,dc=com" -w secret -f
replicatest1.ldif
------------------------------------------------------------------------
modifying entry "uid=testUser2,dc=my-domain,dc=com"
------------------------------------------------------------------------
⑨. ldapsearchでプロバイダ、コンシューマに共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10002
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
----------------------------------------------------
～途中省略
# testUser2, my-domain.com
dn: uid=testUser2,dc=my-domain,dc=com
objectClass: account
objectClass: posixAccount
cn: testUser2
uid: testUser2
uidNumber: 10001
gidNumber: 10001
homeDirectory: /home/testUser2
userPassword:: cGFzc3dvcmQ=
loginShell: /bin/bash
～以下省略
----------------------------------------------------
gidがプロバイダ、コンシューマ共に変更されている事を確認。
これで変更についても正常に同期される事を確認出来ましたね。
最後に、エントリの削除。
⑩. 先程作成したtestUser2をldapdelete。
# ldapdelete -x uid=testUser2,dc=my-domain,dc=com -D \
"cn=Manager,dc=my-domain,dc=com" -w secret
⑪. プロバイダ、コンシューマ共に確認。
# ldapsearch -x -b 'dc=my-domain,dc=com' -h プロバイダのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
# ldapsearch -x -b 'dc=my-domain,dc=com' -h コンシューマのIP
--------------------------
～途中省略
# search result
search: 2
result: 0 Success
# numResponses: 8
# numEntries: 7
--------------------------
プロバイダ、コンシューマ共にエントリ数が一つ減っています。
削除についても正常に同期される事を確認出来ました。
以上でsync replicationについての設定は完了です。
| LDAP Super Expert (2006/04/11) 編集部 商品詳細を見る OpenLDAP ver2.3の新機能などについて詳しく書かれている。またいくつかのミドルウェア連携の他、OpenSSH鍵認証LDAP化やsudoのLDAP化まで書かれていているのが非常に役立つ。 |
| ホーム |
