Re: Common Address Book

[J Michasel Gilks <mike@robres.com.au>]

I can't try to edit this post and leave any sense of it behind, so I
will just top post. Sorry.

This has been an excellent reply and explanation. Thank you very much.
I was getting confused thinking pam and ssl and all the rest of the
alphabet soup were needed by evolution to authenticate. between you and
Dieter Kluenter I now have a much better understanding of what is
happening.
For the authentication, I did have the correct dn entered, but first I
did not have the entry marked as
access by anonymous auth
which turns out to be rather important.
Then, and much more embarrassing, the scope of the search on evolution
was one, not sub, which meant the search could not delve deep enough
into the directory to authenticate.
I can now authenticate my users to evolution, getting it to display my
entries is the next challenge. I think this is to do with the fact I
have not filled in any of the evolutionperson.schema entries yet. Here's
hoping anyway.

I would like to extend a big thank you to everyone who has helped me
with this problem of understanding I have suffered.

Love
Mike.

On Mon, 2003-11-17 at 20:43, Andrew Findlay wrote:
> 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