openldap-technical

openldap-technical@openldap.org

20 participants
9802 discussions

Re: (ITS#6666) Feature Request: Triggers implementation
by Buchan Milne 07 Oct '10

07 Oct '10

On Thursday, 7 October 2010 08:35:45 nick(a)eurobjects.com wrote: > Sorry, I' m not a developer. I'm trying to find a solution from an > administrator's point of view. I think you should have discussed this on a mailing list first, coming to some feasible method that would be acceptable, before deciding whether an ITS should be filed. > How about doing something like: > on log attr <attrname> notify <[ip]:[port]> > which would send a "message" with the attr name, the old and the new > value of the attribute to [ip]:[port]. But, slapd already "publishes" changes via syncrepl. > Then, someone can set up a net listening process like netcat (nc) to > read data and do whatever. But it is possible to provide an example perl script to search for changes in the directory, and have it execute actions which are configurable in a configuration file. I have a daemonised perl script using Net::LDAPapi that could potentially be modified to read from a configuration file (but, it was written to feed commands into a long-running interactive tool, so I would need to re-work it a bit). Regards, Buchan

1 0

Re: OpenLDAP session authentication
by Erik Lotspeich 07 Oct '10

07 Oct '10

Hi Dan, OK, I got things working. Thank you for your patience! >> What DN would I use for simple authentication? Maybe Thunderbird cannot >> perform a SASL BIND? It seems Thunderbird only performs a simple bind. > For simple authentication, you'd need to specify the DN of an entry within > your LDAP tree. This statement helped me put it all together. Another missing piece for me was the userPassword attribute. I didn't realize that it was to be part of an entry (for some reason, I thought it was a slapd.conf parameter). I added this entry for the users who I want to allow to authenticate. It is acceptable to me to bind against the full dn of users entry, so I bind against this: cn=Erik Lotspeich,ou=family,ou=people,dc=lotspeich,dc=org The userPassword attribute is set to: userPassword: {SASL}erik So now, simple binds work now: erik@starfish:~/ldif$ ldapwhoami -H ldaps://localhost/ -D 'cn=Erik Lotspeich,ou=family,ou=people,dc=lotspeich,dc=org' -W Enter LDAP Password: dn:cn=Erik Lotspeich,ou=family,ou=people,dc=lotspeich,dc=org For SASL binds, it also works: erik@starfish:~/ldif$ ldapwhoami -H ldaps://localhost/ -U erik -W Enter LDAP Password: SASL/PLAIN authentication started SASL username: erik SASL SSF: 0 dn:uid=erik,cn=plain,cn=auth Looking through the Admin guide, I decided on a set of rules that seem to accomplish what I want: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users write by * none Again, thanks for your help. I learned a lot -- I believe I know enough now to make better sense of the Admin guide. Regards, Erik

1 0

Re: best practice and account management (passwd)
by Chris Jacobs 07 Oct '10

07 Oct '10

Please reply-to-all. :) And, no, your confusion can never be wrong. :s However, I haven't heard or seen anyone trying to store user's files in LDAP. Even with Windows AD networks, using roaming profiles, the AD stores the user's account and group info, and the user's 'profiles' (ie: homedir) were usually kept on another file server. That said, even in Windows, I've only ever been in one environment that used roaming profiles and it was painful to login to a new system (takes a while to copy the data!) and it was eventually discontinued. The typical LDAP (or AD for that matter) is setup, at it's heart, to be a user db - name, email, homedir, group memberships, and other various bits of user /info/. I do believe it's possible to store files in LDAP, but openldap doesn't provide the tools necessary to handle the retrieval and setup of homedirs, nor the syncing of the homedir back to the LDAP server on logout. That would be handled by other tools, and then it's best to store the data in a file server location rather than in the LDAP db (it's not intended to store files, per se, I suspect it would awfully slow compared to a file server). If I were to attempt to setup roaming profiles, I would aim to store the files on a file server. Recommendation: do one thing at a time. Research and test roaming profiles, before LDAP. Or vice versa. You'll find you won't be using LDAP to handle the file storage, but you may end up configuring clients via some of the same files (nsswitch, pam.conf, etc.). - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jacobs(a)apollogrp.edu ----- Original Message ----- From: tangonights(a)yahoo.it <tangonights(a)yahoo.it> To: Chris Jacobs Sent: Thu Oct 07 04:08:20 2010 Subject: Re: best practice and account management (passwd) thanks for your answer, some comment inline. On Thursday 7 October 2010 04:01:57 you wrote: > Stefano, > > There are settings that can be set in PAM's ldap.conf (under /etc) to help > abrogate the timeout difficulties. Some aren't documented officially, and > so may disappear without notice - but they do help. Google: > nss-reconnect_tries. > > I wouldn't put root into ldap - if your ldap server is unavailable, logging > in could be /very/ difficult. Not to mention if a node connects without > encryption and the root account is used. One doesn't have to 'own' a box, > merely get to the network to listen in on that. > > And for Debian based distro's, I think it would be a good idea to have a > local account you can use to sudo to root. > > I would also add local to your pam conf - listed after ldap, of course > (unless the timeouts are difficult while you're > troubleshooting/experimenting). > > I would recommend groups and users being put into only ldap, and leaving > necessary local accounts and groups for the box to do it's job (be it > httpd, mysql, etc, users) left alone. > > As for putting home directories into ldap - I don't think that's possible. > I've never seen that in linux personally, but I suspect that would be > outside ldap's purview. However, as the user account would be ldap based, > it would contain home folder location. ldap contains just the homedir path I know, but when ldap implemented, is it a logical consequence to store homedirs on the server? I found a bit complicated to manage accounts 'a la ldap' and keep all the relevant homedirs on the remote clients......Am I wrong? Bye! > > This isn't intended as a complete or authoritative reply - just what I've > gleaned - and I've been wrong before (on this list even). > > Good luck! > - chris > > PS: my apologies for top-posting - it's kinda what BBs do. > > Chris Jacobs, Systems Administrator > Apollo Group | Apollo Marketing | Aptimus > 2001 6th Ave Ste 3200 | Seattle, WA 98121 > phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661 > email: chris.jacobs(a)apollogrp.edu > > ----- Original Message ----- > From: openldap-technical-bounces(a)OpenLDAP.org > <openldap-technical-bounces(a)OpenLDAP.org> To: > openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> Sent: > Wed Oct 06 07:23:11 2010 > Subject: best practice and account management (passwd) > > Hi everybody! > > I'm a openldab absolute beginner so.. > > I started my training with user management, and was wondering if it was a > good practice to move the whole /etc/passwd to ldap and let nsswitch jusst > to 'ldap' the passwd,group,shadow items > > passwd: ldap > group: ldap > shadow: ldap > > I tried and I faced some obvious issues like client's boot errors etc. It > worked but at the cost of a looong timeout.. > > - Is there any point in moving the whole /etc/passwd and groups, or is > maybe better to move the root and other 'human' accounts, leaving local > just the system users and groups? > > - was it better to keep the user's home directories (including /root) > locally on the client, or better to move them on the ldap server, letting > them be net- mounted on the client fs? > > Is it theoretically (and practically :-) ) possible to use ldap and remove > from clients all the account management related binaries (useradd etc.) and > /etc/passwd and /etc/groups? > > maybe naive questions..sorry :-) > > bye, > Stefano. > > > This message is private and confidential. If you have received it in error, > please notify the sender and remove it from your system. This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

