[wplug-internet] Another LDAP server to tinker with

[Bryan J Smith]

On Mon, Jun 17, 2013 at 2:33 PM, Pat Barron <pat at lectroid.com> wrote:

> I have looked at 389, the reason I didn't look at it further is that the
> setup seems ... somewhat daunting.
>

Never heard 389 stated to be "daunting" in the Fedora realm.  It's in the
repo, always has been, and has a built-in, standard, Java-based admin
console.  It's basically the direct linage of Netscape hiring away the
original Michigan LDAP developers, [1] while other projects just took the
code without that mindshare.

I.e., most AOL-Netscape and Sun customers had expections of services, like
multi-master replication, a GUI admin console, etc... from the get-go --
all of which is now GPL, MPL or APL licensed in 389.

Again, if you weren't running a Fedora-based distro, or were "happy" with
OpenLDAP, I wouldn't have brought up 389 (even though it's available for
Debian-based too).  But since you are both running a Fedora-based distro,
and looking for other options than 389, I was just wouldn't also put 389 in
the pool?

The target environment for this is (eventually) WPLUG's own server, on
> CentOS 5.9.


And understand 389 is also in Fedora's Extra Packages for Enterprise Linux
(EPEL).  So it's easy to install on any Enterprise Linux (EL) Rebuilds [2]
as well.  Although it would be nice, additional option if the EL Rebuilds
would build 389 from SRPMS on ftp.redhat.com (Red Hat Directory Server) to
get a full five-plus (5+) years of life cycle without rebasing. [3]

But many of the EL Rebuilds have made their choice to break 1:1 bitwise
compatibility with Red Hat(R) products by tapping often more leading edge
(than the ftp.redhat.com SRPMS) Fedora EPEL for more and more beyond just
the core.  That's their choice, and it saves them effort since Fedora's
maintainers and Red Hat's build servers rebuild for them in EPEL, from the
Fedora packages.

But that doesn't mean it's not stable, far from it.  389 is quite well
liked for this reason, even in leading-edge Fedora.  It also serves as the
basis for IPA, which pretty much everyone is adopting because it solves
many issues (including multi-realm and cross-forest AD trusts).


> The application would be to provide a common
> identity/authentication framework for multiple separate services that we
> may want to deliver from that server, avoiding having to have a
> separately maintained username/password for each.  I'd actually rather
> use something like OAuth (or even Kerberos) that's designed for that -
> but where services provide a hook for some type of common
> authentication, it seems that most these days use LDAP (as opposed to
> anything else) to do it.


If you want Kerberos, then why not IPA?  It's built-into Fedora as well.

Even Debian has added the SSSD/IPA Client for easy-peasy setup, and there's
not a day that goes by that I don't see Ubuntu sysadmins recommending SSSD
and its plethora of modules instead of legacy modules (e.g., pam_ldap,
etc...).

Understand 389 and IPA conflict, so you have to choose one or another.
 I.e., IPA uses 389, but a different build (ipa-* packages, instead of
389-*).  And unlike 389, which is only in EPEL (since Red Hat offers
Directory Server with support/SLAs), the IPA Services are built into RHEL6
(Enterprise Identity Management, IdM [4]), and any EL Rebuilds (the
SSSD/IPA Client is in RHEL5.6+, but not the server, as it requires newer
389).

While you can modify IPA's schema, it's the same rule as AD, you want to
avoid it at all costs.  IPA is adding more schema for various POSIX
(UNIX/Linux) services.  You can manage sudoers and other things in the IPA
base schema.  You can also setup cross-forest trusts with IPAv3 between AD,
so Windows Servers in an AD domain (external Kerberos realm) of an AD
forest can access with their tokens (Kerberos tickets).

While general federation works with IPAv3-AD now (e.g., web services), the
SMB support for AD domains is still forthcoming -- i.e., Windows desktops
in an AD forst accessing Samba shares.  I.e., as of right now, Samba4 just
received the patch to enumerate multiple Kerberos realms via IPA (the IPA
team is offering to help the Samba team to the same for native Samba4 DCs).
 Long story short, IPA and Samba4 take completely different approaches to
AD integration.  Samba4 can work inside of a single domain as a DC, but has
some schema and other issues, whereas IPA takes the approach of a separate
forest.  I.e., POSIX and Windows schema will always differ, so Red Hat
decided a separate forest (which is required for AD forests themselves when
schema differs) is the more sustainable, supportable approach.

But I assume SMB is not of consideration in your case.


> So really, fixed schema is fine for the most part.


Then I'd really, really, _really_ look to IPA.  ;)

It's built-into RHEL6, so all EL Rebuilds based on EL6, that's the only
limitation.  It's based on 389 1.2 and newer MIT Kerberos code (among other
things), so you'll need to be RHEL6.

Only the SSSD/IPA Client is included with RHEL5.6+.  But once you go IPA,
you don't go back.  I.e., you don't have to understand LDAP or Kerberos to
manage IPA.

Ergo, hence why people call it the "AD of POSIX."


> There's some other information we might want to maintain in the
> directory if we were to do something like this (like, if we implement an
> online membership management portal, as long as the directory is already
> there, why not use that to maintain data rather than a separate
> database), but in most cases "uid" and "userPassword" are going to be
> the only attributes we really care about...
>

There's nothing stopping you from modifying the IPA schema.  But there is a
change for future conflict, just like with AD.

Instead, most enterprises would have a "flexible" LDAP "backend" where
"authoritative" information is always stored, and then "feed" down to
departmental/regional AD or IPA forests, where more information is
contained.

Even on my Fedora test system, the reason I didn't spend more time
> looking at 389 was basically, "Well, OK ... but how do I *start* the
> darn thing?"


