directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Seelmann <seelm...@apache.org>
Subject Re: RE - Simplist of ACI's - question
Date Fri, 14 Sep 2007 06:34:54 GMT
To avoid such whitespace problems you could also try to edit your LDIF
and the prescriptiveACI attribute using Apache Directory Studio.

Here are the steps:

1. Create a connection to Apache Directory Server (Note: there is a
known issue when fetching the schema. Please go to the connection's
properties, expand the "Connection" item, select the "Schema" item and
press the "Reload Schema" button.)

2. Create a new LDIF file, choose Menu File->New...->LDIF File

3. In the opened LDIF editor select the ApacheDS connection from the
dropp-down list. The LDIF editor will use the schema of the Server for
proper content assistence.

4. Write your LDIF or copy/paste an existing.

5. It is possible to edit the prescriptiveACI attribute using the ACI
value editor: Select the attribute and choose "Edit value" from context
menu (or press F7)


Kind Regards,
Stefan


Robb Penoyer schrieb:
> That is exactly the case for me....   I guess I should go learn dmsl and
> avoid this whole controversy. Thanks for the help man.
> 
> -----Original Message-----
> From: Ersin Er [mailto:ersin.er@gmail.com] 
> Sent: Thursday, September 13, 2007 10:54 PM
> To: users@directory.apache.org
> Subject: Re: RE - Simplist of ACI's - question
> 
> On 9/14/07, Robb Penoyer <robb@wyattaccelerator.com> wrote:
>>
>> Well that worked famously. I did modify the ldif to contain the
>> administrative role setup and a new non-system user.
>>
>> I do not see a difference in either of your ACI's...?
> 
> 
> Maybe small whitespace changes.
> 
> BTW, here is the screenshot of the working case for me:
> 
> http://people.apache.org/~ersiner/data/ACI.Test.jpg
> 
> Is it also the case for you now? Is it OK?
> 
> -----Original Message-----
>> From: Ersin Er [mailto:ersin.er@gmail.com]
>> Sent: Thursday, September 13, 2007 10:37 PM
>> To: users@directory.apache.org
>> Subject: Re: RE - Simplist of ACI's - question
>>
>> Here is a working LDIF File for me:
>>
>> http://people.apache.org/~ersiner/data/ACI.Test.ldif
>>
>> Please give it a try.
>>
>> HTH,
>>
>> On 9/14/07, Robb Penoyer <robb@wyattaccelerator.com> wrote:
>>> OK,
>>>
>>> I have to be an idiot... but here it is, this is your ldif. Fresh new
>>> install of 1.5.1, XP SP2, Java 1.5.0_12, only config change was to turn
>>> ACI's on. Fails to import.... if you have any pointer, that would be
>>> great,but you're busy, I'll keep playing with it and update the thread.
>>>
>>> R-
>>>
>>> dn: cn=authzSubentry,dc=example,dc=com
>>> objectClass: subentry
>>> objectClass: accessControlSubentry
>>> objectClass: top
>>> cn: authzSubentry
>>> subtreeSpecification:
>>>         { specificExclusions { chopBefore: "ou=notBrowsable" }}
>>> prescriptiveACI:
>>> {
>>>         identificationTag "testACI",
>>>         precedence 10,
>>>         authenticationLevel none,
>>>         itemOrUserFirst userFirst:
>>>         {
>>>                 userClasses { allUsers },
>>>                 userPermissions
>>>                 {
>>>                         {
>>>                                 protectedItems {
>>> allUserAttributeTypesAndValues, entry },
>>>                                 grantsAndDenials { grantRead,
>>> grantReturnDN,
>>> grantBrowse }
>>>                         }
>>>                         ,
>>>                         {
>>>                                 protectedItems { attributeType {
>>> userPassword } }
>>>                                 ,
>>>                                 grantsAndDenials {denyCompare,
>>> denyFilterMatch, denyRead }
>>>                         }
>>>                 }
>>>         }
>>> }
>>>
>>> -----Original Message-----
>>> From: Ersin Er [mailto:ersin.er@gmail.com]
>>> Sent: Thursday, September 13, 2007 3:01 AM
>>> To: users@directory.apache.org
>>> Subject: Re: RE - Simplist of ACI's - question
>>>
>>> It seems I forgot to paste the subtreeSpecification attribute for my
>>> config.
>>> Here it's:
>>>
>>> { specificExclusions { chopBefore: "ou=notBrowsable" } }
>>>
>>> On 9/13/07, Ersin Er <ersin.er@gmail.com> wrote:
>>>> Hi again,
>>>>
>>>> I do not see any problem with your configuration. I tried almost the
>>> same
>>>> configuration and it works fine here. Here is mine:
>>>>
>>>> dn: dc=example,dc=com
>>>> changetype: modify
>>>> add: administrativeRole
>>>> administrativeRole: accessControlSpecificArea
>>>>
>>>> dn: cn=authzSubentry,dc=example,dc=com
>>>> objectClass: subentry
>>>> objectClass: accessControlSubentry
>>>> objectClass: top
>>>> cn: authzSubentry
>>>> prescriptiveACI: {
>>>>     identificationTag "testACI",
>>>>     precedence 10,
>>>>     authenticationLevel none,
>>>>     itemOrUserFirst userFirst:
>>>>     {
>>>>         userClasses { allUsers },
>>>>         userPermissions
>>>>         {
>>>>             {
>>>>                 precedence 10,
>>>>                 protectedItems { allUserAttributeTypesAndValues, entry
>>> },
>>>>                 grantsAndDenials
>>>>                 {
>>>>                     grantRead,
>>>>                     grantReturnDN,
>>>>                     grantBrowse
>>>>                 }
>>>>             }
>>>>             ,
>>>>             {
>>>>                 precedence 10,
>>>>                 protectedItems
>>>>                 {
>>>>                     attributeType { userPassword }
>>>>                 }
>>>>                 ,
>>>>                 grantsAndDenials
>>>>                 {
>>>>                     denyCompare,
>>>>                     denyFilterMatch,
>>>>                     denyRead
>>>>                 }
>>>>             }
>>>>         }
>>>>     }
>>>> }
>>>>
>>>> dn: ou=notBrowsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: notBrowsable
>>>>
>>>> dn: ou=browsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: browsable
>>>>
>>>> dn: ou=child1,ou=browsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: child1
>>>>
>>>> dn: ou=child2,ou=browsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: child2
>>>>
>>>> dn: ou=child3,ou=notBrowsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: child3
>>>>
>>>> dn: ou=child4,ou=notBrowsable,dc=example,dc=com
>>>> objectClass: organizationalUnit
>>>> objectClass: top
>>>> ou: child4
>>>>
>>>>
>>>> And I also attached a screenshot from Apache Directory Studio for
>>> showing
>>>> the case.
>>>>
>>>> HTH,
>>>>
>>>>
>>>> On 9/13/07, Robb Penoyer <robb@wyattaccelerator.com> wrote:
>>>>>
>>>>> Hey guys, turns out I wasn't subscribed to the users list... sorry
>> for
>>>>> the
>>>>> delay getting back with you.
>>>>>
>>>>> The ldif I am importing is pretty simple, the intent is a tree like
>>>>> this,
>>>>> with two regions, one enabled to browse, the other not.
>>>>>
>>>>>                dc=wyatt,dc=com (accessControlSpecificArea)
>>>>>                       |
>>>>>                    /     \
>>>>>      ou=wyattbrowse       ou=wyattnobrowse
>>>>>       /        \              /        \
>>>>> ou=child1   ou=child2   ou=child1   ou=child2
>>>>>
>>>>>
>>>>> Here is the ldif (the ACI I applied is below from original post):
>>>>>
>>>>> dn: uid=wyatt,ou=users,ou=system
>>>>> displayName: Wyatt Directory User
>>>>> uid: wyatt
>>>>> userPassword: wyatt
>>>>> objectClass: top
>>>>> objectClass: person
>>>>> objectClass: organizationalPerson
>>>>> objectClass: inetOrgPerson
>>>>> sn: wyatt
>>>>> cn: wyatt
>>>>>
>>>>> dn: ou=wyattnobrowse,dc=example,dc=com
>>>>> ou: wyattnobrowse
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt cannot browse here
>>>>>
>>>>> dn: ou=child1,ou=wyattnobrowse,dc=example,dc=com
>>>>> ou: childone,
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt cannot browse here
>>>>>
>>>>> dn: ou=child2,dc=example,dc=com
>>>>> ou: child2
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt cannot browse here
>>>>>
>>>>> dn: ou=wyattbrowse,dc=example,dc=com
>>>>> ou: wyattsystem
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt can browse here
>>>>>
>>>>> dn: ou=child1,ou= wyattbrowse,dc=example,dc=com
>>>>> ou: childone,
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt cannot browse here
>>>>>
>>>>> dn: ou=child2,ou=wyattbrowse,dc=example,dc=com
>>>>> ou: child2
>>>>> objectclass: top
>>>>> objectclass: organizationalunit
>>>>> description: Wyatt cannot browse here
>>>>>
>>>>>
>>>>> On 9/12/07, Ersin Er <ersin.er@gmail.com> wrote:
>>>>>> On 9/12/07, Robb Penoyer <robb@wyattaccelerator.com> wrote:
>>>>>>> Long time since I appeared anywhere near this project - hi all.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Started playing with AAA's and such, read all the docs. Now I
>> have
>>> a
>>>>>>> question/problem.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Using the standard ApacheDs 1.5.1 install, I modified the
>>> server.xmlto
>>>>>>> enable access
>>>>>>>
>>>>>>> controls. I also added the administrativeRole:
>>>>> accessControlSpecificArea
>>>>>>> attribute to the base dn for dc=example,dc=com in server.xml.
>>>>>>>
>>>>>>> (Verified the OA was there with studio).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Added a new uid=wyatt via ldif, verified he couldn't see
>> anything.
>>>>>>>
>>>>>>>
>>>>>>> Added a bunch of entries under dc=example,dc=com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Added the following ACI ldif:
>>>>>>>
>>>>>>> dn: cn=authorizationsACISubentry,dc=example,dc=com
>>>>>>>
>>>>>>> changetype: add
>>>>>>>
>>>>>>> objectclass: top
>>>>>>>
>>>>>>> objectclass: subentry
>>>>>>>
>>>>>>> objectclass: accessControlSubentry
>>>>>>>
>>>>>>> cn: authorizationsACISubentry
>>>>>>>
>>>>>>> subtreeSpecification: { specificExclusions { chopBefore:
>>>>>>> "ou=wyattnobrowse"
>>>>>>> } }
>>>>>>>
>>>>>>> prescriptiveACI: {
>>>>>>>
>>>>>>>    identificationTag "allUsersACI",
>>>>>>>
>>>>>>>    precedence 10,
>>>>>>>
>>>>>>>    authenticationLevel none,
>>>>>>>
>>>>>>>    itemOrUserFirst userFirst:
>>>>>>>
>>>>>>>    {
>>>>>>>
>>>>>>>      userClasses
>>>>>>>
>>>>>>>      {
>>>>>>>
>>>>>>>        allUsers
>>>>>>>
>>>>>>>      },
>>>>>>>
>>>>>>>      userPermissions
>>>>>>>
>>>>>>>      {
>>>>>>>
>>>>>>>         {
>>>>>>>
>>>>>>>          protectedItems { entry, allUserAttributeTypesAndValues
>> },
>>>>>>>          grantsAndDenials { grantRead, grantReturnDN,
>> grantBrowse
>>> }
>>>>>>>        },
>>>>>>>
>>>>>>>        {
>>>>>>>
>>>>>>>           protectedItems { attributeType { userPassword } },
>>>>>>>
>>>>>>>           grantsAndDenials { denyRead, denyCompare,
>>> denyFilterMatch
>>>>> }
>>>>>>>        }
>>>>>>>
>>>>>>>      }
>>>>>>>
>>>>>>>    }
>>>>>>>
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The result, the wyatt user still cannot see anything.  whatup?
>> If
>>>>> this
>>>>>>> should
>>>>>>>
>>>>>>> be on dev list, please let me know.
>>>>>>
>>>>>> It's fine to have this on users list.
>>>>>>
>>>>>> Can you please provide complete the complete ldif export? It's
>> hard
>>> to
>>>>> say
>>>>>> what's wrong with the information you gave. I especially would
>> like
>>> to
>>>>>> know
>>>>>> where are the entries you're trying to access with respect to
>>>>>> "ou=wyattnobrowse".
>>>>>>
>>>>>>
>>>>>> Thx.
>>>>>> --
>>>>>> Ersin Er
>>>>>> http://www.ersin-er.name
>>>>>>
>>>>>
>>>>
>>>> --
>>>> Ersin Er
>>>> http://www.ersin-er.name
>>>>
>>>>
>>>
>>> --
>>> Ersin Er
>>> http://www.ersin-er.name
>>>
>>>
>>
>> --
>> Ersin Er
>> http://www.ersin-er.name
>>
>>
> 
> 


Mime
View raw message