I have two ldifs that I use to acheive this, one modifies the area that I want to grant access to:
version: 1
dn: ou=system
changetype: modify
add: administrativeRole
administrativeRole: accessControlSpecificArea
And the other creates the user:
dn: cn=enableSearchForAllUsers,ou=system
objectClass: top
objectClass: subentry
objectClass: accessControlSubentry
subtreeSpecification: {}
cn: enableSearchForAllUsers
prescriptiveACI: { identificationTag "enableSearchForAllUsers", precedence 14, authenticationLevel simple, itemOrUserFirst userFirst: { userClasses { allUsers }, userPermissions { { protectedItems {entry, allUserAttributeTypesAndValues}, grantsAndDenials { grantRead, grantReturnDN, grantBrowse } } } } }
# User account
dn: uid=READER ,ou=users,ou=system
cn: READER
sn: Reader
uid: READER
uidNumber: 10000
gidNumber: 10000
objectClass: top
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
userPassword: secret
When I import both of these ldifs using Apache Directory Studio, it works as I expect -- the user is created, and it has read only access.
However, when I load the same files, in the same order, using LdifFileLoader:
LdifFileLoader ldifLoader = new LdifFileLoader(service.getAdminSession(), workingSchemaPath);
ldifLoader.execute();
The result is not the same. No error messages are given, the end result is that the user is created, but with no read-only access. Since the user is created, I know that it's loading the ldifs from the proper place, and I haven't had trouble with other modification-based ldifs in the past. Do you know why this discrepancy would be there, and if there's anything I can do to get around it? It is difficult since there don't appear to be any errors, so I'm not sure what to search for...
Thanks,
Jon Russell
