On Thu, 8 Nov 2018 11:12:16 -0800
Rick Moen <rick@???> wrote:

> Redirecting back on-list.
>
> Quoting wirelessduck@??? (wirelessduck@???):
>
> > On Mon, 3 Sep 2018 at 13:47, Rick Moen <rick@???> wrote:
> > >
> > > Anyway, it's been a _long_ time since I dealt with all of that
> > > badness, so I'm probably forgetting a lot. This looks like a
> > > decent starting point: https://wiki.debian.org/LDAP/Kerberos
> > > (except it has little to say about AD integration).
> >
> > Thanks,
>
> Yr. welcome, Tom.
>
> > As there will be no Windows machines on this network, I don't have
> > any requirement for AD integration. I probably should have
> > clarified that further in the original email.
>
> Ah, that does indeed simplify things.
>
> > After a couple of months of head-banging and much googling of
> > various docs, blogs, etc., I think I've finally managed to setup two
> > replicating OpenLDAP servers talking to each other over TLS. :D
> > LDIF is much less confusing now than it originally appeared to be,
> > thanks to the excellent reference at http://zytrax.com/books/ldap/.
> > The ldapscripts package is also working nicely in a simple way to
> > add users and groups, although I'm not entirely sure why I would add
> > machines to LDAP, unless I use those accounts for binding services?
>
> Offhand, I don't think that'd be useful, no.
>
> As I see it, part of what's both really useful and really annoying
> about LDAP is that it was designed as an _extremely general_
> implementation of the X.500 directory management standard. So, it'll
> happily inhale the kitchen sink of all possible information about
> everything in the enterprise. Therefore, you often find yourself
> saying 'Yes, I could do _this_ thing with it, too, but what would be
> the point? I have no use-case for doing that.' The trick is to
> realise that the 'But _why_?' reaction is normal and doesn't
> necessarily mean you missed something significant.
>
> > So my next question is, whats the recommended package to
> > authenticate with LDAP and allow users to login to a desktop via
> > their LDAP account? I've seen various options for PAM and NSS, but
> > do I need to configure both or just one?
>
> Tom, ten years ago and two major employers ago, I would have been glad
> to send you example configurations from what I and the other senior SA
> at $FIRM somewhat painfully figured out at that time. I'm really
> sorry, but I just no longer have that anywhere.
>
> I remember that you very much needed a PAM hook, because you're
> introducing a new and preferred authentication method for shell login.
> Offhand, I can't remember exactly _how_ NSS is part of this picture
> (being about name services, e.g., names of hosts), but NSS and PAM
> are pretty intertwined.
>
> I remember that each machine needed a rather painfully worked out
> ldap.conf file. I vaguely recall the need to have a self-signed X.509
> certificate. Each machine needed to run the nscd and nslcd daemons:
> The latter was a new, surprising requirement introduced as of CentOS
> 6.x (which was then new) -- though there is also an alternative
> called sssd:
> https://support.hpe.com/hpsc/doc/public/display?docId=emr_na-c02791157
>
> And there, I'm afraid, we've now exhausted what I can easily remember
> after so many years of not needing to know it. I hope that helps.
>
> > Should I be diving into the world of Kerberos and attempting to
> > integrate that with my OpenLDAP servers, or is it fine to just
> > authenticate via LDAP?
>
> IIRC, $FIRM didn't end up having to develop Kerberos infrastructure
> just to deploy user authentication against LDAP directory services
> back-ended in OpenLDAP. It sufficed for our needs to rely on X.509
> SSL certs as a 'shared secret'. However, you decide what the local
> degree of paranoia requires.
>
> Beyond user shell authentication against LDAP, one can also tweak
> other applications where user authentication is relevant to do so as
> well, e.g., Web-based services backed by Apache HTTPd (and thus
> entailing plumbing added to the Apache conffiles). Bear that in mind
> if relevant to your use-case.
>

I will say it again (and yes, I might be biased here) A samba AD DC
will do all of the above without all of the complexity of setting up
LDAP and then extending it to just install users and groups.

Rowland