Thanks Jeff!

I think you cleared everything for me. I did misunderstood the concept of "ldap:///self", and I agree with you that deny rules should be avoided.

ldap:///self refers to the owner of the entry which is the creator of the entry. Am I correct on this?

After I specified the userdn as cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI, everything is now working as expected. user1 doesn't have the ability to write/add/replace the entry.

Below is my new LDIF dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0; acl "user1"; allow (read, search, compare) (userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com ");)

Thanks,

David

On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com> wrote:

Couple things here. First, avoid deny rules if at all possible - deny rules always take precedence, so you can *never* override a deny rule with something to allow access that has been denied elsewhere.

Second, I think you are misunderstanding how ldap:///self works. ldap:///self basically says "These permissions are granted on the targetted entry if I bind to the server as that target entry". In your case, what your deny rule is saying is that if I bind as user1, I can't read, write, or even search for the user1 entry, and as a deny rule, you can't create any other rule to ever allow user1 to see his own entry.

So, you've created a rule that says anyone can read/write/search to anything under ou=serviceaccounts, *except* user1 can't read/write/search on his own entry.

BTW, this seems like a really bad idea. Forget about ACI's and implementation for the moment - conceptually, what are you trying to do? Who should be able to do what? Are you saying you want anyone except user1 to be able to have full access to anything under ou=serviceaccounts?

To define your access controls, you should really figure out who you want to do what, then define aci's for each thing you want to allow, such that they only *allow* just what you need, so you don't need any kind of deny rules.

If you want to, for example, allow any user to edit any part of just their own record, put something like the following on the ou=serviceaccounts entry:

aci: (targetattr = "*") (version 3.0; acl "default aci for service accounts"; allow (all) (userdn=ldap:///self) ;) This says that if I bind as a user under ou=serviceaccounts, I have full read/write/search access to the entry I bound as (i.e. my account). However, I'd recommend making even that more restrictive (for example, if all they really need to write to is their password, create one aci to allow them to read/search all attributes except the userpassword, and one to allow write to the userpassword with userdn of ldap:///self), etc. If you want all users to read other users entries, create another aci that allows search/read access to ldap:///anyone (and at least make it targetattr!="userpassword"), and so on..

• Jeff

---

*From:* fedora-directory-users-bounces@redhat.com [mailto: fedora-directory-users-bounces@redhat.com] *On Behalf Of *Chun Tat David Chu *Sent:* Monday, December 10, 2007 11:37 AM *To:* fedora-directory-users@redhat.com *Subject:* Re: [Fedora-directory-users] Question about ACI

Hi guys,

Please see below for my original question.

I spend a little more time reading "Chapter 6 - Managing Access Control" from the RH Administrator Guide. At first, I thought it was my placement of ACI that was wrong, but it seems like that's not the case from what I read. The book stated that "The precedence rule that applies is that ACIs that deny access take precedence over ACIs that allow access." If my root allows everything and then my leaf denies everything then I don't see why the add operation that I mentioned below should work.

Let me clear up a little more in case there's any confusion. The ou=serviceaccounts and cn=user1 entry is created by the "cn=Directory Manager" user. In my test, the root (ou=serviceaccounts), I specified an ACI that allows all user to do anything. In my leaf (cn=user1), I specified an ACI that denies everything for user1 by defining the bind rule as (ldap:///self).

When I logged in as user1, I'm able to add entry in the cn=user1 context. I am not sure why because I thought that user1 shouldn't have any privilege to do anything due to my specified ACI.

Any idea? Am I missing some obvious?

Thanks!

David

On Dec 7, 2007 6:28 PM, Chun Tat David Chu beyonddc.storage@gmail.com wrote:

...

Hi guys,

I am trying to create an organizational unit and an user with ACI, but it looks like my ACI is not defined correctly. Below is my ldif.

dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit aci: (targetattr = "*") (version 3.0; acl "default aci for service accounts"; allow (all) (userdn="ldap:///anyone") ;)

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: tscei.obs userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0; acl "user1"; deny (all) (userdn="ldap:///self") ;)

I create an organizational unit that allows all users to modify it, then I create user1 that denies everything. I then use the below LDIF to perform a LDAP add operation.

dn: cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: room

I use this ldapmodify command to perform the add operation ldapmodify -h hostname -p 1389 -D "cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f my_test.ldif -x

The add operation succeeded unexpectedly. The result that I'm looking for should be not enough privilege to perform add operation.

Anyone knows what's wrong with my ACI setup?

Thanks!

David

-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users

Thanks for your response Jeff.

I tried with your suggestion and did the following to my LDIF file. I use the ldapmodify command and logged in as "cn=Directory Manager" to perform these add operations. dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit aci: (targetattr = "*") (version 3.0; acl "general user access"; allow (all) (userdn="ldap:///self") ;)

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test

Now when I use the ldapmodify and logged in as "cn=user1", to perform the below operation, it failed and gave me an insufficient access (50) error. Any idea? I think I'm stuck again. :-( dn: cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: room

Thanks

David

On Dec 10, 2007 3:44 PM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com> wrote:

...

I think you cleared everything for me. I did misunderstood the

concept of "ldap:///self", and

...

I agree with you that deny rules should be avoided.

ldap:///self refers to the owner of the entry which is the creator of

the entry. Am I correct on this?

No. ldap:///self means the aci applies to the entry you bind to the server as. For example, if you create a rule on ou=serviceaccounts that says ldap:///self can change the attribute "userpassword", any user under ou=serviceaccounts can change their own password (i.e. if I bind as uid=user1,ou=serviceaccounts, I can write to the userpassword attribute of user1, and no one elses. If I bind as user2, I can write to user2's userpassword attribute, but no one elses). Creator of the entry has nothing to do with it. Technically, "owner" is yet something else (if an entry has an owner attribute, that typically will contain dn's of "owners" of the entry that can manipulate it in some way, but that's not automatic - you'd have to create aci's to define that owner relationship. LDAP does not otherwise/by default have "owners" of entries - Creator != Owner).

...

After I specified the userdn as

cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI,

...

everything is now working as expected. user1 doesn't have the ability

to write/add/replace the entry.

...

Below is my new LDIF dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0; acl "user1"; allow (read, search, compare)

(userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com

...

");)

By doing it this way, you are allowing user1 to see it's own account, and nothing more - this aci does not allow other users to see user1, and does not allow user1 to see other users. Not unreasonable in and of itself, but if you create many users where you want identical behavior, it's very inefficient - you'll have way to many aci's in the directory and maintenance is more difficult.

If you want all users to have these same rights, a better way is to put an aci like the following on the ou=serviceaccounts entry (and leave the aci off the user):

aci: (targetattr = "*") (version 3.0; acl "user access"; allow (read, search, compare) (userdn="ldap:///self ");)

This will allow any user under that branch of the tree that binds to the directory to read/search/compare their own entry, in it's entirety, without granting them access to anything else, nor granting any other user to see their entry. (I'd still recommend that you restrict the attribute list further, at least to targetattr!="userpassword" - there's usually no need for users to see their password hash, and letting that be transmitted over the network so freely is a bit of a security concern.)

(Note: if you already have aci's in your tree above this, including the default aci's that come with the dir server, you may have other access granted that is added to this).

• Jeff

On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com mailto:jeff_clowser@fanniemae.com > wrote:

   Couple things here.  First, avoid deny rules if at all possible

• deny rules always take precedence, so you can *never* override a deny

rule with something to allow access that has been denied elsewhere.

   Second, I think you are misunderstanding how ldap:///self works.

ldap:///self basically says "These permissions are granted on the targetted entry if I bind to the server as that target entry". In your case, what your deny rule is saying is that if I bind as user1, I can't read, write, or even search for the user1 entry, and as a deny rule, you can't create any other rule to ever allow user1 to see his own entry.

   So, you've created a rule that says anyone can read/write/search

to anything under ou=serviceaccounts, *except* user1 can't read/write/search on his own entry.

   BTW, this seems like a really bad idea.  Forget about ACI's and

implementation for the moment - conceptually, what are you trying to do? Who should be able to do what? Are you saying you want anyone except user1 to be able to have full access to anything under ou=serviceaccounts?

   To define your access controls, you should really figure out who

you want to do what, then define aci's for each thing you want to allow, such that they only *allow* just what you need, so you don't need any kind of deny rules.

   If you want to, for example, allow any user to edit any part of

just their own record, put something like the following on the ou=serviceaccounts entry:

           aci:
    (targetattr = "*")
    (version 3.0;
    acl "default aci for service accounts";
    allow (all)

    (userdn=ldap:///self)
    ;)

   This says that if I bind as a user under ou=serviceaccounts, I

have full read/write/search access to the entry I bound as (i.e. my account). However, I'd recommend making even that more restrictive (for example, if all they really need to write to is their password, create one aci to allow them to read/search all attributes except the userpassword, and one to allow write to the userpassword with userdn of ldap:///self), etc. If you want all users to read other users entries, create another aci that allows search/read access to ldap:///anyone (and at least make it targetattr!="userpassword"), and so on..

    - Jeff

---

   From: fedora-directory-users-bounces@redhat.com

[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Chun Tat David Chu Sent: Monday, December 10, 2007 11:37 AM To: fedora-directory-users@redhat.com Subject: Re: [Fedora-directory-users] Question about ACI

   Hi guys,

   Please see below for my original question.

   I spend a little more time reading "Chapter 6 - Managing Access

Control" from the RH Administrator Guide. At first, I thought it was my placement of ACI that was wrong, but it seems like that's not the case from what I read. The book stated that "The precedence rule that applies is that ACIs that deny access take precedence over ACIs that allow access." If my root allows everything and then my leaf denies everything then I don't see why the add operation that I mentioned below should work.

   Let me clear up a little more in case there's any confusion.

The ou=serviceaccounts and cn=user1 entry is created by the "cn=Directory Manager" user. In my test, the root (ou=serviceaccounts), I specified an ACI that allows all user to do anything. In my leaf (cn=user1), I specified an ACI that denies everything for user1 by defining the bind rule as (ldap:///self).

   When I logged in as user1, I'm able to add entry in the cn=user1

context. I am not sure why because I thought that user1 shouldn't have any privilege to do anything due to my specified ACI.

   Any idea?  Am I missing some obvious?

   Thanks!

   David


   On Dec 7, 2007 6:28 PM, Chun Tat David Chu

beyonddc.storage@gmail.com wrote:

           Hi guys,

           I am trying to create an organizational unit and an user

with ACI, but it looks like my ACI is not defined correctly. Below is my ldif.

           dn: ou=serviceaccounts,dc=test,dc=example,dc=com
           changetype: add
           objectclass: top
           objectclass: organizationalunit
           aci:
            (targetattr = "*")
            (version 3.0;
            acl "default aci for service accounts";
            allow (all)
            (userdn="ldap:///anyone")
            ;)

           dn:

cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0; acl "user1"; deny (all) (userdn="ldap:///self") ;)

           I create an organizational unit that allows all users to

modify it, then I create user1 that denies everything. I then use the below LDIF to perform a LDAP add operation.

           dn:

cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: room

           I use this ldapmodify command to perform the add

operation ldapmodify -h hostname -p 1389 -D "cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f my_test.ldif -x

           The add operation succeeded unexpectedly.  The result

that I'm looking for should be not enough privilege to perform add operation.

           Anyone knows what's wrong with my ACI setup?

           Thanks!

           David




   --
   Fedora-directory-users mailing list
   Fedora-directory-users@redhat.com
   https://www.redhat.com/mailman/listinfo/fedora-directory-users

-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users

Jeff, I think I understood now. Thanks for your help, I very appreciated.

I think look at the error log next time to check on error.

:-)

On Dec 11, 2007 10:58 AM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com> wrote:

ldap:///self allows user1 to modify it's own entry, not it's own entry plus subentries, so that aci does not allow you to create subentries like that.

I don't really recommend allowing all users to be able to create entries like this - they can literally create anything (other users, groups, etc) that may have undesirable effects (security loopholes, duplicate email addresses, etc). Do you really need to allow this?

If you really realy do want to do this, you probably will have to create an aci on each users entry allowing access by that userdn (something like like your previous aci on the user but with write access to allow what you want (but again, I really don't think what you want to do is a good idea).

If user1 is the only user you want to do this (i.e. user1 is an admin), I would recommend the following:

• Create an ldap group (groupofnames/groupofuniquenames) somewhere outside

of the ou=serviceaccounts branch.

• put an aci on ou=serviceaccounts that allows all access to the

ou=serviceaccounts branch (actually, it would be best if it allowed all access to uid=*,ou=serviceaccounts,... to avoid members of that group editing the actual ou=serviceaccounts entry and changing the aci, for example) if they are a member of that admin group (actually, you should set targetattr to something like !="aci" and maybe other attributes, so members of this group can't redefne aci's within that subtree).

• add user1 to that group to make it admin.

This is assuming you want a subset of users to be able to create entries, rather than every user. If you must allow all users to create entries, you should still make targetattr!="aci" at least, so that users can't set random access controls of the stuff they create.

One final word - use the error log - it will often tell you more about why something fails when it fails.

• Jeff

The electronic mail message you have received and any files transmitted with it are confidential and solely for the intended addressee(s) attention. Do not divulge, copy, forward, or use the contents, attachments, or information without permission of Fannie Mae. Information contained in this message is provided solely for the purpose stated in the message or its attachment(s) and must not be disclosed to any third party or used for any other purpose without consent of Fannie Mae. If you have received this message and/or any files transmitted with it in error, please delete them from your system, destroy any hard copies of them, and contact the sender. ***

**

---

*From:* fedora-directory-users-bounces@redhat.com [mailto: fedora-directory-users-bounces@redhat.com] *On Behalf Of *Chun Tat David Chu *Sent:* Monday, December 10, 2007 4:53 PM *To:* General discussion list for the Fedora Directory server project.

*Subject:* Re: [Fedora-directory-users] Question about ACI

Thanks for your response Jeff.

I tried with your suggestion and did the following to my LDIF file. I use the ldapmodify command and logged in as "cn=Directory Manager" to perform these add operations. dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit aci: (targetattr = "*") (version 3.0; acl "general user access"; allow (all) (userdn="ldap:///self") ;)

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test

Now when I use the ldapmodify and logged in as "cn=user1", to perform the below operation, it failed and gave me an insufficient access (50) error. Any idea? I think I'm stuck again. :-( dn: cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: room

Thanks

David

On Dec 10, 2007 3:44 PM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com> wrote:

...

...

I think you cleared everything for me. I did misunderstood the

concept of "ldap:///self", and

...

I agree with you that deny rules should be avoided.

ldap:///self refers to the owner of the entry which is the creator of

the entry. Am I correct on this?

No. ldap:///self means the aci applies to the entry you bind to the server as. For example, if you create a rule on ou=serviceaccounts that says ldap:///self can change the attribute "userpassword", any user under ou=serviceaccounts can change their own password (i.e. if I bind as uid=user1,ou=serviceaccounts, I can write to the userpassword attribute of user1, and no one elses. If I bind as user2, I can write to user2's userpassword attribute, but no one elses). Creator of the entry has nothing to do with it. Technically, "owner" is yet something else (if an entry has an owner attribute, that typically will contain dn's of "owners" of the entry that can manipulate it in some way, but that's not automatic - you'd have to create aci's to define that owner relationship. LDAP does not otherwise/by default have "owners" of entries - Creator != Owner).

...

After I specified the userdn as

cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com in my ACI,

...

everything is now working as expected. user1 doesn't have the ability

to write/add/replace the entry.

...

Below is my new LDIF dn: ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: organizationalunit

dn: cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0; acl "user1"; allow (read, search, compare)

(userdn="ldap:///cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com

...

");)

By doing it this way, you are allowing user1 to see it's own account, and nothing more - this aci does not allow other users to see user1, and does not allow user1 to see other users. Not unreasonable in and of itself, but if you create many users where you want identical behavior, it's very inefficient - you'll have way to many aci's in the directory and maintenance is more difficult.

If you want all users to have these same rights, a better way is to put an aci like the following on the ou=serviceaccounts entry (and leave the

aci off the user):

aci: (targetattr = "*") (version 3.0; acl "user access"; allow (read, search, compare) (userdn="ldap:///self ");)

This will allow any user under that branch of the tree that binds to the directory to read/search/compare their own entry, in it's entirety, without granting them access to anything else, nor granting any other user to see their entry. (I'd still recommend that you restrict the attribute list further, at least to targetattr!="userpassword" - there's usually no need for users to see their password hash, and letting that be transmitted over the network so freely is a bit of a security concern.)

(Note: if you already have aci's in your tree above this, including the default aci's that come with the dir server, you may have other access granted that is added to this).

• Jeff

On Dec 10, 2007 12:48 PM, Clowser, Jeff (Contractor) < jeff_clowser@fanniemae.com mailto:jeff_clowser@fanniemae.com > wrote:

   Couple things here.  First, avoid deny rules if at all possible

• deny rules always take precedence, so you can *never* override a deny

rule with something to allow access that has been denied elsewhere.

   Second, I think you are misunderstanding how ldap:///self works.

ldap:///self basically says "These permissions are granted on the targetted entry if I bind to the server as that target entry". In your case, what your deny rule is saying is that if I bind as user1, I can't read, write, or even search for the user1 entry, and as a deny rule, you can't create any other rule to ever allow user1 to see his own entry.

   So, you've created a rule that says anyone can read/write/search

to anything under ou=serviceaccounts, *except* user1 can't read/write/search on his own entry.

   BTW, this seems like a really bad idea.  Forget about ACI's and

implementation for the moment - conceptually, what are you trying to do?

Who should be able to do what? Are you saying you want anyone except user1 to be able to have full access to anything under ou=serviceaccounts?

   To define your access controls, you should really figure out who

you want to do what, then define aci's for each thing you want to allow, such that they only *allow* just what you need, so you don't need any kind of deny rules.

   If you want to, for example, allow any user to edit any part of

just their own record, put something like the following on the ou=serviceaccounts entry:

           aci:
    (targetattr = "*")
    (version 3.0;
    acl "default aci for service accounts";
    allow (all)

    (userdn=ldap:///self)
    ;)

   This says that if I bind as a user under ou=serviceaccounts, I

have full read/write/search access to the entry I bound as (i.e . my account). However, I'd recommend making even that more restrictive (for example, if all they really need to write to is their password, create one aci to allow them to read/search all attributes except the userpassword, and one to allow write to the userpassword with userdn of ldap:///self), etc. If you want all users to read other users entries, create another aci that allows search/read access to ldap:///anyone (and

at least make it targetattr!="userpassword"), and so on..

    - Jeff

---

   From: fedora-directory-users-bounces@redhat.com

[mailto:fedora-directory-users-bounces@redhat.com] On Behalf Of Chun Tat David Chu Sent: Monday, December 10, 2007 11:37 AM To: fedora-directory-users@redhat.com Subject: Re: [Fedora-directory-users] Question about ACI

   Hi guys,

   Please see below for my original question.

   I spend a little more time reading "Chapter 6 - Managing Access

Control" from the RH Administrator Guide. At first, I thought it was my placement of ACI that was wrong, but it seems like that's not the case from what I read. The book stated that "The precedence rule that applies is that ACIs that deny access take precedence over ACIs that allow access." If my root allows everything and then my leaf denies everything then I don't see why the add operation that I mentioned below should work.

   Let me clear up a little more in case there's any confusion.

The ou=serviceaccounts and cn=user1 entry is created by the "cn=Directory Manager" user. In my test, the root (ou=serviceaccounts), I specified an ACI that allows all user to do anything. In my leaf (cn=user1), I specified an ACI that denies everything for user1 by defining the bind rule as (ldap:///self).

   When I logged in as user1, I'm able to add entry in the cn=user1

context. I am not sure why because I thought that user1 shouldn't have any privilege to do anything due to my specified ACI.

   Any idea?  Am I missing some obvious?

   Thanks!

   David


   On Dec 7, 2007 6:28 PM, Chun Tat David Chu

<beyonddc.storage@gmail.com > wrote:

           Hi guys,

           I am trying to create an organizational unit and an user

with ACI, but it looks like my ACI is not defined correctly. Below is my ldif.

           dn: ou=serviceaccounts,dc=test,dc=example,dc=com
           changetype: add
           objectclass: top
           objectclass: organizationalunit
           aci:
            (targetattr = "*")
            (version 3.0;
            acl "default aci for service accounts";
            allow (all)
            (userdn="ldap:///anyone")
            ;)

           dn:

cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: person sn: user1 userPassword: testing123 description: This is a test aci: (targetattr = "*") (version 3.0 ; acl "user1"; deny (all) (userdn="ldap:///self") ;)

           I create an organizational unit that allows all users to

modify it, then I create user1 that denies everything. I then use the below LDIF to perform a LDAP add operation.

           dn:

cn=testing123,cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com changetype: add objectclass: top objectclass: room

           I use this ldapmodify command to perform the add

operation ldapmodify -h hostname -p 1389 -D "cn=user1,ou=serviceaccounts,dc=test,dc=example,dc=com" -w testing123 -f my_test.ldif -x

           The add operation succeeded unexpectedly.  The result

that I'm looking for should be not enough privilege to perform add operation.

           Anyone knows what's wrong with my ACI setup?

           Thanks!

           David




   --
   Fedora-directory-users mailing list
   Fedora-directory-users@redhat.com
   https://www.redhat.com/mailman/listinfo/fedora-directory-users

-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users

-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users