questions about openldap replication
by plug bert 07 Oct '10

07 Oct '10

Hi All, i've read through the replication section of the admin guide, but i'm still not clear on the ff: 1. For push-type setups, do i really need to set up a sync proxy? the docs seem to imply this is necessary only if there are firewall restrictions, yet i haven't seen any examples of a push setup w/o a proxy. 2. Is it possible to set up a push delta-syncrepl scheme? 3. In a syncrepl/delta-syncrepl push setup, how does the master know where the replicas are? Things were a bit simpler with slurpd...ah, progress B) tia

4 4

subordinate + translucent
by Wouter D'Haeseleer 07 Oct '10

07 Oct '10

This is what I would like todo: - Have a local DB which contains only groups under ou=Groups,OU=example,DC=com - Have a translucent conection to Active Directory - using subordinate gue this 2 databases together This should make it possible to administrate local Groups And add the needed Posix stuff to our ActiveDirectory users. This seems to work exept for the translucent stuff. I see both my databases (The AD and the Local one) I can write to my local one (adding a group for example) But when I want to add extra attributes to an ActiveDirectory use (using the translucent) I can't do this I Receive the following error "No Such Object" It seems that I'm not able to write to the glued translucent DB. Here is the config. database bdb suffix "ou=ActiveDir,OU=example,DC=com" subordinate directory "/var/lib/ldap-translucent" overlay translucent uri "ldap://remotehost" acl-bind bindmethod=simple binddn="cn=readonlyuser,OU=example,DC=com" credentials=secret idassert-bind bindmethod=simple binddn="cn=readonlyuser,OU=example,DC=com" credentials="secret" mode=none flags=non-prescriptive database bdb suffix "OU=example,DC=com" overlay glue directory "/var/lib/ldap" rootdn "cn=admin,OU=example,DC=com" rootpw supersecure index cn,sn,uid pres,eq,approx,sub index objectClass eq

1 0

RE: memberOf module install on ubuntu 10.04 slapd package gives:"Insufficient access" using admin interface
by Jon Skarpeteig 07 Oct '10

07 Oct '10

