I looked at the issue that you have opened on this matter, and it seems to suggest that the workaround entails splitting the .ldif file into two .ldif files -- one for content and another for actions. I i went ahead and isolated the following entry into its own separate .ldif file:
dn: dc=mycompany,dc=com changetype: modify add: administrativeRole administrativeRole: accessControlSpecificArea But that still does not add administrativeRole to my partition. Could you please provide a more detailed description of the workaround? Thanks! > Date: Tue, 24 Feb 2015 18:04:23 +0800 > Subject: Re: ldif import works in studio, fails with LdifFileLoader > From: [email protected] > To: [email protected] > > On Tue, Feb 24, 2015 at 3:54 PM, Michael Perelman < > [email protected]> wrote: > > > Ok, I understand the need for proper order within an .ldif file when > > loading one via LdifFileLoader, thanks! > > > > What I am still not clear about is how to properly add administrativeRole > > entry. I have modified my .ldif file to look like this: > > > > dn: dc=mycompany,dc=com > > objectclass: domain > > objectclass: top > > objectclass: extensibleObject > > dc: mycompany > > ou: mycompany > > > > dn: dc=mycompany,dc=com > > changetype: modify > > add: administrativeRole > > administrativeRole: accessControlSpecificArea > > > > LDIF is not allowed to contain both entries and changesets, however Studio > allows this and we may support[1] this mode in > server as well. > > For now, the workaround is to add this attribute during that entry > creation > > [1] https://issues.apache.org/jira/browse/DIRAPI-222 > > > dn: cn=allowUserSelfMod,dc=mycompany,dc=com > > objectClass: subentry > > objectClass: accessControlSubentry > > objectClass: top > > cn: allowUserSelfMod > > prescriptiveACI: { identificationTag "", precedence 0, authenticationLevel > > s > > imple, itemOrUserFirst userFirst: { userClasses { thisEntry }, > > userPermissi > > ons { { protectedItems { entry }, grantsAndDenials { grantBrowse, > > grantRetu > > rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues { > > u > > serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } } > > subtreeSpecification: { } > > > > dn: ou=people,dc=mycompany,dc=com > > objectClass: organizationalUnit > > objectClass: top > > ou: people > > > > This is still not loading properly via LdifFileLoader. In your previous > > response, you stated that administrativeRole must be added to the entry > > immediately, yet I was still not able to make it work. Please show me the > > proper way to configure it. > > > > To answer your last question, I am using an admin session to import the > > .ldif file. > > > > Thanks! > > > > On 11/02/15 19:26, Michael Perelman wrote : > > > Hi. My case involves an embedded instance of ADS-M17 where I load a > > simple .ldif file > > during start-up using LdifFileLoader instance. I always use the Studio to > > perform initial > > tests, and it works in this particular case. But when I use > > LdifFileLoader, the security-related > > entities are never created. Here is what the .ldif looks like: > > > > LdapStudio will order the LDIF before injecting it. The LdifLoader wont. > > Typically, here, the dc=myCompany,dc=com is not the first entry, and the > > loader will yell at you because it's messing when it will try to load > > the first entry (ou=people,dc=mycompany,dc=co). > > > > Another thing : why are you modifying the entry you just injected before > > (dc=mycompany,dc=com)? It's a better idea to add the administrativeRole > > attribute to the entry immediately. > > > > Last, not least: which user are you using to inject the entries ? > > > > > > > > dn: ou=people,dc=mycompany,dc=com > > > objectClass: organizationalUnit > > > objectClass: top > > > ou: people > > > > > > dn: dc=mycompany,dc=com > > > objectclass: domain > > > objectclass: top > > > objectclass: extensibleObject > > > dc: mycompany > > > ou: mycompany > > > > > > dn: dc=mycompany,dc=com > > > changetype: modify > > > add: administrativeRole > > > administrativeRole: accessControlSpecificArea > > > > > > dn: cn=allowUserSelfMod,dc=mycompany,dc=com > > > objectClass: subentry > > > objectClass: accessControlSubentry > > > objectClass: top > > > cn: allowUserSelfMod > > > prescriptiveACI: { identificationTag "", precedence 0, > > authenticationLevel s > > > imple, itemOrUserFirst userFirst: { userClasses { thisEntry }, > > userPermissi > > > ons { { protectedItems { entry }, grantsAndDenials { grantBrowse, > > grantRetu > > > rnDN, grantModify, grantRead } }, { protectedItems { allAttributeValues > > { u > > > serPassword } }, grantsAndDenials { grantRemove, grantAdd } } } } } > > > subtreeSpecification: { } > > > > > > The dc=mycompany,dc=com partition and its ou=people org unit are created > > successfully > > when using either the Studio or the LdifFileLoader. Yet partition's > > administrativeRole and > > accessControlSubentry are only created when using the Studio, while > > importing via LdifFileLoader > > does not! And no exceptions are thrown at any time. > > > > > > Thanks! > > > > > > > > -- > Kiran Ayyagari > http://keydap.com
