openldap-technical November 2011

openldap-technical@openldap.org

80 participants
91 discussions

Re: OpenLDAP syncrepl woes
by Jeffrey Crawford 01 Dec '11

01 Dec '11

On Wed, Nov 23, 2011 at 10:13 AM, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, November 23, 2011 9:26 AM -0800 Jeffrey Crawford > <jeffreyc(a)ucsc.edu> wrote: > >> read that already: >> >> my original question was the following: >> >> Granted the above issues might be explained away in that we don't yet >> have enough ram on the machines yet, however it does seem to present >> us with a problem when we notice the discrepancy, how do we during run >> time re-sync the data from the provider server? I have tried the slapd >> -c rid=2,csn=20111114000000.000000Z but that doesn't seem to do any >> good. (I've tried several different values of csn=0 >> csn=20111114000000.000000Z#000000#000#000000 etc. to no avail) > > > Regardless of RAM limitations, you should never have an inconsistent > database. However, so far, the only replication mechanism I've seen > guarantee this is delta-syncrepl. This may be better in the upcoming > OpenLDAP 2.4.27 for syncrepl. > > If you read the slapd man page for the -c option, it is quite clear: > > Use only the rid part to force a full reload. Humm that didn't seem to work. I'm rebuilding so I'll give that another try. > > >> from man slapadd >> >> LIMITATIONS >> Your slapd(8) should not be running when you do this to ensure >> consis- tency of the database. >> >> So how can I have slapd run, respond to what data it has currently yet >> understand that it will update all it's data with the source provider >> updating, adding, removing entries as necessary without removing the >> database first? > > I don't understand why you would want slapd to respond with completely bogus > data to any clients doing queries. If you're going to force reload the > replica anyway, it makes much more sense to use slapadd from the master > rather than trying to do it via syncrepl, which can take numerous amounts of > time longer than doing it via slapadd, and during that entire time period, > you have the possibility of sending out significantly erroneous data. > > --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 >

2 2

Possible ACL Issue while try to read Root DSE
by Axel Birndt 01 Dec '11

01 Dec '11

Hi @All, i'am new on this list and i have a question. While i'am using the tool web2ldap from Michael Stroeder and try to create a new entry with this tool. I'am using openldap with cn=config backend on ubuntu 10.04 Michael mentioned it could be a acl problem, because his tool couldn't read the Root DSE If i specify the search base and the adminuser i could see the content of the Tree root. ldapsearch -b "dc=2axels-company,dc=de" -s base 'objectclass=*' -h localhost -D cn=admin,dc=2axels-company,dc=de -W -------------------->> abirndt@ubuntunb:~$ ldapsearch -b "dc=2axels-company,dc=de" -s base 'objectclass=*' -h localhost -D cn=admin,dc=2axels-company,dc=de -W Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=2axels-company,dc=de> with scope baseObject # filter: objectclass=* # requesting: ALL # # 2axels-company.de dn: dc=2axels-company,dc=de objectClass: dcObject objectClass: organization o: 2axels-company.de dc: 2axels-company description: Tree root <<<<---------------------------------------- But if i use ldapsearch with the following command i got nothing: ldapsearch -b "" -s base 'objectclass=*' ldap_sasl_interactive_bind_s: No such object (32) Could you help me please to identify if there is a problem with reading the Root DSE? What could i do next ? Any help is very appreciated. -- Gruß Axel ------------------------------

6 14

unclean shutdown detected; attempting recovery - question
by frank.offermanns＠caseris.de 01 Dec '11

01 Dec '11

Hello, I am using OpenLDAP 2.4.25. After reboot I see logs (Logsetting -d 256) like : => bdb_idl_delete_key: c_del id failed: DB_LOCK_DEADLOCK: Locker killed to resolve a deadlock (-30994) I checked this and found that I can ignore this. But one minute after this message OpenLDAP stopped working. I automatically detected it and restarted OpenLDAP. After restarting I see a logmessage: hdb_db_open: database "o=mydomain": unclean shutdown detected; attempting recovery. Then I see for 1 to 3 minutes that OpenLDAP seems to work, before stopping the work again. I repeated restarting. After the sixths restarts LDAP now seems to work correctly. So now my question: When I see the message: "unclean shutdown detected; attempting recovery" How long does the recovery take? Is it possbile that the recovery was still in progress as I restarted (after 5 mins) OpenLDAP? Is there a Logsetting I could activate to see when the recovery is finished? Would it be better to manually do the recovery after stopping slapd? Regards, Frank

2 2

Re: Ldap+Nfsv4+kerberos *nix / *bsd puzzle.
by Harry Coin 30 Nov '11

30 Nov '11

On 11/30/2011 7:23 AM, Juergen.Sprenger(a)swisscom.com wrote: > Hi Harry, > > have done this here with an extended schema for a > heterogeneous environment of AIX, HPUX, Solaris and Linux. > > Extended posixaccount to x-posixaccount with attributetypes (complete schema on request): > 'x-homeDirectory' > 'x-SolarishomeDirectory' > 'x-AIXhomeDirectory' > 'x-LinuxhomeDirectory' > 'x-HPUXhomeDirectory' > > 'x-loginShell' > 'x-SolarisloginShell' > 'x-AIXloginShell' > 'x-LinuxloginShell' > 'x-HPUXloginShell' > > 'x-uidNumber' > 'x-SolarisuidNumber' > 'x-AIXuidNumber' > 'x-LinuxuidNumber' > 'x-HPUXuidNumber' > > 'x-gidNumber' > 'x-SolarisgidNumber' > 'x-AIXgidNumber' > 'x-LinuxgidNumber' > 'x-HPUXgidNumber' > > 'x-AIX5shadowLastChange' > 'x-AIX5shadowMin' > 'x-AIX5shadowMax' > 'x-AIX5shadowWarning' > 'x-AIX5shadowInactive' > 'x-AIX5shadowExpire' > 'x-AIX5shadowFlag' > > Objectclasses: > 'x-posixAccount' > 'x-shadowAccount' > 'x-posixGroup' > > Then configure ldap clients with proper attribute mapping, example for Solaris: > NS_LDAP_ATTRIBUTEMAP= passwd:uidNumber=x-SolarisuidNumber > NS_LDAP_ATTRIBUTEMAP= passwd:gidNumber=x-SolarisgidNumber > NS_LDAP_ATTRIBUTEMAP= passwd:homeDirectory=x-SolarishomeDirectory > NS_LDAP_ATTRIBUTEMAP= passwd:loginSHell=x-SolarisloginShell > > Now each operating system can have its own uid/gid combination and shadow > attributes for a given username. > > Disadvantage is, that You have slightly more complex users and You have to > provide consistent settings on all machines of the same operating system. > > dn: uid=myname,ou=Person,dc=myEnterprise,dc=com > objectClass: top > objectClass: person > objectClass: organizationalPerson > objectClass: inetOrgPerson > objectClass: posixAccount > objectClass: x-posixAccount > objectClass: shadowAccount > sn: myname > cn: myname > uid: myname > mail: myname(a)myEnterpsiem.com > uidNumber: 287564 > gecos: myname > displayName: myname > x-LinuxuidNumber: 287564 > x-SolarisuidNumber: 287564 > x-HPUXuidNumber: 287564 > x-AIXuidNumber: 287564 > homeDirectory: /home/myname > x-AIXhomeDirectory: /home/myname > x-HPUXhomeDirectory: /home/myname > x-LinuxhomeDirectory: /home/myname > x-SolarishomeDirectory: /home/myname > loginShell: /usr/bin/bash > x-LinuxloginShell: /bin/bash > x-HPUXloginShell: /bin/ksh > x-SolarisloginShell: /usr/bin/bash > x-AIXloginShell:: /bin/sh > gidNumber: 50001 > x-HPUXgidNumber: 50001 > x-SolarisgidNumber: 50001 > x-LinuxgidNumber: 50001 > x-AIXgidNumber: 50001 > . > . > . > > > Kind regards > > Juergen Sprenger > Juergen, thanks very much for this. I think your approach strikes a balance between storing the same data in more than one place (separate whole ou trees for each os duplicating other information -- at the benefit of no schema changes), returning exactly the one result wanted given a search (a practical necessity as those who aren't given to maintain ldap clients like nslcd/nss_ldap are not able to cause them to iterate through a number of home-directory results with the same name looking for attributes to discern which is intended). The downside of your approach is as you note no machine specific variants, but those are few enough they can be put in the relevant machine's passwd file and that set to be searched before ldap.

1 0

How to synchornize in ldap? Please help.
by meena jain 30 Nov '11

30 Nov '11

Hi I am new to ldap. In my project , I need to send employee's information to the third party software. For the first time set up , may be I can export the ldap data and push the information to the third party software but later I want to send delta changes. We don't want to write all employee changes every day. How do I achieve this in ldap? Meena

3 2

CUCM search
by W.Siebert＠t-systems.com 30 Nov '11

30 Nov '11

> check your suffixmassage rules and compare to the rewritten suffix. Sorry, now with the right congig bellow, suffixmassage and rewritten suffix matchs, but the problem still the same ----------------------------------------------------------- Hello, now I extended the schema and filter appears without of "?", but my problem still not solved: slapd[20876]: ber_get_next on fd 8 failed errno=0 (Success) slapd[20876]: connection_read(8): input error=-2 id=1001, closing. Nov 28 20:27:39 walrhel5 If I send the same search with various LDAP-Browsers (Softerra, LDP, Perlscript...), all is OK. I tried witch OpenLDAP version: 2.4.26 and 2.4.28 FullLog: Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 fd=8 ACCEPT from IP=10.28.113.34:53476 (IP=0.0.0.0:389) Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_get(8) Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: op tag 0x60, time 1322601831 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 do_bind Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: >>> dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov> Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: <<< dnPrettyNormal: <cn=metaguru,dc=meta,dc=pov>, <cn=metaguru,dc=meta,dc=pov> Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" method=128 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: do_bind: version=3 dn="cn=metaguru,dc=meta,dc=pov" method=128 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 meta_back_bind: dn="cn=metaguru,dc=meta,dc=pov". Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0: rootdn="cn=metaguru,dc=meta,dc=pov" bind succeeded Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 BIND dn="cn=metaguru,dc=meta,dc=pov" mech=SIMPLE ssf=0 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: do_bind: v3 bind: "cn=metaguru,dc=meta,dc=pov" to "cn=metaguru,dc=meta,dc=pov" Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_result: conn=1001 op=0 p=3 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_result: err=0 matched="" text="" Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: send_ldap_response: msgid=1 tag=97 err=0 Nov 29 22:23:51 despcdarmradtest01 slapd[20876]: conn=1001 op=0 RESULT tag=97 err=0 text= Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_get(8) Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: op tag 0x63, time 1322601833 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 do_search Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: >>> dnPrettyNormal: <dc=meta,dc=pov> Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: <<< dnPrettyNormal: <dc=meta,dc=pov>, <dc=meta,dc=pov> Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: SRCH "dc=meta,dc=pov" 0 3 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: 0 0 0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: AND Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter_list Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: EQUALITY Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: NOT Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: begin get_filter Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: EQUALITY Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter_list Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: end get_filter 0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: filter: (&(objectClass=user)(!(objectClass=computer))) Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: => get_ctrls Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: => get_ctrls: oid="2.16.840.1.113730.3.4.2" (noncritical) Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: <= get_ctrls: n=1 rc=0 err="" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: attrs: Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 SRCH base="dc=meta,dc=pov" scope=0 deref=3 filter="(&(objectClass=user)(!(objectClass=computer)))" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1: meta_back_getconn[0] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1: meta_back_getconn[1] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_getconn: candidates=2 conn=ROOTDN fetched Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_back_search_start[0] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_search_dobind_init[0] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_search_dobind_init[0]=1 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov' Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'dc=spcdom,dc=udb'} Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=spcdom,dc=udb" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=computer)))' Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=computer)))" -> "(&(objectClass=user)(!(objectClass=computer)))" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_back_search_start[0]=1 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_back_search_start[1] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 >>> meta_search_dobind_init[1] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_search_dobind_init[1]=1 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='dc=meta,dc=pov' Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_rule_apply rule='((.+),)?dc=meta,[ ]?dc=pov$' string='dc=meta,dc=pov' [1 pass(es)] Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'dc=metdom,dc=net'} Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchBase: "dc=meta,dc=pov" -> "dc=metdom,dc=net" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] string='(&(objectClass=user)(!(objectClass=computer)))' Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: ==> rewrite_context_apply [depth=1] res={0,'NULL'} Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: [rw] searchFilter: "(&(objectClass=user)(!(objectClass=computer)))" -> "(&(objectClass=user)(!(objectClass=computer)))" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 <<< meta_back_search_start[1]=1 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search: ncandidates=2 cnd="**" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search[0] match="" err=0. Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 meta_back_search[1] match="" err=0. Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_result: conn=1001 op=1 p=3 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_result: err=0 matched="" text="" Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: send_ldap_response: msgid=2 tag=101 err=0 Nov 29 22:23:53 despcdarmradtest01 slapd[20876]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_get(8) Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_get(8): got connid=1001 Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_read(8): checking for input on id=1001 Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: op tag 0x42, time 1322601835 Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: ber_get_next on fd 8 failed errno=0 (Success) Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_read(8): input error=-2 id=1001, closing. Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_closing: readying conn=1001 sd=8 for close Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: connection_close: deferring conn=1001 sd=8 Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: conn=1001 op=2 do_unbind Nov 29 22:23:55 despcdarmradtest01 slapd[20876]: conn=1001 op=2 UNBIND Kind regards Waldemar -----Ursprüngliche Nachricht----- Von: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Gesendet: Dienstag, 29. November 2011 12:42 An: Siebert, Waldemar Cc: openldap-technical(a)openldap.org Betreff: Re: CUCM search > Hello, > > I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD > targets. ... > Nov 28 20:27:39 walrhel5 slapd[7447]: filter: > (&(?objectClass=user)(!(?objectClass=Computer))) The objectClasses "user" and "computer" are unknown. They need to be defined in the proxy's schema. p. ########################################################################################## Hello, I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD targets. Cisco Unified Call Manager (CUCM) sends a rather simpy query: (&(objectclass=user)(!(objectclass=Computer))) If CUCM connects AD server directly, all is OK, gets a search result. But sending this search to Meta, does not work. Log: Nov 28 20:27:39 walrhel5 slapd[7447]: ber_get_next on fd 10 failed errno=0 (Success) Nov 28 20:27:39 walrhel5 slapd[7447]: connection_read(10): input error=-2 id=1000, closing. If I send the same search with various LDAP-Browsers (Softerra, LDP, Perlscript...), all is OK. I tried witch OpenLDAP version: 2.4.26 and 2.4.28 My config: include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/ts_ext.schema pidfile /usr/local/var/run/slapd.pid argsfile /usr/local/var/run/slapd.args loglevel -1 ####################################################################### database meta lastmod off suffix "dc=meta,dc=pov" rootdn "cn=metaguru,dc=meta,dc=pov" rootpw Makaka77 uri "ldap://10.28.4.37:389/dc=meta,dc=pov" suffixmassage "dc=meta,dc=pov" "dc=spcdom,dc=udb" idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=radiator,cn=Users,dc=spcdom,dc=udb" credentials="Makaka77" mode=none uri "ldap://10.28.4.39:389/dc=meta,dc=pov" suffixmassage "dc=meta,dc=pov" "dc=metdom,dc=net" idassert-authzFrom "dn:*" idassert-bind bindmethod=simple binddn="cn=predator,cn=Users,dc=metdom,dc=net" credentials="Makaka99" mode=none

