[wplug-internet] Another LDAP server to tinker with

[Bryan J Smith]

Pat Barron <pat at lectroid.com> wrote:

> This is all really good information - I appreciate that you took the
> time to share it!  As you can tell, I'm a relative newbie to LDAP. So
> the more help I can get, the better... ;-)
>

I'm used to the overlooking of 389/RHDS and the newer development of
IPA/IdM.  It's common.  From a compliance (and certification in Red Hat(R)
product) standpoint, it used to hurt organizations (don't get started).**

Regardless of your LDAP interface (e.g., OpenLDAP, 389, IPA, AD, etc...),
for Apache and other services, you will still need to deal with knowing the
tree and other references.

However, having built-in platform authentication with IPA (Kerberos or
LDAP) certainly helps -- e.g., your web server already being a configured
IPA client.  There are caveats to using Kerberos though.

E.g., you can setup browsers with native Kerberos pass-thru.  But that's
not always straight-forward for users.  So if you use password hashing
(e.g., MD5 or SHA256), and then use Kerberos on the back-end, the "weakest
link" is that hash negotiation.

I'm going to set up a test VM running CentOS 6 (just to make things
> easier) and try to make it go.


Despite common FUD, RHEL6 is a _fine_ Xen paravirt or fullvirt guest on
RHEL5.  Red Hat will continue to support Xen hypervisors until at least
2017 (possibly longer via ELS) in RHEL5, and Xen guests until at least 2020
(possibly longer via ELS) in RHEL6.

So you can run RHEL6 on RHEL5's Xen (or KVM) hypervisor.

Just on a lark, I did "yum install ipa-server" on one of my test boxes at
> work,

and it was cool with that.  Of course, it also wanted to pull in 57 other
> packages

, but what can you do... ;-)
>

IPA/IdM is the uber-integration of 389 (LDAP), Kerberos (MIT), Dogtag
(Certificate), NTP, DNS, etc...

One thing I will warn you about is that if you setup IPA in a VM, do _not_
use it for NTP or you will get skew (bad enough in Xen/KVM, and horrendous
in latency-hell VMware).  Use the --no-ntp option as recommended in the
documentation. [1]

You still need NTP (Kerberos required same time on all systems, within 5
minutes or so), but setup your host to provide it to your VMs, and sync
your host with another server.

I would like Kerberos - biggest problem is, I can't think of anything
> we'd want to deploy (mostly web-based applications), that could actually
> use Kerberos...


Again, catch-22.

To get "real Kerberos," your browser _should_ be passing your credentials
via GSSAPI from the platform (more info follows).

Otherwise, you're just using Kerberos on the "backend" (web server to KDC),
and the web browser to web server is _not_ using Kerberos, but a hash or
similar authentication (possibly clear text, even if SSL encrypted).

For "real Kerberos" ...

This typically meant /etc/krb5.conf, a system keytab, an user kinit,
etc..., which means platform configured for the Kerberos realm.  In the
case of IPA, that means your system is an IPA client to an IPA server.
 Interchange "domain" for "realm" as you wish -- i.e., Kerberos Realm ~ IPA
or AD domain.

However, with the newer "realmd" option in GNOME 3+ (among other desktop
environments Red Hat et al. is configuring realmd support for in, like
KDE), it's possibly for the platform to not be setup with a Kerberos realm,
but the user session in the GUI having a Kerberos ticket that is passed
through the browser.  No separate kinit required, it's part of the login
thanx to realmd.  ;)

-- bjs

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

**P.S.  Luckily, as of 389 1.2 (circa 2010+), Red Hat has really supported
a lot of OpenLDAP and OpenSSL lib/client developments, so Netscape Service
Services (NSS) from the iPlanet codebases are optional.  This includes in
the System Security Services Daemon (SSSD), which leverages the newer
codebases.  Everyone should be using SSSD in Fedora/Red Hat, and seriously
consider such in all distros, especially given its augmented capabilities
(e.g., many ways, and better support of AD), caching and migration (e.g.,
authenticate against AD, migrate credentials to LDAP -- especially when AD
doesn't have IdM for UNIX schema), newer OpenLDAP/OpenSSL than legacy
modules (e.g., pam_ldap -- everyone should stop using it ... as of 2010 ...
IMHO ;), etc...




--
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/58db9ddb/attachment.html