Differences between version 4 and predecessor to the previous major change of SASLNotes.
Other diffs: Previous Revision, Previous Author, or view the Annotated Edit History
| Newer page: | version 4 | Last edited on Monday, November 29, 2004 1:38:51 pm | by AristotlePagaltzis | Revert |
| Older page: | version 1 | Last edited on Sunday, March 9, 2003 7:20:03 pm | by DanielLawson | Revert |
@@ -23,4 +23,39 @@
* edit the SPEC file (/usr/src/redhat/SPECS/openldap2.spec or whatever)
* and change --with-cyrus-sasl to read --without-cyrus-sasl, and also remove the --with-spasswd directive (this depends on cyrus-sasl.
* change the version number of the rpm so that it wont be overridden
* run rpm -bb <SPECFILE> to rebuild
+
+----
+The thing about [SASL] is that it sounds like a really really good idea. The bad thing about [SASL] is that it's a [PITA]. My biggest beef with [SASL] is that by default it doesn't do anything sane (like use [PAM] or /etc/passwd), it tries to use /etc/sasldb (or /etc/sasldb2 depending on the version of sasl). Of course when you first start looking at [SASL] you won't have anything in this file, so you won't be able to authenticate. Sigh.
+
+----
+
+You'll need to make sure you have [SASL] modules installed, if you don't, [SASL] will just fail. Sigh. Under debian you'll need libsasl2-modules at least, perhaps also libsasl2-gssapi-mit, libsasl2-krb4-mit, libsasl2-modules-gssapi-heimdal, and/or libsasl2-modules-kerberos-heimdal, but probably not.
+
+Now you can set a password for a user, use:
+ /usr/sbin/saslpasswd2 ''username''
+now you should be able to authenticate using [SASL]. [SASL] will of course try and use the most secure authentication mechanism it can. This probably means that behind the scenes it will go off and do challenge response, and other magic. Good luck :)
+
+----
+
+To get [SASL] working with [LDAP] apparently you need:
+ access to attr=supportedSASLMechanisms,entry,objectClass
+ by anonymous read
+ by * read
+in your slapd.conf, preferably before any other access directive. For more information about ldap access directives see [LDAPNotes].
+
+----
+
+[SASL] stores passwords in /etc/sasldb and/or /etc/sasldb2 by default. Why it doesn't it do it somewhere in /var like it should is anyone's guess. However this means that /etc will have to be writable. Passwords are stored in these files __in plain text__, so make sure your permissions on them are correct. You can disable this by providing the -n parameter to saslpasswd2. You have been warned.
+
+----
+
+[SASL] has the concepts of realms. A "realm" is authentication mechanism dependant, but the general idea is that it works like a kerberos realm. By default you'll be using the realm which is the same as your hostname. If you're authenticating against a different host, make sure your realm is right or it isn't going to work.
+
+----
+
+[SASL] allows one user to authenticate on behalf of another user. I have no idea why on earth it supports that or why you'd practically want to use it, but it does support it. It calls this an authorization identity.
+
+----
+
+[SASL] sounds like the only reason you'd even consider it is if you're using Kerberos, although, in the case of Kerberos, it sounds like it will work really well. [YMMV]
