[19087] in Kerberos
Re: Kerberos Backend for LDAP
daemon@ATHENA.MIT.EDU (Booker Bense)
Wed Apr 16 17:58:58 2003
Date: Wed, 16 Apr 2003 14:57:56 -0700 (PDT)
From: Booker Bense <bbense@SLAC.Stanford.EDU>
In-reply-to: <3e9db47c@news0.ucc.uconn.edu>
To: Matthew Smith <matt@forsetti.com>
Message-id: <Pine.LNX.4.51.0304161431010.26084@telemark.slac.stanford.edu>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=US-ASCII
Content-transfer-encoding: 7BIT
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
On Wed, 16 Apr 2003, Matthew Smith wrote:
> Booker Bense wrote:
>
> Disclaimer: I will admit, right off the bat, that I am not very familiar
> with OpenLDAP.
> If there was a back-krb5 for OpenLDAP, would an unmodified slurpd be
> able to replicate the krb info, since slurpd just sees it as LDAP info?
- I would have to double check to make sure, and it would depend
on exactly how back-krb5 was written, but I don't see any obvious
reason why not. Clearly, there is a certain level of paranoia
about putting private keys on the wire that is necessary to
overcome. IMHO, the hard part of back-krb5 would be capturing the
necessary ACL data.
> Does slurpd use the LDAP interface for obtaining data to replicate, or
> does it tie in somewhere behind the scenes?
>From the man page:
Slurpd is used to propagate changes from one slapd
database to another. If slapd is configured to produce a
replication log, slurpd reads that replication log and
sends the changes to the slave slapd instances via the
LDAP protocol. slurpd is typically invoked at boot time,
usually out of /etc/rc.local.
- You'd want to take a hard long look at the replication log and
make sure you understand the total data path if you're really
going to sync keys this way. Openldap has changed a lot since
I looked at this part of the code, but there is definitely an
issue here with storing the cleartext key vs. a key encrypted
with the KDC master key. The whole issue of setting/changing
passwords via an LDAP admin interface is also somewhat complex.
Ideally, you'd want neither the password nor the resulting key
to ever reside anywhere but in memory in unencrypted form.
The conservative approach would be to not allow password
changing/setting via ldap at all.
- Booker C. Bense
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
