Under LDAP, the user exchanges a token (just like cookies), so they triangulate with the server. But it's not "secure" any more than lock boxes are to physical home security where the combination can be easily obtained. If/when you install the recent OpenLDAP, the cilent obfuscates it's key via encryption that authenticates against either the server on Linux (kerberos) or via the AD in Windows server model.
Kerberos doesn't protect anything in LDAP over and above the standard password hash key exchange.
In the case of SASL/GSSAPI, the client and server participate in
mutual Kerberos authentication exchange requiring each to obtain
appropriate tickets from the KDC. See a site about Kerberos for details.
One can configure saslauthd to verify a user's password,
provided by the client to the server via SASL/PLAIN,
LDAP simple bind, etc., against Kerberos credential information
maintained by the KDC. This is NOT Kerberos authentication.
This is password authentication.
Use of the latter violates the Kerberos security model as
it, amongst other things, exposes the user's password to the
server (and, if you don't adequately protect the LDAP bind
request, the world).
Note that this discussion is not really OpenLDAP-specific,
say applies to any application protocol server configured
to verify user passwords in this manner instead of using
a Kerberos-based authentication mechanism of that
protocol (SASL/GSSAPI in the case of LDAPv3).
OpenLDAP as a protocol is completely drop and designate in and of itself (using PAM/kerberos in linux). Where access to the server token and client tokens are available it is a fairly open door.
You can intercept and decrypt the key exchanged ciphers with John/Crypt for regular user administration with access to the hash also.
www.Obnosis.com |
http://en.wiktionary.org/wiki/Citations:obnosis | (503)754-4452
January PLUG HackFest = Kristy Westphal, AZ Department of Economic Security Forensics @ UAT 1/10/09 12-3PM
> Subject: Re: ****Re: ****Re: Linux Administration - Users in (any) database howto/why...
> From: craigwhite@azapple.com
> To: plug-discuss@lists.plug.phoenix.az.us
> Date: Fri, 2 Jan 2009 17:40:17 -0700
>
> On Fri, 2009-01-02 at 16:40 -0700, Joe wrote:
> > Good point on TLS. The /etc/ldap.secret is where I had the problem. If
> > you put that file on an end users machine, wouldn't they be able to boot
> > into single user mode or sudo and read that file? Doesn't that file
> > provide the keys to the kingdom? Once you have full read access to the
> > directory. can't you read all the user id's and hashes and gain access
> > to every other system? Sorry if this was already a hackfest activity and
> > I missed it.
> ----
> and I should mention that if you want to get around that issue, you
> implement kerberos in addition to LDAP.
>
> Craig
>
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
_________________________________________________________________
Life on your PC is safer, easier, and more enjoyable with Windows Vista®.
http://clk.atdmt.com/MRT/go/127032870/direct/01/---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss 
(text/plain)