openldap-software January 2007

openldap-software@openldap.org

98 participants
123 discussions

Re: some minor issues with the new ldif-config-style
by Howard Chu 22 Jan '07

22 Jan '07

Wolfgang Hennerbichler wrote: > On 21.01.2007, at 08:34, Howard Chu wrote: >> In general, once the slapd.conf file has been converted to LDIF, you >> should never manually edit the configuration ever again. Do all >> subsequent changes through LDAP. > > Allright, will do. Already tested it, works really great! >>> 3) This is the really interesting stuff: is it possible to start a >>> "stupid" replication server with syncrepl, who only knows how to connect >>> to the main server, and then syncs the schemas and parts of the config >>> to itself? that would be cool, and I guess it can be done. Yet it's >>> still dependend on question 1 :) >> That is a desired feature, but we've explicitly disabled that in >> OpenLDAP 2.3. It will probably be enabled in OpenLDAP 2.4, but it requires >> some other enhancements to the syncrepl system before it can be done safely. > Allright. Thanks a lot for your helpful answers! By the way, test049 was just added to CVS HEAD showing exactly how to do this. It starts with a bare minimum slave server that pulls its entire configuration and all database contents from a provider. You can play around with it to get an idea of what the 2.4 release will offer. This feature is most likely not in its final form; some type of filtering still needs to be developed to allow parts of the slave configuration to be different from the provider. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

problems with bdb-indexes
by peter pilsl 22 Jan '07

22 Jan '07

I set up a simple ldap-backend to maintain our systems userdatabase. After finding loads of entries in my log like: Jan 22 17:51:10 ihf2 slapd[18454]: <= bdb_equality_candidates: (uid) index_param failed (18) I looked up the docs and found that this is cause no proper index for uid is defined. So I setup a index in slapd.conf index uid eq Now there are no such messages in my logs again, but ldap-search does not work anymore !!! And all applications that rely on ldap (postfix, cyrus, nss, pam ..) dont work proper anymore. As soon as I remove the index, everything is working fine again. This is very strange to me. The proper index-file is created in my ldap-directory: uid.bdb when slapd is started, so I dont think I need to manually create the index after setting an index to an already existing ldap-datebase. I also didnt find anything in the docs about creating an index mannually. example: without the uid-index: $ldapsearch -x uid=peter mail # extended LDIF # # LDAPv3 # base <> with scope sub # filter: uid=peter # requesting: mail # # peter, user, ihf.local dn: uid=peter,ou=user,dc=ihf,dc=local mail: pilsl(a)ihf-hr.org # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 and now with the index active: $ldapsearch -x uid=peter mail # extended LDIF # # LDAPv3 # base <> with scope sub # filter: uid=peter # requesting: mail # # search result search: 2 result: 0 Success # numResponses: 1 -------------------------------------------- my slapd.conf: include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/mail.schema schemacheck on pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd.args loglevel 2048 modulepath /usr/lib/ldap moduleload back_bdb backend bdb checkpoint 512 30 database bdb suffix "dc=ihf,dc=local" directory "/data/ldap/ihf" index objectClass eq lastmod on rootdn "cn=ldapadmin,dc=ihf,dc=local" rootpw {SSHA}xxxxxxxxxxxxxxxxxxxxx Access to * by * read access to attr=userPassword,userPKCS12 by self write by * auth access to attr=shadowLastChange by self write by * read access to * by * read access to dn.base="" by * read access to * by dn="cn=ldapadmin,dc=ihf,dc=local" write by self write by * read thnx for any idea, peter ps: I use slapd 2.2.26 on a ubuntu 6.10-machine -- mag. peter pilsl - goldfisch.at IT-Consulting Tel: +43-650-3574035 Tel: +43-1-8900602 Fax: +43-1-8900602-15 skype: peter.pilsl pilsl(a)goldfisch.at www.goldfisch.at

2 2

How to chase referrals
by S Kalyanasundaram 22 Jan '07

22 Jan '07

