Is there an elegant way to limit simpleSecurityObject users to reading and searching within their own ou? Perhaps using an ACL based on a regular expression?
Some background: I'm adding LDAP support to Enswitch, which is a soft-switch for multi-tenant hosted telephone services. An Enswitch system has many tenants, each of which is typically a small company. Each tenant is completely independent and for privacy reasons must not be able to see any other tenant on the system. Each tenant has people and telephones. The telephones are physical VoIP telephones that sit on the users' desks, and they have LDAP clients built-in that allow the telephone to search for people within their tenant. Each telephone and each person has a corresponding entry in Enswitch. These are stored in a MySQL database, and pushed to the LDAP server by the Enswitch code. This part is done and working. I'm storing each tenant as a separate ou below the LDAP base, and within the tenant storing each person as a inetOrgPerson and each telephone as a simpleSecurityObject. I have anonymous access to LDAP disabled. This allows the telephones to connect to the LDAP server with their username and password and search for people. The only part missing is limiting the telephone lines to searching within their own tenant (i.e. the same ou).
Any suggestions on how to do this? If this is not feasible using the ou method, I'm willing to consider other methods such as groups.
Hi ,
From my point of view , the easiest way to solve this is to set a search filter on the OU corresponding to the tenant on each phone. Can you modify the software on the phone ?
The other way could be by creating a 389 plugin that add a filter on the good OU regarding the DN of user which make the call to the ldap.
Rgds
On 25/11/2018 11:44, Olivier JUDITH wrote:
From my point of view , the easiest way to solve this is to set a search filter on the OU corresponding to the tenant on each phone. Can you modify the software on the phone ?
Unfortunately not. The telephone handset firmware is written by various third parties, and we have no access to it.
This would also be insecure. Anyone with the username and password of a telephone and who could use an LDAP client such as LDAP search could bypass the filter to see all the users in all the tenants (i.e. every ou).
The other way could be by creating a 389 plugin that add a filter on the good OU regarding the DN of user which make the call to the ldap.
That might be an option. Do you know where I can find documentation on how to do this?
Hi,
I'm using the Redhat documentation on this link https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
Regards
lun. 26 nov. 2018 à 05:46, Alistair Cunningham acunningham@integrics.com a écrit :
On 25/11/2018 11:44, Olivier JUDITH wrote:
From my point of view , the easiest way to solve this is to set a
search filter on the OU corresponding to the tenant on each phone.
Can you modify the software on the phone ?
Unfortunately not. The telephone handset firmware is written by various third parties, and we have no access to it.
This would also be insecure. Anyone with the username and password of a telephone and who could use an LDAP client such as LDAP search could bypass the filter to see all the users in all the tenants (i.e. every ou).
The other way could be by creating a 389 plugin that add a filter on
the good OU regarding the DN of user which make the call to the ldap.
That might be an option. Do you know where I can find documentation on how to do this?
-- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/
On 26/11/2018 18:59, Olivier JUDITH wrote:
Hi,
I'm using the Redhat documentation on this link https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL.
Regards
lun. 26 nov. 2018 à 05:46, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 25/11/2018 11:44, Olivier JUDITH wrote: > From my point of view , the easiest way to solve this is to set a search filter on the OU corresponding to the tenant on each phone. > Can you modify the software on the phone ? Unfortunately not. The telephone handset firmware is written by various third parties, and we have no access to it. This would also be insecure. Anyone with the username and password of a telephone and who could use an LDAP client such as LDAP search could bypass the filter to see all the users in all the tenants (i.e. every ou). > The other way could be by creating a 389 plugin that add a filter on the good OU regarding the DN of user which make the call to the ldap. That might be an option. Do you know where I can find documentation on how to do this? -- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Hi,
Give IT a try. It should work aci: (target="ldap:///ou=tenant1,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci1";allow (read,search) userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com";) aci: (target="ldap:///ou=tenant2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com";)
Let me know
Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham acunningham@integrics.com a écrit :
On 26/11/2018 18:59, Olivier JUDITH wrote:
Hi,
I'm using the Redhat documentation on this link
https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL.
Regards
lun. 26 nov. 2018 à 05:46, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 25/11/2018 11:44, Olivier JUDITH wrote: > From my point of view , the easiest way to solve this is to set a search filter on the OU corresponding to the tenant on each phone. > Can you modify the software on the phone ? Unfortunately not. The telephone handset firmware is written by
various
third parties, and we have no access to it. This would also be insecure. Anyone with the username and password
of a
telephone and who could use an LDAP client such as LDAP search could bypass the filter to see all the users in all the tenants (i.e. every ou). > The other way could be by creating a 389 plugin that add a filter on the good OU regarding the DN of user which make the call to the ldap. That might be an option. Do you know where I can find documentation
on
how to do this? -- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
-- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/ _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
Thank you, I'll give that a go.
On a related topic, do you know why when I try to add a simpleSecurityObject, I get a 'attribute "cn" not allowed' error?
$ cat 1234567890.ldif dn: cn=1234567890,ou=2,dc=integrics,dc=com objectClass: simpleSecurityObject userPassword: abcdef $ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com" ldap_add: Object class violation (65) additional info: attribute "cn" not allowed
I've tried with "uid=1234567890" instead, and it tells me that uid is not allowed.
On 27/11/2018 10:31, Olivier JUDITH wrote:
Hi,
Give IT a try. It should work aci: (target="ldap:///ou=tenant1,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci1";allow (read,search) userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com";) aci: (target="ldap:///ou=tenant2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com";)
Let me know
Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 26/11/2018 18:59, Olivier JUDITH wrote: > Hi, > > I'm using the Redhat documentation on this link > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/plug-in_guide/index That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL. > Regards > > lun. 26 nov. 2018 à 05:46, Alistair Cunningham > <acunningham@integrics.com <mailto:acunningham@integrics.com> <mailto:acunningham@integrics.com <mailto:acunningham@integrics.com>>> a écrit : > > On 25/11/2018 11:44, Olivier JUDITH wrote: > > From my point of view , the easiest way to solve this is to set > a search filter on the OU corresponding to the tenant on each phone. > > Can you modify the software on the phone ? > > Unfortunately not. The telephone handset firmware is written by various > third parties, and we have no access to it. > > This would also be insecure. Anyone with the username and password of a > telephone and who could use an LDAP client such as LDAP search could > bypass the filter to see all the users in all the tenants (i.e. > every ou). > > > The other way could be by creating a 389 plugin that add a > filter on the good OU regarding the DN of user which make the call > to the ldap. > > That might be an option. Do you know where I can find documentation on > how to do this? > > -- > Alistair Cunningham > +1 888 468 3111 > +44 20 799 39 799 > https://enswitch.com/ > > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > -- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/ _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 11/26/18 7:44 PM, Alistair Cunningham wrote:
Thank you, I'll give that a go.
On a related topic, do you know why when I try to add a simpleSecurityObject, I get a 'attribute "cn" not allowed' error?
$ cat 1234567890.ldif dn: cn=1234567890,ou=2,dc=integrics,dc=com objectClass: simpleSecurityObject userPassword: abcdef $ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com" ldap_add: Object class violation (65) additional info: attribute "cn" not allowed
I've tried with "uid=1234567890" instead, and it tells me that uid is not allowed.
You need an objectclass that allows CN or UID, simpleSecurityObject only allows the userpassword attribute
On 27/11/2018 10:31, Olivier JUDITH wrote:
Hi,
Give IT a try. It should work aci: (target="ldap:///ou=tenant1,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci1";allow (read,search) userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com";) aci: (target="ldap:///ou=tenant2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com";)
Let me know
Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 26/11/2018 18:59, Olivier JUDITH wrote: > Hi, > > I'm using the Redhat documentation on this link > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL.
> Regards > > lun. 26 nov. 2018 à 05:46, Alistair Cunningham > <acunningham@integrics.com mailto:acunningham@integrics.com <mailto:acunningham@integrics.com mailto:acunningham@integrics.com>> a écrit : > > On 25/11/2018 11:44, Olivier JUDITH wrote: > > From my point of view , the easiest way to solve this is to set > a search filter on the OU corresponding to the tenant on each phone. > > Can you modify the software on the phone ? > > Unfortunately not. The telephone handset firmware is written by various > third parties, and we have no access to it. > > This would also be insecure. Anyone with the username and password of a > telephone and who could use an LDAP client such as LDAP search could > bypass the filter to see all the users in all the tenants (i.e. > every ou). > > > The other way could be by creating a 389 plugin that add a > filter on the good OU regarding the DN of user which make the call > to the ldap. > > That might be an option. Do you know where I can find documentation on > how to do this? > > -- > Alistair Cunningham > +1 888 468 3111 > +44 20 799 39 799 > https://enswitch.com/ > > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... >
-- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/ _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 27/11/2018 12:32, Mark Reynolds wrote:
On 11/26/18 7:44 PM, Alistair Cunningham wrote:
Thank you, I'll give that a go.
On a related topic, do you know why when I try to add a simpleSecurityObject, I get a 'attribute "cn" not allowed' error?
$ cat 1234567890.ldif dn: cn=1234567890,ou=2,dc=integrics,dc=com objectClass: simpleSecurityObject userPassword: abcdef $ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com" ldap_add: Object class violation (65) additional info: attribute "cn" not allowed
I've tried with "uid=1234567890" instead, and it tells me that uid is not allowed.
You need an objectclass that allows CN or UID, simpleSecurityObject only allows the userpassword attribute
I see, thank you. In that case, what DN should I use instead of "cn=1234567890,ou=2,dc=integrics,dc=com" for this simpleSecurityObject? If no DN, how do I specify the simpleSecurityObject's username?
On 11/26/18 8:35 PM, Alistair Cunningham wrote:
On 27/11/2018 12:32, Mark Reynolds wrote:
On 11/26/18 7:44 PM, Alistair Cunningham wrote:
Thank you, I'll give that a go.
On a related topic, do you know why when I try to add a simpleSecurityObject, I get a 'attribute "cn" not allowed' error?
$ cat 1234567890.ldif dn: cn=1234567890,ou=2,dc=integrics,dc=com objectClass: simpleSecurityObject userPassword: abcdef $ ldapadd -x -D "cn=Directory Manager" -w secret -f 1234567890.ldif adding new entry "cn=1234567890,ou=2,dc=integrics,dc=com" ldap_add: Object class violation (65) additional info: attribute "cn" not allowed
I've tried with "uid=1234567890" instead, and it tells me that uid is not allowed.
You need an objectclass that allows CN or UID, simpleSecurityObject only allows the userpassword attribute
I see, thank you. In that case, what DN should I use instead of "cn=1234567890,ou=2,dc=integrics,dc=com" for this simpleSecurityObject? If no DN, how do I specify the simpleSecurityObject's username?
You should add an objectclass that allows CN (or UID), for example:
dn: cn=1234567890,ou=2,dc=integrics,dc=com objectclass: top objectclass: person objectClass: simpleSecurityObject userPassword: abcdef cn: 1234567890
Technically you don't even need simpleSecurityObject, just "person" alone will get you the entry that you need.
HTH,
Mark
On 27/11/2018 15:05, Mark Reynolds wrote:
I see, thank you. In that case, what DN should I use instead of "cn=1234567890,ou=2,dc=integrics,dc=com" for this simpleSecurityObject? If no DN, how do I specify the simpleSecurityObject's username?
You should add an objectclass that allows CN (or UID), for example:
dn: cn=1234567890,ou=2,dc=integrics,dc=com objectclass: top objectclass: person objectClass: simpleSecurityObject userPassword: abcdef cn: 1234567890
Technically you don't even need simpleSecurityObject, just "person" alone will get you the entry that you need.
Thank you, it works doing it purely as a person.
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
On 27/11/2018 10:31, Olivier JUDITH wrote:
Hi,
Give IT a try. It should work aci: (target="ldap:///ou=tenant1,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci1";allow (read,search) userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com";) aci: (target="ldap:///ou=tenant2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com";)
Let me know
Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 26/11/2018 18:59, Olivier JUDITH wrote: > Hi, > > I'm using the Redhat documentation on this link > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html-single/plug-in_guide/index That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL. > Regards > > lun. 26 nov. 2018 à 05:46, Alistair Cunningham > <acunningham@integrics.com <mailto:acunningham@integrics.com> <mailto:acunningham@integrics.com <mailto:acunningham@integrics.com>>> a écrit : > > On 25/11/2018 11:44, Olivier JUDITH wrote: > > From my point of view , the easiest way to solve this is to set > a search filter on the OU corresponding to the tenant on each phone. > > Can you modify the software on the phone ? > > Unfortunately not. The telephone handset firmware is written by various > third parties, and we have no access to it. > > This would also be insecure. Anyone with the username and password of a > telephone and who could use an LDAP client such as LDAP search could > bypass the filter to see all the users in all the tenants (i.e. > every ou). > > > The other way could be by creating a 389 plugin that add a > filter on the good OU regarding the DN of user which make the call > to the ldap. > > That might be an option. Do you know where I can find documentation on > how to do this? > > -- > Alistair Cunningham > +1 888 468 3111 > +44 20 799 39 799 > https://enswitch.com/ > > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org > -- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/ _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org <mailto:389-users@lists.fedoraproject.org> To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org <mailto:389-users-leave@lists.fedoraproject.org> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.org
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
There might be an aci that is allowing anonymous access to basic entries. By default if there are no ACI's then access is completely blocked except for Directory Manager. So some aci is allowing access. We need to see all the ACI's you have:
For example, this would list all the aci's under dc=example,dc=com:
# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci
I suspect there is an aci with a userdn that equals "anyone", but we'll see...
On 27/11/2018 10:31, Olivier JUDITH wrote:
Hi,
Give IT a try. It should work aci: (target="ldap:///ou=tenant1,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci1";allow (read,search) userdn="ldap:///uid=*,ou=tenant1,dc=example,dc=com";) aci: (target="ldap:///ou=tenant2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=tenant2,dc=example,dc=com";)
Let me know
Le mar. 27 nov. 2018 à 00:03, Alistair Cunningham <acunningham@integrics.com mailto:acunningham@integrics.com> a écrit :
On 26/11/2018 18:59, Olivier JUDITH wrote: > Hi, > > I'm using the Redhat documentation on this link > https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
That looks rather complex. It's a real shame that there's no way of limiting users to the same ou using a regular expression ACL.
> Regards > > lun. 26 nov. 2018 à 05:46, Alistair Cunningham > <acunningham@integrics.com mailto:acunningham@integrics.com <mailto:acunningham@integrics.com mailto:acunningham@integrics.com>> a écrit : > > On 25/11/2018 11:44, Olivier JUDITH wrote: > > From my point of view , the easiest way to solve this is to set > a search filter on the OU corresponding to the tenant on each phone. > > Can you modify the software on the phone ? > > Unfortunately not. The telephone handset firmware is written by various > third parties, and we have no access to it. > > This would also be insecure. Anyone with the username and password of a > telephone and who could use an LDAP client such as LDAP search could > bypass the filter to see all the users in all the tenants (i.e. > every ou). > > > The other way could be by creating a 389 plugin that add a > filter on the good OU regarding the DN of user which make the call > to the ldap. > > That might be an option. Do you know where I can find documentation on > how to do this? > > -- > Alistair Cunningham > +1 888 468 3111 > +44 20 799 39 799 > https://enswitch.com/ > > > _______________________________________________ > 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org > To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject.... >
-- Alistair Cunningham +1 888 468 3111 +44 20 799 39 799 https://enswitch.com/ _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org mailto:389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org mailto:389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 28/11/2018 12:08, Mark Reynolds wrote:
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
There might be an aci that is allowing anonymous access to basic entries. By default if there are no ACI's then access is completely blocked except for Directory Manager. So some aci is allowing access. We need to see all the ACI's you have:
For example, this would list all the aci's under dc=example,dc=com:
# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci
I suspect there is an aci with a userdn that equals "anyone", but we'll see...
There is indeed. Shall I delete it?
$ ldapsearch -x -D "cn=Directory Manager" -w secret -b "dc=integrics,dc=com" "aci=*" aci # extended LDIF # # LDAPv3 # base <dc=integrics,dc=com> with scope subtree # filter: aci=* # requesting: aci #
# integrics.com dn: dc=integrics,dc=com aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";) aci: (targetattr="carLicense || description || displayName || facsimileTelepho neNumber || homePhone || homePostalAddress || initials || jpegPhoto || labele dURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddr ess || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertif icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for commo n attributes"; allow (write) userdn="ldap:///self";) aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow (all) (groupdn = "ldap:///cn=Directory Administrators, dc=integrics,dc=com"); )
# 2, integrics.com dn: ou=2,dc=integrics,dc=com aci: (target="ldap:///ou=2,dc=integrics,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com";)
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
On 11/27/18 8:15 PM, Alistair Cunningham wrote:
On 28/11/2018 12:08, Mark Reynolds wrote:
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
There might be an aci that is allowing anonymous access to basic entries. By default if there are no ACI's then access is completely blocked except for Directory Manager. So some aci is allowing access. We need to see all the ACI's you have:
For example, this would list all the aci's under dc=example,dc=com:
# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci
I suspect there is an aci with a userdn that equals "anyone", but we'll see...
There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";)
That depends. Do you have any clients that expect to have anonymous access to entries? Removing this aci will block everyone from access to the database - then you need to add aci's to open up access to the users/groups of your choosing.
So to accomplish what you want in this email then yes delete it, but it could break clients that be expecting anonymous access to be allowed. So be careful :-)
$ ldapsearch -x -D "cn=Directory Manager" -w secret -b "dc=integrics,dc=com" "aci=*" aci # extended LDIF # # LDAPv3 # base <dc=integrics,dc=com> with scope subtree # filter: aci=* # requesting: aci #
# integrics.com dn: dc=integrics,dc=com aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";) aci: (targetattr="carLicense || description || displayName || facsimileTelepho neNumber || homePhone || homePostalAddress || initials || jpegPhoto || labele dURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddr ess || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertif icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for commo n attributes"; allow (write) userdn="ldap:///self";) aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow (all) (groupdn = "ldap:///cn=Directory Administrators, dc=integrics,dc=com"); )
# 2, integrics.com dn: ou=2,dc=integrics,dc=com aci: (target="ldap:///ou=2,dc=integrics,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com";)
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
Thank you, it's now working correctly! We don't need anonymous access.
Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
On 29/11/2018 03:54, Mark Reynolds wrote:
On 11/27/18 8:15 PM, Alistair Cunningham wrote:
On 28/11/2018 12:08, Mark Reynolds wrote:
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
There might be an aci that is allowing anonymous access to basic entries. By default if there are no ACI's then access is completely blocked except for Directory Manager. So some aci is allowing access. We need to see all the ACI's you have:
For example, this would list all the aci's under dc=example,dc=com:
# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci
I suspect there is an aci with a userdn that equals "anyone", but we'll see...
There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";)
That depends. Do you have any clients that expect to have anonymous access to entries? Removing this aci will block everyone from access to the database - then you need to add aci's to open up access to the users/groups of your choosing.
So to accomplish what you want in this email then yes delete it, but it could break clients that be expecting anonymous access to be allowed. So be careful :-)
$ ldapsearch -x -D "cn=Directory Manager" -w secret -b "dc=integrics,dc=com" "aci=*" aci # extended LDIF # # LDAPv3 # base <dc=integrics,dc=com> with scope subtree # filter: aci=* # requesting: aci #
# integrics.com dn: dc=integrics,dc=com aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";) aci: (targetattr="carLicense || description || displayName || facsimileTelepho neNumber || homePhone || homePostalAddress || initials || jpegPhoto || labele dURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddr ess || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertif icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for commo n attributes"; allow (write) userdn="ldap:///self";) aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow (all) (groupdn = "ldap:///cn=Directory Administrators, dc=integrics,dc=com"); )
# 2, integrics.com dn: ou=2,dc=integrics,dc=com aci: (target="ldap:///ou=2,dc=integrics,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com";)
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 11/29/2018 12:32 AM, Alistair Cunningham wrote:
Thank you, it's now working correctly! We don't need anonymous access.
Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
you should look into Macro ACIs, cahp 18.16 soemthing like: aci: (target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";
or maybe [$dn] in the userdn to be able to target subentries.
Now it is question if you should use this. If your tree is very dynamic and you add or remove subtrees and don't want to change the acis each time macro acis are the right approach, but if you have a few subtrees which are stable, macroacis can be a bit of overhead in evaluating and adding indiuvidual acis is only a bit tedious in the beginning
On 29/11/2018 03:54, Mark Reynolds wrote:
On 11/27/18 8:15 PM, Alistair Cunningham wrote:
On 28/11/2018 12:08, Mark Reynolds wrote:
On 11/27/18 7:24 PM, Alistair Cunningham wrote:
I've added these acis, but a telephone (with objectClass 'person') in tenant1 can still see people (with objectClass 'inetOrgPerson') in tenant2. Presumably there needs to also be a blanket aci to forbid all telephones from viewing other tenants, that these tenant-specific allow acis then override?
There might be an aci that is allowing anonymous access to basic entries. By default if there are no ACI's then access is completely blocked except for Directory Manager. So some aci is allowing access. We need to see all the ACI's you have:
For example, this would list all the aci's under dc=example,dc=com:
# ldapsearch -D "cn=directory manager" -W -b "dc=example,dc=com" aci=* aci
I suspect there is an aci with a userdn that equals "anyone", but we'll see...
There is indeed. Shall I delete it?
aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";)
That depends. Do you have any clients that expect to have anonymous access to entries? Removing this aci will block everyone from access to the database - then you need to add aci's to open up access to the users/groups of your choosing.
So to accomplish what you want in this email then yes delete it, but it could break clients that be expecting anonymous access to be allowed. So be careful :-)
$ ldapsearch -x -D "cn=Directory Manager" -w secret -b "dc=integrics,dc=com" "aci=*" aci # extended LDIF # # LDAPv3 # base <dc=integrics,dc=com> with scope subtree # filter: aci=* # requesting: aci #
# integrics.com dn: dc=integrics,dc=com aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous ac cess"; allow (read, search, compare) userdn="ldap:///anyone";) aci: (targetattr="carLicense || description || displayName || facsimileTelepho neNumber || homePhone || homePostalAddress || initials || jpegPhoto || labele dURI || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredAddr ess || roomNumber || secretary || seeAlso || st || street || telephoneNumber || telexNumber || title || userCertificate || userPassword || userSMIMECertif icate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for commo n attributes"; allow (write) userdn="ldap:///self";) aci: (targetattr ="*")(version 3.0;acl "Directory Administrators Group";allow (all) (groupdn = "ldap:///cn=Directory Administrators, dc=integrics,dc=com"); )
# 2, integrics.com dn: ou=2,dc=integrics,dc=com aci: (target="ldap:///ou=2,dc=integrics,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///uid=*,ou=2,dc=integrics,dc=com";)
# search result search: 2 result: 0 Success
# numResponses: 3 # numEntries: 2
389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
On 29/11/2018 20:12, Ludwig Krispenz wrote:> On 11/29/2018 12:32 AM, Alistair Cunningham wrote:
Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
you should look into Macro ACIs, cahp 18.16 soemthing like: aci: (target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";
or maybe [$dn] in the userdn to be able to target subentries.
Now it is question if you should use this. If your tree is very dynamic and you add or remove subtrees and don't want to change the acis each time macro acis are the right approach, but if you have a few subtrees which are stable, macroacis can be a bit of overhead in evaluating and adding indiuvidual acis is only a bit tedious in the beginning
The tree design will be simple and stable, with one ou for each tenant directly under the base. However, there may be a very large number of them - potentially hundreds of thousands. Would you recommend Macro ACIs in this case?
On 11/29/2018 12:12 PM, Alistair Cunningham wrote:
On 29/11/2018 20:12, Ludwig Krispenz wrote:> On 11/29/2018 12:32 AM, Alistair Cunningham wrote:
Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
you should look into Macro ACIs, cahp 18.16 soemthing like: aci: (target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";
or maybe [$dn] in the userdn to be able to target subentries.
Now it is question if you should use this. If your tree is very dynamic and you add or remove subtrees and don't want to change the acis each time macro acis are the right approach, but if you have a few subtrees which are stable, macroacis can be a bit of overhead in evaluating and adding indiuvidual acis is only a bit tedious in the beginning
The tree design will be simple and stable, with one ou for each tenant directly under the base. However, there may be a very large number of them - potentially hundreds of thousands. Would you recommend Macro ACIs in this case?
yes, if they work for you.
There is always two phases in aci evaluation: 1] find all the acis applying to the target, this is negatively impacted by a high number of acis and the complexity, eg macros or wildcards, targetfilterss .... 2] applying the aci, which means evaluating the bind rules, also negatively affected by complexity, eg macros, targetattrs,...... and/or clauses ....
In your case I think it is more efficient to match and apply one macro aci than finding the one simple aci in thousands of acis
On 30/11/2018 00:00, Ludwig Krispenz wrote:
On 11/29/2018 12:12 PM, Alistair Cunningham wrote:
On 29/11/2018 20:12, Ludwig Krispenz wrote:> On 11/29/2018 12:32 AM, Alistair Cunningham wrote:
Is there a neat way to replace the ACL below that needs to be added once for each ou with one single ACL that works for every ou? Perhaps some way of saying that the "ou=2,dc=example,dc=com" in the target part must match the same string in the userdn part?
aci: (target="ldap:///ou=2,dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,ou=2,dc=example,dc=com";)
you should look into Macro ACIs, cahp 18.16 soemthing like: aci: (target="ldap:///*($dn*),dc=example,dc=com")(targetattr=*)(version 3.0;acl "aci2";allow (read,search) userdn="ldap:///cn=*,*($dn)*,dc=example,dc=com";
or maybe [$dn] in the userdn to be able to target subentries.
Now it is question if you should use this. If your tree is very dynamic and you add or remove subtrees and don't want to change the acis each time macro acis are the right approach, but if you have a few subtrees which are stable, macroacis can be a bit of overhead in evaluating and adding indiuvidual acis is only a bit tedious in the beginning
The tree design will be simple and stable, with one ou for each tenant directly under the base. However, there may be a very large number of them - potentially hundreds of thousands. Would you recommend Macro ACIs in this case?
yes, if they work for you.
There is always two phases in aci evaluation: 1] find all the acis applying to the target, this is negatively impacted by a high number of acis and the complexity, eg macros or wildcards, targetfilterss .... 2] applying the aci, which means evaluating the bind rules, also negatively affected by complexity, eg macros, targetattrs,...... and/or clauses ....
In your case I think it is more efficient to match and apply one macro aci than finding the one simple aci in thousands of acis
Thanks!
This is all done and working. In the end, the changes I needed were:
dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse
dn: dc=example,dc=com changetype: modify delete: aci aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
dn: dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///($dn),dc=example,dc=com")(targetattr!="userPassword || aci")(version 3.0;acl "aci";allow (read,search) userdn="ldap:///cn=*,[$dn],dc=example,dc=com";)
This page was also useful:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/h...
Many thanks to Olivier Judith, Mark Raynolds, and Ludwig Krispenz for their help!
On 12/2/18 7:45 PM, Alistair Cunningham wrote:
This is all done and working. In the end, the changes I needed were:
dn: cn=config changetype: modify replace: nsslapd-allow-anonymous-access nsslapd-allow-anonymous-access: rootdse
dn: dc=example,dc=com changetype: modify delete: aci aci: (targetattr!="userPassword || aci")(version 3.0; acl "Enable anonymous access"; allow (read, search, compare) userdn="ldap:///anyone";)
dn: dc=example,dc=com changetype: modify add: aci aci: (target="ldap:///($dn),dc=example,dc=com")(targetattr!="userPassword || aci")(version 3.0;acl "aci";allow (read,search) userdn="ldap:///cn=*,[$dn],dc=example,dc=com";)
This page was also useful:
https://access.redhat.com/documentation/en-us/red_hat_directory_server/9.0/h...
Many thanks to Olivier Judith, Mark Raynolds, and Ludwig Krispenz for their help!
Glad you got working, and glad Ludwig mentioned macro aci's (these are often overlooked)!
Best Regards,
Mark
389-users@lists.fedoraproject.org