You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@directory.apache.org by Oliver Schmidt <ol...@arcor.de> on 2011/11/02 19:04:36 UTC
[ApacheDS] Re: Access Restriction
On Wed, 02 Nov 2011 13:59:25 +0100, Kevin Hamilton <kh...@umem.org>
wrote:
> Hello everyone,
>
> My name is Kevin and I am writing to ask a question about access to
> ApacheDS 2.0.0-M2. Currently I have a bunch of users set up and the
> apacheds is used to authenticate the users on my website. My question
> is about accessing the apacheds. On my Apache Directory Studio, I can
> login as admin and see everything. The problem is that I can also log
> in as any other user in the database and I can see other user's
> information. Not sure if I am being clear.
>
> If someone has their own username and password and also the port and
> address of my server, they can login (using Apache Directory Studio or
> any other client) and see all of the records. Obviously the passwords
> are hashed, but it is still a liability for the users to be able to
> see e-mails/etc of other users.
>
> Is there any way to limit the information that certain users can see
> (ie, they could login, but not see any records)?
>
> Please let me know soon.
>
> Thanks,
> Kevin
Hi Kevin,
I'm moving this topic to the users list...
There's a chapter about this topic in the doco. Please see the User Guides
on the topic "authorization".
Depending on what you intend to allow/disallow your users to see in your
directory, you might also need to write some ACIs. If you want, I can
assist you setting this up.
Please note that ehe documentation still mentions the server.xml file.
This file is however obsolete in version 2.0. Instead, config is done
directly in the server. You can alter the configuration using ehe
Directory Studio. Just look under the ou=config node.
Kind regards
Oliver
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
I got it working!
Thank you all so much for your help. You guys are life savers!
-Kevin
On Fri, Nov 4, 2011 at 1:41 PM, Oliver Schmidt
<ol...@arcor.de> wrote:
> Hi Kevin,
>
> sorry for the confusion. administrativeRole has to be added to the entry
> under which the protected items are. E.g. ou=people,ou=example.com
>
> The subentry has also to be stored there. You should re-apply the
> userPassword in order to do at least simle authentication.
>
> A little background:
> A subentry is a kind of selector for all elements under its parent element.
> E.g. You can create a subentry under, let's say ou=people,... which selects
> all people with the attribute value memberOf=mygroup. Then you can add
> attributes to the subentry and those attributes automatically apply to all
> elements selected by the subentry. This way, you can automatically add
> attributes which are common to a specific group of elements. Even to
> elements which do not yet exist in your DIT.
>
> --
> Kind regards / freundliche Grüße
> Oliver Schmidt
>
> Sent via HP Veer
>
> Am 04.11.2011, 17:33 Uhr, schrieb Kevin Hamilton <kh...@umem.org>:
>
>> Ok, so if I remove the userPassword, sn, and mail attributes from the
>> entry (the new accessControlSubentry) then it lets me create it. The
>> record exists as a subentry of the uid=admin2 object. When I bind to
>> ApacheDS as admin2, I still cannot see anything but the tree root.
>>
>> Any more advice on this and why it would say my userPassword, sn, and
>> mail attributes were invalid for the accessControlSubentry, subentry,
>> and top objectclasses?
>>
>> Thanks,
>> Kevin
>>
>> On Fri, Nov 4, 2011 at 9:48 AM, Kevin Hamilton <kh...@umem.org> wrote:
>>>
>>> I am using ADS 2.0.0-M2.
>>>
>>> Thanks,
>>> Kevin
>>>
>>> On Fri, Nov 4, 2011 at 9:39 AM, Emmanuel Lécharny <el...@apache.org>
>>> wrote:
>>>>
>>>> On 11/4/11 2:29 PM, Kevin Hamilton wrote:
>>>>>
>>>>> The cn=admin2Test,uid=admin2,ou=system was never created because the
>>>>> error occurred while I was trying to create it.
>>>>>
>>>>> I was following Oliver's instructions by doing the following:
>>>>> 2) Add a new entry below the entry where you have added the
>>>>> "administrativeRole" attribute. Use the object classes
>>>>> "accessControlSubentry", "subentry" and "top". As RDN attribute name,
>>>>> use
>>>>> "cn" and choose a name of your preference.
>>>>> 2a) You will be asked to specify the subentry. Leave it empty.
>>>>> 2b) You will be asked to specify the ACI element:
>>>>> * Identificator:<your choice>
>>>>> * Priority: 0
>>>>> * Authentication level: simple=non-SASL / strong=SASL (I would
>>>>> choose
>>>>> simple first)
>>>>> * User or element first: User
>>>>> * User classes: Choose "name" and specify your admin2
>>>>> * User permissions:
>>>>> * Protected elements: "entry", "all user attribute types and
>>>>> values"
>>>>> * Grants and denials: Here, you can grant everything
>>>>>
>>>>>
>>>>> When he says add a new entry below the entry where I added
>>>>> administrativeRole, he means I should right click on the
>>>>> uid=admin,ou=system and add an entry to that, right? That is what I
>>>>> have been doing. Is this incorrect?
>>>>
>>>> No, this is the way it should be done.
>>>>
>>>> The error message is a bit suprising...
>>>>
>>>> What version of ADS are you using ?
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Cordialement,
>>>> Emmanuel Lécharny
>>>> www.iktek.com
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Kevin
>>>
>>
>>
>>
>
>
> --
> Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Oliver Schmidt <ol...@arcor.de>.
Hi Kevin,
sorry for the confusion. administrativeRole has to be added to the entry
under which the protected items are. E.g. ou=people,ou=example.com
The subentry has also to be stored there. You should re-apply the
userPassword in order to do at least simle authentication.
A little background:
A subentry is a kind of selector for all elements under its parent
element. E.g. You can create a subentry under, let's say ou=people,...
which selects all people with the attribute value memberOf=mygroup. Then
you can add attributes to the subentry and those attributes automatically
apply to all elements selected by the subentry. This way, you can
automatically add attributes which are common to a specific group of
elements. Even to elements which do not yet exist in your DIT.
--
Kind regards / freundliche Grüße
Oliver Schmidt
Sent via HP Veer
Am 04.11.2011, 17:33 Uhr, schrieb Kevin Hamilton <kh...@umem.org>:
> Ok, so if I remove the userPassword, sn, and mail attributes from the
> entry (the new accessControlSubentry) then it lets me create it. The
> record exists as a subentry of the uid=admin2 object. When I bind to
> ApacheDS as admin2, I still cannot see anything but the tree root.
>
> Any more advice on this and why it would say my userPassword, sn, and
> mail attributes were invalid for the accessControlSubentry, subentry,
> and top objectclasses?
>
> Thanks,
> Kevin
>
> On Fri, Nov 4, 2011 at 9:48 AM, Kevin Hamilton <kh...@umem.org>
> wrote:
>> I am using ADS 2.0.0-M2.
>>
>> Thanks,
>> Kevin
>>
>> On Fri, Nov 4, 2011 at 9:39 AM, Emmanuel Lécharny
>> <el...@apache.org> wrote:
>>> On 11/4/11 2:29 PM, Kevin Hamilton wrote:
>>>>
>>>> The cn=admin2Test,uid=admin2,ou=system was never created because the
>>>> error occurred while I was trying to create it.
>>>>
>>>> I was following Oliver's instructions by doing the following:
>>>> 2) Add a new entry below the entry where you have added the
>>>> "administrativeRole" attribute. Use the object classes
>>>> "accessControlSubentry", "subentry" and "top". As RDN attribute name,
>>>> use
>>>> "cn" and choose a name of your preference.
>>>> 2a) You will be asked to specify the subentry. Leave it empty.
>>>> 2b) You will be asked to specify the ACI element:
>>>> * Identificator:<your choice>
>>>> * Priority: 0
>>>> * Authentication level: simple=non-SASL / strong=SASL (I would
>>>> choose
>>>> simple first)
>>>> * User or element first: User
>>>> * User classes: Choose "name" and specify your admin2
>>>> * User permissions:
>>>> * Protected elements: "entry", "all user attribute types and
>>>> values"
>>>> * Grants and denials: Here, you can grant everything
>>>>
>>>>
>>>> When he says add a new entry below the entry where I added
>>>> administrativeRole, he means I should right click on the
>>>> uid=admin,ou=system and add an entry to that, right? That is what I
>>>> have been doing. Is this incorrect?
>>>
>>> No, this is the way it should be done.
>>>
>>> The error message is a bit suprising...
>>>
>>> What version of ADS are you using ?
>>>
>>>
>>> --
>>> Regards,
>>> Cordialement,
>>> Emmanuel Lécharny
>>> www.iktek.com
>>>
>>>
>>
>>
>>
>> --
>> Thanks,
>> Kevin
>>
>
>
>
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
Ok, so if I remove the userPassword, sn, and mail attributes from the
entry (the new accessControlSubentry) then it lets me create it. The
record exists as a subentry of the uid=admin2 object. When I bind to
ApacheDS as admin2, I still cannot see anything but the tree root.
Any more advice on this and why it would say my userPassword, sn, and
mail attributes were invalid for the accessControlSubentry, subentry,
and top objectclasses?
Thanks,
Kevin
On Fri, Nov 4, 2011 at 9:48 AM, Kevin Hamilton <kh...@umem.org> wrote:
> I am using ADS 2.0.0-M2.
>
> Thanks,
> Kevin
>
> On Fri, Nov 4, 2011 at 9:39 AM, Emmanuel Lécharny <el...@apache.org> wrote:
>> On 11/4/11 2:29 PM, Kevin Hamilton wrote:
>>>
>>> The cn=admin2Test,uid=admin2,ou=system was never created because the
>>> error occurred while I was trying to create it.
>>>
>>> I was following Oliver's instructions by doing the following:
>>> 2) Add a new entry below the entry where you have added the
>>> "administrativeRole" attribute. Use the object classes
>>> "accessControlSubentry", "subentry" and "top". As RDN attribute name, use
>>> "cn" and choose a name of your preference.
>>> 2a) You will be asked to specify the subentry. Leave it empty.
>>> 2b) You will be asked to specify the ACI element:
>>> * Identificator:<your choice>
>>> * Priority: 0
>>> * Authentication level: simple=non-SASL / strong=SASL (I would choose
>>> simple first)
>>> * User or element first: User
>>> * User classes: Choose "name" and specify your admin2
>>> * User permissions:
>>> * Protected elements: "entry", "all user attribute types and
>>> values"
>>> * Grants and denials: Here, you can grant everything
>>>
>>>
>>> When he says add a new entry below the entry where I added
>>> administrativeRole, he means I should right click on the
>>> uid=admin,ou=system and add an entry to that, right? That is what I
>>> have been doing. Is this incorrect?
>>
>> No, this is the way it should be done.
>>
>> The error message is a bit suprising...
>>
>> What version of ADS are you using ?
>>
>>
>> --
>> Regards,
>> Cordialement,
>> Emmanuel Lécharny
>> www.iktek.com
>>
>>
>
>
>
> --
> Thanks,
> Kevin
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
I am using ADS 2.0.0-M2.
Thanks,
Kevin
On Fri, Nov 4, 2011 at 9:39 AM, Emmanuel Lécharny <el...@apache.org> wrote:
> On 11/4/11 2:29 PM, Kevin Hamilton wrote:
>>
>> The cn=admin2Test,uid=admin2,ou=system was never created because the
>> error occurred while I was trying to create it.
>>
>> I was following Oliver's instructions by doing the following:
>> 2) Add a new entry below the entry where you have added the
>> "administrativeRole" attribute. Use the object classes
>> "accessControlSubentry", "subentry" and "top". As RDN attribute name, use
>> "cn" and choose a name of your preference.
>> 2a) You will be asked to specify the subentry. Leave it empty.
>> 2b) You will be asked to specify the ACI element:
>> * Identificator:<your choice>
>> * Priority: 0
>> * Authentication level: simple=non-SASL / strong=SASL (I would choose
>> simple first)
>> * User or element first: User
>> * User classes: Choose "name" and specify your admin2
>> * User permissions:
>> * Protected elements: "entry", "all user attribute types and
>> values"
>> * Grants and denials: Here, you can grant everything
>>
>>
>> When he says add a new entry below the entry where I added
>> administrativeRole, he means I should right click on the
>> uid=admin,ou=system and add an entry to that, right? That is what I
>> have been doing. Is this incorrect?
>
> No, this is the way it should be done.
>
> The error message is a bit suprising...
>
> What version of ADS are you using ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Emmanuel Lécharny <el...@apache.org>.
On 11/4/11 2:29 PM, Kevin Hamilton wrote:
> The cn=admin2Test,uid=admin2,ou=system was never created because the
> error occurred while I was trying to create it.
>
> I was following Oliver's instructions by doing the following:
> 2) Add a new entry below the entry where you have added the
> "administrativeRole" attribute. Use the object classes
> "accessControlSubentry", "subentry" and "top". As RDN attribute name, use
> "cn" and choose a name of your preference.
> 2a) You will be asked to specify the subentry. Leave it empty.
> 2b) You will be asked to specify the ACI element:
> * Identificator:<your choice>
> * Priority: 0
> * Authentication level: simple=non-SASL / strong=SASL (I would choose
> simple first)
> * User or element first: User
> * User classes: Choose "name" and specify your admin2
> * User permissions:
> * Protected elements: "entry", "all user attribute types and values"
> * Grants and denials: Here, you can grant everything
>
>
> When he says add a new entry below the entry where I added
> administrativeRole, he means I should right click on the
> uid=admin,ou=system and add an entry to that, right? That is what I
> have been doing. Is this incorrect?
No, this is the way it should be done.
The error message is a bit suprising...
What version of ADS are you using ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
The cn=admin2Test,uid=admin2,ou=system was never created because the
error occurred while I was trying to create it.
I was following Oliver's instructions by doing the following:
2) Add a new entry below the entry where you have added the
"administrativeRole" attribute. Use the object classes
"accessControlSubentry", "subentry" and "top". As RDN attribute name, use
"cn" and choose a name of your preference.
2a) You will be asked to specify the subentry. Leave it empty.
2b) You will be asked to specify the ACI element:
* Identificator: <your choice>
* Priority: 0
* Authentication level: simple=non-SASL / strong=SASL (I would choose
simple first)
* User or element first: User
* User classes: Choose "name" and specify your admin2
* User permissions:
* Protected elements: "entry", "all user attribute types and values"
* Grants and denials: Here, you can grant everything
When he says add a new entry below the entry where I added
administrativeRole, he means I should right click on the
uid=admin,ou=system and add an entry to that, right? That is what I
have been doing. Is this incorrect?
Thanks,
Kevin
On Fri, Nov 4, 2011 at 9:18 AM, Emmanuel Lécharny <el...@apache.org> wrote:
> On 11/4/11 2:13 PM, Kevin Hamilton wrote:
>>
>> version: 1
>> dn: uid=admin2,ou=systemobjectclass: organizationalPersonobjectclass:
>> personobjectclass: inetOrgPersonobjectclass: topcn: admin2sn:
>> admin2mail:admin@umem.orguid: admin2userPassword:: REMOVED for
>> e-mailadministrativeRole: accessControlSpecificAreacreateTimestamp:
>> 20111104121155ZcreatorsName:
>> 0.9.2342.19200300.100.1.1=admin,2.5.4.11=systementryCSN:
>> 20111104121347.312000Z#000000#000#000000entryParentId: 1entryUUID::
>> REMOVED for e-mailmodifiersName:
>> 0.9.2342.19200300.100.1.1=admin,2.5.4.11=systemmodifyTimestamp:
>> 20111104121347ZpwdHistory:: REMOVED for e-mail
>
> Thanks, but the error messag was not for this entry, but for
> cn=admin2Test,uid=admin2,ou=system
>
> Do you have the LDIF for this entry ?
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Emmanuel Lécharny <el...@apache.org>.
On 11/4/11 2:13 PM, Kevin Hamilton wrote:
> version: 1
> dn: uid=admin2,ou=systemobjectclass: organizationalPersonobjectclass:
> personobjectclass: inetOrgPersonobjectclass: topcn: admin2sn:
> admin2mail:admin@umem.orguid: admin2userPassword:: REMOVED for
> e-mailadministrativeRole: accessControlSpecificAreacreateTimestamp:
> 20111104121155ZcreatorsName:
> 0.9.2342.19200300.100.1.1=admin,2.5.4.11=systementryCSN:
> 20111104121347.312000Z#000000#000#000000entryParentId: 1entryUUID::
> REMOVED for e-mailmodifiersName:
> 0.9.2342.19200300.100.1.1=admin,2.5.4.11=systemmodifyTimestamp:
> 20111104121347ZpwdHistory:: REMOVED for e-mail
Thanks, but the error messag was not for this entry, but for
cn=admin2Test,uid=admin2,ou=system
Do you have the LDIF for this entry ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
version: 1
dn: uid=admin2,ou=systemobjectclass: organizationalPersonobjectclass:
personobjectclass: inetOrgPersonobjectclass: topcn: admin2sn:
admin2mail: admin@umem.orguid: admin2userPassword:: REMOVED for
e-mailadministrativeRole: accessControlSpecificAreacreateTimestamp:
20111104121155ZcreatorsName:
0.9.2342.19200300.100.1.1=admin,2.5.4.11=systementryCSN:
20111104121347.312000Z#000000#000#000000entryParentId: 1entryUUID::
REMOVED for e-mailmodifiersName:
0.9.2342.19200300.100.1.1=admin,2.5.4.11=systemmodifyTimestamp:
20111104121347ZpwdHistory:: REMOVED for e-mail
On Fri, Nov 4, 2011 at 9:01 AM, Emmanuel Lecharny <el...@gmail.com> wrote:
> On 11/4/11 1:23 PM, Kevin Hamilton wrote:
>>
>> Hey Oliver,
>>
>> Thanks so much for your response. I followed your instructions and
>> still had trouble.
>>
>> I checked the source of the prescriptive ACI in my new entry. The
>> source is below.
>>
>> {
>> identificationTag "admin2Tag",
>> precedence 0,
>> authenticationLevel simple,
>> itemOrUserFirst userFirst:
>> {
>> userClasses
>> {
>> name { "uid=admin2,ou=system" }
>> }
>> ,
>> userPermissions
>> {
>> {
>> protectedItems { allUserAttributeTypesAndValues, entry },
>> grantsAndDenials
>> {
>> grantBrowse,
>> grantCompare,
>> grantRename,
>> grantExport,
>> grantRead,
>> grantModify,
>> grantDiscloseOnError,
>> grantFilterMatch,
>> grantImport,
>> grantAdd,
>> grantInvoke,
>> grantRemove,
>> grantReturnDN
>> }
>> }
>> }
>> }
>> }
>>
>>
>> When I try to add this, I get a constraint violation that says ERR_277
>> Attribute userPassword not declared in objectClasses of entry
>> cn=admin2Test,uid=admin2,ou=system
>
> Can you provide the LDIF for this entry ?
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Emmanuel Lecharny <el...@gmail.com>.
On 11/4/11 1:23 PM, Kevin Hamilton wrote:
> Hey Oliver,
>
> Thanks so much for your response. I followed your instructions and
> still had trouble.
>
> I checked the source of the prescriptive ACI in my new entry. The
> source is below.
>
> {
> identificationTag "admin2Tag",
> precedence 0,
> authenticationLevel simple,
> itemOrUserFirst userFirst:
> {
> userClasses
> {
> name { "uid=admin2,ou=system" }
> }
> ,
> userPermissions
> {
> {
> protectedItems { allUserAttributeTypesAndValues, entry },
> grantsAndDenials
> {
> grantBrowse,
> grantCompare,
> grantRename,
> grantExport,
> grantRead,
> grantModify,
> grantDiscloseOnError,
> grantFilterMatch,
> grantImport,
> grantAdd,
> grantInvoke,
> grantRemove,
> grantReturnDN
> }
> }
> }
> }
> }
>
>
> When I try to add this, I get a constraint violation that says ERR_277
> Attribute userPassword not declared in objectClasses of entry
> cn=admin2Test,uid=admin2,ou=system
Can you provide the LDIF for this entry ?
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
Hey Oliver,
Thanks so much for your response. I followed your instructions and
still had trouble.
I checked the source of the prescriptive ACI in my new entry. The
source is below.
{
identificationTag "admin2Tag",
precedence 0,
authenticationLevel simple,
itemOrUserFirst userFirst:
{
userClasses
{
name { "uid=admin2,ou=system" }
}
,
userPermissions
{
{
protectedItems { allUserAttributeTypesAndValues, entry },
grantsAndDenials
{
grantBrowse,
grantCompare,
grantRename,
grantExport,
grantRead,
grantModify,
grantDiscloseOnError,
grantFilterMatch,
grantImport,
grantAdd,
grantInvoke,
grantRemove,
grantReturnDN
}
}
}
}
}
When I try to add this, I get a constraint violation that says ERR_277
Attribute userPassword not declared in objectClasses of entry
cn=admin2Test,uid=admin2,ou=system
So the main admin2 user is of objectclasses inetOrgPerson,
organizationalPerson, person, and top. He has attributes cn, sn, mail,
uid, userPassword. The DN is uid=admin2,ou=system.
I use the PasswordHashingInterceptor and I use a SSHA512. I am not
sure how to go about fixing it.
Any help would be greatly appreciated.
Thanks so much in advance,
Kevin
On Fri, Nov 4, 2011 at 7:37 AM, Oliver Schmidt
<ol...@arcor.de> wrote:
> Hi Kevin,
>
> you'll have to do the following steps now:
>
> 1) Go to the entry for which you want to enable access control. Add the
> attribute "administrativeRole" with the value "accessControlSpecificArea".
> AD-Studio will mention that this attribute does not belong to the schema
> you use. You can ignore this.
> 2) Add a new entry below the entry where you have added the
> "administrativeRole" attribute. Use the object classes
> "accessControlSubentry", "subentry" and "top". As RDN attribute name, use
> "cn" and choose a name of your preference.
> 2a) You will be asked to specify the subentry. Leave it empty.
> 2b) You will be asked to specify the ACI element:
> * Identificator: <your choice>
> * Priority: 0
> * Authentication level: simple=non-SASL / strong=SASL (I would choose
> simple first)
> * User or element first: User
> * User classes: Choose "name" and specify your admin2
> * User permissions:
> * Protected elements: "entry", "all user attribute types and values"
> * Grants and denials: Here, you can grant everything
>
> Once you have set this up, you can play around with your ACI a little bit
> more and maybe grant users to see their own entries and so on. There
> should be some learning trails about access control in the user guides
> which might also help you.
>
> --
> Kind regards
>
> Oliver
>
> Am 03.11.2011, 19:13 Uhr, schrieb Kevin Hamilton <kh...@umem.org>:
>
>> Hello Oliver and Company,
>>
>> I had successfully enabled the accessControl. My issue now is that I
>> am using another superuser I created (I called it admin2) to modify my
>> users. Now, I am no longer to modify my users because he does not have
>> access.
>>
>> I read about Prescriptive ACIs, but the lack of examples left me kind
>> of stumped. How can I grant all access to admin2 only, or something
>> with the dn=uid=admin,ou=system?
>>
>> Thanks,
>> Kevin
>>
>> On Wed, Nov 2, 2011 at 2:04 PM, Oliver Schmidt
>> <ol...@arcor.de> wrote:
>>>
>>> On Wed, 02 Nov 2011 13:59:25 +0100, Kevin Hamilton <kh...@umem.org>
>>> wrote:
>>>
>>>> Hello everyone,
>>>>
>>>> My name is Kevin and I am writing to ask a question about access to
>>>> ApacheDS 2.0.0-M2. Currently I have a bunch of users set up and the
>>>> apacheds is used to authenticate the users on my website. My question
>>>> is about accessing the apacheds. On my Apache Directory Studio, I can
>>>> login as admin and see everything. The problem is that I can also log
>>>> in as any other user in the database and I can see other user's
>>>> information. Not sure if I am being clear.
>>>>
>>>> If someone has their own username and password and also the port and
>>>> address of my server, they can login (using Apache Directory Studio or
>>>> any other client) and see all of the records. Obviously the passwords
>>>> are hashed, but it is still a liability for the users to be able to
>>>> see e-mails/etc of other users.
>>>>
>>>> Is there any way to limit the information that certain users can see
>>>> (ie, they could login, but not see any records)?
>>>>
>>>> Please let me know soon.
>>>>
>>>> Thanks,
>>>> Kevin
>>>
>>>
>>> Hi Kevin,
>>>
>>> I'm moving this topic to the users list...
>>>
>>> There's a chapter about this topic in the doco. Please see the User
>>> Guides
>>> on the topic "authorization".
>>>
>>> Depending on what you intend to allow/disallow your users to see in your
>>> directory, you might also need to write some ACIs. If you want, I can
>>> assist
>>> you setting this up.
>>>
>>> Please note that ehe documentation still mentions the server.xml file.
>>> This
>>> file is however obsolete in version 2.0. Instead, config is done directly
>>> in
>>> the server. You can alter the configuration using ehe Directory Studio.
>>> Just
>>> look under the ou=config node.
>>>
>>> Kind regards
>>> Oliver
>>>
>>
>>
>>
>
>
> --
> Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
>
--
Thanks,
Kevin
Re: [ApacheDS] Re: Access Restriction
Posted by Oliver Schmidt <ol...@arcor.de>.
Hi Kevin,
you'll have to do the following steps now:
1) Go to the entry for which you want to enable access control. Add the
attribute "administrativeRole" with the value "accessControlSpecificArea".
AD-Studio will mention that this attribute does not belong to the schema
you use. You can ignore this.
2) Add a new entry below the entry where you have added the
"administrativeRole" attribute. Use the object classes
"accessControlSubentry", "subentry" and "top". As RDN attribute name, use
"cn" and choose a name of your preference.
2a) You will be asked to specify the subentry. Leave it empty.
2b) You will be asked to specify the ACI element:
* Identificator: <your choice>
* Priority: 0
* Authentication level: simple=non-SASL / strong=SASL (I would choose
simple first)
* User or element first: User
* User classes: Choose "name" and specify your admin2
* User permissions:
* Protected elements: "entry", "all user attribute types and
values"
* Grants and denials: Here, you can grant everything
Once you have set this up, you can play around with your ACI a little bit
more and maybe grant users to see their own entries and so on. There
should be some learning trails about access control in the user guides
which might also help you.
--
Kind regards
Oliver
Am 03.11.2011, 19:13 Uhr, schrieb Kevin Hamilton <kh...@umem.org>:
> Hello Oliver and Company,
>
> I had successfully enabled the accessControl. My issue now is that I
> am using another superuser I created (I called it admin2) to modify my
> users. Now, I am no longer to modify my users because he does not have
> access.
>
> I read about Prescriptive ACIs, but the lack of examples left me kind
> of stumped. How can I grant all access to admin2 only, or something
> with the dn=uid=admin,ou=system?
>
> Thanks,
> Kevin
>
> On Wed, Nov 2, 2011 at 2:04 PM, Oliver Schmidt
> <ol...@arcor.de> wrote:
>> On Wed, 02 Nov 2011 13:59:25 +0100, Kevin Hamilton <kh...@umem.org>
>> wrote:
>>
>>> Hello everyone,
>>>
>>> My name is Kevin and I am writing to ask a question about access to
>>> ApacheDS 2.0.0-M2. Currently I have a bunch of users set up and the
>>> apacheds is used to authenticate the users on my website. My question
>>> is about accessing the apacheds. On my Apache Directory Studio, I can
>>> login as admin and see everything. The problem is that I can also log
>>> in as any other user in the database and I can see other user's
>>> information. Not sure if I am being clear.
>>>
>>> If someone has their own username and password and also the port and
>>> address of my server, they can login (using Apache Directory Studio or
>>> any other client) and see all of the records. Obviously the passwords
>>> are hashed, but it is still a liability for the users to be able to
>>> see e-mails/etc of other users.
>>>
>>> Is there any way to limit the information that certain users can see
>>> (ie, they could login, but not see any records)?
>>>
>>> Please let me know soon.
>>>
>>> Thanks,
>>> Kevin
>>
>>
>> Hi Kevin,
>>
>> I'm moving this topic to the users list...
>>
>> There's a chapter about this topic in the doco. Please see the User
>> Guides
>> on the topic "authorization".
>>
>> Depending on what you intend to allow/disallow your users to see in your
>> directory, you might also need to write some ACIs. If you want, I can
>> assist
>> you setting this up.
>>
>> Please note that ehe documentation still mentions the server.xml file.
>> This
>> file is however obsolete in version 2.0. Instead, config is done
>> directly in
>> the server. You can alter the configuration using ehe Directory Studio.
>> Just
>> look under the ou=config node.
>>
>> Kind regards
>> Oliver
>>
>
>
>
--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
Re: [ApacheDS] Re: Access Restriction
Posted by Kevin Hamilton <kh...@umem.org>.
Hello Oliver and Company,
I had successfully enabled the accessControl. My issue now is that I
am using another superuser I created (I called it admin2) to modify my
users. Now, I am no longer to modify my users because he does not have
access.
I read about Prescriptive ACIs, but the lack of examples left me kind
of stumped. How can I grant all access to admin2 only, or something
with the dn=uid=admin,ou=system?
Thanks,
Kevin
On Wed, Nov 2, 2011 at 2:04 PM, Oliver Schmidt
<ol...@arcor.de> wrote:
> On Wed, 02 Nov 2011 13:59:25 +0100, Kevin Hamilton <kh...@umem.org>
> wrote:
>
>> Hello everyone,
>>
>> My name is Kevin and I am writing to ask a question about access to
>> ApacheDS 2.0.0-M2. Currently I have a bunch of users set up and the
>> apacheds is used to authenticate the users on my website. My question
>> is about accessing the apacheds. On my Apache Directory Studio, I can
>> login as admin and see everything. The problem is that I can also log
>> in as any other user in the database and I can see other user's
>> information. Not sure if I am being clear.
>>
>> If someone has their own username and password and also the port and
>> address of my server, they can login (using Apache Directory Studio or
>> any other client) and see all of the records. Obviously the passwords
>> are hashed, but it is still a liability for the users to be able to
>> see e-mails/etc of other users.
>>
>> Is there any way to limit the information that certain users can see
>> (ie, they could login, but not see any records)?
>>
>> Please let me know soon.
>>
>> Thanks,
>> Kevin
>
>
> Hi Kevin,
>
> I'm moving this topic to the users list...
>
> There's a chapter about this topic in the doco. Please see the User Guides
> on the topic "authorization".
>
> Depending on what you intend to allow/disallow your users to see in your
> directory, you might also need to write some ACIs. If you want, I can assist
> you setting this up.
>
> Please note that ehe documentation still mentions the server.xml file. This
> file is however obsolete in version 2.0. Instead, config is done directly in
> the server. You can alter the configuration using ehe Directory Studio. Just
> look under the ou=config node.
>
> Kind regards
> Oliver
>
--
Thanks,
Kevin