<div class="gmail_quote">On Mon, Jun 17, 2013 at 2:33 PM, Pat Barron <span dir="ltr"><<a href="mailto:pat@lectroid.com" target="_blank">pat@lectroid.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">I have looked at 389, the reason I didn't look at it further is that the</div>
setup seems ... somewhat daunting.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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?</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The target environment for this is (eventually) WPLUG's own server, on<br>
CentOS 5.9.</blockquote><div><br></div><div>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 <a href="http://ftp.redhat.com">ftp.redhat.com</a> (Red Hat Directory Server) to get a full five-plus (5+) years of life cycle without rebasing. [3]</div>
<div><br></div><div>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 <a href="http://ftp.redhat.com">ftp.redhat.com</a> 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.</div>
<div><br></div><div>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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The application would be to provide a common<br>
identity/authentication framework for multiple separate services that we<br>
may want to deliver from that server, avoiding having to have a<br>
separately maintained username/password for each. I'd actually rather<br>
use something like OAuth (or even Kerberos) that's designed for that -<br>
but where services provide a hook for some type of common<br>
authentication, it seems that most these days use LDAP (as opposed to<br>
anything else) to do it.</blockquote><div><br></div><div>If you want Kerberos, then why not IPA? It's built-into Fedora as well.</div><div><br></div><div>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...).</div>
<div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div><br></div><div>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.</div>
<div><br></div><div>But I assume SMB is not of consideration in your case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So really, fixed schema is fine for the most part.</blockquote>
<div><br></div><div>Then I'd really, really, _really_ look to IPA. ;)</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div><br></div><div>Ergo, hence why people call it the "AD of POSIX."</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">There's some other information we might want to maintain in the<br>
directory if we were to do something like this (like, if we implement an<br>
online membership management portal, as long as the directory is already<br>
there, why not use that to maintain data rather than a separate<br>
database), but in most cases "uid" and "userPassword" are going to be<br>
the only attributes we really care about...<br></blockquote><div><br></div><div>There's nothing stopping you from modifying the IPA schema. But there is a change for future conflict, just like with AD.</div><div><br>
</div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Even on my Fedora test system, the reason I didn't spend more time<br>
looking at 389 was basically, "Well, OK ... but how do I *start* the<br>
darn thing?"</blockquote><div><br></div><div>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.</div><div><br></div>
<div>Here's the breakdown of versions ...</div><div><br></div><div>Original AOL-Netscape iPlanet 7.1 (acquired by Red Hat 10 years ago)</div><div>(also available as Sun, now Oracle, Directory Server 7.1)</div><div>=> RHDS 7.1 (commercial product)</div>
<div>=> "Binary" Fedora Directory Server (FDS) 7.1 distributions</div><div><br></div><div>"Open source" 389 release 1.0</div><div>(iPlanet 7.1 nearly all open sourced + rewritten when could not + new features/updates)</div>
<div>=> RHDS 8.x (commercial product w/Common Criteria config/certification)</div><div><br></div><div>"Open source" 389 release 1.2</div><div>=> RHDS 9.x (commercial product w/Common Criteria config/certification)</div>
<div>=> all IPAv2/v3 releases (built-into RHEL6)</div><div><br></div><div>As such, the Red Hat Directory Server documentation [5] usually applies for the equivalent 389 release. E.g.,</div><div>- RHDS 8.2 for 389 on RHEL5</div>
<div>- RHDS 9.2 for 389 on RHEL6</div><div><br></div><div>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. ;)</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">You know, with just a tiny, basic config, to get<br>
bootstrapped with. Both 389 and OpenLDAP seem to have this problem.</blockquote><div><br></div><div>Which IPA solves nicely, because it gives a "fixed" schema (although new versions add to it).</div><div><br></div>
<div>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.</div><div><br></div><div>With IPA, there's really no planning. It's, "you're going to get this schema and you're going to like it!"</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At least for proof-of-concept testing, and at least until I get my head<br>
wrapped around the innards of LDAP more, I was really looking for (in<br>
effect) "LDAP-in-a-box". Something I could get at least a basic<br>
configuration on, and get it running, in just a few minutes, without<br>
having a whole lot of knowledge about LDAP or how it works inside - that<br>
was the primary goal.</blockquote><div><br></div><div>That's _exactly_ what IPA is designed to do, once and for all.</div><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Like I said, I would never recommend OpenDS for<br>
production use (due to the various problems that I mentioned), but it<br>
did meet the primary goal, and got me a "toy" LDAP server that I could<br>
poke around at and tinker with, and do some proof-of-concept testing<br>
with. For "real" use, I'd take the data (and knowledge) gained from<br>
messing with this, and move it to something else (most likely OpenLDAP,<br>
given our CentOS environment).<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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...</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If there were some kind of "canned" IPA installation I could get, that<br>
might also fit the bill - but IPA seems like a lot of overkill, for what<br>
we'd end up using it for...<br></blockquote><div><br></div><div>IPA _is_ "canned." ;)</div><div><br></div><div>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).</div>
<div><br></div><div>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...</div>
<div><br></div><div>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).</div>
<div><br></div><div>-- bjs</div><div><br></div></div>[1] <a href="http://en.wikipedia.org/wiki/389_Directory_Server">http://en.wikipedia.org/wiki/389_Directory_Server</a><div><br></div><div>[2] <a href="http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds">http://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux#Rebuilds</a><br>
<div><br></div><div>[3] <a href="https://access.redhat.com/support/policy/updates/directory/">https://access.redhat.com/support/policy/updates/directory/</a><br><br>[4] <a href="https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html">https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html-single/Identity_Management_Guide/index.html</a><br>
<br>[5] <a href="https://access.redhat.com/site/documentation/Red_Hat_Directory_Server/">https://access.redhat.com/site/documentation/Red_Hat_Directory_Server/</a><br><br><br clear="all"><div>--</div>Bryan J Smith - Professional, Technical Annoyance<br>
b.j.smith at <a href="http://ieee.org" target="_blank">ieee.org</a> - <a href="http://www.linkedin.com/in/bjsmith" target="_blank">http://www.linkedin.com/in/bjsmith</a><br><br>
</div></div>