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化まで書かれていているのが非常に役立つ。 |
スポンサーサイト
0
0
| ホーム |