To clarify some: As I understand it, the interface I use is for admin purposes only, doing changes from root@localhost without any cn credentials. In fact, I created an admin account from the same interface, which could import schemas, create OU and CN entries, and generally behaving like expected for everything except enabling modules. I used this guide: http://albanianwizard.org/ubuntu-10-0-4-lucid-lynx-ldap-configuration-th e-working-how-to.albanianwizard to get this working as I expected. (Note the modifications to cn=config here, which worked fine for me) Openldap no longer have any config file, so all config changes is done through this interface. Using the CN=admin,DC=domain,DC=com created from the guide above return the same insufficient error message. I have also attempted to force the use of a slapd.conf file, which I ported from 8.04 conf file, without success. I also attempted an strace to follow the login procedure without getting any other message than the generic 'Insufficient access', or any reference to what permissions it checks. What I can't figure out is why the admin account doesn't have access by default, or how/what to change in order to allow access. But I suspect there is something other than simple missing admin permissions going on here. I also attempted to change permissions and ownership of any files related to slapd, also with the same result. Any ideas on what to look for? From: openldap-technical-bounces(a)openldap.org [mailto:openldap-technical-bounces@openldap.org] On Behalf Of Jon Skarpeteig Sent: 5. oktober 2010 10:41 To: openldap-technical(a)openldap.org Subject: memberOf module install on ubuntu 10.04 slapd package gives:"Insufficient access" Attempting to enable memberOf module, following http://dimaj.net:1784/blog/2010/07/howto-verify-that-a-member-is-part-of -a-secondary-group-in-openldap/ gives me: ldap_modify: Insufficient access (50) - I am root on Ubuntu 10.04 using slapd package. What am I doing wrong?

1 0

Re: OpenLDAP session authentication
by Dan White 07 Oct '10

07 Oct '10

On 29/09/10 10:19 -0500, Erik Lotspeich wrote: >Hi Dan, > >I hope that I don't mind if I ask a follow-up question: > >root@starfish:/usr/local/etc/openldap# testsaslauthd -u erik -p XXX -s >slapd >0: OK "Success." > >That works, but when I run ldapwhami, it doesn't: > >root@starfish:/usr/local/etc/openldap# ldapwhoami -Y login -U erik -H >ldap://localhost >ldap_sasl_interactive_bind_s: Unknown authentication method (-6) > additional info: SASL(-4): no mechanism available: No worthy >mechs found > >I did a search on the internet, and I ran this command: > >root@starfish:/usr/local/etc/openldap# ldapsearch -x -ZZ -s base -b "" ># extended LDIF ># ># LDAPv3 ># base <> with scope baseObject ># filter: (objectclass=*) ># requesting: ALL ># > ># >dn: >objectClass: top >objectClass: OpenLDAProotDSE > ># search result >search: 3 >result: 0 Success > >In other examples I've seen, mechanisms such as PLAIN or LOGIN or listed >here. Make sure you have the appropriate sasl shared libraries installed on both your server and your client (which appears to be the same according to your examples from above). Use plugingview/saslpluginviewer to see which server/client mechanisms you do have installed. For instance, on a Debian system you'd need to have the libsasl2-modules package. If you do have those mechanisms installed but are still not seeing them in the '-s base -b ""' search, make sure you've added 'sasl-secprops none' to your openldap slapd.conf. -- Dan White

3 4

best practice and account management (passwd)
by tangonights＠yahoo.it 06 Oct '10

06 Oct '10

Hi everybody! I'm a openldab absolute beginner so.. I started my training with user management, and was wondering if it was a good practice to move the whole /etc/passwd to ldap and let nsswitch jusst to 'ldap' the passwd,group,shadow items passwd: ldap group: ldap shadow: ldap I tried and I faced some obvious issues like client's boot errors etc. It worked but at the cost of a looong timeout.. - Is there any point in moving the whole /etc/passwd and groups, or is maybe better to move the root and other 'human' accounts, leaving local just the system users and groups? - was it better to keep the user's home directories (including /root) locally on the client, or better to move them on the ldap server, letting them be net- mounted on the client fs? Is it theoretically (and practically :-) ) possible to use ldap and remove from clients all the account management related binaries (useradd etc.) and /etc/passwd and /etc/groups? maybe naive questions..sorry :-) bye, Stefano.

2 1

High memory usage in provider server
by Claudio Cuqui 05 Oct '10

05 Oct '10

Hi there ! We are using two LDAP servers providers (openldap 2.4.23) in mirror mode: one just to receive modifies and the other, just to be "consumed" by 11 consumer servers. Both servers have almost 1MM objects with 10kb in size each. Id2entry.bdb has 21Gb and dn2id.bdb has 286Mb in size. When checking the first server we note that slapd is using ~4.0Gb of memory (RES). The problem is the second server, where all 11 consumers points to. Slapd in this server is using ~18.0Gb of memory (RES). We are using syncrepl to synchronize the 11 consumers with the 2nd server (RefreshandPersist). Openldap´s compile options are identical in both servers. Same for OS (Fedora 13 - x86_64 fully updated) and packages. Any ideas to reduce memory usage in the second server ? Regards, Claudio Cuqui

2 2

Checking compile options
by Bryan Payne 05 Oct '10

05 Oct '10

I compiled two ldap servers quite some time ago and I can't remember what options I compiled in. I need to compile a new server and was wondering if there is a way to see what options I used previously?

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical