Roberto Polli wrote: > hi all, > > I got similar problem with: dblink+proxyuser. > > >> Rich Megginson wrote: >> >>> Giovanni Mancuso wrote: >>> Bu if i try to execute the ldapserach in first directory server i have the >>> following error: proxy does not currently work with directory manager. >>> Directory manager is considered a "local" user to each directory server. >>> Try a different user. Now, i create a new user in first DS: >>> > > >> By first DS do you mean the DS with the "real" database or the DS with the >> database link? We also refer to the DS with the "real" database as the >> "remote" DS and the DS with the database link as the "local" DS. >> > > case1) > * I bind with uid=admin to the local DS tree to modify the "givenName" of a > user on the remote server > * the modify is successful, as the uid=admin is proxied and the "uid=admin" is > replicated on the remote server > > case2) > * same as case1 but I try to modify "userPassword" > * the modify fails as the remote server won't evaluate aci on "uid=admin" but > on "dn:proxyuser" > Is there an aci on the remote server that explicitly denies access to userPassword? How about on the local server? > >> Did you add an ACI to allow the uid=ttestuser,cn=config to add entries under >> node=testgio,dc=example,dc=com ? >> > to solve that issue it seems by this thread that you suggest giving > (proxy+all) access to proxyuser instead of the proxied one (uid=admin) > > imho this won't fit, as every proxied user will be granted write access; while > the desired behaviour is to have the aci checked against uid=admin > > Am I wrong? > You should not have to allow the proxy user "all" access, only "proxy" access. The proxy user is not a "superuser". The access control should apply to the actual user. > Peace, > R. > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20090723/6a63d0f2/attachment.bin