Hi, What i have done this, char *ldap_username="xx"; char *ldap_password="xx"; if( ldap_set_option(ld, LDAP_OPT_REFERRALS, LDAP_OPT_ON) != 0) { log_error("LDAP set Optoin for referral"); } if( ldap_set_rebind_proc(ld, get_rebind, NULL) != 0) { log_error("LDAP set Optoin for rebind"); } static int get_rebind( LDAP *ld, char **whop, char **credp,int *methodp, int freeit, void* arg ) { if ( !freeit ) { *whop = ldap_username; *credp = ldap_password; *methodp = LDAP_AUTH_SIMPLE; } return( LDAP_SUCCESS ); } This cause be Segfault. I traced with gdb when it reaches this function get_rebind it gives like "credb" address is ox63 and methodp is 0x2. I dont understand why the low address has come up for these variables. Then i added the following, static int LDAP_CALL LDAP_CALLBACK get_rebind ... but it gives me the compilation error. What i am missing here. Can you find something odd here. thanks a lot for your help, -"kalyan"

2 2

Re: How to only accept TLS connection on port 389
by Kurt D. Zeilenga 22 Jan '07

22 Jan '07

At 05:32 PM 1/21/2007, Jean-Yves Avenard wrote: >Is there a way to have OpenLDAP listening on port 389 (standard ldap) >but only accept tls encrypted session? You can require TLS (SSL) via the slapd.conf(5) security directive. The client can then either use ldap:// (to whatever port(s) you have configured slapd(8) to listen on) and initiate TLS via the Start TLS operation or use ldaps:// (to whatever port(s) you have configured slapd(8) on) and initiate TLS upon connecting. If you want to restrict clients to using just the former or the latter, eliminate one or the other listener. >I've searched for quite a while and it seems that the only option is >to disable listening on port 389 alltogether and only listen on port >636. While ldap:// uses 389 by default and ldaps:// uses 636 by default, one can actually use ldap:// or ldaps:// on any port. >But this isn't good for my purpose, as some broken clients only work >over TLS on port 389 ldap:// on port 389 and use of Start TLS operation to initiate TLS (SSL) is the standard way of securing LDAP with TLS. Kurt

8 12

RE: pesky ppolicy problems
by Metcalf, Roger 22 Jan '07

22 Jan '07

