Hi Nicolas,
The documentation does not say that wildcard is supported in groupdn evaluation and I have not seen anything in the code that handles it.
The documentation does not say that wildcard is supported in groupdn evaluation and I have not seen anything in the code that handles it.
IMHO The comment about group dn filter is a bit confusing:
the only place it is supported while evaluating groupdn is within the (filter) part when using the full ldap url notation (dn??scope?(filter)) but that is not really a wildcard but a substring or a presence ldap
filter .
And I do not see how it could be implemented efficiently because
it would mean that either all groups are checked or that
something similar to the ismemberof plugin is used
(and that is neither scalable nor efficient).
Note: for user dn things are easier because there is a single bind dn (and we can easily check if it matches).
So to achieve your goal you should use alternatives:
use groupdn filter as ludwig suggested.
the only place it is supported while evaluating groupdn is within the (filter) part when using the full ldap url notation (dn??scope?(filter)) but that is not really a wildcard but a substring or a presence ldap
filter .
And I do not see how it could be implemented efficiently because
it would mean that either all groups are checked or that
something similar to the ismemberof plugin is used
(and that is neither scalable nor efficient).
Note: for user dn things are easier because there is a single bind dn (and we can easily check if it matches).
So to achieve your goal you should use alternatives:
use groupdn filter as ludwig suggested.
use a group of groups
In any case I hope that there are not too many cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld groups on your system or there will be a serious performance hit.
In any case I hope that there are not too many cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld groups on your system or there will be a serious performance hit.
Regards,
Pierre
Pierre
On Thu, Feb 4, 2021 at 11:49 AM N R <randria.nicolas@xxxxxxxxx> wrote:
Hi Ludwig,
Thanks for your reply.
To clarify, when I say it's not working, it means that members of the
groups are not able to search the "cn=proxy" container's entries.
For example, I've set the following ACI on "cn=proxy":
(targetattr = "*") (target =
"ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld") (version 3.0;acl "ACI
title";allow (all)(groupdn =
"ldap:///cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld");)
User "uid=test" is a member of Group1 within "cn=proxy", but if I try
to search the container, I get no results:
[nicolas@dell ~]$ ldapsearch -D "uid=test,ou=People,dc=domain,dc=tld"
-W -H "ldaps://annuaire.domain.tld" -b
"cn=proxy,ou=Servers,dc=domain,dc=tld" cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=proxy,ou=Servers,dc=domain,dc=tld> with scope subtree
# filter: (objectclass=*)
# requesting: cn
#
# search result
search: 2
result: 0 Success
# numResponses: 1
I "works" when I mention groups explicitely in the ACI like:
(targetattr = "*")
(target = "ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld")
(version 3.0;
acl "Allow only groups members to query this object";
allow (all)
(groupdn = "ldap:///cn=Group1,cn=proxy,ou=Servers,dc=domain,dc=tld" or
groupdn = "ldap:///cn=Group2,cn=proxy,ou=Servers,dc=domain,dc=tld")
;)
Search gives results:
[nicolas@dell ~]$ ldapsearch -D "uid=test,ou=People,dc=domain,dc=tld"
-W -H "ldaps://annuaire.domain.tld" -b
"cn=proxy,ou=Servers,dc=domain,dc=tld" cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <cn=proxy,ou=Servers,dc=domain,dc=tld> with scope subtree
# filter: (objectclass=*)
# requesting: cn
#
# proxy, Servers, domain.tld
dn: cn=proxy,ou=Servers,dc=domain,dc=tld
cn: proxy
[...]
# search result
search: 2
result: 0 Success
# numResponses: 5
# numEntries: 4
I'll try using ACI with the filter as you suggested and take a look at
the logs, maybe I'll be luckier.
Thanks for your help!
Cheers,
Nicolas
2021-02-03 19:07 UTC+01:00, Ludwig Krispenz <krispenz@xxxxxxxxxxx>:
>
> On 03.02.21 16:23, N R wrote:
>> Hi everyone,
>>
>> I'm not an English native speaker, so please forgive me if there's
>> mistakes in this e-mail.
>>
>> OS : Fedora 30
>> 389ds version / build number : 1.4.1.14 / 2020.023.2226
>>
>> I'm struggling with ACI and despite hours of documentation reading, I
>> don't understand how to make it work as I want.
>>
>> Basic directory structure
>> ==================
>> dc=domain,dc=tld
>> |
>> +---ou=Servers
>> |
>> +---cn=proxy <---- here is where I add the ACI
>> |
>> +---cn=group1
>> |
>> +---cn=group2
>> ===================
>> Container "proxy" is a "iphost" object.
>>
>> I'm trying to allow only members of any group inside "cn=proxy" to
>> access attributes of "cn=proxy".
>>
>> Relying on redhat directory server documentation, I've tried the
>> following ACI which didn't worked the way I wanted:
> you don't say in which way it did not work, didn't the group members get
> access or was access granted for dns outside the groups, maybe an
> example of a group and a search would be useful. And in a next step you
> should eventually turn on acl logging, which is very verbose, but coul
> help.
>> (targetattr = "*") (target =
>> "ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld") (version 3.0;acl
>> "Allow only groups members to query this object";allow (all)(groupdn =
>> "ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld??sub");)
>
> did you try to add a filter, like
>
> "ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld??sub?(objectclass=groupofnames");)
> or groupofuniquenames if you define your group with uniquemembers
>
>>
>> (targetattr = "*") (target =
>> "ldap:///cn=proxy,ou=Servers,dc=domain,dc=tld") (version 3.0;acl
>> "Allow only groups members to query this object";allow (all)(groupdn =
>> "ldap:///cn=*,cn=proxy,ou=Servers,dc=domain,dc=tld");)
> this should work if the dn of your groups matches this pattern
>>
>> I used informations provided on
>> https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html/administration_guide/defining_bind_rules#using_the_groupdn_keyword_with_an_ldap_filter
>> but I don't understand how to adapt them to my use-case.
>>
>> The ugly and suboptimal way of solving it would be to list every group
>> within "cn=proxy" in the ACI, but I'm almost sure there's a better way
>> to do it.
>>
>> Thanks in advance for your replies and any possible help.
>>
>> Cheers,
>>
> _______________________________________________
> 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
--
389 Directory Server Development Team
389 Directory Server Development Team
_______________________________________________ 389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@xxxxxxxxxxxxxxxxxxxxxxx
