Hi, list
Now we are using ldap-tree for auth several services on many hosts. We have two types of admins (admin1 and admin2 roles) and I want separate permissions: - admin1 can edit cn=usergroup1, but can't edit cn=usergroup2. - admin2 can edit both. (I know how I can do it).
Next. User can be registered in both groups, or just in one. We are developing our own ldap admin-tool for usermanagement. When user gone, we removing his id from all groups and lock his account. Usualy, this is work for admin1.
We need this behavior of our tool: If we can't remove user id from some group (inusufficient access), we do nothing. Just answer to admin1 "You can't remove user from group2 -- ask admin2".
For this behavior we need either transactions or some easy way to check our access rights for all entries which we want to modify.
Afaik, transactions are not feasible for our case. What about checking access rights on client side without performing modification itself?
WBR
LDAP Transactions and their implementation in slapd(8) is very much a work in progress (... or maybe said "a work not making much progress)...
At 02:43 AM 10/5/2006, Dmitriy Kirhlarov wrote:
Hi, list
Now we are using ldap-tree for auth several services on many hosts. We have two types of admins (admin1 and admin2 roles) and I want separate permissions:
- admin1 can edit cn=usergroup1, but can't edit cn=usergroup2.
- admin2 can edit both.
(I know how I can do it).
Next. User can be registered in both groups, or just in one. We are developing our own ldap admin-tool for usermanagement. When user gone, we removing his id from all groups and lock his account. Usualy, this is work for admin1.
We need this behavior of our tool: If we can't remove user id from some group (inusufficient access), we do nothing. Just answer to admin1 "You can't remove user from group2 -- ask admin2".
For this behavior we need either transactions or some easy way to check our access rights for all entries which we want to modify.
Afaik, transactions are not feasible for our case. What about checking access rights on client side without performing modification itself?
WBR
Dmitriy Kirhlarov OILspace, 26 Leninskaya sloboda, bld. 2, 2nd floor, 115280 Moscow, Russia P:+7 495 105 7247 ext.208 F:+7 495 105 7246 E:DmitriyKirhlarov@oilspace.com OILspace - The resource enriched - www.oilspace.com
Dmitriy Kirhlarov wrote:
Hi, list
Now we are using ldap-tree for auth several services on many hosts. We have two types of admins (admin1 and admin2 roles) and I want separate permissions:
- admin1 can edit cn=usergroup1, but can't edit cn=usergroup2.
- admin2 can edit both.
(I know how I can do it).
check man 5 slapd.access
Next. User can be registered in both groups, or just in one. We are developing our own ldap admin-tool for usermanagement. When user gone, we removing his id from all groups and lock his account. Usualy, this is work for admin1.
We need this behavior of our tool: If we can't remove user id from some group (inusufficient access), we do nothing. Just answer to admin1 "You can't remove user from group2 -- ask admin2".
For this behavior we need either transactions or some easy way to check our access rights for all entries which we want to modify.
Afaik, transactions are not feasible for our case. What about checking access rights on client side without performing modification itself?
WBR
Erlend
Dmitriy Kirhlarov wrote:
Hi, list
Now we are using ldap-tree for auth several services on many hosts. We have two types of admins (admin1 and admin2 roles) and I want separate permissions:
- admin1 can edit cn=usergroup1, but can't edit cn=usergroup2.
- admin2 can edit both.
(I know how I can do it).
Next. User can be registered in both groups, or just in one. We are developing our own ldap admin-tool for usermanagement. When user gone, we removing his id from all groups and lock his account. Usualy, this is work for admin1.
We need this behavior of our tool: If we can't remove user id from some group (inusufficient access), we do nothing. Just answer to admin1 "You can't remove user from group2 -- ask admin2".
For this behavior we need either transactions or some easy way to check our access rights for all entries which we want to modify.
Afaik, transactions are not feasible for our case. What about checking access rights on client side without performing modification itself?
I think the NoOp control will suffice here. It will do all of the checks for the modification (including access control) without actually committing the changes.
openldap-software@openldap.org