Re: Syncrepl SSL fail
Philip Guenther wrote: Next: the fact that you need tls_reqcert=never for TLS negotiation to succeed strongly suggests the problem is either a) the subject and subjectAltName of the cert don't match the hostname in the URL, OR b) the client doesn't have the self-signed CA cert at the root of the signing chain for the server's cert. Those are both necessary to protect the server against Man-in-the-Middle attacks. (It used to be that tls_reqcert=allow would disable check (b) and only perform check (a), or at least that was the case when using the OpenSSL crypto backend, but that behavior has apparently been removed from the version in git as of August. Given the vagaries of the error reporting of the underlying crypto libraries, this was a useful tool in tracking down which check was causing TLS failures. Oh well.) Frankly I agree with you that the original behavior was better. As far as I recall, though i don't believe it was never documented anywhere, the main point to using ALLOW was to accept certs that were expired but otherwise correct. The current patch in git makes you totally defenseless against MITM attacks, and I can't see any reason why it would ever be correct to deploy this way. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: What's the java equivalent of ldap_set_option( NULL, LDAP_OPT_X_TLS_CACERTDIR, cert_path)?
Nick Milas wrote: Probably not much to the point, but I thought I should send this info (derived from earlier posts in this list). Which Java LDAP SDK you use is irrelevant. The point is that Java has its own TLS certificate/key management system and it doesn't use PEM files. For Java apps one could also use: http://www.unboundid.com/products/ldapsdk/ for Java or (now Oracle's) JNDI. Nick On 19/10/2011 2:28 πμ, daisy...@emc.com wrote: I am trying to write a Java LDAP client program using Novell’s JLDAP -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Loading LDAP schema files into cn=config
Ondrej Kuznik wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/19/2011 12:50 PM, Howard Chu wrote: Read http://highlandsun.com/hyc/drafts/draft-chu-ldap-xordered-xx.html I would like to point out that while back-ldif handles the ordering prefix fine, bconfig's (bconfig.c:4726) implementation of the same maintains one joint sibling ordering for all AttributeTypes under the same parent, instead of one ordering per each AttributeType as in the draft. Lately, I've been hacking together a solution to this, but my code so far is too ugly and fragile as DN handling inside OpenLDAP has been a Terra Incognita for me until now. This is the issue behind ITS#6987 I reported some time ago. Thank you Howard for linking to the draft. It reminded me that I should have done a better job at describing the issue than I did back when reporting the ITS. (Should I post the more descriptive explanation to the ITS too?) Sounds like that would be a good idea. Also, the draft does not handle multivalued RDN's nor does it explicitely say they are out of scope. Well, certainly they are out of the scope of the current implementation. I thought the draft specified that only single-valued RDNs were supported, but looking again, it's not there. - -- Ondrej Kuznik -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk6euU0ACgkQ9GWxeeH+cXuDTwCfULpYqmU+MWgJBG1QFCqImjdt h2kAoK+ork9Ycgy3+hy8TFSCAyNTG7TA =F5O4 -END PGP SIGNATURE- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: howto view slapd configuration : ldapsearch VS slapcat
Sébastien Bernard wrote: Le 19/10/2011 15:51, Olivier Guillard a écrit : Hi Seb, Isn't there any way to pass filters to slapcat see spécific part of the configuration ? Don't ask questions that are already answered in the manpages. RTFM. See slapcat(8) option -a. ldapsearch -x -LLL -D uid=admin,cn=config -W -s sub -b cn=config (olcDatabase=*) olcAccess [snip ...] Unfortunately not. Slapcat is meant to dump the whole context. You can eventualy use a small perl script to sort the relevant nodes afterwards. Else ldapsearch with '*' '+' should give you all the attributes included in the database. ldapsearch -x -LLL -D uid=admin,cn=config -W -s sub -b cn=config (olcDatabase=*) '*' '+' The '+' adds the operational attributes. S. Bernard -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SLAPI plugins do not load
Dimitri wrote: However, this is probably beside the point. I'd sooner check with a debugger if you're actually calling dlopen(/proper/path/to/the.so). If you are, it's unlikely that you'll need to debug libtool itself; it has successfully performed its wrapping and things are now in the hands of your linker. I doubt you'd find anything of note by debugging libtool itself in this scenario. If you never make it to an actual dlopen(), you're right, you may want libtool debugging. Yes, plugin library is actually being loaded. But after that it pulls libslapi.so, unsuccessfully. My bad, last time I haven't noticed an important line in ld-linux.so debug output: /usr/local/lib/libslapi-2-devel.so.0: error: symbol lookup error: undefined symbol: entry2str_mutex (fatal) Let me guess - you're on Debian or Ubuntu. https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/478827 That's why ltdl cannot load a plugin. However, this doesn't make things much clearer: that entry2str_mutex symbol is definitely present in the slapd binary, according to nm output: [root@localhost slapd]$ nm slapd | grep entry2str_mutex 082676b0 B entry2str_mutex Sounds like the slapd binary was not built correctly (so the symbol didn't get exported from the binary) or the libslapi binary was not built correctly (and doesn't have a runtime link dependency on the slapd binary). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SLAPI plugins do not load
Nick Milas wrote: On 19/10/2011 6:05 μμ, Dimitri wrote: I have tried putting ld-linux.so into debug mode (using LD_DEBUG=all), but it has shown no anomalies. Seems like it's purely ltdl issue. Does anyone have any evidence of SLAPI plugins being successfully loaded? If yes, which version of ltdl was used? Dimitri I am using LTB Project RPMs and Symas Silver RPMs (I am using x86_64 on CentOS 5.7) which have SLAPI enabled. OpenLDAP v2.4.26 is available. I've tested SLAPI with slapi-dnsnotify on Symas Silver RPMs and worked flawlessly. Thanks for the independent confirmation. The original poster is probably on a Debian-derived distro with a broken libltdl, and that's their problem, not an OpenLDAP Project issue. ltdl version: libltdl.so.3.1.4. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: syncrepl + slapd-relay + slapo-rwm some clarification needed
Jeffrey Crawford wrote:
I hate to be answering my own posts, but I've had to abandon slapd-relay
in favor of the (more advertised) slapd-ldap push replication method of
which I can put the slapo-rwm overlay on top.
There seems to be some part of the syncrepl/syncprov that transmits the
actual modification record instead of just telling the consumer to look
at what it can actually see. This had the result of the attributes I was
trying to map bypassing the rwm overlay rewrite rule and showing up
after the initial correct sync.
the slapd-ldap + sycrepl + rwm seems to be working much better.
One problem I am having with the slapd-ldap syncrepl method is that I
can't seem to integrate the slapd-ldap on the same instance as the
consumer. (Which of course is not documented anyway) Trying to do so was
causing any attempt to create or modify the syncrepl push proxy to hang.
I also didn't want to place the proxy on the supplier server either so I
settled for an additional proxy instance that sits in-between the
provider and consumer. So far this has been stable in the functional
testing (I haven't load tested yet).
I'm not sure if the syncrepl push proxy should be able to be on the same
machine as the consumer or if that kind of configuration is undefined
and not expected to work. If there is consensus of the former I'll
create a ticket, but I don't want to waste time either.
No, that's not intended to work. Push replication using a slapd-ldap proxy was
only developed to allow pushing to a slave on the other side of a firewall; as
such the proxy would not normally reside in the same place as the replica.
Jeffrey
On 10/11/11 9:35 AM, Jeffrey Crawford wrote:
Hello all,
We have a need to populate one of our replicas with mapped attributes
long story short, using a ldap proxy to perform the mapping will not be
sufficient since the attributes are being used by OpenLDAP itself.
I've found that when setting up a slapd-relay to virtualize the suffix
and then use rwm to perform the mapping I get the desired view. However
when trying to replicate the content using a replication account things
start acting weird I think mostly because syncrepl processes changes via
logs and update instructions from the provider to the consumer.
That being the case the syncrepl RefreshAndPersist actually changes the
values from the original update instruction. Ergo the replica looking at
the virtualized suffix (using relay) actually gets the attribute
populated that I wanted mapped. Meaning the replica and the relay view
don't agree rather the replica and the original data agree.
I've found that if I use the syncrepl RefreshOnly the replica yields the
desired results however that is performed on intervals so the data isn't
immediately available. So Have I missed something on the
RefreshAndPersist method that would also yield the desired results? Or
is RefreshAndPersist always going to see the original change being made
even if the underlying relay view shows the mapped attributes?
Ugh the above is so complex to describe Below is an example to
facilitate a quick explanation.
### Provider hdb database
dn: cn=record,dc=suffix,dc=org
cn: record
attr1: value1
attr2: value2
attr3: value3
### Provider relay database
dn: cn=record,dc=suffix,dc=org,cn=mapped
cn: record
attr1: value1
attr2: value3 | |
attr3: value2 | Values switched |
{ Replica Section } #
### replica from cn=mapped using RefreshAndPersist (Undesired)
dn: cn=record,dc=suffix,dc=org
cn: record
attr1: value1
attr2: value2
attr3: value3
### replica from cn=mapped using RefreshOnly (Desired)
dn: cn=record,dc=suffix,dc=org,cn=mapped
cn: record
attr1: value1
attr2: value3 | |
attr3: value2 | Values switched |
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: howto view slapd configuration : ldapsearch VS slapcat
Olivier wrote: Hi Howard, As said in a previous mail, I had seen the -a option in the manual that also says : -a : Deprecated : use -H ldap:///???(filter) instead. I however tried -a and I humbly admit that I have not been able to say : ' -s sub -b cn=config (olcDatabase=*) olcAccess ' using that option ( by the way, I tend to beleive that it is not feasable and that Sebastien was right at the end (-: I only answered your question about how to use a filter with slapcat. You cannot duplicate the effect of ldapsearch completely; you can't ask for just a specific list of attributes. slapcat always returns whole entries. I also looked at the recommended -H option but : - first, as I understand it -H can't be used if slapd doesn't run, Where does any documentation say that? Where do you get these mistaken understandings from? Please point them out so the documents can be corrected. slapcat reads the database files directly. Whether slapd is running or not is irrelevant. - Second, even with slapd runing, I have not been able with -H to say : -s sub -b cn=config (olcDatabase=*) olcAccess You haven't shown an example of the command you attempted, so we can't tell what you did wrong, but obviously you did it wrong. Go read RFC4516. slapcat -H ldap:///cn=config??sub?(olcDatabase=*) I will survive without it to be honnest, but I just try to understand tools and to be clean. --- Olivier On Wed, Oct 19, 2011 at 5:27 PM, Howard Chuh...@symas.com wrote: Don't ask questions that are already answered in the manpages. RTFM. See slapcat(8) option -a. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Securing cn=config and allowing micro-engineering
Nick Milas wrote: Hello, Having migrated from slapd.conf, I would like to ask some questions regarding cases/scenarios where someone - unintentionally - breaks the configuration. So, let's assume that, due to some misspelling or use of wrong values (esp. when using a graphical LDAP Browser - like JXplorer - to maintain the configuration DIT), we have added/modified a setting that would break the installation without warning. *Question 1*: Are there cases where: 1/ LDAP Server will stop immediately? (It is stated that Beware: You can configure cn=config to an unusable state., ref. with example: http://www.zytrax.com/books/ldap/ch6/slapd-config.html) Not intentionally. Some errors could lead to an assert() failing, which would cause slapd to stop. Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what they advise is misguided or flat wrong. 2/ LDAP Server will continue to operate but, if stopped, when restarted it will not be able to restart? This has been known to happen a few times in the past due to bugs in the config code. In general, no. If the answer to Q1.2 above is yes: *Question 2*: How can we test at any given point the current configuration to make sure it will be OK if/when restarted (AFAIK, slaptest only tests slapd.conf and not slapd.d configuration)? Where do you get this knowledge? From Zytrax? slaptest tests the server configuration - it doesn't matter whether it is in slapd.conf or slapd.d. *Question 3* (especially critical if the answer to Q1.1 or Q1.2 above is yes): If the server is stopped, how can we change manually the config settings (e.g. by editing slapd.d/ files) to attempt to correct it? Manually editing slapd.d files is the surest way of causing a problem that prevents slapd from restarting. (In one such test I did, I changed - directly in cn=config.ldif file - olcLogLevel as follows: Initial state: olcLogLevel: Config olcLogLevel: Sync New state (removed one attribute value and changed the other): olcLogLevel: -1 and when I tried to start I got: ldif_read_file: checksum error on /usr/local/openldap/etc/openldap/slapd.d/cn=config.ldif so I had to re-edit the file and change the values as they were initially, which allowed the server to start. So (to *repeat Question 3*), how can we re-engineer cn=config settings when off-line? It is always desirable to be able to do some low-level engineering to the configuration (under administrator's or system engineer's responsibility) in case something goes wrong. This is also important in cases of cloning the server where we want a copy of the config but we need to change a few settings in the new context. We need to avoid things like checksum error! It is always desirable to not make a mistake that blows your foot off (or ankle or leg, for that matter). In this case, that means ensuring that any changes you want to make are checked for syntax and other such constraints, so that you're not stuck with a non-working config. Obvious approach: slapcat -n0 -F old/slapd.d config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy... Finally, there might be cases where - after having migrated and worked for a period using cn=config - business/technical needs require the use of overlay(s) or other modules like SLAPI, which would not be supported by cn=config and someone would need to move to slapd.conf configuration (at least temporarily). If such a need arises, *Question 4*: Is there a tool/method to migrate to slapd.conf from a slapd.d configuration? Ask your buddies at Zytrax, they seem to think so. As far as the OpenLDAP Project is concerned, conversion from slapd.conf to slapd.d is a one-way trip. Migrate everything else forward. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: howto view slapd configuration : ldapsearch VS slapcat
Olivier Guillard wrote: Thanks Howard, you can't ask for just a specific list of attributes. slapcat always returns whole entries. That's what I didn't get : thanks. The slapcat(8) manpage says: The entry records will include all (user and operational) attributes stored in the database. You haven't shown an example of the command you attempted I tried almost the same with the attribute that I try to retreive included : slapcat -H ldap:///cn=config??sub?(olcDatabase=*) slapcat -H ldap:///cn=config?olcAccess?sub?(olcDatabase=*) but obviously you did it wrong. You are obviously right since I get this : usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o name[=value]] [-c] [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s subtree] [-H url] I thought that my URI was correct though. The slapcat(8) manpage says: -H URI use dn, scope and filter from URI to only handle matching entries. It says nothing about using an attribute list in the URI. Did you think we were just joking? That what the docs say is not what is actually meant? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Google hits for OpenLDAP
Brett @Google wrote: On Thu, Oct 20, 2011 at 10:00 PM, Hallvard B Furuseth h.b.furus...@usit.uio.no mailto:h.b.furus...@usit.uio.no wrote: Howard Chu writes: Zytrax.com is not a reliable source of OpenLDAP documentation. Most of what they advise is misguided or flat wrong. Yet Google(OpenLDAP cn=config)'s two first hits are at Zytrax. It's not surprising people keep using that stuff. Maybe the OpenLDAP site could be improved to help that. Google has some guidelines for that at http://www.google.com/webmasters/ I think the popularity of Zytrax guide on google indicates that there is a need for some simple guide or howto of how to get some sort of trivial ldap server running, in the first instance. Zytrax might fail with regard to accuracy in specific details as it seems to be infrequently updated (last August 2010, before that July 2009), but taken asis it gets people going such that they can at least get a server running, then they can then start to learn by actively using openldap. The zytrax guide itself is open source, so the other alternative is to help improve it's accuracy ? Wow, talk about putting the cart before the horse. Last time I checked, the OpenLDAP documentation was also open source. If anyone sincerely wants to improve the docs and make things easier for new users to get off the ground, while getting their edits vetted by people who actually understand how the code works, the obvious (to me anyway) thing to do is to submit updates in the ITS. The Zytrax guys are clearly just out to make a buck, lifting the OpenLDAP Admin Guide content and putting a thin layer of personal experience around it. They're not contributing back to the OpenLDAP community; they're not participating in the community at all, and the info they're distributing is (as noted) already outdated. Such a openldap guide might least serve a purpose, more for newbies as supposed to the old salts, in that it could reduce chatter regards to getting a server compiled/running/loaded etc., in the first place, but call me an optimist. If you really believe that helping a 3rd party keep their obsolete plagiarism of the OpenLDAP Project's work up to date is a good idea, optimist is not the word I'd use for you. Cheers Brett -- *The only thing that interferes with my learning is my education.* * Albert Einstein* -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Securing cn=config and allowing micro-engineering
Nick Milas wrote: On 20/10/2011 9:03 μμ, Quanah Gibson-Mount wrote: slapcat -n0 -F old/slapd.d config.ldif edit config.ldif slapadd -n0 -F new/slapd.d -l config.ldif test using new/slapd.d deploy... I would note that OpenLDAP 2.5 (when released) adds a slapmodify command per my request. It allows you to do offline modifications of cn=config in a way similar to ldapmodify. This will also keep the CRC checksum intact. slapmodify will surely be an important addition. (Although v2.5 might not be that close.) Question: Can we use: slapadd -n0 -F new/slapd.d -l config.ldif while slapd is running? Documentation states: Your slapd should not be running when you do this (i.e. when using slapadd) to ensure consistency of the database... But this command does not really interfere with the current database (which is in old/slapd.d). So please clarify. That note is only referring to use of slapadd to add data to a database that slapd is already using. If you're using totally separate filesystem directories, then of course you can slapadd to a config directory different from the one that slapd is currently running. It's not like there's a magical filesystem lock such that slapd knows about everything else occurring on the machine or filesystem. Use some common sense. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapcat -n 0 and slapadd
Craig White wrote: On Oct 26, 2011, at 12:00 PM, Howard Chu wrote: Craig White wrote: Having migrated to dynamic config, I'm looking for a reasonable way to restore in the event of a disaster. The discussion last week got me curious and though I can slapcat -n 0 -l $SOME_FILE I can't slapadd this same file because it complains that I don't have a slapd.conf file, which of course is true... I haven't needed it with the dynamic configuration backend. What's the minimum that I would need in a slapd.conf file so I can simply 'rm -fr /var/lib/ldap/* slapadd -l $SLAPD_BACKUP' ? You don't need a slapd.conf file at all. You just need to tell it where to slapadd the configuration. slapadd -F new/slapd.d -n0 config.ldif # mkdir /etc/ldap/slapd.d # slapadd -l slapcat_config.ldif -F /etc/ldap/slapd.d Available database(s) do not allow slapadd There aren't any databases configured because I'm thinking recovery from a disaster, starting from a clean install as it were. Pay attention. Even a monkey can copy text without omitting parts. slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapcat -n 0 and slapadd
Craig White wrote:
On Oct 26, 2011, at 1:13 PM, Howard Chu wrote:
Pay attention. Even a monkey can copy text without omitting parts.
slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif
sorry - I'm stupid but and am not a monkey.
It seems to me the reason that something like Zytrax gets traction is
sometimes the seemingly very simple just doesn't work and then of course,
there is the public chastisement that seemingly comes with the territory.
It's called negative reinforcement, and it is intentional, to discourage
careless posts like yours. You're free to carelessly waste as much of your own
time as you like, but it's extremely inconsiderate of you to waste the time of
everyone else subscribed to the mailing list.
All
I am trying to do is have a disaster plan though admittedly, I can do pretty
much the same because I have a scripted installation which I can use to set up
the configuration again and just ldapadd (possibly slapadd) the main DSA data.
This was something I could do easily with a flat file configuration but
dynamic configuration has made this a real chore.
It may seem a real chore to you but you've only made it difficult for
yourself, by failing to read and pay attention, as already demonstrated
before. There are countless installations out there all working fine. The
majority of deployments simply fire it up and go their merry way. That would
not be the case, if things were as difficult as you make them out to be.
blow by blow... (have done slapcat -n 0 -n 1 from my production machine
and
am working on a VM test, certificate names paths have been fixed for the VM
and adjustments made for apparmor)
root@ubuntu:/etc/ldap# rm -fr slapd.d/*
root@ubuntu:/etc/ldap# rm -fr /var/lib/ldap/*
root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 0 -l slapcat_config.ldif
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd: could not add entry dn=olcDatabase={2}hdb,cn=config (line=1009):
_### 99.24% eta none elapsednone spd 5.4 M/s
Closing DB...
Your first mistake here is in continuing on even though this first slapadd
command clearly failed. Again - PAY ATTENTION to what's in front of you.
Your other mistake is obviously that you deleted the directory that your
config used. This mistake has nothing to do with dynamic configuration; you
would have had the same error if you were using slapd.conf. It's easy to shirk
responsibility for your actions and blame the software, but it's clear that
you're creating your own problems by not paying attention to what you're doing.
root@ubuntu:/etc/ldap# slapadd -F /etc/ldap/slapd.d -n 1 -l slapcat_data.ldif
accesslog: logdbsuffix missing or invalid.
backend_startup_one (type=hdb, suffix=dc=ttinet,dc=local): bi_db_open failed!
(1)
slap_startup failed
line 1009 in my slapcat_config.ldif...
dn: olcDatabase={2}hdb,cn=config
Once again - the software clearly told you which entry and attribute it had a
problem with. If you had paid attention to it, instead of ignoring it and
creating your own fantasy scenarios, you would have a working system by now.
but just above that line is the section...
Which was completely irrerlevant...
You can learn from your mistakes, and actually start paying attention, or you
can continue to ignore what's in front of you. If you choose the latter, I
would ask that you quit using OpenLDAP software and go use someone else's
package, because there's nothing rewarding in trying to help people who don't
learn.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Using NSS
Daniel Qian wrote: On 11-10-27 3:41 PM, Braden Northington McDaniel wrote: On Oct 27, 2011, at 2:27 PM, Daniel Qian wrote: why don't you simply try TLS_CACERT /etc/pki/nssdb/filename instead of TLS_CACERTDIR /etc/pki/nssdb Because the cert isn't in a text file; it's in the NSS database. I saw similar problems to what you are having but it was for openssl and can be fixed by running an openssl command plus some options. In your case it seems the NSS database isn't in the format ldap client expects. Note that by default, NSS expects to see a certificate database. You need an additional module to enable it to use PEM files. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: back-config and Post Read Control?
masar...@aero.polimi.it wrote: Michael Ströder wrote: Does back-config support the Post Read Control? That would be handy for retrieving the renumbered DN after an Add or Modify request. Hmm, experiments shows that this does work. Server returns: Critical extension is unavailable: critical control unavailable in context As far as I remember, back-ldif is relatively poor in terms of non-core functionalities it supports, as it has never been intended for actual stuff storage with the only notable exception of back-config. I think, due to the extra processing back-config does on top, it wouldn't matter if back-ldif supported it or not, it would still need to be explicitly added to back-config. It would be interesting to see back-config based on top of something else (e.g. back-hdb or even back-mbd). back-mdb would be pretty interesting, definitely. It would be possible (in the future) to reference settings directly from an MDB entry record, instead of copying back and forth between slapd global variables and Entry structures. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Configuring shared memory / memory mapped files
Meike Stone wrote: Hello, time ago, we installed a Linux Guest with OpenLDAP (db size appox. 650MByte / ) server in a ESXi environment. Maybe because of a read/write ratio 100:1, the hard discs where heavy used by writing bdb backends memory mapped files. The CPU in that Linux system had iowait (top) between 80% and 100% and the other VMs on the ESXi went slow down. After changing to shared memory (shm_key), all problems with disc IO where gone. I read in the mailing list and on OpenLDAP performance tuning guide, that it does not matter if using memory mapped files or shared memory until the database is over 8GB. But why we had such problems? Please note, the OpenLDAP was operating very fast with the memory mapped files, because of using indexes and proper caching. Now, I want install more than one OpenLDAP server on one Linux system (now real Hardware). Every OpenLDAP server will be bind on a separate IP and DNS host name. So in this scenario it is hard to calculate the shared memory and assign each LDAP server to the right shared memory region (key). ?? Just pick some key numbers that are spread out enough to not overlap. 10, 20, 30, 40, etc. Therefore I want go back to memory mapped files. Are there any recommendation for sizing the Linux system like: - type of file system (ext3, ext4, xfs, ..) - parameters of file system (syncing - commit=nrsec, data=*, ... ) - swap using (swappiness, dirty_background_ratio) - ??? Probably the most important setting is to mount with noatime or relatime. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Configuring shared memory / memory mapped files
Meike Stone wrote: Hello, time ago, we installed a Linux Guest with OpenLDAP (db size appox. 650MByte / ) server in a ESXi environment. Maybe because of a read/write ratio 100:1, the hard discs where heavy used by writing bdb backends memory mapped files. The CPU in that Linux system had iowait (top) between 80% and 100% and the other VMs on the ESXi went slow down. After changing to shared memory (shm_key), all problems with disc IO where gone. I read in the mailing list and on OpenLDAP performance tuning guide, that it does not matter if using memory mapped files or shared memory until the database is over 8GB. But why we had such problems? Please note, the OpenLDAP was operating very fast with the memory mapped files, because of using indexes and proper caching. Now, I want install more than one OpenLDAP server on one Linux system (now real Hardware). Every OpenLDAP server will be bind on a separate IP and DNS host name. So in this scenario it is hard to calculate the shared memory and assign each LDAP server to the right shared memory region (key). Therefore I want go back to memory mapped files. Are there any recommendation for sizing the Linux system like: - type of file system (ext3, ext4, xfs, ..) - parameters of file system (syncing - commit=nrsec, data=*, ... ) - swap using (swappiness, dirty_background_ratio) - ??? Also, back-mdb (in git master) will behave much better in a VM deployment. (Actually, back-mdb behaves better than back-bdb/hdb in all environments.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Searches causing disk writes
Meike Stone wrote: 2011/11/10 Adam Walead...@staff.iinet.net.au: For anyone that was interested in the fix for this, moving to shared memory resolved the issue. Hello Adam, we had the same problem and could it solve the same way. Sorry, I haven't seen this thread.. Do you have tried to mount your partition where the data directory is located with noatime? This (atime) causes a lot of very expensive write operations on every read access of the memory mapped files. It would be very interesting if mounting the data partition with noatime can solve the problem too? But be careful, some other programs (e.g. mail, backup,..) may rely on atime, it depends what programs using this partition. Use relatime, that will take care of any other dependencies. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: proxy authentication
LALOT Dominique wrote: Hello, We would like to setup a kind of replica. We don't want to replicate some attributes like userpassword, lmpassword, ntpassword. How can we configure the replica to proxy the authentication somewhere else. Is there a way to do that via an overlay or something else? The pbind (ProxyBind) overlay will proxy Simple Binds to another LDAP server. See slapo-pbind(5). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: biometric authentication
Chris Lee wrote: Dear all, I am a newbie to OpenLDAP. I would like to know whether OpenLDAP can interface with other authentication method. For example, finger print authentication. OpenLDAP relies on SASL for pluggable authentication mechanisms. Since SASL is extensible, new mechs should just be implemented there (which thus allows them to be used by any other applications that are also SASL-enabled, such as IMAP servers or whatever...) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: MDB distribution
Brett @Google wrote: On Mon, Nov 14, 2011 at 3:20 PM, Howard Chu h...@symas.com mailto:h...@symas.com wrote: Brett @Google wrote: Sorry for the fuzzy logic :P, but : My thoughts for no: 1. The name will affect only the name of the backend module, which is logically a unit under the scope of openldap (and all backends share a prefix), it can't exist by itself. This point is false; libmdb builds on its own and is intended for use in more than just OpenLDAP. (I already spelled this out in my LDAPCon presentation...) I've ported SQLite to use it, for example, and I will be porting it to Cyrus SASL (sasldb), Heimdal, and various other miscellaneous stuff that comes along. The API is fully documented in Doxygen, and part of the reason I went to that trouble was to ensure that other programmers could use it easily. Mmm. That sounds interesting. I have only just read your LDAPCon presentation, i have been away. Will the source for mmdb library itself eventually live separately somewhere, or just bundled with ldap ? It will always reside in the OpenLDAP git repo. You can use e.g. git clone -b mdb.master git://git.openldap.org/openldap.git mdb to grab just the libmdb source. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: About set LDAP passwd expires
Simone Piccardi wrote: On 11/11/2011 03:31, Chris Jacobs wrote: Password Policy. The OpenLDAP Admin Guide and Google are your friends. That's good for LDAP authentication, but when you want to put linux users in LDAP then you need to have also to configure NSS and PAM to use it. And for most distribution nssov (that if I understand rightly the issue is the way to use ppolicy for NSS) is not packaged nor supported (and is not documented too, at least in the Guide). When did nssov come into the discussion? pam_ldap supports the password policy extension. The Admin Guide has only ever been a Guide, not an exhaustive reference. The manpages are always the complete and authoritative documentation. If you choose not to use features because they aren't mentioned in the Guide, you're shortchanging yourself. So at least for me the traditional posixAccount and posixGroup are still a better option (and there are many management packages you can use). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: trigger script on change to db
Michael Ströder wrote: E.S. Rosenberg wrote: I was wondering is it possible to set a slapd syncprov consumer to trigger a script when it receives changes to the db (updates of specific attributes). You might want to try something with a synclrepl consumer served by back-sock. But I think getting this right is almost as much work as implementing your own syncrepl client. That's almost on the right track. Use back-sock as an overlay. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Search access does not return any result
sim123 wrote: On Mon, Nov 14, 2011 at 4:45 PM, Howard Chu h...@symas.com mailto:h...@symas.com wrote: sim123 wrote: On Mon, Nov 14, 2011 at 1:37 PM, sim123 sim3...@gmail.com mailto:sim3...@gmail.com mailto:sim3...@gmail.com mailto:sim3...@gmail.com wrote: Hi All, I am playing with access controls on openldap 2.4.26, I have a user with search access on everything access to * by anonymous auth by dn=uid=102,ou=system,dc=__example,dc=com search And when I perform search I get nothing ldapsearch -H ldap://testldap:389; -D uid=102,ou=system,dc=example,__dc=com -b ou=users,dc=example,dc=com -x -W '(uid=1)' mail cn dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base ou=users,dc=example,dc=com with scope subtree # filter: (uid=1) # requesting: mail cn dn # # search result search: 2 result: 0 Success # numResponses: 1 so I get a success but no value, is it a valid response? Yes, it's a valid response. You haven't given Read access to anything, so no values can be returned. But the search base existed and you had search access to it, so the search request succeeded. I want to control access so that the uid=102 user can do lookup from given attributes but can not do (objectClass=*) to get a list of every entry in the ldap. Thanks for the help Other way of stating my problem is I want to control query filters on the server side so the user with uid=102 can only do query using filter (uid=.+) , all other filters should be restricted. I tried this regular expression but getting no such object error. It seems to me that what you want cannot be done. You need Read access in order to retrieve any values. Read access includes Search access. So if you are able to read the value of an attribute, you are allowed to Search for it as well. Thanks for the response, just wondering how can one prevent ldap injections from the server side? In my scenario there will be different systems talking to server and how can I prevent them from getting list of users by doing simple query? I am using uid as login id and this uid is not part of DN (because it can change and I need the DN in different ldap groups), so for normal authentication these systems need to know respective DN from given uid. Thats why I give read privilege to a system account, all anonymous users have auth privilege only. Am I missing something here? Thanks again for the help and support. Perhaps just configuring a sizelimit for those servers' IDs will be sufficient for your goal. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP syncrepl woes
Jeffrey Crawford wrote: I'm trying to stabilize our openldap server farm before going live and am finding that despite the contextCSN matching between providers and replicas, the actual content of the server is getting out of sync. This is most prominent when we are testing our population routine and we need to remove all accounts before starting. right now it's only about 22000 entries (It will get much larger). During the mass delete we got the following sprinkled throughout the logs on all machines: Nov 15 15:47:16 idm-prod-ldap-2 slapd[33070]: bdb(dc=domain,dc=name): previous transaction deadlock return not resolved Wow. I've never seen this error message before. What version of OpenLDAP and BerkeleyDB are you using? Nov 15 15:47:16 idm-prod-ldap-2 slapd[33070]: = bdb_idl_delete_key: cursor failed: Invalid argument (22) and the various replicas would still have accounts left over but they wouldn't match each other. There are known bugs in syncrepl delete handling. ITS#7052 is probably relevant here. The fix will be in 2.4.27. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP syncrepl woes
Jeffrey Crawford wrote: On Wed, Nov 16, 2011 at 12:09 AM, Howard Chuh...@symas.com wrote: There are known bugs in syncrepl delete handling. ITS#7052 is probably relevant here. The fix will be in 2.4.27. Any idea when it will be released? The release branch has been ready to go for a few days. Probably sometime next week. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP syncrepl woes
Jeffrey Crawford wrote: On Wed, Nov 16, 2011 at 1:27 PM, Howard Chu h...@symas.com mailto:h...@symas.com wrote: Jeffrey Crawford wrote: On Wed, Nov 16, 2011 at 7:40 AM, Jeffrey Crawfordjeffr...@ucsc.edu mailto:jeffr...@ucsc.edu wrote: On Wed, Nov 16, 2011 at 12:09 AM, Howard Chuh...@symas.com mailto:h...@symas.com wrote: Jeffrey Crawford wrote: I'm trying to stabilize our openldap server farm before going live and am finding that despite the contextCSN matching between providers and replicas, the actual content of the server is getting out of sync. This is most prominent when we are testing our population routine and we need to remove all accounts before starting. right now it's only about 22000 entries (It will get much larger). During the mass delete we got the following sprinkled throughout the logs on all machines: Nov 15 15:47:16 idm-prod-ldap-2 slapd[33070]: bdb(dc=domain,dc=name): previous transaction deadlock return not resolved Wow. I've never seen this error message before. What version of OpenLDAP and BerkeleyDB are you using? FreeBSD 8.2 with openldap 2.4.26, however like I mentioned before, right now I think we are squeezing ram right now Part of this deployment was to discover how much ram we needed on the virtual machine and it was started pretty low. Oh and we are using bdb 4.6 right now (forgot to answer that) Running out of memory would cause an obvious error message (no memory) so that's not likely to be the problem here. Might be worth upgrading to at least BDB 4.8, but again, never having seen BDB spit out that error before, that's just a guess. Not sure if this is significant but I'm been noticing that this error only shows up on deletes. However it also shows up on deletes on the machine I'm running the ldapdelete against. So perhaps this is more of a software issue. I'll go ahead and run this with more ram and I'll check with the sysadmin if they can compile it against bdb 4.8 and see if that changes anything. But I don't think ITS#7052 applies here because the machine I'm doing this against does not use syncrepl, its the provider to others. This is a machine on a VM. Are there any known issues with that? Way back in the dawn of time, there were some VMware implementations that didn't support mutexes correctly. I don't think that's been an issue for many years. There ought to be other error messages in your log, immediately preceding the one you quoted. Post those too. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP syncrepl woes
Jeffrey Crawford wrote: On Thu, Nov 17, 2011 at 5:50 PM, Howard Chuh...@symas.com wrote: There ought to be other error messages in your log, immediately preceding the one you quoted. Post those too. There really isn't much there but here is an example really not much around it: (I've modified the usernames only) Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 DEL dn=uid=user1,ou=people,dc=ucsc,dc=edu Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10706 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 DEL dn=uid=user2,ou=people,dc=ucsc,dc=edu Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10707 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 DEL dn=uid=user3,ou=people,dc=ucsc,dc=edu Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10708 RESULT tag=107 err=0 text= Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 DEL dn=uid=user4,ou=people,dc=ucsc,dc=edu Nov 17 21:11:55 localhost slapd[1912]: bdb(dc=ucsc,dc=edu): previous transaction deadlock return not resolved Nov 17 21:11:55 localhost slapd[1912]: = bdb_idl_delete_key: cursor failed: Invalid argument (22) Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10709 RESULT tag=107 err=80 text=entry index delete failed Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 DEL dn=uid=user5,ou=people,dc=ucsc,dc=edu Nov 17 21:11:55 localhost slapd[1912]: conn=1478 op=10710 RESULT tag=107 err=0 text= Strange. The log shows an error occurring while deleting an index. The error message indicates that there was already a deadlock before, but there's no message from the original deadlock, and the indexing code logs *every* error that occurs. Seems more likely a BDB bug. Also your client is broken, it looks like it completely ignored the failure result from the ldapdelete operation, it just went right on to issue another request. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Aw: Re: Newbie: can't connect and enable logging
cf...@arcor.de wrote: Hi, Von: NetNinja2bitni...@gmail.com Hi, This how I enable logging for openldap on red hat. In the /etc/openldap/slapd.conf file add this line. there's no slapd.conf in Debian. That's my problem. All manuals reference to slapd.conf but they use cn=config. Not all. http://www.openldap.org/doc/admin24/slapdconf2.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: proxy authentication
LALOT Dominique wrote: I am coming back on a thread as there was no answer master or replica (managed by a central team) /\ | (proxied bind) partial replica (no userpassword) (managed by another team) /\ | simple bind Is there a simple way to do that (no kerberos/sasl)? The bind on the partial replica is proxied to another server. Use the proxybind overlay (built into back-ldap). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP 2.4.27 RPMs available on LTB-project
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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Syncrepl error causes consumers to freeze
Nick Milas wrote: On 28/11/2011 11:37 πμ, Quanah Gibson-Mount wrote: You've provided zero information on why they are freezing (i.e., a backtrace with debugging symbols enabled on the servers where slapd has frozen). Thanks Quanah, Unfortunately, such error has not ever appeared until now, so I doubt I'll be able to reproduce, so as to create a backtrace. If, however, I manage to reproduce, I'll surely post the results. It's a production system, so testing is not so straightforward. Error logging of the form: Nov 23 23:12:04 dns2 kernel: slapd[2736] general protection rip:4b5342 rsp:43c54530 error:0 is practically useless? It shows that something crashed. It doesn't tell what or why. Without a backtrace there's nothing we can determine. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Ldap+Nfsv4+kerberos *nix / *bsd puzzle.
Harry Coin wrote: Hello group! Looking for guidance on an ldap+NFS4+Kerberos puzzle in a mixed OS local environment. Simple demo case, four computers on a little net. box 1: Running openlap server, kerberos KDC, kadmin, lets say it's running freebsd, doesn't matter. nfs server client. box 2: Linux box. nfs server client. box 3: *bsd/Solaris box. nfs server client. box 4: misc user box, could be *bsd or *nix. Networking: Nfs4 secured with kerberos. That means No uid/gid numbers on the wire, only user@box.NSS is active on all boxes, reaching out to the ldap server on box 1 for info for what is not in the local passwd file searched first. Popular package X gets installed on box 2 and box 3. Package X is a drop-root privilege package, has its own uid/gid!=0. It is active on the net, might write log files or get data files via nfs on either of the other two computers in the setup. The maintainers for package X in the *bsd world have chosen a different number for the uid / gid for the package X daemon than the maintainers for package X have chosen in the *nix world. Those get written in the local passwd file on each system at package X install / download time. Note: Package X does _not_ get installed on the ldap server box #1, or box #4. There is no entry in the #1 or #4 system's passwd file for nss to find for the daemon associated with package X. nfsuserd via nss must find the package X user in ldap or the files will be unreadable or seem 'owned' by nobody:nogroup on 1 or 4 if say config or log files edited/accessed from there. Puzzle: What should the posixAccount uidNumber and gidNumber value be in ldap for uid=packageXdaemon? Alternatives: 1: Choose no entry, leave it out of the ldap db: PackageXDaemon's files will be owned by nobody:nogroup on box 1. Security Fail. 2: Choose *nix for the uid/gid in the ldap database on box 1. Fail: The files will be stored with a uid/gid that might collide with another account in the passwd database on the *bsd server. 3: Choose *bsd for the uid/gid in the ldap database on box 1: Fail: The *nix user on box 4's nfsuserid will get the bsd uid/gid from ldap which could create files not actually owned by something colliding in the *nix passwd database on box 4. 4: Instead storing all the users once under an ou=Account... create ou=AccountBSD and ou=AccountNix, duplicate the whole account tree but vary the apropos uid/gid pair under each tree with all the other remaining equal, manage collisions when amending the database. Not so pretty. 5: Edit the schema to replace uidNumber and gidNumber with uidNixNumber / uidBsdNumber etc. for gid. Breaks code expecting standard uidNumber gidNumber in the default ldap schemas. There are so many packages that could be X, you can imagine not wanting to have to qualify and patch all of them to use a common uid/gid number. (And it gets even worse in a mixed nfs3 / nfs4 environment where uid/gid numbers actually go over the wire in some cases, and user@box in others, let's leave that to the side for now). I'm leaning toward #5 to avoid storing all the other account information under two different trees.But I'd prefer a scheme were there is a not-edited standard schema tree stored once under 'ou=Account' but with a different overlay for the uid/gid elements if looked up as AccountNix or AccountBsd. I'm sure someone has done battle with this already, what's the right answer? http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=doc/drafts/draft-howard-rfc2307bis-xx.txt;h=74bfdc7c268053c8375e5fe9de68f60b10e91084;hb=HEAD Section 2.2.2 AFAIK nobody has implemented this feature yet, but it is the right solution. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: memberof overlay deployment
Asplund Marko wrote: Masarati wrote: slapo-memberof(5) does not support tool mode; *No* overlays support tool mode. That's fundamental to the design. in order to populate the memberOf attribute of an existing database you need to use ldapadd(1). You could, for example, dump your group entries, remove them, and re-add them via ldapadd(1). Thanks for clearing that out. Could this be mentioned in the documentation somewhere (e.g. slapo-memberof(5))? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: openldap with Ipv6 link local ip?
Richard Knight wrote: Is it possible to use an IPv6 Link-Local ip with openlap clients? address would be of the form ldaps://[fe80::abcd:346:123%eth0]:636 where %eth0 is the interface specifier The host part of the URL is just passed to getaddrinfo() and the resulting address is returned in a struct sockaddr. As far as I know there is no field of these structs reserved for an interface name, so the %eth0 part would not be valid. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: db_recover question
frank.offerma...@caseris.de wrote: Since I haven't got an answer to my previous question. Maybe you could answer me this questions: In the cases slapd.exe performes internal database cleanup at startup is it possible for LDAP clients to access the database while cleanup is running or will connect attempts from clients fail at that state. Connections will fail until recovery is done. If the database is locked while recovering we would be able to assume safely, that internal database recovery at startup has completed when a client connect attempt succeeds. Can we? Yes. I searched the list and found several different informations to db_recover. In older versions it was not advised to do a manual db_recover. Can db_recover still harm a consistent database (I use db-5.1.25.NC / hdb)? No, it will not harm the DB. It will reset the BDB environment, thus erasing the BDB cache and causing a slower startup, but aside from that there should be no visible effect. To be more precise, should I try to find out, if a unclean shutdown occured and then db_recover manually or can I db_recover with the 5.1.25 DB and Openldap 2.4.26 at every startup? No. slapd does recovery automatically. In most cases there is no need to run db_recover manually. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Starting out with NSS overlay - Guidance required
ptw wrote:
Hi gang!
I'm looking for some guidance in what is most probably a very common
objective. Which is to manage all authentication to network hosts
from slapd. To begin, my goal is to have:
1. one machine (generically-configured LDAP client) running sshd
(10.153.107.100)
2. multiple LDAP users
3. specify, from slapd, that only one user (tony) can log in over ssh
to the machine
Surprisingly, I have not found much documentation on this stuff beyond
the slapo-nssov man page.
The man page contains everything you need to know. You just need to pay
attention to the details.
These are the entries I have so far:
for slapd-config:
# NSSOV
dn: olcOverlay=nssov,ocDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcNssOvConfig
olcOverlay: nssov
olcNssSsd: passwd ldap:///ou=People,dc=example,dc=com??one
olcNssSsd: group ldap:///ou=People,dc=example,dc=com??one
ou=People is obviously wrong there.
olcNssSsd: hosts ldap:///ou=People,dc=example,dc=com??one
ou=People is obviously wrong there too.
olcNssPam: hostservice uid2dn
olcNssPamSession: sshd
# ACL
dn: olcDatabase={1}hdb,cn=config
olcAccess: to attrs=userPassword by anonymous auth by self write by * none
olcAccess: to attrs=shadowLastChange by self write by * none
olcAccess: to * by self write by * read
olcAccess: to dn.exact=cn=host1.example.com,ou=Hosts,dc=example,dc=com
attrs=authorizedservice
by dn.exact=cn=ssh,ou=host1,ou=server_access,ou=Groups,dc=example,dc=com compare
by * read
This ACL will never be seen/used since it comes after access to *.
==
The sshd host, user group entries from my regular hdb-based DIT:
# NSSOV HOST and USER
dn: cn=host1.example.com,ou=Hosts,dc=example,dc=com
objectClass: device
objectClass: top
objectClass: ipHost
objectClass: authorizedServiceObject
cn=host1.example.com
ipHostNumber: 10.153.107.100
authorizedService: sshd
dn: cn=ssh,ou=host1,ou=server_access,ou=Groups,dc=example,dc=com
objectClass: posixGroup
cn: ssh-host1-server_access
gidNumber: 6000
dn: uid=tony,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
uid: tony
cn: Tony Doe
uidNumber: 11000
gidNumber: 6000
userPassword: tonyldap
loginShell: /bin/bash
homeDirectory: /home/tony
===
Anyone?
Thanks in advance,
Peter
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL/TLS testing
reyman wrote: You have a self signed certificate, Correct. so you don't need to verify your certificate. When you activate the tls on ldap, you only need this two lines, and you don't need the line with certificate verification*olcTLSCACertificateFile : * Wrong. RTFM. http://www.openldap.org/doc/admin24/tls.html On Mon, Dec 12, 2011 at 12:31 PM, Jayavant Patil jayavant.pati...@gmail.com mailto:jayavant.pati...@gmail.com wrote: Hi, On Mon, Dec 12, 2011 at 4:19 PM, reyman reyma...@gmail.com mailto:reyma...@gmail.com wrote: With the option -ZZ i think, try this |ldapsearch -x -LLL -ZZ -d 150| Yeah, It shows output containing ber_dump, ldap_write,ldap_read, tls_write, tls_read etc. But at the end is shows the following: TLS certificate verification: Error, self signed certificate TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_ CERTIFICATE:certificate verify failed (self signed certificate). ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate) Why it shows an error ? and how to resolve this? and when I do ldapsearch with -ZZ option it gives error $ldapsearch -x -v -D cn=root,dc=abc,dc=com -w cluster -b ou=People,dc=abc,dc=com uid=ldap_6 -h n0 -ZZ ldap_initialize( ldap://n0 ) ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed On Mon, Dec 12, 2011 at 11:21 AM, Jayavant Patil jayavant.pati...@gmail.com mailto:jayavant.pati...@gmail.com wrote: Hi, I am using openldap-2.4.19-4.x86_64 on fedora 12 machine. I have enabled openldap SSL/TLS. How do I know (test) that I am using SSL/TLS connections instead of normal ldap:///? -- Thanks Regards, Jayavant Ningoji Patil Engineer: System Software Computational Research Laboratories Ltd. Pune-411 004. Maharashtra, India. +91 9923536030 tel:%2B91%209923536030. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: controls require LDAPv3 on cn=config syncrepl
Brandon Hume wrote: I had a medium-size post describing some problems I'm having with an N-Way setup with 2.4.28, but I saw a post from Quanah that sent me in a new direction so I'm doing some more testing before whining about *that* problem... But meanwhile... can anyone tell me if seeing errors like the following is normal when replicating cn=config? No. Errors are by definition not normal. The test suite tests these types of replication setups. Does make test pass on your build? On the provider: Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1027 fd=26 ACCEPT from IP=172.30.96.203:55371 (IP=172.30.96.202:389) Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1026 op=0 BIND dn=cn=config mech=SIMPLE ssf=0 Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1026 op=0 RESULT tag=97 err=0 text= Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1026 op=1 DISCONNECT tag=101 err=2 text=controls require LDAPv3 Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1026 op=1 do_search: get_ctrls failed Nov 30 14:41:22 kil-ds-3 slapd[7540]: conn=1026 fd=27 closed (operations error) ... and on the consumer: Nov 30 14:41:22 kil-ds-4 slapd[8178]: do_syncrep2: rid=001 LDAP_RES_SEARCH_RESULT (2) Protocol error Nov 30 14:41:22 kil-ds-4 slapd[8178]: do_syncrep2: rid=001 (2) Protocol error Nov 30 14:41:22 kil-ds-4 slapd[8178]: do_syncrepl: rid=001 rc -2 retrying (3 retries left) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL/TLS testing
rey sebastien wrote: Le 12/12/2011 19:24, Howard Chu a écrit : reyman wrote: You have a self signed certificate, Correct. so you don't need to verify your certificate. When you activate the tls on ldap, you only need this two lines, and you don't need the line with certificate verification*olcTLSCACertificateFile : * Wrong. It true and false, with debian and openLdap compiled with GnuTLS (my case), i read this documentation : http://wiki.debian.org/LDAP/OpenLDAPSetup and they said : Pure garbage. Procedure: You're going to need the gnutls certificate generator: certtool http://www.gnu.org/software/gnutls/manual/html_node/Invoking-certtool.html. Run these two commands to generate a new self-signed key (into the current working directory): certtool --generate-privkey --outfile ca-key.pem certtool --generate-self-signed --load-privkey ca-key.pem --outfile ca-cert.pem Then, update your certificate locations in /etc/ldap/slapd.conf (TLSCertificateFile points to ca-cert.pem and TLSCertificateKeyFile points to ca-key.pem), *comment out TLSCACertificateFile*, and change *TLSVerifyClient to never.* In /etc/ldap/ldap.conf, comment out TLS_CACERT and change TLS_REQCERT to never. This is utterly bogus. Turning off these checks disables any spoofing detection; you might as well run without TLS at all. Since the certificate is self-signed, we can't have gnutls trying to verify it (hence the never), otherwise it will never run. And RTFM is a little violent, i try to help with my little experience, i'm not an expert for sure. RTFM is exactly the correct response. Best regards, SR. RTFM. http://www.openldap.org/doc/admin24/tls.html On Mon, Dec 12, 2011 at 12:31 PM, Jayavant Patil jayavant.pati...@gmail.com mailto:jayavant.pati...@gmail.com wrote: Hi, On Mon, Dec 12, 2011 at 4:19 PM, reyman reyma...@gmail.com mailto:reyma...@gmail.com wrote: With the option -ZZ i think, try this |ldapsearch -x -LLL -ZZ -d 150| Yeah, It shows output containing ber_dump, ldap_write,ldap_read, tls_write, tls_read etc. But at the end is shows the following: TLS certificate verification: Error, self signed certificate TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_ CERTIFICATE:certificate verify failed (self signed certificate). ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate) Why it shows an error ? and how to resolve this? and when I do ldapsearch with -ZZ option it gives error $ldapsearch -x -v -D cn=root,dc=abc,dc=com -w cluster -b ou=People,dc=abc,dc=com uid=ldap_6 -h n0 -ZZ ldap_initialize( ldap://n0 ) ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed On Mon, Dec 12, 2011 at 11:21 AM, Jayavant Patil jayavant.pati...@gmail.com mailto:jayavant.pati...@gmail.com wrote: Hi, I am using openldap-2.4.19-4.x86_64 on fedora 12 machine. I have enabled openldap SSL/TLS. How do I know (test) that I am using SSL/TLS connections instead of normal ldap:///? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL/TLS testing
Please trim irrelevant text from your emails. Please update your Subject line to something relevant to the actual discussion topic. Raffael Sahli wrote: On 14.12.2011 16:54, rey sebastien wrote: Le 13/12/2011 16:48, Raffael Sahli a écrit : Hi! It's not easy to start with zero configuration with cn=config new openldap administration .. I create my bd.ldif based on the slapd.ldif example in the /usr/local/etc/openldap directory. But how can i insert this ldif with ldapadd -Y EXTERNAL -H ldapi:/// -f myldiffile.ldif if i cannot run slapd without configuration ? How do you start a fresh install of openldap in this case? there is an option to run slapd without zero configuration? Thanks a lot, Use slapadd. Again, RTFM. Everything you've asked in the past week or so has been documented in the manpages and the Admin Guide. Read and learn. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slapd-ldap as proxy to active directory
Juan Miscaro wrote: On 14 December 2011 17:44, Quanah Gibson-Mountqua...@zimbra.com wrote: --On Wednesday, December 14, 2011 3:40 PM -0500 Juan Miscaro jmisc...@gmail.com wrote: I would like to use the slapd-ldap backend as a proxy to Active Directory (Windows Server 2008 R2). Firstly, AD can be queried directly: Does your local OpenLDAP have a schema file that defines the AD attributes you are using? No. I read that since OpenLDAP 2.3 this was not necessary (I'm running 2.4.25 on Ubuntu 11.10). I got my project from a tutorial [1] where this all worked. [1]: http://is.gd/dqM1Ts (see section Using OpenLDAP 2.3 to Pass Unknown Schema on page 2) The passthru of unknown schema is just a hack. It will allow you to see some data but without actual schema definitions it can't do proper normalization, case matching, filter parsing, etc... Everything works better with actual schema defined. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP for Central Auth?
Craig T wrote: Hi, Has anyone successfully deployed OpenLDAP for central auth in a very mixed unix environment? With Host based access control? Plus any documentation would be really great. My needs; - Central Auth - Host based access control (e.g. user John from group accounts can't log into development servers. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;f=contrib/slapd-modules/nssov;h=4fbd7f263e96709b20360cbee503874a68e3f2c3;hb=HEAD - Caching for Client logins on laptops. I figure SSSD will be useful here? slapo-pcache(5) - Encryption (This looks pretty straight forward in the OpenLDAP 2.4 doco) Client OS's involved; - Solaris 9/10 - Fedora 15/16 - Centos 5/6 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP for Central Auth?
Raffael Sahli wrote: - Caching for Client logins on laptops. I figure SSSD will be useful here? I guess you mean userpassword caching? Then the nscd Daemon is your friend. Or do you mean credential caching for one session with Single Sign On, then a kerberos setup is you best option. nscd is nobody's friend. It's a poor design and even more poorly implemented. slapo-pcache has full support for laptops/disconnected operation, and actually works. Unlike those others. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP for Central Auth?
Craig T wrote: Thanks for the quick response everyone.. I've been reading up on the pam.conf (pam_groupdn) entries, it sounds pretty much perfect. No complicated access-rules in openldap to write, only catch is that it can only handle one group in the pam_groupdn cn=GroupName,ou=OUName,dc=example,dc=net line? Single group, yes. And the fact that you have to configure the pam.conf files individually for each and every machine in your network. Insanely unscalable and unmanageable. cya Craig On Mon, Dec 19, 2011 at 01:03:13AM -0700, Chris Jacobs wrote: I can vouch for cent5/6... And 6 seems to prefer SSSD - no /etc/[pam_]ldap.conf but an sssd.conf instead - which I understand is the preferred method now in Fedora too (using SSSD which can also replace NSCD). I noticed that someone felt the need to rewrite PADL's PAM plugin for Cent6, but it introduces a new service; might as well go for the newer and shinier method. My .02 - sorry for top posting; PDA. - Original Message - From: openldap-technical-boun...@openldap.orgopenldap-technical-boun...@openldap.org To: openldap-technical@openldap.orgopenldap-technical@openldap.org Sent: Mon Dec 19 00:52:20 2011 Subject: Re: OpenLDAP for Central Auth? Hi On 12/19/2011 08:18 AM, Craig T wrote: Hi, Has anyone successfully deployed OpenLDAP for central auth in a very mixed unix environment? With Host based access control? Plus any documentation would be really great. Yes, that's no problem. And for documentation, take a look at your distro specific man pages or wikis. My needs; - Central Auth No problem with nss ldap and pam ldap libraries... - Host based access control (e.g. user John from group accounts can't log into development servers. Sure with pam_groupdn or a specific search filter, maybe with the memberOf attribute. - Caching for Client logins on laptops. I figure SSSD will be useful here? I guess you mean userpassword caching? Then the nscd Daemon is your friend. Or do you mean credential caching for one session with Single Sign On, then a kerberos setup is you best option. - Encryption (This looks pretty straight forward in the OpenLDAP 2.4 doco) Also no problem Just compile the newest OpenLDAP with OpenSSL support. Client OS's involved; - Solaris 9/10 - Fedora 15/16 - Centos 5/6 No problem, I don't know the Solaris setup, but I guess it's pretty much the same. cya Craig -- Raffael Sahli pub...@raffaelsahli.com Switzerland This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Value of contextCSN not persisted
Torsten Schlabach (Tascel eG) wrote: Hi Quanah! First of all: Thanks for answering the original question. I was wondering first why changes to the database content as such have been persisted and the new contextCSN hasn't until I found that this syncprov-checkpoint thing actually belongs to the syncprov overlay. So I guess it makes sense to switch that on as otherwise - for example after a power failure - I would have lost information, wouldn't I? No, of course not. If there was a danger of data loss we certainly would not leave that as the default behavior. In fact the syncprov overlay always reads the largest entryCSN out of the database at startup time anyway, so even if it didn't save the contextCSN before stopping, it will be up to date on every startup. Checkpointing the CSN is only an optimization, it will reduce the length of the search time on the next startup. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Value of contextCSN not persisted
Torsten Schlabach (Tascel eG) wrote: Howard! In fact the syncprov overlay always reads the largest entryCSN out of the database at startup time anyway, so even if it didn't save the contextCSN before stopping, it will be up to date on every startup. I wonder how that works if the last operation before the unclean shutdown has been a delete operation? IIUC, then on a delete, the contextCSN is updated but you would have to read the deleted entry upon the next startup to get the contextCSN back, wouldn't you? I didn't actually try it, but I bet that in the discussed scenario, i.e.: - delete an entry from master - replicate deletion to slaves - master crashes - master is restarted you would end up with a slave newer than master kind of situation, which IIUC, is considered an error, isn't it? Or do you keep a log of operations (which is persisted immediately / timely) which syncprov may read also upon startup to learn about the delete operation and the resulting contextCSN? If you just scan for the still existing entry with the largest entryCSN number, you will detinitely end up with a to low contextCSN of the master in case of the above scenario IMO. In regular syncrepl there is no persistent log. In delta-syncrepl yes, there is a persistent log. The situation you describe would have caused problems for regular syncrepl, but in fact we've got a workaround for that as well. Regards, Torsten On Wed, 21 Dec 2011 10:29:08 -0800, Howard Chuh...@symas.com wrote: Torsten Schlabach (Tascel eG) wrote: Hi Quanah! First of all: Thanks for answering the original question. I was wondering first why changes to the database content as such have been persisted and the new contextCSN hasn't until I found that this syncprov-checkpoint thing actually belongs to the syncprov overlay. So I guess it makes sense to switch that on as otherwise - for example after a power failure - I would have lost information, wouldn't I? No, of course not. If there was a danger of data loss we certainly would not leave that as the default behavior. In fact the syncprov overlay always reads the largest entryCSN out of the database at startup time anyway, so even if it didn't save the contextCSN before stopping, it will be up to date on every startup. Checkpointing the CSN is only an optimization, it will reduce the length of the search time on the next startup. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Question about using memberOf attribute in OpenLDAP
Suneet Shah wrote: Hello, Java and its native libraries to work with OpenLDAP in our application. I need to be able to associate users to groups and this part works file. I can do an ldap search and I can see the membership ie: dn: cn=NURSE,ou=roles,dc=mydir,dc=com uniqueMember: uid=Suneet.LDAP-TEST-1,ou=users,dc=mydir,dc=com ldif for Role dn: ou=roles,dc=mydir,dc=com objectClass: top objectClass: organizationalUnit ou: roles Sample user that created for above: dn: uid=Suneet.LDAP-TEST-1,ou=users,dc=mydir,dc=com preferredLanguage: E displayName: LDAP-TEST-1,Suneet employeeType: PERM FULL TIME userPassword:: cGFzc3dvcmQ= ou: OpenIAM givenName: Suneet uid: Suneet.LDAP-TEST-1 telephoneNumber: 234-123-4567 mail: suneet_s...@openiam.com mailto:suneet_s...@openiam.com cn: Suneet LDAP-TEST-1 manager: uid=abc,ou=users,dc=mydir,dc=com o: OpenIAM departmentNumber: - sn: LDAP-TEST-1 title: Test User x-com-mydir-userStatus: Inactive objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: DIRUser I also need to be able to remove users from a group. In this case, I am looking up the user to see if they a have memberOf attribute. However, when I do this, my search results are always empty. My code and search filter are below. Any thoughts on what I am doing wrong? I tried this OpenDS and it works, but I need to get this work with OpenLDAP. Also I noticed that my user in ldap does not contain any attributes that show membership to a group. I have pasted below my code where I add a user to a group incase that is the source of my error That's the wrong approach. Use an LDAP Compare operation on the group, checking for uniquemember matching the user's DN. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP replciation issue with MirrorMode
Aaron Richton wrote: On Mon, 9 Jan 2012, ZHOU Eric JP wrote: This issue only happens when power-off/power cut-off one of the mirror servers, and could be probably prevented by ?sending heart beat? to verify the established connections. [cutting out openldap-devel; this is usage] Sure; see the associated ITS and the thread No replication after power failure: http://www.openldap.org/lists/openldap-bugs/200710/msg00044.html The only thing I'd note is that 2 hours...is too long doesn't seem like that strong an excuse. It's easily tunable in all modern OS I can think of, and in some cases (Linux comes to mind) you can just setsockopt() within the application itself so as to not alter the system-wide settings. Actually, I'm starting to wonder if this should be an option you can pass as a syncrepl (really libldap) configuration directive. There's something to be said for having aggressive-ish keepalives on server-to-server communication (with, hopefully, good bandwidth/latency/communication costs/etc.) and keeping your site defaults for normal clients. OpenLDAP already inched in this direction with the ability to set different idletimeout, etc., for the syncrepl client. Is anybody interested in this? Maybe I'll do it (or have a student do it) if a few people think it'd help... Already done, see the keepalive= keyword in syncrepl config. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Password Policy pwdFailureTime count limits?
Jeffrey Crawford wrote: Hello Everyone, I'm having trouble enforcing our password policy for login attempts within a particular time frame. After looking into the issue a little further it seems to stem from the fact that the operational attribute pwdFailureTime can only resolve time down to the second. so if there are three Bind attempts within a single second we only get a single pwdFailureTime entry for that time. Our policy is geared more to try and prevent brute force attacks since this instance of the ldap server will be available publicly. However someone can continuously try to bind and not lock the account for as many seconds as is defined in the pwdMaxFailure attribute in the policy definition. For example: if the following account locking configs are set pwdMaxFailure: 10 pwdFailureCountInterval: 3600 pwdLockout: TRUE pwdLockoutDuration: 30 If I try to lock my account by providing the incorrect credentials 11 times, it didn't lock if my 11 attempts were shorter than 10 seconds, I then tried 100 in a for loop which finished in 7 seconds, it still didn't lock. I looked at the account and counted the number of pwdFailureTime's and found 7. I then place a one second sleep between each bad bind attempt and low an behold it would lock as expected. Therefore there seems to be a limitation of pwdFailureTime to only resolve down to the second and its inability to store the same time multiple times. I'm not sure if this is expected behavior, but it makes locking policies against brute force attacks more difficult to fend against. I did a quick look to see if there was a way of delaying a incorrect credential bind so it wouldn't return for at least a second, but didn't see one. If such a config exists it might help if someone can point me to it. A delay option is in the latest Draft specification, but not implemented by anyone (as far as I know). Yes, it seems we should be using finer than 1-second resolution for the failure timestamps. Might be worth filing an enhancement request for this in the ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: View or filter based on ldaps://FQDN
Ronie Gilberto Henrich wrote: Hello, I need to be able to restrict ldap ou's access based on the ldaps://FQDN used to query the ldap server. Let say I have the following in my ldap server: ou=domain ou=raincoatcompany.com ou=umbrellacompany.com Considering that both ldap.raincoatcompany.com and ldap.umbrellacompany.com are resolving to IP address 10.0.0.10 So, querying the ldap server using ldaps://ldap.raincoatcompany.com/ou=domain should grant access only to the following: ou=domain ou=raincoatcompany.com Is there any way to accomplish that with OpenLDAP? Not possible. slapd only sees the IP address of the incoming connection, it has no way to know what DNS name was used to resolve to that address. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: View or filter based on ldaps://FQDN
Erwann Abalea wrote: Can't SNI support be added? Perhaps. It depends on which version of TLS library is being used. -- Erwann. Le 14 janv. 2012 13:08, Howard Chu h...@symas.com mailto:h...@symas.com a écrit : Ronie Gilberto Henrich wrote: Hello, I need to be able to restrict ldap ou's access based on the ldaps://FQDN used to query the ldap server. Let say I have the following in my ldap server: ou=domain ou=raincoatcompany.com http://raincoatcompany.com ou=umbrellacompany.com http://umbrellacompany.com Considering that both ldap.raincoatcompany.com http://ldap.raincoatcompany.com and ldap.umbrellacompany.com http://ldap.umbrellacompany.com are resolving to IP address 10.0.0.10 So, querying the ldap server using ldaps://ldap.raincoatcompany.com/ou=domain http://ldap.raincoatcompany.com/ou=domain should grant access only to the following: ou=domain ou=raincoatcompany.com http://raincoatcompany.com Is there any way to accomplish that with OpenLDAP? Not possible. slapd only sees the IP address of the incoming connection, it has no way to know what DNS name was used to resolve to that address. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: syncprov_db_open: invalid config, lastmod must be enabled
Dieter Klünter wrote: Am Mon, 16 Jan 2012 11:03:25 +0100 schrieb Angel L. Mateoama...@um.es: Hi, I'm trying to configure chain overlay in a ldap replica consumer. My final purpose is that if this node receives an update, it directly tries to make it in the provider node, instead of returning the referrral. Is that possible? I think so... But I have a problem with the configuration. My config is ... moduleload back_ldap moduleload syncprov ... databasehdb suffix dc=mysuffix ... overlay syncprov syncrepl rid=31 provider=ldap://provider binddn=replica user dn bindmethod=simple credentials=password searchbase=dc=mysuffix type=refreshAndPersist interval=00:00:00:10 retry=5 5 300 + timeout=1 overlay chain chain-max-depth 1 chain-return-error true chain-uri ldap://provider chain-rebind-as-user yes chain-idassert-bind bindmethod=simple binddn=replica user dn credentials=password starttls=no mode=self But when I test configuration with slaptest, I get: root@canis32:/etc/ldap# slaptest -f /etc/ldap/slapd.conf syncprov_db_open: invalid config, lastmod must be enabled backend_startup_one (type=hdb, suffix=mysuffix): bi_db_open failed! (-1) slap_startup failed (test would succeed using the -u switch) and I can't run slapd. Any idea? I'm running slapd 2.4.21 (ubuntu lucid package) The chain overlay has to be configured in the global part, prior to any database declaration. That might be true, but the actual error here is that the syncprov overlay has been included even though there is no need for it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: The problem of BINDDN/BINDPW in ldap.conf
Tianyin Xu wrote: Hi, all, I'm using Ubuntu 10.04 and LDAP 2.4.23. I'm having difficulty with the basic binding. I don't want to allow anonymous ldapsearch on the LDAP server so I specify a dn and password for the bind. If I use the following parameters for ldapsearch like ldapsearch -b dc=ucsd,dc=edu -D cn=admin,dc=ucsd,dc=edu -w 1234 This works quite fine. Then, I write the parameters into ldap.conf as follows: -ldap.conf--- BASEdc=ucsd,dc=edu BINDDN cn=admin,dc=ucsd,dc=edu BINDPW 12345 - Then only BASE has effect. According to the ldap.conf manual, BINDDN is a user-only attribute and needs to go in ~/.ldaprc; it doesn't mention BINDPW at all. But searching on the web, I found several cases that used binddn and bindpw in ldap.conf and worked successfully. So I'm quite confused for these two directives. Those were not OpenLDAP's ldap.conf. BINDPW isn't mentioned in OpenLDAP documentation because it does not exist in OpenLDAP. Reading non-OpenLDAP documentation and attempting to apply it to OpenLDAP software is a pretty reliable means of confusing yourself. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: memberOf and glued databases
Marc Patermann wrote: Hi, Marc Patermann schrieb (16.01.2012 17:44 Uhr): short question first: Is overlay memberOf supposed to work with glued databases in any direction? Hm, nobody? Did I make a configuration error? Is it a bug? Is it worth a feature request? Will it never work that way? Dunno. IMO most people using memberOf are misusing the data model anyway, so it's of little interest. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: memberOf as misuse of data model
Felipe Augusto van de Wiel wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, On 19-01-2012 15:14, Howard Chu wrote: Dunno. IMO most people using memberOf are misusing the data model anyway, so it's of little interest. Out of curiosity (and because I do try to avoid misusing the data model), why in your opinion memberOf represents a misuse? There are two common operations on a group: list all the members, and see if user X is a member of a group. For the first case, just retrieve the group entry and look at its member attribute. For the second case, just do a Compare on the group and test the member attribute against the user's DN. Kind regards, - -- Felipe Augusto van de Wielfelipe.w...@hpp.org.br Tecnologia da Informação (TI) - Complexo Pequeno Príncipe http://www.pequenoprincipe.org.br/T: +55 41 3310 1747 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJPGHjGAAoJECCPPxLgxLxPx0kP/A1vueiP4471kk8YrAv72wsQ 6L+++LZTPcNCkxBGbQK/cUnncV0S/h6wkSbHFMiZO1pfx8QWUITgw3L1hPSBxnGA stWvcrIf9MeoigqzQuPgDbQ/TppganSA0cGyGEM0a5H0+GxhqbwLMFa3MGw49DOD FElsd1muDo/uKKgAlGU27zNs9Oysi3ICw5CBIp9bLGcrKX0xpq3hjP4wyS0/hDRu euLFr+F7EYdvOQ16rzB3CQv6UWmDvYg76Km8VuzG+UEnR4DcNiAbNKR6Fm22kv/w O2ifUXdOnVLugiHekRF2VXYzYO3XNxg7wqORObhePRAsnobjE9p/lXEt+c7Pf938 WJBcHAa3NUS7JKQIK3TEC/iAfx+3/BHvDYXyoa57YK4MOdbv1GCgZLD8mTKSyATo r/CdxrfoVv8YI6D+Lo4x+0dGjwbXBeIP1ArWT4li23c8TTMi7H6NYPbRCBc0LvaQ 22ifiDfE9TxhonXwMgbG5ONybrWeX9/Os//ofJXqWY2qXP4p3H0ceALDBmAI6LpP NEvaGh1OA2hDEUq+XpFg9TJDN9+WXlZ3tz135H1WUHXyik8xzHZOSSFFWd/LhIcI 3pyo5T+0xjf+3dA4Gn31iGp8CxakTkkJpdeUiZ2mHwHHgTDU72y5p6DudycRq5uK 3cldhqzDAktL1JA1AIHK =gFGM -END PGP SIGNATURE- -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Trying to get passthrough auth working with OpenLDAP and Kerberos
Raffael Sahli wrote:
On 26.01.2012 22:53, Chastity Blackwell wrote:
On Thu, 2012-01-26 at 15:23 -0500, Dan White wrote:
That indicates a mistake in your /etc/sasl2/slapd.conf, which should have:
saslauthd_path: /var/run/saslauthd/mux
not /var/run/sasl2/mux
Well, now I just feel like an idiot. :) That did move things along a
bit, though now I'm getting this error:
2012-01-26T13:48:28-08:00 ldapsandbox10-1-qa-sjc saslauthd[15889]:
do_auth : auth failure: [user=c...@test.com] [service=ldap]
[realm=test.com] [mech=kerberos5] [reason=saslauthd internal error]
I'm guessing the problem here is that the realm should match my Kerberos
realm, which is called KRBTEST, not test.com -- is this something that
needs to be fixed with an authz-regexp?
No, authz-regexp is to map a sasl dn to a real user account in your ldap
directory.
But your user is c...@test.com with a realm named test.com, your
userPassword should be {SASL}chas@KRBTEST
What the heck are you talking about? If the username is c...@test.com then
that is what goes in the password:
userpassword: {SASL}c...@test.com
If the realm is actually KRBTEST then the username should be chas@KRBTEST.
and also exists as a principal on your kerberos db ;)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Trying to get passthrough auth working with OpenLDAP and Kerberos
Chastity Blackwell wrote:
On Thu, 2012-01-26 at 17:38 -0500, Howard Chu wrote:
Raffael Sahli wrote:
No, authz-regexp is to map a sasl dn to a real user account in your ldap
directory.
But your user is c...@test.com with a realm named test.com, your
userPassword should be {SASL}chas@KRBTEST
What the heck are you talking about? If the username is c...@test.com then
that is what goes in the password:
userpassword: {SASL}c...@test.com
If the realm is actually KRBTEST then the username should be chas@KRBTEST.
and also exists as a principal on your kerberos db ;)
Okay, I'm a little confused here now.
Clearly.
So here's what I have in
krb5.conf:
Does kinit work for your chas@KRBTEST user? Judging from what you've pasted
here, I don't think it should. Get your basic Kerberos installation working
first. Take things one step at a time.
[libdefaults]
default_realm = KRBTEST
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
AKTEST = {
kdc = ldapsandbox.test.com:88
admin_server = ldapsandbox.test.com:749
default_domain = test.com
}
[domain_realm]
.agkn.net = KRBTEST
agkn.net = KRBTEST
And when I look at my principals in Kerberos, this is what I have:
kadmin: listprincs
K/M@KRBTEST
chas/admin@KRBTEST
chas@KRBTEST
host/ldapsandbox.test.com@KRBTEST
kadmin/admin@AKTEST
kadmin/changepw@AKTEST
kadmin/history@AKTEST
kadmin/ldapsandbox.test.com@KRBTEST
krbtgt/KRBTEST@KRBTEST
ldap/ldapsandbox.test.com@KRBTEST
root/admin@KRBTEST
So what should the userPassword attribute be set to? I assumed it should
be {SASL}chas@KRBTEST -- is that correct? I just want to make sure I'm
on the right track there.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Trying to get passthrough auth working with OpenLDAP and Kerberos
Chastity Blackwell wrote:
On Thu, 2012-01-26 at 18:40 -0500, Howard Chu wrote:
Does kinit work for your chas@KRBTEST user? Judging from what you've pasted
here, I don't think it should. Get your basic Kerberos installation working
first. Take things one step at a time.
It does:
[chas@ldapsandbox log]$ ldapwhoami
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Local error (-2)
additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified
GSS failure. Minor code may provide more information (Unknown code krb5
195)
[chas@ldapsandbox log]$ kinit chas
Password for chas@KRBTEST:
[chas@ldapsandbox log]$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: chas@KRBTEST
SASL SSF: 56
SASL installing layers
dn:uid=chas,ou=people,dc=test,dc=com
Result: Success (0)
[chas@ldapsandbox log]$
As I said, I think Kerberos and LDAP are all working on their own...it's
the combination of the two doing the SASL passthrough that is
confounding me.
Seems like it's working for the wrong reasons, then. Your krb5.conf:
[libdefaults]
default_realm = KRBTEST
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
AKTEST = {
kdc = ldapsandbox.test.com:88
admin_server = ldapsandbox.test.com:749
default_domain = test.com
}
[domain_realm]
.agkn.net = KRBTEST
agkn.net = KRBTEST
You defined a kdc for an AKTEST realm; you don't actually have any kdc
defined for the KRBTEST realm so kinit should be failing.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: DEL don't get synced
Marc Patermann wrote: Hi, under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment. Already known, ITS#7052. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: DEL don't get synced
Marc Patermann wrote: Hi, Howard Chu schrieb (31.01.2012 12:08 Uhr): Marc Patermann wrote: under some circumstances DEL don't get replicated to the consumers (SyncRepl). I think this has to do with other changes at the some moment. Already known, ITS#7052. Thanks. So this is fixed in 2.6.27 (and later). The master already is 2.4.28, the consumers are older. So I have to update the consumers, right? Yes, the fix was consumer side. Also, the fix was incomplete, an additional fix will be in 2.4.29. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
BayLISA OpenLDAP talk
For any folks in the San Francisco area who haven't already heard, I'll be giving a talk on OpenLDAP's new memory-mapped database and backend (back-mdb) there on February 16. http://www.baylisa.org/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: 2.4.28 cn=config replication trouble
0x7f59cc100910 msgid 2 wait4msg ld 0x7f59cc100910 msgid 2 (timeout 0 usec) wait4msg continue ld 0x7f59cc100910 msgid 2 all 0 ** ld 0x7f59cc100910 Connections: * host: animal.clarku.edu port: 636 (default) refcnt: 2 status: Connected last used: Thu Feb 2 14:14:14 2012 ** ld 0x7f59cc100910 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x7f59cc100910 request count 1 (abandoned 0) ** ld 0x7f59cc100910 Response Queue: Empty ld 0x7f59cc100910 response count 0 ldap_chkResponseList ld 0x7f59cc100910 msgid 2 all 0 ldap_chkResponseList returns ld 0x7f59cc100910 NULL ldap_int_select read1msg: ld 0x7f59cc100910 msgid 2 all 0 ber_get_next ldap_err2string 4f2ae08a do_syncrep2: rid=001 (-1) Can't contact LDAP server ldap_err2string 4f2ae08a connection_get(15): got connid=0 ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_free_connection: actually freed Thanks for your time – any help is appreciated. - Aaron --- Aaron Bennett Manager of Systems Administration Clark University ITS -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How do I reset rootdn password?
Jose Ildefonso Camargo Tolosa wrote:
Hi,
On Sat, Feb 4, 2012 at 1:56 AM, Daniel Savarddsav...@cids.ca wrote:
I would like to know how to reset the rootpw in OpenLDAP 2.4?
Do I need to recreate over the entire configuration database and the
database itself or there is a trick?
Risking to be burned by the community, you could directly edit the
slapd.d files (this is NOT recommended, but you could risk doing it in
your case), this one in particular (shutdown slapd before doing this):
If you don't know what you're doing, keep your grubby hands out of there. If
you know what you're doing, you don't need us to tell you what to do.
You don't know what you're doing, neither does the OP.
/etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif
And change that line:
olcRootPW:: e1NTSEF9b085TTcyaUNnK2lKUVp1d2s3SENvZHpEOHFBS2c5VCs=
Note this is bsae64 encoded, so, will need to generate it with
slappasswd and then encode it to base64, there are some online
encoders you could use.
The first thing I would have done would be slapcat -n0 to see what all of the
existing rootpw's were. They would all be base64 encoded; decode them to see
if any of them are plaintext. If so, then the problem is already solved - you
have the password.
Also, I believe there are olcRootPW per-database (I don't remember
seeing that on slapd.conf kind of configs, but I just saw it on the
slapd.d right now):
Don't guess. RTFM. It's all stated there clearly.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Chinese characters in mail search causes failed assertion in slapd
Alfie John wrote: On Tue, Feb 7, 2012, at 11:34 AM, Charles T. Brooks wrote: Non-english character sets are going to become part of hostnames and DNS. That's inevitable. Mail addresses are based on DNS hostnames. Ergo, mail attributes will one day need to support all possible characters. Thanks for that. It makes sense and it was enough to convince me to submit a bug. None of this has any significance until someone writes a new spec and submits it to the IETF for approval. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Is putting slapd into read-only mode sufficient for backups?
Hallvard B Furuseth wrote: On Thu, 09 Feb 2012 12:54:27 -0800, Quanah Gibson-Mount qua...@zimbra.com wrote: The only officially supported backup method with OpenLDAP is slapcat. Everything else, you do at your own risk. The admin guide disagrees with you. Chapter 19 describes incremental backup by copying first the entire DB, then backing up further DB logs. Chapter 19 is obviously a work-in-progress, transferred over from the FAQ-o-Matic. I'd say that anything referencing BerkeleyDB in there should be deleted, since it is specific to BerkeleyDB and not specific to OpenLDAP. (And most likely, in future releases, BerkeleyDB will disappear anyway.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: GnuTLS / OpenSSL certificates compatibilty
Daniel Savard wrote: Le jeudi 09 février 2012 à 23:21 +0100, rey sebastien a écrit : Hi, One or two question about certificate compatibility, I have self signed certificate generated by openSSL, and the official package of openldap in Ubuntu is compilated with gnutls library. Do you think this configuration could create error ? If this is the case, and if i want to maintain the easy deb package upgrade system, do you know a repository with deb version of openldap compiled with openssl library ? Thanks for advice, SR I've just fix my problem by recompiling openldap without GnuTLS support. You are trying to do the exact thing I did. It won't work. I don't know about Debian and deb packages, I am running another distro. But you need an OpenLDAP not linked to GnuTLS. In general, if a software package is creating certificates that comply to the X.509 specs, then it should make no difference what library you use. In practice, GnuTLS and OpenSSL don't support the same set of ciphers and hashes, so the digital signatures used to create a certificate may not be compatible from one to the other. Since OpenSSL has been the de facto standard for internet apps since the early 1990s, yes, it's generally a safe bet to just stick with it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Error - not compiled with SASL support
Dieter Klünter wrote:
Am Wed, 15 Feb 2012 10:19:10 +0530
schrieb Gaurav Gugnanigugnanigau...@gmail.com:
Hello All,
I'm *trying to implement SASL on the openldap of version 2.4.26.*
First we install the openldap and then we install the necessary
packages of cyrus-sasl.
*Packages of cyrus-sasl:* (installed in below mentioned order)
cyrus-sasl-lib-2.1.22-5.el5_4.3.x86_64.rpm
cyrus-sasl-devel-2.1.22-5.el5_4.3.x86_64.rpm
cyrus-sasl-plain-2.1.22-5.el5_4.3.x86_64.rpm
cyrus-sasl-2.1.22-5.el5_4.3.x86_64.rpm
cyrus-sasl-ldap-2.1.22-5.el5_4.3.x86_64.rpm
cyrus-sasl-md5-2.1.22-5.el5_4.3.x86_64.rpm
After then i set up the SASL with proper ACL's (having the steps and
also i setup the same on some other box where it running fine)
*Steps:*
*1 *Modify /usr/lib64/sasl2/slapd.conf
*# SASL Configuration
pwcheck_method: auxprop
auxprop_plugin: slapd
mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5*
*2 *Modify $LDAP_HOME/etc/openladp/slapd.conf
*password-hash {CLEARTEXT}
authz-regexp uid=(.*),cn=DIGEST-MD5,cn=auth
uid=$1,ou=System,o=xyz*
but it throws all together different error to me:
/u01/app/openldap/product/2.4.26/etc/openldap ldapwhoami -Y
DIGEST-MD5 ldapwhoami: not compiled with SASL support
And similar errors for ldapsearch and other commands.
It suggests to me that some package installation is not proper.
Can any one guide me on this.
Check whether ldapwhoami is linked against libsasl2,
ldd ldapwhoami
There is nothing to check. The error message not compiled with SASL support
could not be any plainer.
If he installed OpenLDAP from a distro package, then he needs to complain to
his distro provider. If he built OpenLDAP from source, then of course it had
no SASL support since he says he didn't install SASL until *after* he
installed OpenLDAP. Obviously you can't compile with SASL support if the SASL
devel packages weren't already present at compile time.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Changing schema OID values in cn=config
Nick Milas wrote: On 14/2/2012 11:21 μμ, Nick Milas wrote: Following the fix of ITS 7098, now (after upgrading to a version with the fix) I changed successfully the values of OIDs 1.3.6.1.4.1.25260.1.00x to 1.3.6.1.4.1.25260.1.x. (No service stop followed.) Yet, after these changes, we could not modify the associated attributes any more. ... I tried reindexing the directory and this solved the problem. Is this expected behavior? Sorry, may I ask again if it is the expected behavior to have to reindex the directory after OID changes? Yes, the OID is included in the index computation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Changing schema OID values in cn=config
Nick Milas wrote: On 17/2/2012 10:07 πμ, Howard Chu wrote: Yes, the OID is included in the index computation. Thank you. Could/Should the software automatically reindex the directory after OID change or - if not possible - inform the administrator with a message that such reindexing should be done manually? No. It is our policy to expect sysadmins to know what they're doing. Admins should know that OIDs are meant to be constants; you should have very good reasons for changing them, otherwise you should never change them. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: adding new databases and olc*dbconfig must attributes
ben thielsen wrote: i was experimenting a bit with adding new databases to the config, and found that if the olcsuffix attribute was not provided, it would fail: providing an olcSuffix attribute in the ldif allowed the new database to be added without error: this behavior wasn't really all that surprising to me, as i don't really know in what capacity there might be a database without a suffix defined, even if it were just , but what i am curious about is the schema definition for the olcHdbConfig object class. the best i can tell, only olcDatabase and olcDbDirectory are MUST attributes, while olcSuffix is not: why is olcSuffix not a MUST attribute if the database can't be added without it? are there cases different than my exercise where a database might be added without the need for a suffix? it's not anything that's causing an insurmountable hurdle, just mostly curious if this was intended. This is just an artifact of slapd.conf support. Since slapd.conf files aren't affected by the olc objectclass definitions, we need to put the enforcement in the common code instead of in the schema. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: DEL don't get synced
Michael Ströder wrote: Howard Chu wrote: Marc Patermann wrote: There are reverted commits in git (ITS#7162). Should a build again with current git status? Yes, build with current git. Should we take this as a call to have a test round? Eh. I would look at the RE24 CHANGES file and see if any of it is likely to affect you. If so, then feel free to try it. If not, then no rush. I'm still chasing down ITS#7170 in the meantime; expect 2.4.30 to go when 7170 is resolved. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Howto implement RBAC with OU's and posixGroups
Fred van Zwieten wrote: Hi llg, I fail to see how this solves my RBAC need. Let me give an example: Say, personA is in ou DeptA. Then, ideally personA would based on being in this ou, become member of group webserver No, when I move personA to ou DeptB, this would mean that, on the next login, it looses it's membership to group Webserver, but now becomes member of ie group mailservers This way, you implement security policies based on the role of a person. This is not the right way to implement roles. Generally DNs are intended to be constant (though obviously they are allowed to change, changes should be infrequent). How could this ideally be done with OpenLDAP? Greetz, Fred http://epsilon.eridani.nl 2012/2/22 llg l...@portaildulibre.fr mailto:l...@portaildulibre.fr Hi, persons should use inetOrgPerson and PosixAccount schemas : gidNumber gives primary group. Then define specific branch ou=posix based on PosixGroup schema and add the uid of the person in memberUid multiple values attribute to specify secondary gid. Regards Llg Le 22/02/2012 10:22, Fred van Zwieten a écrit : Hi all, warning: openldap newbie.. is it possible to have a person put into an OU and, because of this, will become member of some group in such a way that this group shows up in linux using id. This to implement some form of RBAC. I found GroupofMembers, but that has nothing to do with OU's. Also, it seems posixGroup and groupOfMembers objecttypes are no longer allowed together because the are both STRUCTURAL. In AD this is possible. Greetz, Fred http://epsilon.eridani.nl -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: SSL handshake failure
Bryce Powell wrote: Hi, I can’t get slapd to respond successfully to TLS or SSL connections using an RSA 2048-bit PEM certificate: You're using Mozilla NSS, so the fact that OpenSSL tools accept your cert doesn't help you. While a lot of good work has gone into the Mozilla NSS support, I would still say the MozNSS design is braindead and is not well suited for anything besides the Netscape/Mozilla browser codebase and should be avoided. Rebuild OpenLDAP using OpenSSL and I suspect these problems will disappear. $ ldapsearch -x -ZZ -d1 -H ldap://FQDNhostname TLS: loaded CA certificate file /etc/openldap/cacerts/FQDNhostname.cacert.pem. TLS: error: tlsm_PR_Recv returned 0 - error 21:Is a directory TLS: error: connect - force handshake failure: errno 21 - moznss error -5938 TLS: can't connect: TLS error -5938:Encountered end of file. ldap_err2string ldap_start_tls: Connect error (-11) additional info: TLS error -5938:Encountered end of file $ openssl s_client -connect FQDNhostname:636 -CAfile /etc/openldap/cacerts/FQDNhostname.cacert.pem CONNECTED(0003) 140457427965768:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:s23_lib.c:184: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 113 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- The following packages are installed on CentOS 6.2: openldap-servers-2.4.23-20.el6.x86_64 openldap-2.4.23-20.el6.x86_64 openldap-clients-2.4.23-20.el6.x86_64 openssl-1.0.0-20.el6_2.1.x86_64 openssl-devel-1.0.0-20.el6_2.1.x86_64 gnutls-2.8.5-4.el6.x86_64 gnutls-devel-2.8.5-4.el6.x86_64 nss-pam-ldapd-0.7.5-14.el6_2.1.x86_64 The /etc/openldap/ldap.conf file contains: TLS_CACERT /etc/openldap/cacerts/FQDNhostname.cacert.pem , which contains a chain of three certificates (root CA, intermediate/functional, and issuing). The /etc/openldap/slapd.conf file contains: TLSCipherSuite HIGH:+SSLv3 TLSCertificateFile /etc/openldap/FQDNhostname.cert.pem TLSCertificateKeyFile /etc/openldap/FQDNhostname.key.pem The server is acting as a proxy to an Active Directory, and therefore I only have one LDAP database defined. My intention is to use LDAPS for communication between the client and LDAP proxy servers: database ldap suffix dc=abc,dc=local rebind-as-user uri ldap://IPaddress1/ ldap://IPaddress2/ ldap://IPaddress3/ ldap://IPaddress4/; chase-referrals yes noundeffilter yes use-temporary-conn yes The certificate and private key are located in /etc/openldap/, with the following permissions : -r--r-. 1 ldap ldap 2076 Feb 21 15:30 FQDNhostname.cert.pem -r--r-. 1 ldap ldap 1675 Feb 21 15:35 FQDNhostname.sdi.key.pem The CN of the certificate matches the FQDN host name of the LDAP server. The private key is not password protected. Everything checks out OK by testing the certificate using openssl: $ openssl verify -purpose sslserver -CAfile /etc/openldap/cacerts/FQDNhostname.cacert.pem /etc/openldap/FQDNhostname.cert.pem /etc/openldap/FQDNhostname.cert.pem: OK OpenSSL client/server connections work fine too: openssl s_server -cert /etc/openldap/FQDNhostname.cert.pem -key /etc/openldap/FQDNhostname.key.pem -cipher 'HIGH:+SSLv3 openssl s_client -connect FQDNhostname:4433 -CAfile /etc/openldap/cacerts/FQDNhostname.cacert.pem *Bryce Powell* -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Mozilla NSS -- how to deploy intermediate certificate
Rich Megginson wrote: On 02/24/2012 01:31 PM, Aaron Bennett wrote: On other oddity about this is there are two boxes in play -- one's hostname is 'animal.clarku.edu' and the other is 'zoot.clarku.edu'; they are round-robin'd behind the hostname 'ds.clarku.edu.' However the cert I have installed on each box is for ds.clarku.edu. Not sure how this works with openldap - the usual way to handle this is to use subjectAltName so that the server's cert has animal.clarku.edu zoot.clarku.edu and ds.clarku.edu That's already documented here: http://www.openldap.org/doc/admin24/tls.html Obviously there is a standard for it and we implement that spec. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: require StartTLS
Dieter Klünter wrote: Am Sun, 26 Feb 2012 12:39:26 +0100 schrieb Daniel Pocockdan...@pocock.com.au: On 26/02/12 12:15, Dieter Klünter wrote: Am Sun, 26 Feb 2012 11:49:14 +0100 schrieb Daniel Pocockdan...@pocock.com.au: Is there some way to ensure that a client who connects on port 389 can do nothing without StartTLS? Or is it necessary to just disable port 389 and only listen for ldaps:/// ? read on TLS OPTIONS in man ldap.conf(5) and man slapd.conf(5) Thanks for the fast reply I'm not keen to rely on ldap.conf (client side config) - I want to enforce a preference for TLS from the server side, to avoid a situation where some application might be configured non-TLS by mistake. I've looked at the TLS options and I have TLS running fine already. I notice the TLSCipherSuite option sets the cipher level within TLS, but it doesn't appear to guarantee that TLS is used. From man slapd.conf TLSVerifyClientlevel demand | hard | true These keywords are all equivalent, for compatibility reasons. The client certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated. To make an analogy, in postfix, I require `plain' authentication: but the client is not allowed to try to authenticate until it has done StartTLS, because I never want a client to try sending a password over a channel that is not encrypted. Postfix is a LDAP client, thus all client configurations apply according to man ldap.conf(5). Dieter, no. Josh Miller's post was correct. http://www.openldap.org/lists/openldap-technical/201202/msg00414.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: ssl negotiation and openldap
Brett @Google wrote: Hello, I've recently had issues with a 3rd party java client using jdk 1.4.x, trying to connect with ldaps:// to openldap 2.4.26, compiled with OpenSSL 1.0.0d It would appear that the client's jdk 1.4.x has a few harsh restrictions with regard to modulus size in certiicates, even with all unrestricted export policies installed. So i was wondering a few things : 1. does openldap do anything with the CA certs, other than verify local or remote certiticates, such as sending them over the ssl connection ? OpenLDAP doesn't do *anything* with certs. The backing TLS library does. What the TLS library does is the same thing it does for any TLS session, be it https, smtps, or whatever. 2. it's my understanding that in SSL negotiation, only server or client certiticates are exchanged, and ca certs's are not sent over the wire (as IMHO it would literally bet a trust issue to do otherwise :). I suggest you run ldapsearch -d7 and see exactly what happens. 3. other than providing certificates / keys to the openssl API, is there anything special that happens other than hand off to stock openssl negotiation ? No. Trying to work out what is being sent to the client to trigger a modulus size error on the client, other than clients inherent badness which i cannot control :) JDK 1.4? Good luck. If 3. is no, then i'm open to any suggestions with regard to interesting or useful SSL negotiation documents out there, that might shed some light. Cheers Brett -- *The only thing that interferes with my learning is my education.* * Albert Einstein* -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30)
;
##
databaseconfig
rootdn cn=config
rootpw {SHA}secret
###
# BDB database definitions
###
# Accesslog database definitions
database hdb
suffix cn=accesslog
checkpoint 10245
cachesize 1
directory C:/test/accessdata
dbconfig set_cachesize 0 30001
dbconfig set_flags DB_LOG_AUTOREMOVE
dbconfig set_lg_regionmax 1048576
dbconfig set_lg_max 10485760
dbconfig set_lg_bsize 2097152
rootdn cn=accesslog
index objectClass,entryCSN,entryUUID eq
# I even tried removing reqMod, reading your docs I am not sure if
this
is
needed here
index reqEnd,reqResult,reqMod,reqStarteq
overlay syncprov
syncprov-nopresent TRUE
syncprov-reloadhint TRUE
# Let the replica DN have limitless searches
limits dn.exact=cn=Replicator,ou=admins,o=caesar
time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
# Primary database definitions
database hdb
suffix o=caesar
checkpoint 10245
cachesize 1
idlcachesize3
rootdn cn=Administrator,o=caesar
rootpw {SHA}secret
directory C:/test/data
dbconfig set_cachesize 0 1 1
dbconfig set_flags DB_LOG_AUTOREMOVE
dbconfig set_lg_regionmax 1048576
dbconfig set_lg_max 10485760
dbconfig set_lg_bsize 2097152
# syncprov specific indexing
index sn pres,eq
index cn pres,eq,sub
...
index entryUUID eq
index entryCSNeq
index objectClass eq
# syncrepl Provider for primary db
overlay syncprov
syncprov-checkpoint 1000 60
syncprov-sessionlog 1
# accesslog overlay definitions for primary db
overlay accesslog
logdb cn=accesslog
logops writes
logsuccess TRUE
# scan the accesslog DB every day, and purge entries older than 7
days
logpurge 07+00:00 01+00:00
sizelimit size.soft=100 size.hard=1000 size.prtotal=unlimited
# Let the replica DN have limitless searches
limits dn.exact=cn=Replicator,ou=admins,o=caesar
time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
syncrepl rid=001
provider=ldap://firstmaster.mydomain.local;
searchbase=o=caesar
type=refreshAndPersist
retry=5 3 15 +
binddn=cn=Replicator,ou=admins,o=caesar
bindmethod=simple
credentials=secret
logbase=cn=accesslog
logfilter=((objectClass=auditWriteObject)(reqResult=0))
schemachecking=on
syncdata=accesslog
syncrepl rid=002
provider=ldap://secondmaster.mydomain.local;
searchbase=o=caesar
type=refreshAndPersist
retry=5 3 15 +
binddn=cn=Replicator,ou=admins,o=caesar
bindmethod=simple
credentials=secret
logbase=cn=accesslog
logfilter=((objectClass=auditWriteObject)(reqResult=0))
schemachecking=on
syncdata=accesslog
MirrorMode On
-
I did my test on 2 Windows PCs and OpenLDAP 2.4.29 with Berkeley 5.1
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP TLS server authority verification
Daniel Pocock wrote: http://tools.ietf.org/html/rfc4513#section-3.1.3 gives some detail about how a client should check an LDAP server's TLS certificate. The language used there is very general though. Can anyone comment on how OpenLDAP does this, and whether it can be tweaked from the client side (e.g. through settings in /etc/ldap/ldap.conf or URI parameters) to mandate a particular policy for choosing the `reference identity'? From RFC 4513, The client determines the type (e.g., DNS name or IP address) of the reference identity and performs a comparison between the reference identity and each subjectAltName value of the corresponding type until a match is produced is very vague. My understanding of `reference identity' is that it should be a statically/administratively configured value on the client host. On the other hand, a value derived/mapped from a network source (e.g. DNS SRV lookup) can never be trusted as a reference identity. To give an example: Sounds like you understand it fine. In practice, there are no APIs that tell us whether a DNS lookup used DNSSEC or not. IMO relying on DNS SRV records is dicy, but as long as your certificate trust chains are intact it shouldn't be an issue. ldap[12].outsource.com: - are the OpenLDAP hosts (run by an external company) - both have a TLS certificate with CN=ldap[12].outsource.com, and subjectAltName mycompany.com _ldap._tcp.mycompany.com: - an SRV record pointing to ldap[12].outsource.com - mycompany.com DNS is not secured (no DNSSEC) webserver.mycompany.com: - wants to authenticate a user logging in - has dc=mycompany,dc=com statically configured in some cfg file, so it trusts mycompany.com as a `reference identity' - discovers ldap1.outsource.com from DNS SRV lookup on mycompany.com, (so the LDAP client should not consider ldap1.outsource.com as a reference identity, because it is a value from DNS) - therefore, when it connects to ldap1.outsource.com, if the TLS certificate contains CN=ldap1.outsource.com only, it would not trust the connection, - but when it finds the subjectAltName mycompany.com in the cert too, it should trust the connection -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Help tweaking settings so slapd is not writing to disk so much
Marc wrote: To enable shared memmory I just do this? In DB_CONFIG: set_shm_key 1 No. And Put the slapd conf: olcDbShmKey to 1 No. Read the slapd-bdb(5) manpage. And rebuild the bdb database in /var/lib/ldap/ You don't need to rebuild the database. Just run db_recover on the database. I have a default (centos6) DB_CONFIG setup. == set_cachesize 0 268435456 1 set_lg_regionmax 262144 set_lg_bsize 2097152 I think if you had mounted the DB's filesystem with noatime or relatime that would also have removed the problem. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: fw: multimaster
Quanah Gibson-Mount wrote: --On Friday, March 09, 2012 10:49 AM +1000 Brett @Google brett.maxfi...@gmail.com wrote: Hello, Are the tests in test050 (multimaster concurrency) for release 2.4.30, still likely or expected to fail on solaris 10 with bdb 4.8.30 ? We dont use multimaster, but at one point in recent history the tests in test050 (multimaster concurrency) were expected to fail. I'll log an ITS if it is now unexpected for this test to fail.. Cheers Brett Waiting 5 seconds for slapd to start... Waiting 5 seconds for slapd to start... 29490 Segmentation Fault - core dumped segmentation faults are never expected. You should file an ITS with the backtrace on the core file. And the last few lines of slapd.1.log. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: slow or inconsistent syncrepl
Amol Kulkarni wrote: Dear Quanah, Thanks a lot for these 2 pointers. I'll check out the 2.4.30 version. We had used delta syncrepl earlier but our accesslog size used to grow suddenly sometimes and the disk used to get full crashing/hanging the ldap service itself on the provider. But at that time we had kept the max age for the accesslog to be 7 days. I'll reduce it and give it a try again. Also it would be helpful if you can throw some light on : 2. On a really busy ldap server, can replication slow down drastically? i.e does the read operations affect the replication in any way? Syncrepl executes as an LDAP Search operation, so of course it competes for server resources with other Search activity on the server. 4. We are currently having about 60 consumers - is this too much ? What can be the max numbers of consumers ? That depends entirely on the speed of your server and network. If you're seeing that replication speed is inconsistent, you probably should reduce the load on the provider. A simple approach in your scenario would be to just point the 10 consumers on the fast LAN at the provider, and configure these consumers to act as providers for your WAN nodes (i.e., cascaded replication). 5. Sometimes we urgently need some particular node to be present on the consumer - for which we cannot wait - in that case we get ldif of that node from provider and do ldapadd on the consumer ( mirrormode is ON on the consumers ). Is this safe and correct or could it cause some side effects ? Is there a better way to handle it? If you have configured distinct serverIDs for each consumer, this might work. Otherwise, no, not safe, not correct. Fix your configuration layout, or fix your apps. If your apps can't wait then they are mis-designed; there is no such thing as instantaneous propagation of information in the real world. Thanks and Regards, Amol Kulkarni. - Original Message - From: Quanah Gibson-Mount Sent: 03/09/12 11:57 PM To: Amol Kulkarni, openldap-technical@openldap.org Subject: Re: slow or inconsistent syncrepl --On Friday, March 09, 2012 2:20 PM +0100 Amol Kulkarni amolkulka...@gmx.com wrote: I have a following openldap setup with syncrepl : - openldap version 2.4.23 This is your #1 issue. - 1 provider and about 10 consumers in lan and 50 consumers on wan This is your #2 issue. Upgrade to a stable release. Use delta-syncrepl, which uses significantly less bandwidth than syncrepl. --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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP 2.4 : replication doesn't work when customer is stopped
on the list. Please see:http://www.openldap.org/faq/data/cache/1456.html for just a beginning of the reasons as to why this is a bad idea. --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 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP and dynalogin (two-factor auth with HOTP)
Daniel Pocock wrote: Some time ago I created the dynalogin ( http://www.dynalogin.org ) solution for two-factor authentication. I'm just contemplating how to make it easier to integrate, and making it convenient to use with OpenLDAP seems like a good strategy: can anyone comment on that? This is not the place to make that happen. LDAP uses SASL as its extensible authentication mechanism, you should be looking there. The initial thoughts that I have about the subject: - SASL based solution (dynalogin has digest capability already, so it could be adapted for SASL PLAIN or DIGEST-MD5) Yes, provide a Cyrus-SASL plugin implementing your mechanism and then it will immediately be usable in OpenLDAP and a number of other software packages. - should not prevent password logins (user should be able to use either password or HOTP code) - should enable people to use it indirectly (e.g. if someone already has pam_ldap working, they should be able to add dynalogin to their OpenLDAP server and get immediate benefit) - use cases: UNIX login, high-security webmail login, VPN and OpenID provider backed by OpenLDAP I know that SASL already supports OTP, but that is not HOTP, it is OPIE (or S/Key) RFC 2289: http://tools.ietf.org/html/rfc2289 whereas HOTP is RFC 4226: http://www.ietf.org/rfc/rfc4226.txt HOTP is considered more secure and more widely implemented. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OPENLDAP SYNCREPL
Borresen, John - 0442 - MITLL wrote:
Thanks, Quanah;
As requested:
That was clearly not the problem; if the syncprov module was missing your
config would have caused slapd to fail to start. Also it was clearly present
since you had it updating the contextCSN in your shutdown log. Quanah, you
should have already seen that and not sent him on a wild goose chase.
And, one more time: DO NOT DIRECTLY ACCESS THE FILES IN THE CONFIG DIRECTORY.
Use the database administration tools. For your previous case, you should have
simply used:
slapcat -s olcDatabase=\{1\}bdb,cn=config
Make sure the consumer is talking to the server you think it is. Show slapd
-d7 output from the provider while the consumer is trying to connect.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: olcTLSVerifyClient: demand not taking effect
Peter Wood wrote: On Mon, Mar 12, 2012 at 9:41 PM, Quanah Gibson-Mount qua...@zimbra.com mailto:qua...@zimbra.com wrote: --On Monday, March 12, 2012 6:52 PM -0700 Peter Wood peterwood...@gmail.com mailto:peterwood...@gmail.com wrote: Hi, I setup openldap-2.4.23 server Why? I'd suggest you start with the current release, 2.4.30. You may also want to look at http://www.openldap.org/its/__index.cgi/?findid=7197 http://www.openldap.org/its/index.cgi/?findid=7197 That's the openldap version in centos6.2 repo. In production I try to stick with stock versions. Also I tried all variations of olcTLSVerifyClient: [demand|hard|true] with the same result. I don't think StartTLS is enabled. I'm wondering if just setting olcTLSCACertificateFile, olcTLSCertificateFile and olcTLSCertificateKeyFile is enough to get StartTLS enabled. It's very frustrating. I'd hate to go to ldaps just because I can't get StartTLS working. Is there anything else I have to set on the server to get StartTLS working? No. StartTLS is an LDAP Request, the client has to ask for it. There is nothing a server can do to initiate it. The TLSVerifyClient setting only affects sessions where the client has already initiated TLS. To force connections to require TLS, look at the olcRequires and olcSecurity settings in slapd-config(5). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Fwd: OpenLdap Startup Failure
Swapnesh sharma wrote:
Hi All,
I have installed OpenLdap-2.4.26 on Solaris 10 (SunOS xxx 5.10
Generic_142900-09 sun4v sparc SUNW,SPARC-Enterprise-T5220) using the packages
available from sunfreeware (http://www.sunfreeware.com/indexsparc10.html)
Installation was successful without any error. But when starting slapd, I am
getting below error.
Looks like you have installed on top of an existing BDB database that was
created on an x86 machine. You can't do that. When migrating databases you
must slapcat the old DB and slapadd it onto the new machine. Like the Admin
Guide says.
Can anyone please help/redirect me ?
I am trying to find a solution using the documents and archive mails. Let me
know if you require more information.
bash-3.00#/usr/local/libexec/slapd -d 255
slapd startup: initiated.
backend_startup_one: starting cn=config
config_back_db_open
Backend ACL: access to *
by * none
config_back_db_open: line 0: warning: cannot assess the validity of the ACL
scope within backend naming context
config_build_entry: cn=config
config_build_entry: cn=schema
dnNormalize: cn={0}core
dnNormalize: cn={0}core
config_build_entry: cn={0}core
config_build_entry: olcDatabase={-1}frontend
config_build_entry: olcDatabase={0}config
config_build_entry: olcDatabase={1}bdb
backend_startup_one: starting dc=my-domain,dc=com
bdb_db_open: dc=my-domain,dc=com
*bdb_db_open: database dc=my-domain,dc=com:
dbenv_open(/usr/local/var/openldap-data).*
*bdb(dc=my-domain,dc=com): Ignoring log file:
/usr/local/var/openldap-data/log.01: magic number 88090400, not 40988*
*bdb(dc=my-domain,dc=com): Invalid log file: log.01: Invalid argument*
*bdb(dc=my-domain,dc=com): PANIC: Invalid argument*
*bdb(dc=my-domain,dc=com): unable to join the environment*
*bdb_db_open: database dc=my-domain,dc=com cannot be opened, err -30974.
Restore from backup!*
bdb_cache_release_all
bdb(dc=my-domain,dc=com): txn_checkpoint interface requires an environment
configured for the transaction subsystem
bdb_db_close: database dc=my-domain,dc=com: txn_checkpoint failed: Invalid
argument (22).
backend_startup_one (type=bdb, suffix=dc=my-domain,dc=com): bi_db_open
failed! (-30974)
slapd shutdown: initiated
bdb_cache_release_all
bdb_db_close: database dc=my-domain,dc=com: alock_close failed
slapd destroy: freeing system resources.
slapd stopped.
Regards,
Swapnesh
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Scaling LDAP
Hallvard B Furuseth wrote: Gaurav Gugnani wrote: Actually, i want to know - how to scale out once you reach the limits to run openLdap in one single box? You said some million of records. That's nowhere near OpenLDAP's limits, nor near the multi-terabyte databases you mention, unless your LDAP entries are quite large - e.g. lots of JPEG photos and the like. Your scenario just sounds like a database which does not all fit in RAM. The Tuning section of the Admin Guide describes which parameters to give priority in that case. But as Howard mentions, that'll become unnecessary. The MDB backend will leave that to the OS. Anyway, if you do reach those limits, I guess you must currently split up your LDAP directory. Put different subtrees in different servers. Then set up referrals between them. Tie them together with the chain overlay or ldap backend if you don't want the clients to have to deal with referrals, though that increases the server load. Back when I wrote about that, I was speaking of back-ndb. Since it uses MySQL Cluster, you can simply add more cluster nodes if you want to scale further. Going back to the original question - once you reach the limits of a single box, you obviously need either a larger box, or more boxes. Unfortunately back-ndb (and the NDB API) needs a bit more work before it can be generally useful. And in the time since Oracle acquired Sun (and therefore MySQL), most people who were interested in the NDB OpenLDAP code have walked away from it. If you know of any developers who'd like to pick up back-ndb and push it further, send them over... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
Chris Hiestand wrote: Part 1: Readability I know you veterans are probably sick to death of us late-comers asking questions about cn=config. I understand but please hear me out because I feel I have done due diligence; but I still have some concerns with the transition. Workflow has been discussed before, but I suspect it hasn't been fleshed out because the switch from editing schema and ACLs in flat files to LDAP entries reduces readability. I have no problem using cn=config for most configuration attributes, but it gets a lot less user friendly when the value is, what used to be in slapd.conf, a multi-line string. But I could just be missing something. Your help is appreciated. Attached are some screenshots of editing ACLs and a custom schema via 3 methods: 1. cn=config via ldap client (ie apache directory studio) 2. cn=config via ldif 3. old style slapd.conf Look at the pictures and pick which method you'd like to use to edit ACLs or a schema: http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldap.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-ldif.png http://snl.salk.edu/~chiestand/openldap/ACLs-via-slapd.conf.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldap.png http://snl.salk.edu/~chiestand/openldap/schema-via-ldif.png http://snl.salk.edu/~chiestand/openldap/schema-via-slapd.conf.png I think the choice is clearly old style slapd.conf. Otherwise you miss comments and ordering (until Howard Chu's X-ORDERED ldap extension is implemented), and unlimited whitespace to substantially improve readability. The LDIF files are a mess because of the way words are split unpredictably by new lines. You can't use a simple search and replace with any hope of it working. Readability would be vastly improved with new lines before keywords (eg to, filter, attrs …) but I don't think it's possible to have ldapsearch output this way. As an LDAP Admin you're going to have to learn to deal with LDIF anyway. This is the most trivial of complaints and seems to be dealt with every couple of years on these mailing lists. http://www.openldap.org/lists/openldap-technical/201009/msg00140.html Editing via an ldap client is easy if you're just editing an attribute here and there, but because of the interacting nature of ACLs and schema elements, poor readability (no newlines) makes editing via an ldap client more difficult (a gui with smart sorting and syntax highlighting could make it better). The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks. Am I just missing workflow techniques or key concepts that improves readability? Or is your advice to just suck it up and get used to it? Part 2: Deleting entries in cn=config Quanah Gibson-Mount has said entry deletes are coming in 2.5, is that still the plan? The Roadmap page isn't specific. Not likely. What about whole schema deletes? From a sysadmin perspective, I should be able to add, modify, or delete anything from the configuration. For QA reasons, you want to be have the exact configuration you want; not the configuration you want plus legacy boogers. I understand if this isn't trivial to achieve from the developer perspective. Granted I don't have the whole picture here, but I'd argue that it's worth it. The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone. On the other hand, we should certainly provide a slapdelete tool for removing things while slapd is offline. If you have screwed up your configuration so badly that you need to delete something from it, you might as well restart the server anyway. Lastly, I thank everyone who contributes to OpenLDAP. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: openLDAP as a proxy for AD
Chris O'Kelly wrote: Hi guys, Read the slaptest(8) manpage. Set up your slapd.conf as desired and then convert to slapd.d format. Read the slapo-pbind(8) manpage. If all you need is web authentication you may not need to bother with full proxy configuration. I have been trying for a few weeks to integrate 2 directories. One is an AD directory which holds internal employees and is used for windows domain logins/policy etc. The other is an openLDAP directory I set up myself last week which contains external users (not employed by the company but need access to various web applications we serve). As some of our web applications do not support chaining multiple authentication sources we are trying to get all the AD content available in OpenLDAP, so we can use that for web app authentication and AD for Windows Domain stuff. Before this I have basically no experience with LDAP (if I don't count adding and removing the odd user or group from AD). As a result I went into this project rather optimistically, having read great stuff about syncrepl and how easy it is to set up replication to openLDAP. By now I am guessing most people have guessed the realisation I came to when I tried to go down that path, being that AD doesn't play nicely with others and syncrepl is not going to help here. Since then I have been doing a good deal of RTFMing and JFGIing and I believe what I need to do is to use the back-ldap database type to set up a proxy. Unfortunately that's where I hit a dead end. Every tutorial I can find seems to relate to slapd.conf, whereas I am setup with RTC in the slapd.d directory. In attempting to get around this I have been doing things like adding olc to the beginning of pretty much everything I would put into slapd.conf, saving as a .ldif and ldapadding it. After a while of trial and error runs I discovered what modules needed to be loaded and what not in order to complete the ldapadd without error, but still saw no change, searching found the results in OpenLDAP but never the ones in AD. In desperation, today I apt-get purged OpenLDAP and its dependencies and reinstalled it. I deleted the basic configuration loaded into slapd.d and set up a slapd.conf file as best I could with the setup I needed plus the back-ldap stuff I had found in tutorials. I successfully slaptested it but I am hitting the exact same problem, and the changes I have made since then seem to have only succeeded in breaking OpenLDAP to the point where I was no longer able to connect to it with Apache Directory Studio. So now I have purged the lot again, and I suppose I am looking for some help as to where to go from here. OpenLDAP is running on Ubuntu and the ldif I have been trying to add for the proxy is- olcDatabase: ldap olcSuffix: dc=companyname,dc=local olcSubordinate: yes olcRebind-as-user: yes olcUri: ldap://companyname.local/; olcChase-referrals: yes Thanks in advance to anyone who can help! -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Line breaks in Directory String values
Michael Ströder wrote: Nick Milas wrote: On 22/3/2012 2:20 μμ, btb wrote: i press the enter key on my keyboard Interestingly, I found that the same is also possible with JXPlorer. ACLs can be formatted like that and they remain formated. They also function without problems. Unfortunately, normal listing (all values together), does not show them formatted; I must edit each one separately to view it formatted. For the upcoming release I've registered possibly multi-line olc* attribute types with web2ldap's plugin class MultilineText and I could add line breaks manually. (This plugin class is also used for XML data found in config of other directory server products, etc.) But I wonder whether this is guaranteed to work since slapd rips out line breaks from the values imported from slapd.conf during automatic config conversion. It preserves multiple space chars formerly used for indentation though. So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP. The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF. OpenLDAP stores attribute values verbatim. It always has and always will. You shouldn't even need to ask this question. Additional white space introduced when displaying as LDIF (e.g. for line-wrapping) is strictly an LDIF concern; it is not part of the actual attribute values. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Line breaks in Directory String values
Michael Ströder wrote: Howard Chu wrote: Michael Ströder wrote: So I'd be interested in hearing one of the core developers confirm that line breaks in those attribute values will always be preserved when added via LDAP. The attribute types in question all have Directory String syntax. But glancing at the RFC the syntax Directory String allows CR and LF. OpenLDAP stores attribute values verbatim. It always has and always will. Thanks for confirming that. You shouldn't even need to ask this question. As said the automatic conversion hunks out the line breaks found in in the original slapd.conf and many attributes in back-config gets extra checking anyway. So the question whether some attribute values might get stored sanitized is not that false. Your question is pretty imprecise, then. Values stored due to conversion from slapd.conf are not treated exactly the same as values stored by LDAP operations. Everything read from slapd.conf has had excess whitespace stripped (as documented in slapd.conf(5)) when read; that is the normal behavior of the slapd.conf parser and has been since the dawn of time. I think you should appreciate client developers clarifying possible interop issues in advance. So there's nothing justifying your arrogant attitude. Michael, you are not a newbie; quit acting like one. You've been associated with this Project for at least the past 12 years. There is nothing arrogant in telling you you should know better by now. *You* *should* know better by now. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
Buchan Milne wrote: On Tuesday, 20 March 2012 12:53:08 Howard Chu wrote: The purpose of cn=config is to support configuration changes on a server without causing any service outage. Supporting Deletes in cn=config is fundamentally opposed to this goal. E.g., deleting an olcDatabase entry cannot be seen as anything other than a service outage - you were serving a database a second ago, now it's gone. On a server serving multiple databases, removing one of the databases is not necessarily a service outage. I would prefer (when I can clean up a legacy database, once the last of the legacy software that uses it is migrated) not to have outages on the other 3 databases in use. And how will you know definitively that all of your legacy clients have been turned off? Anyway, you can accomplish nearly the same, without deleting the database object, simply by modifying the olcDbDirectory to point to an empty directory. The old pathname will be closed, the new one opened, and there will be no data to serve. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Concerns with OLC (cn=config) for editing schema, ACLs, and deleting entries
Michael Ströder wrote: Howard Chu wrote: The OpenLDAP Project is only concerned with implementing the low level functionality. If you want a GUI, ask the Apache Directory Studio folks. But back-config's schema has a very high influence. The question is why it's so much easier for GUI clients to directly support tweaking cn=config or similar configuration entries of other directory servers? Is it easier? File ITSs on the obvious problem areas then. AFAIK all other directory servers with LDAP-enabled configuration still intend for you to use their custom client for configuration. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Line breaks in Directory String values
Michael Ströder wrote: You're missing the point. I'm thinking one step *ahead* you. IMO there's nothing wrong with bringing to your attention that people *now* assume line breaks to be preserved. Especially since you're not working in the GUI camp at all. There could be valid reasons in the future to strip white spaces in LDAP requests in a normalization step. So asking for the confirmation that this behaviour will remain in the future is not imprecise or false at all. Especially when looking at 12 years history where sometimes things changed (for valid reasons). In that case, since we cannot make any predictions about the future, the smart thing to do is to make no assumptions whatsoever about what the server will preserve or strip. Treat all values as unformatted data and reformat it in your client whenever presenting to a user. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: usage of slapadd with replication/option -w
frank.offerma...@caseris.de wrote: Hi all, at the end of the thread Re: delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30)/ slapadd Usage I already asked some questions. But probably due to the wrong threadname I got no answer. So here again with a clearer threadname: Multimaster only works when slapdadd for initial filling is used with -w Is this a bug or does it work as designed? Can't confirm your statement. You need to provide more information about the steps you followed that lead you to this conclusion. If it works as designed maybe the manualpage for slapadd should be more clearly that when you work with replication you always have to use the -w option. No. Wouldn't it be helpfull if slapadd internally always use the -w option or No. are there cases in which this option could be harmfull? Yes. What happens if I use -w and have no replication configured? Irrelevant. Regards, Frank -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: usage of slapadd with replication/option -w
frank.offerma...@caseris.de wrote: Multimaster only works when slapdadd for initial filling is used with -w Is this a bug or does it work as designed? Can't confirm your statement. You need to provide more information about the steps you followed that lead you to this conclusion. In the thread delta-syncrepl and mirrormode problem (2.4.29 and 2.4.30) I already described how I came to the conclusion, that multimaster only works when using slapdadd with -w to initially fill the database. http://www.openldap.org/lists/openldap-technical/201203/msg00010.html and http://www.openldap.org/lists/openldap-technical/201202/msg00212.html But to sum up: I have 2 Masters configured in mirrormode. - both databases empty. - I use slapadd without -w to fill one database. (Ldif has only 1400 bytes ) - then do nothing else but start the first master and the second master (which database is still empty). This won't work. Both servers will initialize their accesslogs separately from their main DB since they are empty, and the two logs will have different timestamps. You need to make sure that the main DB and log DB are initialized together on at least one of the servers. - Each slapd process now has 40 to 50 % CPU usage, although nobody is doing anything with LDAP and this won't reduce no matter how long I wait. Configuration files, logs, etc are in the above threads. Anyway I uploaded a zipfile with the data/aceesdata directories, a logfile, the configfile and my schema. Name is usage of slapadd with replication option -w.zip If I use -w with the initial slapadd everything works fine. are there cases in which this option could be harmfull? Yes. Could you please tell us, what are these cases? For example, if you take a slapcat of a running database, and load it on another server, you should not use -w. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: database cannot be opened
stefano wrote: hi, am working on my ldap server. it was ok until 2 hours ago but now, ldapsearch doesn't run. this is the output on syslog: @(#) $OpenLDAP: slapd 2.4.23 (Jun 16 2011 02:53:39) $#012#011buildd@murphy:/build/buildd-openldap_2.4.23-7.2-i386-Y1mwvF/openldap-2.4.23/debian/build/servers/slapd Mar 26 16:11:33 amahoro slapd[1604]: hdb_db_open: database dc=amahoro,dc=bi cannot be opened, err 13. Restore from backup! errno 13 is EACCES. slapd cannot open the database files because the permissions on the files are wrong. Fix your file permissions. what is the problem? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: clients: libnss-ldapd or libnss-ldap?
stefano wrote: hi, am installing ldap clients. the server is squeeze so i used libnss-ldapd. what about ubuntu 9.10-10-10 clients? libnss-ldap or libnss-ldapd? Why would you want to make life harder on yourself by installing different software on various machines? If you're already using libnss-ldapd on one set of machines, why even consider using something different, given the choice? libnss-ldapd is superior, libnss-ldap causes too many problems. Neither of these packages are part of OpenLDAP; none of this discussion belongs on this mailing list. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