Thanks for the quick response! I'm using 2.3.27 because it was The Stable Release when I started this. I'll move to the latest stable release after I get ppolicy figured out. I want dynamic modules, so I changed my enable-ppolicy to be "mod" -- env LIBS="-L/usr/bin" \ ./configure \ --prefix=/usr/local \ --libdir=/usr/local/lib \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --sysconfdir=/etc \ --localstatedir=/var/lib/ldap \ --enable-modules=yes \ --enable-ppolicy=mod && make depend && make The make/install process displayed: make[3]: Entering directory `/usr/local/src/openldap-2.3.27/servers/slapd/overlays' ../../../build/shtool install -c -m 755 .libs/ppolicy-2.3.so.0.2.15 /usr/sbin/openldap/ppolicy-2.3.so.0.2.15 (cd /usr/sbin/openldap && { ln -s -f ppolicy-2.3.so.0.2.15 ppolicy-2.3.so.0 || { rm -f ppolicy-2.3.so.0 && ln -s ppolicy-2.3.so.0.2.15 ppolicy-2.3.so.0; }; }) (cd /usr/sbin/openldap && { ln -s -f ppolicy-2.3.so.0.2.15 ppolicy.so || { rm -f ppolicy.so && ln -s ppolicy-2.3.so.0.2.15 ppolicy.so; }; }) ../../../build/shtool install -c -m 755 .libs/ppolicy.lai /usr/sbin/openldap/ppolicy.la PATH="$PATH:/sbin" ldconfig -n /usr/sbin/openldap That looked like what I need. In /usr/sbin/openldap I now find: lrwxrwxrwx 1 root root 21 Jan 22 14:51 ppolicy-2.3.so.0 -> ppolicy-2.3.so.0.2.15 -rwxr-xr-x 1 root root 85722 Jan 22 14:51 ppolicy-2.3.so.0.2.15 -rwxr-xr-x 1 root root 836 Jan 22 14:51 ppolicy.la lrwxrwxrwx 1 root root 21 Jan 22 14:51 ppolicy.so -> ppolicy-2.3.so.0.2.15 In slapd.conf I set the module path: modulepath /usr/sbin/openldap moduleload ppolicy.la <snip> overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,c=us" ppolicy_hash_cleartext ppolicy_use_lockout Still I get: [root openldap-2.3.27]# /etc/init.d/ldap start Checking configuration files for : WARNING: No dynamic config support for overlay ppolicy. config file testing succeeded Starting slapd: FAILED [root openldap-2.3.27]# Shouldn't this work now? I attach my slapd.conf, mostly vanilla in this version, and I've removed commented lines for your convenience. How's it look? include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/acs.schema include /etc/openldap/schema/ppolicy.schema pidfile /var/lib/ldap/run/slapd.pid argsfile /var/lib/ldap/run/slapd.args modulepath /usr/sbin/openldap moduleload ppolicy.la database bdb suffix "c=US" rootdn "cn=Manager, c=US" rootpw secret directory /var/lib/ldap/openldap-data index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub loglevel 256 overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,c=us" ppolicy_hash_cleartext ppolicy_use_lockout Thanks, Roger > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@stanford.edu] > Sent: Monday, January 22, 2007 1:36 PM > To: Metcalf, Roger; openldap-software(a)openldap.org > Subject: Re: pesky ppolicy problems > > > > > --On Monday, January 22, 2007 1:08 PM -0500 "Metcalf, Roger" > <roger.metcalf(a)acs-inc.com> wrote: > > > I am trying to use the ppolicy overlay. I've searched, read and > > experimented and can't get it to work. > > I've read other similar postings with similar problems but > haven't found > > the one with the answer. > > > > My OpenLDAP knowledge is intermediate. > > > > I download 2.3.27, then build it: > > Why 2.3.27? 2.3.32 is the current stable release. > > Plus there have been fixes since 2.3.27: > > OpenLDAP 2.3.30 Release (2006/11/14) > Fixed slapo-ppolicy external quality check (ITS#4741) > > > OpenLDAP 2.3.29 Release (2006/11/10) > Fixed slapo-ppolicy leaks (ITS#4665) > > OpenLDAP 2.3.28 Release (2006/10/21) > Fixed slapo-ppolicy pwdChangedTime behavior (ITS#4692) > > > > As for your questions: > > Questions: > > 1) Where is ppolicy.la located? > > Well, if its a dynamic module, then in $lib/openldap: > > ldap00:/usr/local/lib/openldap> ls -l ppol* > lrwxrwxrwx 1 root root 21 Nov 13 22:38 ppolicy-2.3.so.0 -> > ppolicy-2.3.so.0.2.16* > -rwxr-xr-x 1 root root 102169 Nov 8 21:49 ppolicy-2.3.so.0.2.16* > -rwxr-xr-x 1 root root 909 Nov 8 21:49 ppolicy.la* > lrwxrwxrwx 1 root root 21 Nov 13 22:38 ppolicy.so -> > ppolicy-2.3.so.0.2.16* > > 2) Does it need to be loaded? > > Yes, if it is a dynamic module. > > 3) Where is the path to it specified? > > Via the "modulepath" directive in slapd.conf: > > # Load dynamic backend modules: > modulepath /usr/local/lib/openldap > moduleload back_hdb.la > moduleload back_monitor.la > > > 4) When are moduleload specs needed? > > Not sure what you mean here. > > 5) Are env variables needed to find ppolicy.la? > > No. > > 6) What's the secret? > > Reading the man pages and other documentation. > > 7) When will the book be published? > > Howard is currently working on writing it. > > --Quanah > > -- > Quanah Gibson-Mount > Principal Software Developer > ITS/Shared Application Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html >

3 3

RE: pesky ppolicy problems
by Metcalf, Roger 22 Jan '07

22 Jan '07

The failure is just due to the way my startup script (ldap) handles the warning. The warning is the same as before. config_build_entry: "cn=schema" config_build_entry: "cn={0}core" config_build_entry: "cn={1}cosine" config_build_entry: "cn={2}inetorgperson" config_build_entry: "cn={3}nis" config_build_entry: "cn={4}acs" config_build_entry: "cn={5}ppolicy" config_build_entry: "olcDatabase={-1}frontend" config_build_entry: "olcDatabase={0}config" config_build_entry: "olcDatabase={1}bdb" WARNING: No dynamic config support for overlay ppolicy. config_build_entry: "olcOverlay={0}ppolicy" backend_startup_one: starting "c=US" bdb_db_open: c=US bdb_db_open: dbenv_open(/var/lib/ldap/openldap-data) Is it true that the above warning does NOT indicate that ppolicy is not successfully loaded, and that in fact everything should be just fine? Thanks again > -----Original Message----- > From: Quanah Gibson-Mount [mailto:quanah@stanford.edu] > Sent: Monday, January 22, 2007 5:19 PM > To: Metcalf, Roger; openldap-software(a)openldap.org > Subject: RE: pesky ppolicy problems > > > > > --On Monday, January 22, 2007 4:27 PM -0500 "Metcalf, Roger" > <roger.metcalf(a)acs-inc.com> wrote: > > > Thanks for the quick response! I'm using 2.3.27 because it > was The Stable > > Release when I started this. > > I'll move to the latest stable release after I get ppolicy > figured out. > > > Starting slapd: FAILED > > [root openldap-2.3.27]# > > When slapd fais for me, I usually use -d -1 to see why. It > generally will > tell you right away. > > --Quanah > > -- > Quanah Gibson-Mount > Principal Software Developer > ITS/Shared Application Services > Stanford University > GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html >

2 1

Re: WARNING: No dynamic config support for overlay ppolicy?
by Howard Chu 22 Jan '07

22 Jan '07

Errol Neal wrote: >>> Your "overlay ppolicy" clause is in the wrong place. Look at the > test022 example more carefully, and read the > > > You were ABSOLUTELY RIGHT! Very happy - thank you very much. I reworked > my slapd.conf file paying attention to test022 and my password policies > are working now. Thank you very much Howard! > But whats up with the error regarding dynamic overlays at start up? It means what it says. The ppolicy overlay in 2.3.32 doesn't support dynamic configuration via back-config. The support has been in HEAD for some time, it just hasn't been backported. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

pesky ppolicy problems
by Metcalf, Roger 22 Jan '07

22 Jan '07

I am trying to use the ppolicy overlay. I've searched, read and experimented and can't get it to work. I've read other similar postings with similar problems but haven't found the one with the answer. My OpenLDAP knowledge is intermediate. I download 2.3.27, then build it: env LIBS="-L/usr/bin" \ ./configure \ --prefix=/usr/local \ --libdir=/usr/local/lib \ --sbindir=/usr/sbin \ --libexecdir=/usr/sbin \ --sysconfdir=/etc \ --localstatedir=/var/lib/ldap \ --enable-overlays=mod \ --enable-dynamic=yes \ --enable-modules=yes \ --enable-ppolicy=yes && make depend && make I include ppolicy in slapd.conf. include /etc/openldap/schema/ppolicy.schema overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,c=us" ppolicy_hash_cleartext ppolicy_use_lockout I have tried with and without modulepath and moduleload. I suspect they are not needed but am not sure. modulepath /usr/sbin moduleload ppolicy.la I have created a policy structure in my repository. I don't really care if ppolicy is statically or dynamically loaded, I just want it to be available! The problem may be that I really don't get the meaning or dependencies of enable-dynamic, enable-modules, enable-overlays, enable-static, enable-shared. My goal is simple : to get ppolicy working in the simplest way. Problems: /etc/init.d/ldap start -- WARNING: No dynamic config support for overlay ppolicy. This apparently is more than just a "warning" because startup fails. I figured Symas CDS silver would work, so I downloaded it, commented out the ppolicy lines: # Load an instance of the ppolicy overlay for the current database: overlay ppolicy ppolicy_default "cn=Standard Policy,ou=Policies,c=us" ppolicy_hash_cleartext ppolicy_use_lockout and put -d -1 into EXTRA_SLAPD_ARGS so I could see what happens. With this: # Uncomment the following moduleload to add support for # password policies. Refer to the example below and to # slapo-ppolicy(5) for additional information. moduleload ppolicy.la I get: line 93 (moduleload ppolicy.la) lt_dlopenext failed: (ppolicy.la) file not found /opt/symas/etc/openldap/slapd.conf: line 93: <moduleload> handler exited with 1! With this: #moduleload ppolicy.la I get this: line 234 (overlay ppolicy) overlay "ppolicy" not found /opt/symas/etc/openldap/slapd.conf: line 234: <overlay> handler exited with 1! What makes this all the more frustrating is that test022-ppolicy appears to work fine. I have examined its .conf file and environment variables, etc and can't extract the secret. Questions: 1) Where is ppolicy.la located? 2) Does it need to be loaded? 3) Where is the path to it specified? 4) When are moduleload specs needed? 5) Are env variables needed to find ppolicy.la? 6) What's the secret? 7) When will the book be published? All advice welcome. Thanks, Roger Metcalf

3 2

RE: WARNING: No dynamic config support for overlay ppolicy?
by Errol Neal 22 Jan '07

22 Jan '07

You wrote: >> It would help to: >> 1)provide the contents of your ppolicy_default >> 2)explain exactly what is not working Here is the test policy I have in the directory. dn: cn=test,ou=portal,ou=policies,dc=ttpua,dc=portal objectClass: pwdPolicy objectClass: top objectClass: device cn: test pwdAttribute: userPassword pwdMaxAge: 360 pwdExpireWarning: 120 pwdInHistory: 3 pwdCheckQuality: 1 pwdMinLength: 8 pwdMaxFailure: 3 pwdLockout: TRUE pwdLockoutDuration: 60 pwdFailureCountInterval: 120 pwdMustChange: TRUE pwdAllowUserChange: TRUE pwdSafeModify: TRUE pwdGraceAuthNLimit: 3 structuralObjectClass: device entryUUID: dde41790-ddb0-102a-9d8f-2524a04c2d05 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal modifiersName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20060921113420Z modifyTimestamp: 20060921113420Z entryCSN: 20060921113420Z#000000#00#000000 What I'm trying to do is just verify that the directory server is enforcing my policy of login failures and will lock the account out after the specified number of attempts. As I said before, this is exactly whats done in one of the tests when one runs 'make test' in the source code of openldap after it's built I run: ./ldapsearch -x -b "dc=ttpua,dc=portal" -P 3 -LLL -e ppolicy -h localhost -D cn=tuser,ou=testing,ou=portal,ou=users,dc=ttpua,dc=portal -w badpassword Three times. According to the test policy, the account should be locked out. cn=tuser,ou=testing,ou=portal,ou=users,dc=ttpua,dc=portal userPassword:: e1NIQX1XNnBoNU1tNVB6OEdnaVVMYlBnekczN21qOWc9 objectClass: top objectClass: inetOrgPerson objectClass: organizationalPerson sn: User cn: tuser structuralObjectClass: inetOrgPerson entryUUID: 15847d74-3bf4-102b-912f-2d95986cd7a9 creatorsName: cn=scoobydoo,dc=ttpua,dc=portal createTimestamp: 20070119103219Z pwdPolicySubentry: cn=test,ou=portal,ou=policies,dc=ttpua,dc=portal entryCSN: 20070119103245Z#000000#00#000000 modifiersName: cn=scoobydoo,dc=ttpua,dc=portal modifyTimestamp: 20070119103245Z I run the same ldap search for the forth time with the correct password, I'm able to log in - which I thought I shouldn't be able to do. So I clearly am missing something. Can anyone shed some light on what that may be? TIA, Errol Neal

2 1

Re: OpenLDAP issues when connecting over SSL
by Kurt D. Zeilenga 22 Jan '07

22 Jan '07

At 09:42 PM 1/21/2007, Jean-Yves Avenard wrote: >can you configure the server to accept both SSL and Start TLS on port 636? Technically speaking, on different interfaces, yes, but on the same interface or the "any" interface, no. Unless you have an extra interface, this is not a practical optional. And even then, well, it's simply goofy. >Now that would be a good alternative ... Generally speaking, I think it not a good alternative. If, as you say, your client can only talk ldap:// with StartTLS on port 636 (and no support whatsoever for ldaps://), I would suggest you ask the developer of that client to support ldap:// with Start TLS on 389. However, I would be surprised if a developer actually limited their client in such a way. I would guess you might be wrong in what you say. I suggest you contact those familiar with the particular client (using an appropriate list or other means) for clarification. Kurt

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software January 2007