Coda is looking like a promising piece of infrastructure. However blogging about its awesomeness (that I personally haven’t experienced yet) is pointless. People usually look for solutions to problems so here is my share. The environment that kind of worked out of the box was the following:

  • All users are in Windows Active Directory
  • Clients are Linux (Fedora) workstations joined to the AD domain using samba and winbind
  • Server is also Linux (CentOS 5.4) and joined to the same domain with samba
  • Coda is using kerberos for single sign-on Now, let’s try to change a few elements in this picture.

Try 1: Leave the server on the windows domain, but do not use samba to do the joining.

The procedure to do that deserves an article of its own, but the main issue here was with the case sensitivity of MIT Keberos (or should I say, the case insensitivity of Windows AD). You will never be able to get clog to authenticate because the server does not have a keytab with an all-uppercase name and coda request a ticket for the uppercase name of the host. Unless you actually did create a keytab with an uppercase principal in which case lots of other things will break (ssh-ing into the server would not work with kerberosĀ  for example). This is not an issue when joining the domain with samba (net ads join), because in that case the server gets a keytab with both spellings of the host principal – all uppercase and all lowercase. This is not possible to do when doing things manually because windows will just tell you that the principal already exists when you try to create the other one. The only way I found to work around this problem is to just duplicate the principals on the linux side and make one of them in uppercase.

ktutil
ktutil: rkt /etc/krb5.keytab
ktutil: l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
  1    9 host/server.local@REALM.LOCAL
ktutil: wkt /etc/krb5.keytab
ktutil: exit

After that just use some binary editor (vim -b /etc/krb5.keytab) for example and carefully change one of the server.local occurrences to uppercase.

Try 2: Put the server on a separate Linux realm

To accomplish this you have to set up cross-realm trust between the Linux realm and the windows AD. However, in my case this was the easier thing to do since the servers can automatically join the Linux realm and the reverse DNS is already mapping them to that realm. The only problem is that the lowercase/UPPERCASE principal is still an issue. With a Linux domain it is easy to create both service principals (lower and uppercase) and add them to the server keytab. I personally was getting tired of this nonsense and decided to patch coda instead.

The other change that is needed is to make sure that Coda knows what realm the users would belong to. The default one in /etc/krb5.conf is the one used for system accounts so we had to specify the coda users’ realm with kerberos5realm = WINDOWS.REALM in /etc/coda/server.conf.