2 1

Re: OpenLDAP 2.4.27 RPMs available on LTB-project
by Clément OUDOT 30 Nov '11

30 Nov '11

2011/11/28 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Friday, November 25, 2011 8:01 PM +0100 Clément OUDOT > <clem.oudot(a)gmail.com> wrote: > >> 2011/11/25, Howard Chu <hyc(a)symas.com>: >>> >>> Clément OUDOT wrote: >>>> >>>> Hello, >>>> >>>> I built today RPMs for OpenLDAP 2.4.27, for those who are interested, >>>> they are available here: http://ltb-project.org/wiki/download#openldap >>> >>> You are probably going to want to respin these with the last 3 commits in >>> master. >>> 26dc16e9f634ed5dc061088ff3bd156dec5170c0 >>> 2c4d548206916676026a5b57298ae3086500eb66 >>> 2a8b55b1c55cb99c09543f1b5648da98f5d28a8d >> >> Thanks for this information, do you plan to release 2.4.28 to include >> these commits? > > Yes. It is out now. Hi, RPMs for OpenLDAP 2.4.28 are now available: http://ltb-project.org/wiki/download#openldap A new RPM has been created to provide overlays lastbind and smbk5pwd. Clément.

1 0

Re: CUCM search
by masarati＠aero.polimi.it 30 Nov '11

