[27250] in Kerberos
Re: LDAP KDB
daemon@ATHENA.MIT.EDU (Matthew J. Smith)
Wed Jan 24 09:10:04 2007
From: "Matthew J. Smith" <matt.smith@uconn.edu>
To: kerberos@mit.edu
In-Reply-To: <45B68E08.5040702@dlconsulting.com>
Date: Wed, 24 Jan 2007 09:09:40 -0500
Message-Id: <1169647780.6555.11.camel@localhost>
Mime-Version: 1.0
Reply-To: matt.smith@uconn.edu
Content-Type: multipart/mixed; boundary="===============0286374127=="
Errors-To: kerberos-bounces@mit.edu
--===============0286374127==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="=-2EHsK0NSHGSLsjeSHUte"
--=-2EHsK0NSHGSLsjeSHUte
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Along the same lines, I find my comfort level much higher using MIT
Kerberos as a security mechanism, and separately OpenLDAP (or any LDAP)
as a directory server. Using a large piece of software originally
designed, built, and optimized for directory services as a security
mechanism seems dangerous to me, compared with using software designed,
built, and optimized from the ground up as a security mechanism.
However, conversely, I would love to see a LDAP replacement for the
kadmin protocol. I am not looking for an LDAP implementation worthy of
being called a true directory server, but rather simply a GSSAPI
authenticated, TLS protected, LDAP enabled interface for
adding/removing/managing users/acls/policies within the existing
Kerberos database.
I pondered a back-kadmin for OpenLDAP for a while, but my C skills are
rather rusty. Has anyone else considered this path, or is it just a bad
idea?
Just my $0.03,
-Matt
On Wed, 2007-01-24 at 11:36 +1300, Edward Murrell wrote:
> Possibly wandering off topic here, but I feel it's worth mentioning;
>=20
> Having used OpenLDAP and Kerberos, I must say that I wouldn't do this.
> I can see why people would want to, but my experience with the two bits o=
f
> software has left me with a sour taste when it comes to OpenLDAP,
> especially with regards to replication.
>=20
> Granted, most of the problems seem to have been caused by either the BDB
> backend on OpenLDAP, or my own damn fault (schema problems, improper
> copies of replication data, flat out bad configuration, etc), but I have
> actually yet to break MIT KRB5, despite the weird and wonderful setups I
> have pushed through it, whereas OpenLDAP seems to fall over at the drop
> of that hat (or worse yet, half falls over, and doesn't tell you). Maybe
> I've done something wrong, but the fact that I've had to recreate my
> LDAP database at least five times in the past two years has left me a
> little hesitant about it.
>=20
> In any case, I'd thought I'd put a note here. If you're planning a new
> installation from scratch, using the KDB Kerberos in LDAP method...
> Don't. In fact, while I'm on this topic, my recommendation is to set
> things up in the following order;
>=20
> DNS
> Kerberos
> LDAP (using Kerberos for authentication of replicas).
>=20
> Regards
> Edward Murrell
>=20
> Ken Raeburn wrote:
> > On Jan 22, 2007, at 4:39, Enrico M. V. Fasanelli wrote:
> > =20
> >> Dear Kerberos/LDAP gurus
> >>
> >> I've seen that the 1.6 MIT release includes support for storing the =20
> >> database into an LDAP server.
> >>
> >> My apologies for the dummy question, but what are the advantages of =20
> >> putting the database into LDAP?
> >> =20
> >
> > Integration with other LDAP-based account administration, especially =20
> > if Kerberos is being added to an environment already using LDAP; =20
> > automatic and immediate synchronization between all KDCs and kadmin =20
> > servers and password-change servers as changes are made....
> >
> > Ken
> >
> >
> > ________________________________________________
> > Kerberos mailing list Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> > =20
>=20
> ________________________________________________
> Kerberos mailing list Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
--=20
Matthew J. Smith <matt.smith@uconn.edu>
University of Connecticut UITS
--=-2EHsK0NSHGSLsjeSHUte
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQBFt2ikUtSvppOnag8RAqVZAKCNBH3iRkc61yHlAWVtDm7qDShz0ACfXa4p
grPthqAxYJol9dqlZvs4ZLQ=
=O+D/
-----END PGP SIGNATURE-----
--=-2EHsK0NSHGSLsjeSHUte--
--===============0286374127==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============0286374127==--