Familiarity is always the problem.  I don't even recommend 389/RHDS to
non-Fedora/RHEL users.  But for Fedora/RHEL users, most definitely 389/RHDS.

Here's the breakdown of versions ...

Original AOL-Netscape iPlanet 7.1 (acquired by Red Hat 10 years ago)
(also available as Sun, now Oracle, Directory Server 7.1)
=> RHDS 7.1 (commercial product)
=> "Binary" Fedora Directory Server (FDS) 7.1 distributions

"Open source" 389 release 1.0
(iPlanet 7.1 nearly all open sourced + rewritten when could not + new
features/updates)
=> RHDS 8.x (commercial product w/Common Criteria config/certification)

"Open source" 389 release 1.2
=> RHDS 9.x (commercial product w/Common Criteria config/certification)
=> all IPAv2/v3 releases (built-into RHEL6)

As such, the Red Hat Directory Server documentation [5] usually applies for
the equivalent 389 release.  E.g.,
- RHDS 8.2 for 389 on RHEL5
- RHDS 9.2 for 389 on RHEL6

There will be slight differences in version, and Fedora/EPEL will be
slightly more leading-edge.  Plus there is the new 389 release 1.3, which
one could possibly assume might be the version that will be showing up in
RHEL-next as possibly a new RHDS-next.  ;)

In all honesty, if you can get to IPA, do so.  It's far more popular.  It's
also of the "killer app" services that everyone is excited about.  It's all
I use now, especially since admins don't have to know LDAP or Kerberos to
manage it.

You know, with just a tiny, basic config, to get
> bootstrapped with.  Both 389 and OpenLDAP seem to have this problem.


Which IPA solves nicely, because it gives a "fixed" schema (although new
versions add to it).

No site planning.  No customization.  Not that 389/RHDS isn't easy to
setup.  It's quite easy to deploy and bring up the GUI.  But planning tends
to get the better of people.

With IPA, there's really no planning.  It's, "you're going to get this
schema and you're going to like it!"

At least for proof-of-concept testing, and at least until I get my head
> wrapped around the innards of LDAP more, I was really looking for (in
> effect) "LDAP-in-a-box".  Something I could get at least a basic
> configuration on, and get it running, in just a few minutes, without
> having a whole lot of knowledge about LDAP or how it works inside - that
> was the primary goal.


That's _exactly_ what IPA is designed to do, once and for all.

No more LDAP internals, no more Kerberos internals.  At most, you'll need
to know the tree for a few things, but the IPA docs do a good job of
covering that integration.

Like I said, I would never recommend OpenDS for
> production use (due to the various problems that I mentioned), but it
> did meet the primary goal, and got me a "toy" LDAP server that I could
> poke around at and tinker with, and do some proof-of-concept testing
> with.  For "real" use, I'd take the data (and knowledge) gained from
> messing with this, and move it to something else (most likely OpenLDAP,
> given our CentOS environment).
>

I've dealt with 389/RHDS with millions of records.  It's well trusted on
RHEL.  Most organizations are not embracing Oracle LDAP to replace Sun DS,
and instead migrating to 389/RHDS (if they didn't years ago when iPlanet
was open sourced by Red Hat).

389 1.2 / RHDS 9 also ups the number of masters (per tree) to 20 from 4 --
although all 389/RHDS releases have unlimited, read-only consumers.  Best
Common Practice (BCP) is to dedicated 2-4 masters for a tree on one cluster
(usually over two sites), the tree that is most local to that deployments,
and then have all other sites as consumers, etc...

I know many people don't know anything but OpenLDAP, let alone many people
say 389/RHDS is "immature" (ha!).  But if you've been around iPlanet prior
to the Red Hat acquisition (or even post), it's quite the opposite.  It's
well trusted.  And if you're in a large enterprise or government, the
Common Criteria configuration is basically standard.

The same used to be with NSS v. OpenSSL until Red Hat put forth the effort
to get the latter compliant (and certified in Red Hat(R) products).  Now
with SSSD and newer Red Hat developments, it's all moot, as the OpenLDAP
client libraries and NSS/OpenSSL are basically equals.

If there were some kind of "canned" IPA installation I could get, that
> might also fit the bill - but IPA seems like a lot of overkill, for what
> we'd end up using it for...
>

IPA _is_ "canned."  ;)

Other than the colossal "dream" of IPAv1, which proved a "single schema"
between Windows and POSIX was impossible, IPAv2+ has been a total dream for
POSIX (UNIX/Linux) identity and select management.  Policies for sudoers,
SELinux and other things have been added.  More policies and auditing will
follow -- hence the name, Identity, Policy, Audit (IPA).

IPAv3+ adds more schema, along with cross-forest trusts with AD.  More and
more services will start to support IPAv3+'s trust model with AD, including
the required enumeration.  This goes along with other developments like
SSSD now being _superior_ to Samba Winbindd (better caching,
multi-domain/realm enumeration, etc...), the equivalent enumeration being
added to Samba 4.0.5+ (allowing multi-domain/realm, multi-forest trusts),
etc...

IPA is the future for the departmental ID and Policy Management server.
 LDAP will be regulated to when you need more flexible, differing schema
management -- much like Microsoft attempted with Lightweight Directory
Services (LDS -- basically Michigan LDAP built for Win32, without the AD
"canning" -- to solve differing schema between AD Forests).

-- bjs

[1] http://en.wikipedia.org/wiki/389_Directory_Server

[2] http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds

[3] https://access.redhat.com/support/policy/updates/directory/

[4]
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html

[5] https://access.redhat.com/site/documentation/Red_Hat_Directory_Server/


--
Bryan J Smith - Professional, Technical Annoyance
b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.wplug.org/pipermail/wplug-internet/attachments/20130617/03af820c/attachment-0001.html