Dear Peter
Thanks for your update. As you specified I am trying to set up this option. Thanks again
Geo.
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 8:34 PM, Peter Gietz peter.gietz@daasi.de wrote:
Hi Geo,
I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that.
What you should do as I proposed (solution 2b.):
define an attribute like allowedService and manage that instead of using groups.
create accounts for each application (all applications have binddn and bind password to connect to an ldap server)
And the restrict access rights of these DNs via ACLs such as :
access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ...
access to * by * none
Cheers,
Peter
Am 07.05.2013 14:59, schrieb Geo P.C.:
Dear Peter,
Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details:
In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application.
Please let us know is there any additional configuration we need to done. Can you please help me on it.
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 5:51 PM, Peter Gietz peter.gietz@daasi.de wrote:
1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices.
2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups
3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that!
4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups
if not 4.) my recommendation would be 2a.) being the minimal invasive alternative.
Hope this helps,
Peter
Am 06.05.2013 12:21, schrieb Geo P.C.:
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication.
Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue.
Thanks Geo
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Dear Peter
As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as
dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People
dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab
dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab
dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab
Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access.
We have created two organizational units as
dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix
dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab
In zabbix application configured as follows:
host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: password
In slapd.conf file we added acl as:
access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break
But with this configuration we are unable to login to zabix application with user user1.
Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done.
Thanks in advance. Geo Skype id: geopcgeo
On Thu, May 9, 2013 at 4:30 PM, Geo P.C. pcgeopc@gmail.com wrote:
Dear Peter
Thanks for your update. As you specified I am trying to set up this option. Thanks again
Geo.
On Tue, May 7, 2013 at 8:34 PM, Peter Gietz peter.gietz@daasi.de wrote:
Hi Geo,
I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that.
What you should do as I proposed (solution 2b.):
define an attribute like allowedService and manage that instead of using groups.
create accounts for each application (all applications have binddn and bind password to connect to an ldap server)
And the restrict access rights of these DNs via ACLs such as :
access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ...
access to * by * none
Cheers,
Peter
Am 07.05.2013 14:59, schrieb Geo P.C.:
Dear Peter,
Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details:
In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application.
Please let us know is there any additional configuration we need to done. Can you please help me on it.
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 5:51 PM, Peter Gietz peter.gietz@daasi.de wrote:
1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices.
2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups
3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that!
4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups
if not 4.) my recommendation would be 2a.) being the minimal invasive alternative.
Hope this helps,
Peter
Am 06.05.2013 12:21, schrieb Geo P.C.:
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication.
Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue.
Thanks Geo
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate.
like so:
LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password
Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password
ACL configuration:
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read
Hope this works for you.
Cheers,
Peter
Am 13.05.2013 10:54, schrieb Geo P.C.:
Dear Peter
As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as
dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People
dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab
dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab
dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab
Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access.
We have created two organizational units as
dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix
dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab
In zabbix application configured as follows:
host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: passwordIn slapd.conf file we added acl as:
access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break
But with this configuration we are unable to login to zabix application with user user1.
Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done.
Thanks in advance. Geo Skype id: geopcgeo
On Thu, May 9, 2013 at 4:30 PM, Geo P.C. <pcgeopc@gmail.com mailto:pcgeopc@gmail.com> wrote:
Dear Peter Thanks for your update. As you specified I am trying to set up this option. Thanks again Geo. On Tue, May 7, 2013 at 8:34 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: Hi Geo, I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that. What you should do as I proposed (solution 2b.): define an attribute like allowedService and manage that instead of using groups. create accounts for each application (all applications have binddn and bind password to connect to an ldap server) And the restrict access rights of these DNs via ACLs such as : access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ... access to * by * none Cheers, Peter Am 07.05.2013 14:59, schrieb Geo P.C.:Dear Peter, Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details: In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully. Now we created an alias as follows: dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com objectclass: alias objectclass: extensibleObject objectclass: top uid: geo_pc Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application. Please let us know is there any additional configuration we need to done. Can you please help me on it. Thanks Geo *Thanks & Regards Geo P.C. www.geopc.co.cc <http://www.geopc.co.cc>* On Tue, May 7, 2013 at 5:51 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: 1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices. 2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups 3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that! 4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups if not 4.) my recommendation would be 2a.) being the minimal invasive alternative. Hope this helps, Peter Am 06.05.2013 12:21, schrieb Geo P.C.:Hi We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication. Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ . Inline image 1 On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users. So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users. Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue. Thanks Geo-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web: www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web: www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Thanks Peter.
We created a user as follows:
dn: cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: zabbix sn: zabbix userPassword:: e1NIQX1NaTh4WX2V3dabTBGZ2JWRnY0L2s9
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Oct 17 2012 19:48:03) $ buildd@komainu :/build/buildd/openldap-2.4.28/debian/build/clients/tools (LDAP library: OpenLDAP 20428)
In /usr/share/slapd/slapd.conf we added acl but it’s not affecting so we added in olcAccess. It also default contents and please see the current settings.
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs =userPassword by self write by * auth olcAccess: {4}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filte r="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix,ou=App lications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
With this setting zabbix application can be logged by all users in ou=People,dc=prime,dc=ds,dc=geo,dc=com.
Can you please have a check and please help me on it. Thanks in advance.
Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Mon, May 13, 2013 at 4:04 PM, Peter Gietz peter.gietz@daasi.de wrote:
You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate.
like so:
LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password
Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password
ACL configuration:
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read
Hope this works for you.
Cheers,
Peter
Am 13.05.2013 10:54, schrieb Geo P.C.:
Dear Peter
As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as
dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People
dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab
dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab
dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab
Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access.
We have created two organizational units as
dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix
dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab
In zabbix application configured as follows:
host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: passwordIn slapd.conf file we added acl as:
access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break
But with this configuration we are unable to login to zabix application with user user1.
Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done.
Thanks in advance. Geo Skype id: geopcgeo
On Thu, May 9, 2013 at 4:30 PM, Geo P.C. pcgeopc@gmail.com wrote:
Dear Peter
Thanks for your update. As you specified I am trying to set up this option. Thanks again
Geo.
On Tue, May 7, 2013 at 8:34 PM, Peter Gietz peter.gietz@daasi.dewrote:
Hi Geo,
I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that.
What you should do as I proposed (solution 2b.):
define an attribute like allowedService and manage that instead of using groups.
create accounts for each application (all applications have binddn and bind password to connect to an ldap server)
And the restrict access rights of these DNs via ACLs such as :
access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ...
access to * by * none
Cheers,
Peter
Am 07.05.2013 14:59, schrieb Geo P.C.:
Dear Peter,
Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details:
In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application.
Please let us know is there any additional configuration we need to done. Can you please help me on it.
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 5:51 PM, Peter Gietz peter.gietz@daasi.dewrote:
1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices.
2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups
3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that!
4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups
if not 4.) my recommendation would be 2a.) being the minimal invasive alternative.
Hope this helps,
Peter
Am 06.05.2013 12:21, schrieb Geo P.C.:
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication.
Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue.
Thanks Geo
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Your third acl allows everyone to read (by * read). You should delete that
olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read
Peter
Am 13.05.2013 14:46, schrieb Geo P.C.:
Thanks Peter.
We created a user as follows:
dn: cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: zabbix sn: zabbix userPassword:: e1NIQX1NaTh4WX2V3dabTBGZ2JWRnY0L2s9
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Oct 17 2012 19:48:03) $
buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/clients/tools (LDAP library: OpenLDAP 20428)
In /usr/share/slapd/slapd.conf we added acl but it’s not affecting so we added in olcAccess. It also default contents and please see the current settings.
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs =userPassword by self write by * auth olcAccess: {4}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filte r="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix,ou=App lications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
With this setting zabbix application can be logged by all users in ou=People,dc=prime,dc=ds,dc=geo,dc=com.
Can you please have a check and please help me on it. Thanks in advance.
Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc http://www.geopc.co.cc*
On Mon, May 13, 2013 at 4:04 PM, Peter Gietz <peter.gietz@daasi.de mailto:peter.gietz@daasi.de> wrote:
You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate. like so: LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password ACL configuration: access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read Hope this works for you. Cheers, Peter Am 13.05.2013 10:54, schrieb Geo P.C.:Dear Peter As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access. We have created two organizational units as dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab In zabbix application configured as follows: host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: password In slapd.conf file we added acl as: access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break But with this configuration we are unable to login to zabix application with user user1. Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done. Thanks in advance. Geo Skype id: geopcgeo On Thu, May 9, 2013 at 4:30 PM, Geo P.C. <pcgeopc@gmail.com <mailto:pcgeopc@gmail.com>> wrote: Dear Peter Thanks for your update. As you specified I am trying to set up this option. Thanks again Geo. On Tue, May 7, 2013 at 8:34 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: Hi Geo, I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that. What you should do as I proposed (solution 2b.): define an attribute like allowedService and manage that instead of using groups. create accounts for each application (all applications have binddn and bind password to connect to an ldap server) And the restrict access rights of these DNs via ACLs such as : access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ... access to * by * none Cheers, Peter Am 07.05.2013 14:59, schrieb Geo P.C.:Dear Peter, Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details: In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully. Now we created an alias as follows: dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com objectclass: alias objectclass: extensibleObject objectclass: top uid: geo_pc Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application. Please let us know is there any additional configuration we need to done. Can you please help me on it. Thanks Geo *Thanks & Regards Geo P.C. www.geopc.co.cc <http://www.geopc.co.cc>* On Tue, May 7, 2013 at 5:51 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: 1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices. 2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups 3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that! 4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups if not 4.) my recommendation would be 2a.) being the minimal invasive alternative. Hope this helps, Peter Am 06.05.2013 12:21, schrieb Geo P.C.:Hi We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication. Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ . Inline image 1 On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users. So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users. Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue. Thanks Geo-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web: www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web: www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web: www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Dear Peter
Thanks for your updates. I am still unable to fix this issue.
When the acl setup is as follows:
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix, ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
No user can able to login. We tried various option we interchanged rules but still getting same result.
Please see the error log:
May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 ACCEPT from IP= 192.168.1.210:49776 (IP=0.0.0.0:636) May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 TLS established tls_ssf=256 ssf=256 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 BIND dn="cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" method=128 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 RESULT tag=97 err=49 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH attr=namingContexts supportedLdapVersion altServer supportedControl supportedExtension supportedFeatures supportedSASLMechanisms May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 ENTRY dn="" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SRCH base="dc=prime,dc=ds,dc=geo,dc=com" scope=2 deref=0 filter="(uid=user1)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 closed (connection lost)
Can you please have a check. Fedup with this. can you please help to configure it. Thanks in advance. Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Mon, May 13, 2013 at 8:27 PM, Peter Gietz peter.gietz@daasi.de wrote:
Your third acl allows everyone to read (by * read). You should delete that
olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read
Peter
Am 13.05.2013 14:46, schrieb Geo P.C.:
Thanks Peter.
We created a user as follows:
dn: cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: zabbix sn: zabbix userPassword:: e1NIQX1NaTh4WX2V3dabTBGZ2JWRnY0L2s9
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Oct 17 2012 19:48:03) $
buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/clients/tools (LDAP library: OpenLDAP 20428)
In /usr/share/slapd/slapd.conf we added acl but it’s not affecting so we added in olcAccess. It also default contents and please see the current settings.
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs =userPassword by self write by * auth olcAccess: {4}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filte r="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix,ou=App lications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
With this setting zabbix application can be logged by all users in ou=People,dc=prime,dc=ds,dc=geo,dc=com.
Can you please have a check and please help me on it. Thanks in advance.
Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Mon, May 13, 2013 at 4:04 PM, Peter Gietz peter.gietz@daasi.de wrote:
You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate.
like so:
LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password
Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password
ACL configuration:
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read
Hope this works for you.
Cheers,
Peter
Am 13.05.2013 10:54, schrieb Geo P.C.:
Dear Peter
As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as
dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People
dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab
dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab
dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab
Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access.
We have created two organizational units as
dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix
dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab
In zabbix application configured as follows:
host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: passwordIn slapd.conf file we added acl as:
access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break
But with this configuration we are unable to login to zabix application with user user1.
Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done.
Thanks in advance. Geo Skype id: geopcgeo
On Thu, May 9, 2013 at 4:30 PM, Geo P.C. pcgeopc@gmail.com wrote:
Dear Peter
Thanks for your update. As you specified I am trying to set up this option. Thanks again
Geo.
On Tue, May 7, 2013 at 8:34 PM, Peter Gietz peter.gietz@daasi.dewrote:
Hi Geo,
I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that.
What you should do as I proposed (solution 2b.):
define an attribute like allowedService and manage that instead of using groups.
create accounts for each application (all applications have binddn and bind password to connect to an ldap server)
And the restrict access rights of these DNs via ACLs such as :
access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ...
access to * by * none
Cheers,
Peter
Am 07.05.2013 14:59, schrieb Geo P.C.:
Dear Peter,
Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details:
In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application.
Please let us know is there any additional configuration we need to done. Can you please help me on it.
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 5:51 PM, Peter Gietz peter.gietz@daasi.dewrote:
1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices.
2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups
3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that!
4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups
if not 4.) my recommendation would be 2a.) being the minimal invasive alternative.
Hope this helps,
Peter
Am 06.05.2013 12:21, schrieb Geo P.C.:
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication.
Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue.
Thanks Geo
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 BIND dn="cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" method=128 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 RESULT tag=97 err=49 text=
ERR 49 means invalid credentials. Check your password!
Fedup with this.
If you are fedup with this hire an expert. As Quanah said in this thread "it is trivial".
Cheers,
Peter
Am 14.05.2013 10:42, schrieb Geo P.C.:
Dear Peter
Thanks for your updates. I am still unable to fix this issue.
When the acl setup is as follows:
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix, ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
No user can able to login. We tried various option we interchanged rules but still getting same result.
Please see the error log:
May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 ACCEPT from IP=192.168.1.210:49776 http://192.168.1.210:49776 (IP=0.0.0.0:636 http://0.0.0.0:636) May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 TLS established tls_ssf=256 ssf=256 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 BIND dn="cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" method=128 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 RESULT tag=97 err=49 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH attr=namingContexts supportedLdapVersion altServer supportedControl supportedExtension supportedFeatures supportedSASLMechanisms May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 ENTRY dn="" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SRCH base="dc=prime,dc=ds,dc=geo,dc=com" scope=2 deref=0 filter="(uid=user1)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 closed (connection lost)
Can you please have a check. Fedup with this. can you please help to configure it. Thanks in advance. Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc http://www.geopc.co.cc*
On Mon, May 13, 2013 at 8:27 PM, Peter Gietz <peter.gietz@daasi.de mailto:peter.gietz@daasi.de> wrote:
Your third acl allows everyone to read (by * read). You should delete thatolcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * readPeter Am 13.05.2013 14:46, schrieb Geo P.C.:Thanks Peter. We created a user as follows: dn: cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: zabbix sn: zabbix userPassword:: e1NIQX1NaTh4WX2V3dabTBGZ2JWRnY0L2s9 root@geopc:/etc/ldap/slapd.d/cn=config# <mailto:root@geopc:/etc/ldap/slapd.d/cn=config#> ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Oct 17 2012 19:48:03) $ buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/clients/tools <mailto:buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/clients/tools> (LDAP library: OpenLDAP 20428) In /usr/share/slapd/slapd.conf we added acl but it’s not affecting so we added in olcAccess. It also default contents and please see the current settings. root@geopc:/etc/ldap/slapd.d/cn=config# <mailto:root@geopc:/etc/ldap/slapd.d/cn=config#> ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs =userPassword by self write by * auth olcAccess: {4}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filte r="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix,ou=App lications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read dn: olcDatabase={2}hdb,cn=config root@geopc:/etc/ldap/slapd.d/cn=config# <mailto:root@geopc:/etc/ldap/slapd.d/cn=config#> With this setting zabbix application can be logged by all users in ou=People,dc=prime,dc=ds,dc=geo,dc=com. Can you please have a check and please help me on it. Thanks in advance. Geo *Thanks & Regards Geo P.C. www.geopc.co.cc <http://www.geopc.co.cc>* On Mon, May 13, 2013 at 4:04 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate. like so: LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password ACL configuration: access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read Hope this works for you. Cheers, Peter Am 13.05.2013 10:54, schrieb Geo P.C.:Dear Peter As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access. We have created two organizational units as dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab In zabbix application configured as follows: host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: password In slapd.conf file we added acl as: access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break But with this configuration we are unable to login to zabix application with user user1. Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done. Thanks in advance. Geo Skype id: geopcgeo On Thu, May 9, 2013 at 4:30 PM, Geo P.C. <pcgeopc@gmail.com <mailto:pcgeopc@gmail.com>> wrote: Dear Peter Thanks for your update. As you specified I am trying to set up this option. Thanks again Geo. On Tue, May 7, 2013 at 8:34 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: Hi Geo, I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that. What you should do as I proposed (solution 2b.): define an attribute like allowedService and manage that instead of using groups. create accounts for each application (all applications have binddn and bind password to connect to an ldap server) And the restrict access rights of these DNs via ACLs such as : access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ... access to * by * none Cheers, Peter Am 07.05.2013 14:59, schrieb Geo P.C.:Dear Peter, Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details: In application we have given base dn asou=People,dc=geo,dc=com and the userdn:uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully. Now we created an alias as follows: dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com objectclass: alias objectclass: extensibleObject objectclass: top uid: geo_pc Now in application we have given base dn asou=Applications,ou=Groups,dc=geo,dc=com but with this userou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application. Please let us know is there any additional configuration we need to done. Can you please help me on it. Thanks Geo *Thanks & Regards Geo P.C. www.geopc.co.cc <http://www.geopc.co.cc>* On Tue, May 7, 2013 at 5:51 PM, Peter Gietz <peter.gietz@daasi.de <mailto:peter.gietz@daasi.de>> wrote: 1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices. 2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups 3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that! 4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups if not 4.) my recommendation would be 2a.) being the minimal invasive alternative. Hope this helps, Peter Am 06.05.2013 12:21, schrieb Geo P.C.:Hi We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication. Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ . Inline image 1 On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users. So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users. Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue. Thanks Geo-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email:peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web:www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email:peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web:www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email:peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web:www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz-- Peter Gietz, CEO DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany phone: +49 7071 407109-0 fax: +49 7071 407109-9 email:peter.gietz@daasi.de <mailto:peter.gietz@daasi.de> web:www.daasi.de <http://www.daasi.de> Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
Dear Peter
Can you please let me know is the current configuration is correct or not. Is it possible to implement the required solution with acl?
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 14, 2013 at 2:57 PM, Peter Gietz peter.gietz@daasi.de wrote:
May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 BIND dn="cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" method=128 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 RESULT tag=97 err=49 text=
ERR 49 means invalid credentials. Check your password!
Fedup with this.
If you are fedup with this hire an expert. As Quanah said in this thread "it is trivial".
Cheers,
Peter
Am 14.05.2013 10:42, schrieb Geo P.C.:
Dear Peter
Thanks for your updates. I am still unable to fix this issue.
When the acl setup is as follows:
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix, ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
No user can able to login. We tried various option we interchanged rules but still getting same result.
Please see the error log:
May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 ACCEPT from IP= 192.168.1.210:49776 (IP=0.0.0.0:636) May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 TLS established tls_ssf=256 ssf=256 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 BIND dn="cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" method=128 May 14 14:06:14 geopc slapd[4456]: conn=1002 op=0 RESULT tag=97 err=49 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SRCH attr=namingContexts supportedLdapVersion altServer supportedControl supportedExtension supportedFeatures supportedSASLMechanisms May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 ENTRY dn="" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SRCH base="dc=prime,dc=ds,dc=geo,dc=com" scope=2 deref=0 filter="(uid=user1)" May 14 14:06:14 geopc slapd[4456]: conn=1002 op=2 SEARCH RESULT tag=101 err=32 nentries=0 text= May 14 14:06:14 geopc slapd[4456]: conn=1002 fd=22 closed (connection lost)
Can you please have a check. Fedup with this. can you please help to configure it. Thanks in advance. Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Mon, May 13, 2013 at 8:27 PM, Peter Gietz peter.gietz@daasi.de wrote:
Your third acl allows everyone to read (by * read). You should delete that
olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read
Peter
Am 13.05.2013 14:46, schrieb Geo P.C.:
Thanks Peter.
We created a user as follows:
dn: cn=zabbix,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson cn: zabbix sn: zabbix userPassword:: e1NIQX1NaTh4WX2V3dabTBGZ2JWRnY0L2s9
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -VV ldapsearch: @(#) $OpenLDAP: ldapsearch (Oct 17 2012 19:48:03) $
buildd@komainu:/build/buildd/openldap-2.4.28/debian/build/clients/tools (LDAP library: OpenLDAP 20428)
In /usr/share/slapd/slapd.conf we added acl but it’s not affecting so we added in olcAccess. It also default contents and please see the current settings.
root@geopc:/etc/ldap/slapd.d/cn=config# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config '(olcDatabase={1}hdb)' olcAccess dn: olcDatabase={1}hdb,cn=config olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymou s auth by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by self write by dn="cn=admin,dc=ds,dc=geo,dc=com" write by * read olcAccess: {3}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs =userPassword by self write by * auth olcAccess: {4}to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filte r="( allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabbix,ou=App lications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by self read
dn: olcDatabase={2}hdb,cn=config
root@geopc:/etc/ldap/slapd.d/cn=config#
With this setting zabbix application can be logged by all users in ou=People,dc=prime,dc=ds,dc=geo,dc=com.
Can you please have a check and please help me on it. Thanks in advance.
Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Mon, May 13, 2013 at 4:04 PM, Peter Gietz peter.gietz@daasi.dewrote:
You shouldn't use user1 as binddn in the application but a dedicated service account. And you should make sure that everyone is allowed to authenticate.
like so:
LDAP entry: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com objectClass:... ... userPassword: password
Zabix configuration host: 192.168.1.1 base: ou=People,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com password: password
ACL configuration:
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" attrs=userPassword by self write by * auth
access to dn.sub="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,objectClass by dn.exact="cn=zabix,ou=applications,dc=prime,dc=ds,dc=geo,dc=com" read by self read
Hope this works for you.
Cheers,
Peter
Am 13.05.2013 10:54, schrieb Geo P.C.:
Dear Peter
As per your suggestion In inetOrgPerson I created a custom attribute called allowedService and now the users list is as
dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: People
dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user1 allowedService: zabbix allowedService: gitlab
dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user2 allowedService: gitlab
dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: posixAccount objectClass: inetOrgPerson uid: user3 allowedService: gitlab
Now we have two applications zabbix and gitlb. For zabbix user1 need to have access others not. For gitlab three users should have access.
We have created two organizational units as
dn: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: zabbix
dn: ou=gitlab,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com objectClass: top objectClass: organizationalUnit ou: gitlab
In zabbix application configured as follows:
host: 192.168.1.1 base: ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com port: 636 uid: uid bind_dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com password: passwordIn slapd.conf file we added acl as:
access to dn.base="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=zabbix)" attrs=uid,userPassword by dn.exact="ou=zabix,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" read by * break
But with this configuration we are unable to login to zabix application with user user1.
Can you please help me on it. Let me know I am following the correct way? Can you please update me the correct steps we need to done.
Thanks in advance. Geo Skype id: geopcgeo
On Thu, May 9, 2013 at 4:30 PM, Geo P.C. pcgeopc@gmail.com wrote:
Dear Peter
Thanks for your update. As you specified I am trying to set up this option. Thanks again
Geo.
On Tue, May 7, 2013 at 8:34 PM, Peter Gietz peter.gietz@daasi.dewrote:
Hi Geo,
I don't think that alias object will be of use for you. Frankly I don't quite understand how you would like to use that.
What you should do as I proposed (solution 2b.):
define an attribute like allowedService and manage that instead of using groups.
create accounts for each application (all applications have binddn and bind password to connect to an ldap server)
And the restrict access rights of these DNs via ACLs such as :
access to filter=(allowedService=Wordpress) by cn=wordpress,ou=serviceaccounts,dc=examle,dc=com read ...
access to * by * none
Cheers,
Peter
Am 07.05.2013 14:59, schrieb Geo P.C.:
Dear Peter,
Thanks for your reply. In order to login to an application from a selected group only we checked alias option. But it was not working. Please see the details:
In application we have given base dn as ou=People,dc=geo,dc=com and the user dn: uid=geo_pc,ou=People,dc=geo,dc=com can able to login to the application successfully.
Now we created an alias as follows:
dn: uid=geo_pc,ou=Applications,ou=Groups,dc=geo,dc=com
aliasedobjectname: uid=geo_pc,ou=People,dc=geo,dc=com
objectclass: alias
objectclass: extensibleObject
objectclass: top
uid: geo_pc
Now in application we have given base dn as ou=Applications,ou=Groups,dc=geo,dc=com but with this user ou=Applications,ou=Groups,dc=geo,dc=com we are unable to login to the application.
Please let us know is there any additional configuration we need to done. Can you please help me on it.
Thanks Geo
*Thanks & Regards Geo P.C. www.geopc.co.cc*
On Tue, May 7, 2013 at 5:51 PM, Peter Gietz peter.gietz@daasi.dewrote:
1.) If you had a config parameter like search filter in your application you could use that to make unwanted users invisible for the application. But this means you can't use group entries , but dynamic groups, i.e. a group is an ldapfilter, e.g. "(allowedServices=Wordpress)" and you manage group privileges in an own attribute allowedServices.
2.) You could also do this via ACLs in the server, each application using its own bind dn, which can then have read access to a subset of the data. Here you can use a.) group entries or b.) dynamic groups
3.) Of course you could also have a separate replica for each application with filtered entries, but only with dynamic groups (see 1.), but that is a lot of overhead. Beware: combining this with 2. i.e. group ACLs on replica bindDN is a rathole, don't do that!
4.) IMHO best would be to file a feature request to the application developers for supporting LDAP-groups
if not 4.) my recommendation would be 2a.) being the minimal invasive alternative.
Hope this helps,
Peter
Am 06.05.2013 12:21, schrieb Geo P.C.:
Hi
We are using many applications like zabbix, phabricator, AC etc. We need to integrate LDAP in all these applications. These application support LDAP but not group based authentication.
Please let us know is there any option to restrict selected users to login. We created all users under ou ‘users’ .
[image: Inline image 1]
On these application we need to login certain users only. How we can restrict it as we can’t able to restrict on application side
In these application they provide only “Base DN” and “Search Attribute” so we can’t able to give dn: ou=users,ou=system as it gives access to all users.
So is it possible to give Base DN as “cn=Zabbix,ou=groups,ou=system” and this group contains only user1 and user2. SO it will restrict users.
Please let us know how we can implement this scenario. Thanks in advance please help us to solve this issue.
Thanks Geo
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
--
Peter Gietz, CEO
DAASI International GmbH Europaplatz 3 D-72072 Tübingen Germany
phone: +49 7071 407109-0 fax: +49 7071 407109-9 email: peter.gietz@daasi.de web: www.daasi.de
Sitz der Gesellschaft: Tübingen Registergericht: Amtsgericht Stuttgart, HRB 382175 Geschäftsleitung: Peter Gietz
-- _______________________________________________________________________
Peter Gietz (CEO) DAASI International GmbH phone: +49 7071 407109-0 Europaplatz 3 Fax: +49 7071 407109-9 D-72072 Tübingen mail: peter.gietz@daasi.de Germany Web: www.daasi.de
DAASI International GmbH, Tübingen Geschäftsführer Peter Gietz, Amtsgericht Stuttgart HRB 382175 _______________________________________________________________________
openldap-technical@openldap.org
-
Geo P.C. -
Peter Gietz