[Novalug] Monthly Plea

Bryan J Smith b.j.smith@ieee.org
Thu May 28 13:44:01 EDT 2015


On Thu, May 28, 2015 at 11:23 AM, Walt Smith via Novalug
<novalug@firemountain.net> wrote:
> I've heard of 389 only because every 6 months
> I do some CentOS updates and there is a 389 file,
> sitting at the top of the file list in the mirror.
> I've seen it for a year or 2 ?
> It's not on my machine, and I haven't a clue
> what it means.  Secret code ? Pin number ?
> Star Wars outpost ?
> never heard of iplanet.

Short version:

The 389 Server's history is the commercial lineage of the original
Michigan LDAP development, spearheaded by Netscape, also leveraged and
developed by Sun (iPlanet), sold to Red Hat in 2004, fully open
sourced by 2005.

The Identity, Policy, Audit (IPA) Solution is to not only provide a
"canned" solution for POSIX (UNIX/Linux) systems and services that
doesn't require someone to know LDAP, Kerberos, etc... internals, but
to also use ActiveDirectory (AD) Forest Trusts to allow IPA domain
users to access Windows Server resources, and AD domain users to
access Linux Server resources.  All while only IPA admins manage Linux
groups/servers and only AD admins manage Windows gropus/servers, with
each being in control of allowing the other to access theirs -- e.g.,
which AD Security Groups are assigned to which IPA Groups that access
Samba Shares.


Longer chronology, In bullets ...

Early to mid '90s ...
- Illinois (NCSA) created Mosaic (web browser)
- Andresseen et al. (Netscape) brought over most of the developers
- iPlanet project starts in 1994 to develop a directory server
(ironically doesn't secure the trademark, long story)
- Michigan develops LDAP, a lighterweight solution than full X.500 DAP
- Netscape quickly realizes they needed a directory server, to
complement their web server, an dother efforts
- Beyond network authentication and objects, it could store their
sprawlilng set of "Communicator" (web, mail, calendar, etc...) client
profiles**
- Netscape hires a number of the former Michigan developers from LDAPv3

**HISTORICAL NOTE:  Some of us were doing this _before_
ActiveDirectory could with Internet Explorer.  Microsoft didn't invent
this idea.  ;)

Mid '90s to '00 ...
- Sun, looking to move away from NIS+, actually registers the iPlanet trademark
- By 1998, Netscape and Sun start a 4 year collaboration effort
(cross-license, etc...) on directory services using the iPlanet
trademark
- In 1998, with the popularity of the commercial iPlanet solution for
UNIX/Linux, the OpenLDAP project is founded as an open source option
-- using the same Michigan LDAP code in the public domain that
Netscape and even Microsoft is using**
- Late 1998, AOL buys Netscape, some believe it's for more than just
the client software, but also the extensive server software which is
being heavily adopted by enterprises, government and other
institutions, especially for certificate management as much as
directory server
- In 1999 Microsoft releases Windows Server 2000 with ActiveDirectory,
which is a "canned" LDAPv3 (from the Michigan code), Kerberos (from
MIT, although Microsoft would violate the agreement until lawyers
finally get them to release the documentation on the extensions by
2001)

**HISTORICAL NOTE:  Despite popular rheteroic, Microsoft used the
legally obtainable, public domain, Michigan LDAPv3 code, just like
Netscape (although Netscape hired many of the developers, just like
they did NCSA's Mosaic developers for the web broswer).

Early to mid '00s ...

- In 2002, the iPlanet colloboration effort ends, and AOL-Netscape and
Sun go their separate ways
- In 2004, Red Hat acquires all AOL-Netscape assets related to
Directory, Certificate and other services.  iPlanet Directory Server
and Certificate System version 7.1 is rebranded Red Hat Directory
Server 7.1
- By 2005, using its newer trademarked "community" brand "Fedora," Red
Hat releases Fedora Directory Server (FDS), along with Dogtag
(Certificate), version 1.0, which is a "clean" version of iPlanet with
either all IP secured for BSD/MPL/GPL release, or the few components
Red Hat could not being re-written as MPL/GPL.  Red Hat Directory
Server 8.0 is based on the "clean IP" FDS 1.0.
- Other iPlanet technologies not adopted in FDS are also released as
open source if possible, but not developed further (e.g., some Proxy
solutions).

Post-mid '00s ...
- Citing complaints from other distributions, Red Hat drops its use of
its "community" trademark Fedora and uses a number instead, which
cannot be trademarked, 389 Server
- 389 Server 1.2 is developed and released.  One of the biggest
changes with 1.2 is that it now uses OpenLDAP client and libraries by
default (which Red Hat heavily helps develop and mature), the Netscape
Security Servers (NSS) are segmented

Furthermore, SSSD/IPA of '07+
- The Enterprise Identity, Policy, Audit (EntIPA) project is by Red
Hat to explore building a "canned" directory server with many members
from various, Upstream projects (e.g., Samba, OpenLDAP, nscd, etc...),
using 389 and MIT Kerberos.
- EntIPA 1.x released in 2008 for RHEL5 has many issues because it
favors NTuser attributes, which doesn't work well for legacy UNIX, and
Red Hat abandons the idea of making a server work in an AD domain
- FreeIPA is the resulting, Upstream Project from the initial effort,
and Red Hat et al. go a completely different route.  Version 2 will
implement a true POSIX attribute base.
- The System Security Services Deamon (SSSD) project starts to address
various issues, from the legacy of pam_* modules that are out of
compliance and using legacy OpenLDAP library code, to integrating a
more deterministic caching solution built-in to the core, instead of
the separate Name Services Caching Daemon (ncsd) and, eventually, even
Winbindd.  The solution will provide a single set of NSSwitch and PAM
services ("sss"), with modular "providers."
- The IPA Client leverages SSSD for easy, automated setup, while
Fedora/RHEL "authconfig" can setup SSSD for other services (LDAP,
Kerberos, etc...).
- The other, initial capability in SSSD is the full LDAP support (NSS,
PAM, etc...) to read and use IETF RFC2307 POSIX attributes (aka IdM
for UNIX) in ActiveDirectory, so AD can be used as a centralized store
for Linux, a component severely lacking and requiring a lot of hacks.
- Fedora and RHEL 6 includes SSSD by default, and it is backported to
RHEL 5.7, with 6.1 getting IPA v2 (known as Enterprise Identity
Management, IdM, in RHEL).
- Various fixes occur and RHEL 6.2 and 5.8 become well-known for SSSD
"just working better" -- especially better than nscd
- FreeIPA Version 3 is designed to emulate the interfaces (Global
Catalog, Security IDs, etc...) of a separate, AD Forest, which then
another AD Forest can trust.  This is no different than how AD itself
works, which requires separate AD forests if the LDAP schema do not
match (which many Windows departments cannot agree upon).
- SSSD adds not only a replacement for Winbindd, but more importantly,
multi-domain AD UID/GID enumeration, something Winbindd cannot offer.
This is required for IPA domains to interface with AD Forests, and
similar patches are made to Samba for future integration.

So this is where the world is changing ...

- While you can put Samba servers in an AD domain, there are many
complications and limitations to do so ... especially with the common,
multiple domains in -- let alone to an external -- AD Forest
- The biggest problem with Linux in AD domains has always been the AD
administrators who are ignorant of POSIX, don't even populate the
POSIX attributes, and otherwise forces Linux admins to have to locally
enumerate the UID/GIDs and store, in a separate directory, homedir and
other attributes
- Separate AD Forests are used when the LDAP schema differs, which is
common with Windows companies, especially during acquisitions or as
divisions have maintained their own AD or just -- often flat out --
disagree
- IPAv3, which has a different base schema than any AD (POSIX v.
NTuser), solves so many issues by just emulating some of the features
of an AD Forest, enumerating its own Security IDs and providing a
Global Catalog of resources

So ... stepping back and looking at NT/Windows ...

The biggest issue is really AD with itself here, which IPA starts to
solve nicely.

For anyone who does AD, you know you _must_ separate Domain Local
Groups from Security Groups.  Why?  You _must_ put only groups local
to the domain on domain resources, otherwise you have SID issues.
Long story, but it's a design flaw in how NTFS was designed with SIDs,
can cause corruptions, the whole reason for the system accounts
manager, SAM, in the registry to become network-wise -- ergo, NTuser
schema.

So ...

- You put Windows servers in AD domains
- You _always_ assign Domain Local Groups (DLGs) to the Windows Server
resources of the same AD Domain
- You assign local Domain Users to [domain] Security Groups
- You _always_ assign [domain] Security Groups to another domain's
DLGs for access to those server resources local in that domain (with
the DLGs)
- You _never_ assigning one domain's Security Groups directly to
another domain's Windows Server resources, _always_ use a DLG (there
are exceptions, but this is the safest rule)
- And you make AD Forest trusts so you can have different AD Forests
use each others groups
- Because an entire AD Forest of AD domains ("trees" of domains,
logically speaking) _must_ have the same AD (LDAP) schema

Correspondingly ...

- You have an AD Forest trust between IPA Domains and AD Forests
- You put IPA Groups in an AD domain's DLGs to access Windows Server resources

And, going the opposite way ...

- You assign IPA Groups to Linux Server resources (e.g., Samba shares,
NFSv4/Kerberos secured exports, etc...)
- You put AD domains Security Groups in an IPA Group for access to
those Linux Server resources

SIDE NOTE:  Yes, you can put an AD Domain's Security Group directly on
a Samba share because, unlike Windows Server with native NTFS that
doesn't like (i.e., can corrupt, especially in older Windows Server)
SID Access Control Entries (ACEs) outside it's domain.  But the best
solution -- and one AD administrators are familiar with -- is to only
put IPA Groups on Linux resources, and then assign those external, AD
Forest trust AD domain Security Groups into IPA groups.

This of course requires nested groups aka IETF RFC2307bis, which IPA does.

> Still don't know what IPA is...
> OK, OK, I'm being non-retentive... I suppose
> I could google it, but getting a meaningful
> answer isn't likely. LDAP neither, although I
> may have a general notion of *it* based on
> years of reading the maillist ( not for content,
> clearly ;-)   ).

Welcome to the 21st century, where everything has been LDAP for a long
time, and Microsoft AD is not the end-all, be-all solution, far from
it.  ;)

Again, I've even implemented AD Lightweight Directory Services (LDS).
What is that?  It's basically a full, generic implementation of
Michigan LDAPv3 adopt of Win32, and actually has little to do with AD,
other than allowing for basic exchange.  And don't get me started on
Federation Services ... ADFS is basically .NET-only, despite
marketing.  ;)

-- bjs



More information about the Novalug mailing list