How to use BLOB while using Back-NDB
Hi All, I am using back-ndb as a backend for my openldap. I want to know, what is configuration change in slapd.conf I need to make to instruct openldap to always use BLOB and not the VARCHAR. Thanks, Best Regards, Priyesh Potdar
Re: Best way to merge two local DITs vs empty search base suffix
Where is it documented how the conf file slapd.conf file is processed? I've read the documentation, more than once, and still don't know. I suspect this whole 'order thing' is pretty darn important (outside of access config). Seriously, please me at it. Thanks, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.org openldap-technical-bounces+chris.jacobs=apollogrp@openldap.org To: guy.baconni...@swisscom.com guy.baconni...@swisscom.com; openldap-technical@openldap.org openldap-technical@openldap.org Sent: Sun Jun 13 20:20:07 2010 Subject: Re: Best way to merge two local DITs vs empty search base suffix --On Sunday, June 13, 2010 12:17 PM +0200 guy.baconni...@swisscom.com wrote: Hello, We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the current configuration do not use a regular suffix (o=foo,c=bar nor dc=foo,dc=bar) but use an empty suffix (). We want to move away from empty suffix as we cannot use cn=monitor or any additional suffixes as they can not bind when a suffix is in use in a hdb database : You can do this just fine. I do it in all my installs. You simply need to declare them in the right order. I.e., you must declare monitor, etc before the empty suffix. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.
Posix group with /etc/ldap.conf read priv
I don't like having the /etc/ldap.conf world readable because then anyone who has shell access can see our general ldap login credentials (without which you cannot see anything in the ldap tree). So I have added a posixgroup in ldap, added our shell users to it and did: chown root:usergroup /etc/ldap.conf chmod 640 /etc/ldap.conf But when logging in to the shell, users still get the I have no name! problem because they cannot read the /etc/ldap.conf and cannot map their uid / guid numbers to names from the ldap tree. Advice?
Re: Best way to merge two local DITs vs empty search base suffix
--On Monday, June 14, 2010 7:51 AM -0700 Chris Jacobs chris.jac...@apollogrp.edu wrote: Where is it documented how the conf file slapd.conf file is processed? I've read the documentation, more than once, and still don't know. I suspect this whole 'order thing' is pretty darn important (outside of access config). Seriously, please me at it. The slapd configuration is broken up into parts. This is well described in the slapd.conf(5) man page: The slapd.conf file consists of a series of global configuration options that apply to slapd as a whole (including all backends), fol- lowed by zero or more database backend definitions that contain infor- mation specific to a backend instance. The configuration options are case-insensitive; their value, on a case by case basis, may be case- sensitive. The global section is covered in the main slapd.conf/cn=config man pages. It is even clearly titled so as GLOBAL CONFIGURATION OPTIONS in the man page itself. The slapd.conf/cn=config man pages also cover the general database options that apply to all backends (or as otherwise noted in that section). Options specific to a given backend are clearly documented in the man pages for that backend, such as back-hdb, back-bdb, etc. This is also clearly detailed in the slapd.conf/cn=config man pages: DATABASE-SPECIFIC OPTIONS Each database may allow specific configuration options; they are documented separately in the backends' manual pages. See the slapd.backends(5) manual page for an overview of available backends. In any case, it all looks pretty clear to me. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration
Re: Posix group with /etc/ldap.conf read priv
On Mon, 14 Jun 2010, Ariel wrote: I don't like having the /etc/ldap.conf world readable [...] Advice? And you didn't chmod /etc/passwd and /etc/group too? What if people get valuable information out of those? You can't do this and be POSIX multi-user; getgr*/getpw* are unprivileged operations. Your users should be able to get some output with getent(1), and your users should be able to get the same output with cat /etc/ldap.conf and a bit of thought, and any attempts to make that harder will be a waste of time on your part. Change back the permissions, or change your OS. Now, with all this said, if your users can get *more* information with cat /etc/ldap.conf and thought than getent(1) provides, that may well be a configuration error on your part, which would be appropriate to discuss on this list...
Re: Posix group with /etc/ldap.conf read priv
Please keep replies on the list. On Mon, 14 Jun 2010, Ariel wrote: On Jun 14, 2010, at 1:33 PM, Aaron Richton wrote: On Mon, 14 Jun 2010, Ariel wrote: I don't like having the /etc/ldap.conf world readable [...] Advice? And you didn't chmod /etc/passwd and /etc/group too? What if people get valuable information out of those? You can't do this and be POSIX multi-user; getgr*/getpw* are unprivileged operations. Your users should be able to get some output with getent(1), and your users should be able to get the same output with cat /etc/ldap.conf and a bit of thought, and any attempts to make that harder will be a waste of time on your part. Change back the permissions, or change your OS. Now, with all this said, if your users can get *more* information with cat /etc/ldap.conf and thought than getent(1) provides, that may well be a configuration error on your part, which would be appropriate to discuss on this list... I have not heard of getent before, but it seems it would only be able to read ldap users if there was a copy of the ldap database locally? Or am I wrong about this? Don't think about this in terms of LDAP or any other network name service. Imagine you've got a fresh-from-factory laptop. You start adding users, they go into /etc/passwd. /etc/passwd is world-readable. Everybody on the laptop can see the list of users as you update it. Same for a server with LDAP. The actual name service is irrelevant, it's a requirement of the API that has to be provided... I am not worried about local users being seen, there are few per server and they have low privileges. I was worried about someone being able to read all our ldap users which can access every system on our network and many of which have very high privileges. This is the reason why we restrict reading from our ldap server to a validated read-only user in the first place. OK, again forget LDAP. You've got two servers now, each with their own /etc/passwd. Say there are 6 users on one and 8 on the other. In the simple, non-network case, cat /etc/passwd should show 6 or 8 (depending on where you type it) and getent passwd should match with 6 or 8 users shown. Even if they cannot read the password hash, getting a full list of users seemed like something I would want to avoid. But if any attempts at doing so in the way I was describing is meaningless then I can move on to other things that need doing. ...well, to continue my example, if you configure things such that getent passwd shows 14 users, that would probably be a mistake. You're right that outputting a full list of users, across disparate authentication configurations, is probably something to be avoided. But that's what ACLs are for. See slapd.access(5). And you do this server-side (possibly combined with a binddn on the client) by editing the world-readable ldap.conf, not by chmod'ing the file...
Re: Posix group with /etc/ldap.conf read priv
On Jun 14, 2010, at 1:56 PM, Aaron Richton wrote: Please keep replies on the list. On Mon, 14 Jun 2010, Ariel wrote: On Jun 14, 2010, at 1:33 PM, Aaron Richton wrote: On Mon, 14 Jun 2010, Ariel wrote: I don't like having the /etc/ldap.conf world readable [...] Advice? And you didn't chmod /etc/passwd and /etc/group too? What if people get valuable information out of those? You can't do this and be POSIX multi-user; getgr*/getpw* are unprivileged operations. Your users should be able to get some output with getent(1), and your users should be able to get the same output with cat /etc/ldap.conf and a bit of thought, and any attempts to make that harder will be a waste of time on your part. Change back the permissions, or change your OS. Now, with all this said, if your users can get *more* information with cat /etc/ldap.conf and thought than getent(1) provides, that may well be a configuration error on your part, which would be appropriate to discuss on this list... I have not heard of getent before, but it seems it would only be able to read ldap users if there was a copy of the ldap database locally? Or am I wrong about this? Don't think about this in terms of LDAP or any other network name service. Imagine you've got a fresh-from-factory laptop. You start adding users, they go into /etc/passwd. /etc/passwd is world-readable. Everybody on the laptop can see the list of users as you update it. Same for a server with LDAP. The actual name service is irrelevant, it's a requirement of the API that has to be provided... I am not worried about local users being seen, there are few per server and they have low privileges. I was worried about someone being able to read all our ldap users which can access every system on our network and many of which have very high privileges. This is the reason why we restrict reading from our ldap server to a validated read-only user in the first place. OK, again forget LDAP. You've got two servers now, each with their own /etc/passwd. Say there are 6 users on one and 8 on the other. In the simple, non-network case, cat /etc/passwd should show 6 or 8 (depending on where you type it) and getent passwd should match with 6 or 8 users shown. Even if they cannot read the password hash, getting a full list of users seemed like something I would want to avoid. But if any attempts at doing so in the way I was describing is meaningless then I can move on to other things that need doing. ...well, to continue my example, if you configure things such that getent passwd shows 14 users, that would probably be a mistake. You're right that outputting a full list of users, across disparate authentication configurations, is probably something to be avoided. But that's what ACLs are for. See slapd.access(5). And you do this server-side (possibly combined with a binddn on the client) by editing the world-readable ldap.conf, not by chmod'ing the file... Sorry, hit the quick reply button by accident. Thanks for the reply though, I understand more about what you were saying. And `getent passwd` does show all of the posixAccount users in ldap, that is interesting and not good. I understand what you mean about changing ACL's in slapd.conf even though I don't know exactly how I would set the permissions yet. And it does seem more secure in the long run, such that if any random server is compromised, with the basic read-only ldap account should not be able to give them a list of every user in the tree. I will search the interwebs for docs on securing openldap instead of randomly assuming things. Thank you very much for the input!
Re: How to use BLOB while using Back-NDB
Priyesh Potdar wrote: Hi All, I am using back-ndb as a backend for my openldap. I want to know, what is configuration change in slapd.conf I need to make to instruct openldap to always use BLOB and not the VARCHAR. Use attrblob attribute. Apparently this is missing from the manpage. You should file an ITS so that we can get the manpage updated. -- -- 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: Best way to merge two local DITs vs empty search base suffix
Chris Jacobs wrote: Where is it documented how the conf file slapd.conf file is processed? I've read the documentation, more than once, and still don't know. I suspect this whole 'order thing' is pretty darn important (outside of access config). slapd.conf(5): suffix dn suffix Specify the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given and at least one is required for each database definition. If the suffix of one database is inside that of another, the database with the inner suffix must come first in the configuration file. Seriously, please me at it. Thanks, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.orgopenldap-technical-bounces+chris.jacobs=apollogrp@openldap.org To: guy.baconni...@swisscom.comguy.baconni...@swisscom.com; openldap-technical@openldap.orgopenldap-technical@openldap.org Sent: Sun Jun 13 20:20:07 2010 Subject: Re: Best way to merge two local DITs vs empty search base suffix --On Sunday, June 13, 2010 12:17 PM +0200 guy.baconni...@swisscom.com wrote: Hello, We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the current configuration do not use a regular suffix (o=foo,c=bar nor dc=foo,dc=bar) but use an empty suffix (). We want to move away from empty suffix as we cannot use cn=monitor or any additional suffixes as they can not bind when a suffix is in use in a hdb database : You can do this just fine. I do it in all my installs. You simply need to declare them in the right order. I.e., you must declare monitor, etc before the empty suffix. -- -- 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: Restricting client access using pam_groupdn with dynamic groups : Was[Re: restrict host login based on group]
On Mon, Jun 14, 2010 at 12:32 AM, Shamika Joshi shamika.jo...@gmail.comwrote: Ya here it is ...output of slapcat attached. Please let me knw if u could see anything missing from this. Thanks regards Shamika Howard, I will remember that. I always use the ldap commands normally since I have a 3 way multi-master mirror setup. Shamika, Just in case i get to busy this week to look at your config here is the slapcat of my configuration with any sensitive information removed. http://www.gradientzero.com/openldap/Example_config/config.ldif.gz (I am sure that my is not 100% optimal but it is currently working for me.)
Re: Posix group with /etc/ldap.conf read priv
On 06/14/10 20:54, Ariel wrote: On Jun 14, 2010, at 1:56 PM, Aaron Richton wrote: Please keep replies on the list. On Mon, 14 Jun 2010, Ariel wrote: On Jun 14, 2010, at 1:33 PM, Aaron Richton wrote: On Mon, 14 Jun 2010, Ariel wrote: I don't like having the /etc/ldap.conf world readable [...] Advice? And you didn't chmod /etc/passwd and /etc/group too? What if people get valuable information out of those? You can't do this and be POSIX multi-user; getgr*/getpw* are unprivileged operations. Your users should be able to get some output with getent(1), and your users should be able to get the same output with cat /etc/ldap.conf and a bit of thought, and any attempts to make that harder will be a waste of time on your part. Change back the permissions, or change your OS. Now, with all this said, if your users can get *more* information with cat /etc/ldap.conf and thought than getent(1) provides, that may well be a configuration error on your part, which would be appropriate to discuss on this list... I have not heard of getent before, but it seems it would only be able to read ldap users if there was a copy of the ldap database locally? Or am I wrong about this? Don't think about this in terms of LDAP or any other network name service. Imagine you've got a fresh-from-factory laptop. You start adding users, they go into /etc/passwd. /etc/passwd is world-readable. Everybody on the laptop can see the list of users as you update it. Same for a server with LDAP. The actual name service is irrelevant, it's a requirement of the API that has to be provided... I am not worried about local users being seen, there are few per server and they have low privileges. I was worried about someone being able to read all our ldap users which can access every system on our network and many of which have very high privileges. This is the reason why we restrict reading from our ldap server to a validated read-only user in the first place. OK, again forget LDAP. You've got two servers now, each with their own /etc/passwd. Say there are 6 users on one and 8 on the other. In the simple, non-network case, cat /etc/passwd should show 6 or 8 (depending on where you type it) and getent passwd should match with 6 or 8 users shown. Even if they cannot read the password hash, getting a full list of users seemed like something I would want to avoid. But if any attempts at doing so in the way I was describing is meaningless then I can move on to other things that need doing. ...well, to continue my example, if you configure things such that getent passwd shows 14 users, that would probably be a mistake. You're right that outputting a full list of users, across disparate authentication configurations, is probably something to be avoided. But that's what ACLs are for. See slapd.access(5). And you do this server-side (possibly combined with a binddn on the client) by editing the world-readable ldap.conf, not by chmod'ing the file... Sorry, hit the quick reply button by accident. Thanks for the reply though, I understand more about what you were saying. And `getent passwd` does show all of the posixAccount users in ldap, that is interesting and not good. Not only those, but even system [local] users. Depending on /etc/nsswitch.conf/whatever. I understand what you mean about changing ACL's in slapd.conf even though I don't know exactly how I would set the permissions yet. And it does seem more secure in the long run, such that if any random server is compromised, with the basic read-only ldap account should not be able to give them a list of every user in the tree. I will search the interwebs for docs on securing openldap instead of randomly assuming things. Thank you very much for the input! In that case, chroot every single one of them [users]. Or forget the Linux/LDAP/whatever. Here is another idea - personal VMs. I'd love to add 'disposable' as I've read they're working on those, but it's still in dev [not a joke]. Zdenek -- Zdenek Styblik Net/Linux admin OS TurnovFree.net email: sty...@turnovfree.net jabber: sty...@jabber.turnovfree.net
Re: Tool to covert from LDIF cn=config to slapd.conf?
On 6/13/10 10:34 PM, Howard Chu wrote: Useful feedback is always welcome. Francis' post was self-admittedly not even worth a cup of coffee, and he made this personal a long time ago. If his post had been written from an informed standpoint I would have let it slide. Nor do I believe there was anything uncivil in the text of what I wrote. Ugh. Perhaps you would like to remind me about what we got into such a disagreement about and when that you are still mad, because I honestly do not remember. But, I have to admit, your tone is what I have come to expect from you. I fail to see how my question about all the overlays that are provided with OpenLDAP working with cn=config before slapd.conf is deleted means that I have an enormous sense of entitlement. You are, of course, welcome to your opinion. Thankfully, I am not required to agree with you. As for submitting patches. That's not going to be happening. I have submitted patches in the past for the things I cared about. However, these days, I have too many different applications that I have to maintain to take the time to decipher the OpenLDAP code anymore. -- Frank Swasey| http://www.uvm.edu/~fcs Sr Systems Administrator| Always remember: You are UNIQUE, University of Vermont |just like everyone else. I am not young enough to know everything. - Oscar Wilde (1854-1900)