30 Nov '11

> Hello, > > I'v implemented a OpenLDAP Metadirectory that proxying 2 Microsft AD > targets. ... > Nov 28 20:27:39 walrhel5 slapd[7447]: filter: > (&(?objectClass=user)(!(?objectClass=Computer))) The objectClasses "user" and "computer" are unknown. They need to be defined in the proxy's schema. p.

3 2

Read/Write Replication setup
by benoit 29 Nov '11

29 Nov '11

Hello, I have setup a ldap replicate, replicating data from an offsite ldap master. Replication is ok, but being a consumer replicate, my ldap server is read only. I need to add and modify attributes to this replicate, but i have no write access to the master and ldap master admin won't change/update schemas... >From the guide, i can't figure if it's possible. Please, let me know what solution i have (on any Linux distro). thanks Ben,

3 4

Trust between two server
by Raffael Sahli 29 Nov '11

29 Nov '11

Hi I have a huge openldap server and a small one with maybe 10 users. The small one contains it admistrator objects (or most of them are admins) and is complitly different from the huge one. So what I want is to include some userobjects or a specific basedn from the small one in the huge one. Im not sure whats the best way for that, maybe meta backend..? or some proxy auth points to the small one.. dc=hugeldap,dc=com |-ou=users |-ou=admins |->point to ldap://ldapserver.com?dc=smallldap,dc=net/memberof=hugeldap Thanks for your help -- Raffael Sahli public(a)raffaelsahli.com

2 1

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical November 2011