Exim4 and Saslauthd [service=]

Hello! Since I upgraded g00se.org from Debian Sarge to Etch the authentification mechanism of my exim mail server doesn't run properly. I used as I descriped early the saslauthd to authentificate against the pam. Everything went fine. I believed, but a few weeks later (I used all the time my webinterface to send mails.) the exim couldn't use the same credentials as the imap server. The saslauthd always claimed that my credentials are false and so exim awnsered with a SMTP Error 535: Authentification failure. Tonight I managed to look into the problem and it's source. I checked the saslauthd using testsaslauthd. If I used: testsaslauthd -s smtp -u XXX - p XXX everything went fine and the saslauthd replied with credentials ok. But if I issued testsaslauthd -s "" -u XXX - p XXX I got a pam authentification error. I tried the same using exim and same behavior appeared, exim doesn't set the name of the service and so all authentification will fail. The problem is that the saslauthd will try to authenticate against a pam configuration which is not available. Note: I have in /etc/pam.d/ a file called smtp which defines the pam behavior for my smtp service ;). The messages (/var/log/auth.log): Dec 3 00:55:50 h1206589 saslauthd[22244]: do_auth : auth failure: [user=XXX] [service=] [realm=] [mech=pam] [reason=PAM auth error] Dec 3 01:18:45 h1206589 saslauthd[22247]: do_auth : auth success: [user=XXX] [service=imap] [realm=] [mech=pam] As you can see the name of the service is in the first log empty. I found a solution you can tell the exim how to call the saslauthd (Snip of the authentification part of my exim service): plain_saslauthd_server: driver = plaintext public_name = PLAIN server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}} server_set_id = $auth2 server_prompts = : .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif login_saslauthd_server: driver = plaintext public_name = LOGIN server_prompts = "Username:: : Password::" # don't send system passwords over unencrypted connections server_condition = ${if saslauthd{{$auth1}{$auth2}}{1}{0}} server_set_id = $auth1 .ifndef AUTH_SERVER_ALLOW_NOTLS_PASSWORDS server_advertise_condition = ${if eq{$tls_cipher}{}{}{*}} .endif Now tell exim that he have to use a service for saslauthd change: server_condition = ${if saslauthd{{$auth2}{$auth3}}{1}{0}} into server_condition = ${if saslauthd{{$auth2}{$auth3}{smtp}}{1}{0}}. smtp have to be the name of the pam configuration file. That's all. Everythings work as expected.

JOptionPane and the Focus

I started to write a login screen (NEED: two input field [username, password]and two buttons [ok, cancel]). Since a login is a blocking panel I created a JPanel and put that on a JOptionPane.showDialog(...). Everything looked quite fine, but the default focus was set on the OK-Button. So I tried to requestDefaultFocus, but nothing worked. Mark provides a running solution. And it works!

WebSVN vs. ViewCVS

Tonight I removed ViewCVS and started using WebSVN. It's nice simple and in PHP :D... Take a look!

Java Base64 encoding (sun.misc.Base64Encoder)

Today I would like to say some words about BASE64 encoding and JAVA. Let me introduce a cool class to encode a string: sun.misc.Base64Encoder
This class seams to work quite all right for some weeks. So, today we transfered our JEE server from a linux to windows (not my idea). Till now I have assumed that the mythos of the JAVA plattform independence is not only a myth. During the check of the application (the deployed JEE project) it showed up error messages that the base64 coded strings doesn't match.
On the first look everything seemed to be fine. The second showed up that the strings on the windows machine were one (!) character longer. Two hours later we found the problem: Does RFC 3548 say something about line feeds and carriage return?
So why does the base64 coded strings contain some?
The anwser is: Because the encode method of the Base64Enconder split the string after some characters (I suppose at char 76 / 77, but I'm not quite sure). So if you switch the operation system and the new system uses another encoding for the line break, your old base64 encoded data is worthless.
To solve this problem I used the java mail api (cause JEE server needs to implement these):

StringOutputStream output = new StringOutputStream();
OutputStream encoding = MimeUtility.encode(output, "base64");
encoding.write("Hello World");
result = output.toString();

import java.io.IOException; import java.io.OutputStream;
/** * * @author Dennis Guse * */
public class StringOutputStream extends OutputStream {
  private StringBuffer data = new StringBuffer();
  public StringOutputStream() {}
  public String toString() {
    return data.toString();
  }
  public void write(int b) throws IOException { data.append((char)b); } }

So a half day of work for nothing....
PS: Feel free to use this stuff.

Authentification Server via Kerberos (Heimdal) and LDAP backend

Today morning I configured heimdal KDC and as storage the openldap slapd. Slapd stores the user information and holds the kerberos authentification information. The public URI is ldaps://g00se.org. Kerberos realm: G00SE.ORG. KDC: g00se.org The openldap server uses TLS and authenfication and authorisation with the SASL GSSAPI (package (debian): libsasl2-modules-gssapi-heimdal). First I installed slapd (slapd and the above package). Added the krb5-kdc.schema. Configurated SASL support and added authorisation rules. With slapadd -f "backup.ldif" I installed my backup (without internal kerberos accounts). Modified /etc/default/slapd to let the slapd listen on ldaps:// and ldapi://. Reloaded the configuration. Second I installed the heimdal-kdc. Configured the realm. Configured database backend to use the ldapi:// socket. Reloaded. Init the realm and create necessary kerberos host accounts (with random keys): kadmin -l > init G00SE.ORG > add -r host/g00se.org > ext_keytab host/g00se.org > add -r ldap/g00se.org > ext_keytab ldap/g00se.org Reloaded everything and the authenfication server was up and running! Have a nice one!!

Authenfication client via Kerberos (Heimdal) and LDAP backend

To use the provided authenfication mechanism from g00se.org on g00se.org :D I installed libpam-heimdal and configured nss. Kerberos configuration: cat /etc/krb5.conf [libdefaults] default_realm = G00SE.ORG default_keytab_name = /etc/krb5.keytab ticket_lifetime = 28800 default_etypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 default_etypes_des = des3-hmac-sha1 des-cbc-crc des-cbc-md5 [realms] G00SE.ORG = { kdc = g00se.org admin_server = g00se.org } [domain_realm] g00se.org = G00SE.ORG .g00se.org = G00SE.ORG The pam configuration to use the heimdal KDC: cat /etc/pam.d/kerberos #@include common-auth #@include common-account auth required pam_krb5.so account required pam_krb5.so Configuration of the nss-ldap plugin: cat /etc/libnss-ldap.conf uri ldaps://g00se.org/ ldap_version 3 base dc=g00se,dc=org scope sub pam_filter objectclass=account pam_login_attribute uid pam_min_uid 1000 pam_max_uid 2000 nss_base_passwd ou=People,dc=g00se,dc=org?one nss_base_group ou=group,dc=g00se,dc=org?oneh Let nss know that there is a second source which provide authorisation data. cat /etc/nsswitch.conf passwd: compat ldap group: compat ldap That's all! As root you can now check if everything runs: getent passwd and you will see all your local accounts and the provided central ones! I hope everything is cool!!!