MODRDN error

Hello,

We have a perplexing issue with modding an RDN. The most perplexing thing is: we don't want users to be able to mod RDNs!

Here is the situation:

1) "Allow the modify DN operation" is not checked in the admin console.

2) We have restricted a particular bind from being able to see a this particular part of the directory tree, i.e., the user has no access to this part of the tree:

# LDAPv3

# base <cn=hrms,ou=names,ou=namespace,dc=berkeley,dc=edu> with scope one

# filter: objectclass=*

# requesting: ALL

#

# search result

search: 3

result: 32 No such object

matchedDN: ou=names,ou=namespace,dc=berkeley,dc=edu

3) The user can mod a dn from the command line using an ldif:

dn: cn=hrms,ou=names,ou=namespace,dc=berkeley,dc=edu

changetype: moddn

newrdn: cn=hrms1

deleteoldrdn: 1

4) The user cannot mod the dn back to the way it was, something like this:

dn: cn=hrms1,ou=names,ou=namespace,dc=berkeley,dc=edu

changetype: moddn

newrdn: cn=hrms

deleteoldrdn: 1

The user gets an "Insufficient access" error (which is what we would have expected from step 3!).

5) Directory Manager can apply the above ldif without any problems.

Does the previous scenario make sense to anyone? If so, can you explain what we are doing wrong?

Thanks.

Server: Sun Java System Directory Server 5.2_Patch_4 2005.230.0041

-lucas

[1495 byte] By [lr-ucba] at [2007-11-27 8:54:13]
# 1

Whether a user has permission to rename an entry or not is based on ACI.

You may want to check your ACIs to see if users could have permission to create new entries and where. You check evaluate your ACIs with either raising the log level to the ACI function or use the getEffectiveRights feature in an LDAP search.

Note that modRDN does not require the same ACI as a modDN (ie renaming a subtree or moving one or more entries).

Regards,

Ludovic.

ludovicpa at 2007-7-12 21:13:15 > top of Java-index,Web & Directory Servers,Directory Servers...
# 2

Hi Ludovic,

Thanks for the response and the information, especially about doing a modRDN vs. a modDN.

We have made a fix and now the user can't change the cn. Thanks.

However, do you know why in the previous config the user could change the cn, but 1) not shorten it, and 2) not change it back to what it was originally?

For example:

# original value

cn: hrms

# change to

newrdn: cn=hrmsx# works ok

# change back to

newrdn: cn=hrms# does not work

# change to

newrdn: cn=hrm # does not work

Thanks.

-lucas

P.S. Sorry for the delay in responding, we were totally swamped with other stuff yesterday.

lr-ucba at 2007-7-12 21:13:15 > top of Java-index,Web & Directory Servers,Directory Servers...