Re: Common Address Book

[Andrew Findlay <andrew.findlay@skills-1st.co.uk>]

On Mon, Nov 17, 2003 at 07:02:48AM +0800, J Michasel Gilks wrote:

> Still here and still trying.
> I have added the evolutionperson.schema to the directory and updated the
> user password using slappassword to generate the password and ldapmodify
> to insert it into the directory.
> Unfortunately this has brought some strange authentication stuff with
> it.
> From the command line I can now see everything in the directory by
> entering a blank password, although this is probably because of the ACL 
> access to * by * read
> However if I enter a password for my user, call him mike, I get the
> message 
> ldap_bind: Invalid credentials

It seems likely that you are using the wrong parameters to specify
the user to the client software.

As Luca Scamoni said earlier, you also need to understand the
difference between TLS/SSL and SASL. Let's start with SASL:

	SASL is the Simple Authenticatiuon and Security Layer.
	When used in OpenLDAP it is implemented with the Cyrus SASL
	library. SASL provides a range of high-security authentication
	methods. If you want to use it you should read Chapter 10 of
	the OpenLDAP admin guide:

	http://www.openldap.org/doc/admin21/sasl.html

	However, before going into that level of complexity, I would
	first consider whether you really need high security for your
	read-only clients. Do you need any at all? Directories tend to
	mostly hold public-knowledge info, and are there to make it
	widely available. If you don't need to protect the data from
	being read then don't bother with client usernames and
	passwords at all.

	When doing data updates you probably do want more security.
	SASL is one way to provide this, but in the simple case it
	stores usernames and passwords *outside* the directory. If
	this is acceptable, try creating a SASL user (do this as root):

		saslpasswd2 -c fred

	Note that your slapd process will have to run as root to be
	able to read the SASL database. You should now be able to
	authenticate using parameters like '-U fred -W' on the
	ldapsearch commands etc.

	Even having got this far, there are more things to understand
	about SASL before you can deploy it widely. I would advise
	avoiding it until you understand the rest.

Now let's look at TLS/SSL:

	Transport Level Security is the newer form of Secure Sockets
	Layer. It is a service that can be negotiated on top of a
	basic LDAP connection to provide encryption and
	authentication.

	In the most common usage, an X.509 certificate is generated
	for the LDAP server so that clients can verify that they have
	contacted the real server and to allow encryption to be set
	up.

	TLS can also do authentication. I suggest ignoring this for
	now.

And finally, authentication:

	Assuming you are not going to use SASL (which many
	non-OpenLDAP LDAP clients don't support anyway), that means
	that you will be using some variation on 'simple bind'.

	OpenLDAP clients default to using SASL (which is the correct
	behaviour defined in the standard) so if you don't intend to
	use it you must always use the -x flag on OpenLDAP commands.

	Now you need to make some usernames and passwords. The
	important thing to note here is that usernames are DNs
	(Distinguished Names). Thus, you might have a username
	'cn=readonly, o=megacorp, c=au' which is represented by an
	entry in the Directory. To bind as that user and do a search,
	use a command like this:

	ldapsearch -x -D 'cn=readonly, o=megacorp, c=au' -W -b 'o=megacorp, c=au' -s sub 'objectclass=*'

	Note the use of -D to introduce the username.

	Under this scheme, all usernames are part of the Directory
	data. The only exception is the directory manager which can be
	specified in slapd.conf directly and does not have to be in
	the Directory itself.

> Evolution will not accept the blank password and continues requesting a
> password until I cancel the message box.
> One more thing I just noticed, the userPassword reported from the
> command line is different to the userPassword being shown in GQ.

It may be that GQ is decoding the Base64 format. If the command-line
tools show an attribute name followed by *two* colons then the data is
Base64 encoded. Use the attached script to decode it.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------

#!/usr/bin/perl -w
#
# decode-base64

use MIME::Base64;

while (<>) {
	chomp;
	my ($res) = decode_base64($_);
	print $res;
	print "\n";
}