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 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
----- 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:
> 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:
> 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
> 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?
> 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 :-)
> 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.
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)
This is what I would like todo:
- Have a local DB which contains only groups under
- 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.
acl-bind bindmethod=simple binddn="cn=readonlyuser,OU=example,DC=com"
index cn,sn,uid pres,eq,approx,sub
index objectClass eq
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:
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
[mailto:firstname.lastname@example.org] On Behalf Of Jon
Sent: 5. oktober 2010 10:41
Subject: memberOf module install on ubuntu 10.04 slapd package
Attempting to enable memberOf module, following
-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
On 29/09/10 10:19 -0500, Erik Lotspeich wrote:
>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
>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_sasl_interactive_bind_s: Unknown authentication method (-6)
> additional info: SASL(-4): no mechanism available: No worthy
>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
># base <> with scope baseObject
># filter: (objectclass=*)
># requesting: ALL
># search result
>result: 0 Success
>In other examples I've seen, mechanisms such as PLAIN or LOGIN or listed
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
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.
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
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 :-)
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 ?
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?
I am working with the LSEE 11 and trying to run a LDAP server. From
scratch on everything went fine. With the standard configuration I can
login, but if I use the LDAP Browser and hit anonymous access, I can see
my whole LDAP tree. User name, mailaddresses and so on. And I am not
happy with it.
So I tried to change the access control from
access to * by * read
access to * by * auth
access to * by * search
The user password is already in auth mode.
But with every other configuration instead of read, I cannot login
anymore. Insufficient access. After the first try with auth I read the
log files and saw that there is a search operation. So i switched to
search. Now the server denies some read operations.
So, my questions are: Is it just normal that anyone can see the LDAP
tree? Is there any other option to hide my tree? And what attributes
have to be readable to login?
Thanks a lot.
I have 2 OpenLDAP 2.4.11 running as Mirror Mode very well.
But I would like to make sure that everything was replicated how should be
forever :) so I would like to write some script to monitor it.
I've searched around web, but I only found some about LDAP 2.2 and 2.3
Can you give me some tip about how I can do this?
-- Tiago Cruz