openldap-technical

openldap-technical@openldap.org

1 participants
9868 discussions

openldap client wasn't able to authenticate SSH
by ded1＠MyBSD.org.my 16 May '13

16 May '13

Hi, I have issue with my openldap client to authenticate on SSH using openldap server. It's failed to authenticate using account that i create on openldap server OR default user !. I have to reboot to single mode and change everything back to default. The SSH account that i use is "labu" Output from /etc/passwd on openldap server (10.1.1.1): # more /etc/passwd | grep labu labu:x:1003:1003::/home/labu:/bin/sh Here's what i'm using on the setup: Server (10.1.1.1): i. openldap 2.4.28-1.1 on Linux Ubuntu 12.04 Client (10.1.1.2): i. libpam-ldapd 0.8.4 on Linux Ubuntu 12.04 Here's the output when i do on openldap server itself: # ldapsearch -h localhost -D "cn=admin,dc=ROSAK,dc=COM" -w openiam -b "dc=ROSAK,dc=COM" -s sub "objectclass=*" ldap_bind: Invalid credentials (49) _BUT_ i'm am able to login using admin account on phpldapadmin. Here's my /etc/ldap/slapd.conf ############################################################## # S L A P D . C O N F # ############################################################## include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema password-hash {CLEARTEXT} allow bind_v2 pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args modulepath /usr/lib/ldap moduleload back_bdb.la #moduleload back_@BACKEND@ access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * manage access to dn.exact="cn=admin,ou=Roles,dc=ROSAK,dc=COM" by * read access to attrs=userPassword by self write by anonymous auth by * none access to * by self write by users read by anonymous auth database bdb suffix "dc=ROSAK,dc=COM" rootdn "cn=admin,dc=ROSAK,dc=COM" rootpw {CLEARTEXT}123456 directory "/var/lib/ldap" index objectClass eq loglevel 2048 Here's /etc/nsswitch.conf from my openldap client: # /etc/nsswitch.conf passwd: files ldap group: files ldap shadow: files ldap sudoers: files ldap services: files ldap automount: files ldap Here's /etc/pam.d/sshd from my openldap client: # auth include system-auth account required pam_nologin.so account include system-auth password include system-auth session optional pam_keyinit.so force revoke session include system-auth session required pam_loginuid.so Appreciate anyone help / advice. Thanks. --- ded1 "The end is the beginning, the beginning is the end"

2 1

Re: getting bindDN in perl script
by Pierangelo Masarati 16 May '13

16 May '13

Please reply on the mailing list. On 05/16/2013 01:00 AM, Benin Technologies wrote: > yes but...where is this perl function called for binds ??? it isn't in > SampleLDAP.pm... > servers/slapd/back-perl/bind.c calls a method "bind" as much as servers/slapd/back-perl/search.c calls a method "search". Apparently, who wrote "SampleLDAP.pm" did not provide a "bind" example. Note that I've been working for 15 years with OpenLDAP and I never used back-perl; I discovered all of this last night by opening 2 files and reading about 10 lines of code. You should probably try to do something like this yourself. p. > Le 15/05/2013 22:20, Pierangelo Masarati a écrit : >> binddn and bindpw are the first two parameters of the perl function >> called for binds. >> > > -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

3 4

back-mdb vs back-hdb read performance
by Quanah Gibson-Mount 16 May '13

16 May '13

<http://mishikal.wordpress.com/2013/05/16/openldap-a-comparison-of-back-mdb-…> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

getting bindDN in perl script
by Benin Technologies 15 May '13

15 May '13

Hi, I needed to access from an LDAP client (Outlook or Thunderbird) some data stored in several locations (an OpenLDAP server with back-hdb, and a PostgreSQL database). I wrote a perl script used with back-perl, and everything works fine. The client queries that back-ldap server, wich in turn retrieves data both from the back-hdb server and the PostgreSQL server, does some formatting on it, and returns it to the client It works fine, except that I have to use a standard bindDN/password from the perl script to access the back-hdb server, because I don't know how to retrieve in that perl script the initial bindDN/password (the credentials provided initially by the client). I guess there is a way to do it, because I found some links like http://osdir.com/ml/network.openldap.general/2002-09/msg00021.html where people seem to have been able to get the bindDN and password provided by the client, but they didn't say how and I couldn't figure it out. Does anybody know if it's possible to get, within the perl script, the bindDN/password provided by the client ? Thanks Ben

4 7

Access Control List Configuration.
by Geo P.C. 15 May '13

15 May '13

I am trying to configure acl in such a way users with attribute allowedService with application name can only login to that particular application. We have users as follows: dn: ou=People,dc=prime,dc=ds,dc=geo,dc=com dn: uid=user1,ou=People,dc=prime,dc=ds,dc=geo,dc=com uid: user1 allowedService: gitlab dn: uid=user2,ou=People,dc=prime,dc=ds,dc=geo,dc=com uid: user2 allowedService: zabbix dn: uid=user3,ou=People,dc=prime,dc=ds,dc=geo,dc=com objectClass: top uid: user3 allowedService: zabbix We created an user as follows: dn: cn=gitlab,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com cn: gitlab uid: gitlab Now in application we given the details as follows: gitlab configuration base: ou=People,dc=prime,dc=ds,dc=geo,dc=com uid: uid bind_dn: cn=gitlab,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com password: password Now in acl we tried various options as follows: root@geopc:/# 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.subtree="ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" by self write by * write olcAccess: {3}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" by self write by * auth olcAccess: {4}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" filter="(allowedService=gitlab)" by dn.exact="cn=gitlab,ou=Applications,ou=Groups,dc=prime,dc=ds,dc=geo,dc=com" write by self write But with this no user can able to login. But we change olcAccess: {3}to dn.subtree="ou=People,dc=prime,dc=ds,dc=geo,dc=com" by self write by * write, all users can login. But actually we need is only the user1 need only to login to gitlab application. And the users user2 and user3 need only to login to zabbix application Can anyone please help me to configure acl for this. Thanks in advance. Thanks Geo

2 2

Problems with SSH to Openldap server
by Stuart Watson 14 May '13

14 May '13

Hi I have created an ec2 instance and have installed openldap and setup openldap to use OpenSSH. However I cannot ssh from a remote pc, to the openldap server, I just get invalid user, although the username is the same that I have specified in openldap. What am I doing wrong? Thanks

2 7

Re: Using LDAP how to restrict users to certain applications only
by Geo P.C. 14 May '13

14 May '13

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(a)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(a)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(a)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(a)daasi.de > web: www.daasi.de > > Sitz der Gesellschaft: Tübingen > Registergericht: Amtsgericht Stuttgart, HRB 382175 > Geschäftsleitung: Peter Gietz > > > >

2 7

Access Rules and Replication
by Andrew Devenish-Meares 14 May '13

14 May '13

Hi List, I've just joined the list as I'm starting work on a new project to move our OpenLDAP servers over to cn=config from the old slapd.conf configuration. I've been working with our LDAP servers for about twelve months since I started this job, and have used OpenLDAP and other LDAP servers for five years before that. For the moment we're not looking to change the way clients use LDAP, but are looking to bring the config up to the new format, and take advantage of "no downtime" configuration changes. At present our production environment uses a single LDAP Master, which is used by the IAM system and system and network admins to maintain the various entries, while clients are set to read from ldap.une.edu.au, a RR DNS entry to the LDAP consumers. Beyond discussions of moving to an F5 Load Banacer, rather than RR DNS, we're not aiming to change that setup. I've read examples of replicating not only the directory, but also the cn=schema,cn=config DIT, which seems useful. Can anyone advise if there are any pitfalls in this approach, or any reason not to investigate it? I can see that the Access Controls are moved into olcAccess entries either in the cn=config or database parts of the tree. If we can replicate the schema to the consumers, can we replicate our ACLs as well? Has anyone done this, are their examples? I've been searching around for a while and haven't found any. I'm also interested in hearing about any other issues people have encountered moving to the cn=config setup, gotcha's or anything else people might consider useful for me to know. Thanks all Andrew -- Andrew Devenish-Meares Solutions Analyst Information Technology University of New England Armidale NSW 2351 e: adevenis(a)une.edu.au p: 02 6773 4098 w: http://une.edu.au/itd

1 0

back-perl and bind DN
by Benin Technologies 11 May '13

11 May '13

Hi, I'm using a perl backend. Is it possible, inside the perl script, to get the bind DN ? Ben

1 1

Re: connection_read
by Quanah Gibson-Mount 10 May '13

10 May '13

--On Friday, May 10, 2013 9:05 AM -0300 paulo bruck <paulobruck1(a)gmail.com> wrote: > I insert concurrency to 20000 and threads to 64 , but some branches > continues not syncing . Please keep your replies on the list. I have no clue why you think this would do anything to help with your sync issues. At best, it is killing your servers, and you are playing with parameters you don't understand. I would also note the OpenLDAP versions provided by RedHat, if that is what you are using on your RedHat replicas, are also known to be terrible. You should be using the same (current) version of OpenLDAP on all servers (provider and replicas). --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical