Kerberos and Bind

ryeguy146 · 12-24-2010, 06:12 PM

I am running FreeBSD 8.1 on an x86 computer. SAMBA and Kerberos 5 has been installed and GSSAPI is available. Bind (have tried 9.7.2-P2 and 9.8.0-a1) has been installed and configured, and each time bind (compiled with "--with-gssapi=/usr") refuses to connect to the key distribution server when I start it. I receive the following error:

Code:

default realm from krb5.conf (EXAMPLE) does not match tkey-gssapi-credential (DNS/ns1.example.com@EXAMPLE)

Of course, names have been changed here, but remain consistent with the actual situation. Manual pages for named.conf suggest that the principal (DNS/ns1.example.com@EXAMPLE) is correct, and manuals for krb5.conf do seem to support my configuration, but I still receive the error. I have tried other variations on the principal name (ns1@EXAMPLE, ns1.example, etc.) but to no avail. I can connect and receive tickets from the key distribution center (Windows Server 2008, Domain Controller) using kinit -k DNS/ns1.example.com@EXAMPLE. Using the klist utility does indeed reflect the ticket status in the case of kinit.

The pertaining bits of named.conf:

Code:

options {
. . .tkey-gssapi-credential "DNS/ns1.example.com@EXAMPLE";
tkey-domain "EXAMPLE";. . .
}

krb5.conf:

Code:

[logging]
        default = FILE:/var/log/krb5/libs.log
        kdc = FILE:/var/log/krb5/kdc.log
        admin_server = FILE:/var/log/krb5/admin.log
[libdefaults]
        default_realm = EXAMPLE
        default_tkt_enctypes = des-cbc-md5
        default_tgs_enctypes = des-cbc-md5
        dns_lookup_realm = true
        dns_lookup_kdc = true
        ticket_lifetime = 30d
        forwardable = yes
        default_keytab_name = FILE:/etc/ns1.keytab
[realms]
        ROLER = {
                kdc = dc1.example.com:88 // Domain Controller
                admin_server = dc1.example.com
                default_domain = example.com
        }
[domain_realm]
        .example.com = EXAMPLE
        example.com = EXAMPLE
[appdefaults]
        pam = {
                debug = false
                ticket_lifetime = 36000
                renew_lifetime = 36000
                forwardable = true
                krb4_convert = false
        }

My end goal is to securely (GSS-TSIG) allow dynamic updates from hosts in an active directory domain (example.com). I used this as an example for the process, and Microsoft's meager documentation. Though I had to adapt some of the steps to my software versions, the steps were followed closely.

If anyone can tell me what I'm missing and how to resolve the issue, I'd be obliged.

ryeguy146 · 12-26-2010, 03:22 AM

An update. Though I don't use SAMBA4 (I have SAMBA34), their howto page covered dynamic updates for BIND. Using the examples provided, I changed my named.conf as follows:

Code:

options {
. . .

    tkey-gssapi-credential "DNS/example"; 
    tkey-domain "EXAMPLE";

. . .
}

Note the exclusion of the hostname in the credential option. Of course, this differs from the previous howto that I linked to. I no longer get the error suggesting that the realms in the two conf files do not match, but BIND still refuses to start:

Code:

named[3323]configuring TKEY: failure
named[3323]: loading configuration: failure
named[3323]: exiting (due to fatal error)

Of course, these three lines have always been present, but preceded by the previous error. They now exist on their own, and I really have little to go off of. Even running "sh -xv /etc/rc.d/named" fails to turn up any real errors:

Code:

. . .
+ rc_usage start stop restart rcvar reload status poll
+ echo -n 'Usage: /etc/rc.d/named [fast|force|one]('
Usage: /etc/rc.d/named [fast|force|one](+ _sep=''
+ echo -n start
start+ _sep='|'
+ echo -n '|stop'
|stop+ _sep='|'
+ echo -n '|restart'
|restart+ _sep='|'
+ echo -n '|rcvar'
|rcvar+ _sep='|'
+ echo -n '|reload'
|reload+ _sep='|'
+ echo -n '|status'
|status+ _sep='|'
+ echo -n '|poll'
|poll+ _sep='|'
+ echo ')'
)
+ exit 1

Little help there. BIND is obviously slightly more pleased with the new configuration, but still fails to load. I really don't see that it will change anything, but I may try replacing my version of SAMBA with version 4. A job for tomorrow, perhaps.

Any ideas?