Page 1 of 1

Cannot find KDC for requested realm (0x9a)

Posted: Tue Dec 06, 2011 9:36 pm
by EMF
I'm using Adam's "openvpn-super.pl" script to try to get AD authentication functional on a CentOS6 host. However, when trying to connect, I'm getting this in the verb 5 output, and duplicated in the /var/log/openvpn.log:

Code: Select all

2011-12-06 15:36:49     [ERR_AUTH] authentication failure; user: emf; from: 24.89.191.91 (57778/) [ool-1859bf5b.static.optonline.net]; details: Cannot find KDC for requested realm (0x9a); time: 1969-12-31 19:00:00
What strikes me as really odd is that timestamp: epoch?? Am I missing some sort of Kerberos dependency? I do have perl-Authen-Krb5-Simple-0.42-1.el6.rf.x86_64 installed.

I've confirmed that my KDC realm is all capitals (e.g. "COMPANY.COM") and that the DCs are properly identified, resolvable, and reachable. In fact, they're all used by another application on this same box.

Script revision is openvpn-super.pl v1.1.
openvpn-super.conf:

Code: Select all

domain = COMPANY.COM
dc = bowyer.company.com
dc = fletcher.company.com
group = cn=OpenVPN Users,ou=Groups,ou=US,dc=company,dc=com
mailserver = exchange.company.com
mailto = IT\@company.com
logfile = /var/log/openvpn.log
server.conf: (running as root right now for testing; will go to nobody for deployment)

Code: Select all

local 192.168.101.76
port 1194
proto udp
dev tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/fieldpoint.crt
key /etc/openvpn/easy-rsa/keys/fieldpoint.key
dh /etc/openvpn/easy-rsa/keys/dh2048.pem
server 192.168.98.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "route 192.168.100.0 255.255.255.0"
push "route 192.168.101.0 255.255.255.0"
push "redirect-gateway def1"
push "dhcp-option DNS 192.168.101.65"
push "dhcp-option DNS 192.168.101.66"
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 5
script-security 3
client-cert-not-required
auth-user-pass-verify /etc/openvpn/openvpn-super.pl via-env
client-connect /etc/openvpn/openvpn-super.pl
client-disconnect /etc/openvpn/openvpn-super.pl
client.ovpn:

Code: Select all

client
dev tun
proto udp
remote vpn.company.com 1194
resolv-retry infinite
nobind
route-method exe
route-delay 2
ca ca.crt
ns-cert-type server
auth-user-pass
auth-retry interact
comp-lzo
verb 5

Re: Cannot find KDC for requested realm (0x9a)

Posted: Wed Dec 07, 2011 5:42 pm
by EMF
This isn't an error with openvpn-super.pl; this quick-and-dirty script also fails with the same error.

Code: Select all

#!/usr/bin/perl -w
use Authen::Krb5::Simple;
$realm = "COMPANY.COM";
$user = "emf";
$pw = "Temp1234";
my $krb = Authen::Krb5::Simple->new(realm => $realm);
if ($krb->authenticate($user, $pw)) { 
        print "$user authentication successful\n";
} else {
        print "$user authentication failed: ", $krb->errstr(), "\n";
}
So, on to see why Perl's Authen-Krb5-Simple can't find the KDCs...

Re: Cannot find KDC for requested realm (0x9a)

Posted: Wed Dec 07, 2011 7:02 pm
by EMF
Sometimes, it pays to read through code; you learn something new regularly.

The other application on this box (OpenVPN-ALS/Adito, specifically) is completely self-contained. It keeps its own Kerberos configuration, separate from the system.

I wrongly surmised that openvpn-super.pl would do something similar, and be self-reliant. But Authen::Krb5::Simple actually relies upon the libkrb5 system libraries, which refer to the /etc/krb5.conf file. If that's still the default file, then nothing will work.

Configured my /etc/krb5.conf to look up the realm KDCs via DNS, and off we go!

Re: Cannot find KDC for requested realm (0x9a)

Posted: Wed Dec 07, 2011 7:07 pm
by EMF
Note for future reference, though --- openvpn-super.pl requires a designated list of DCs in its config file; if they change, you have to remember to change them there too. If I have spare time, I'll poke around with providing a patch to look them up if the DC list is empty.

Re: Cannot find KDC for requested realm (0x9a)

Posted: Thu Dec 08, 2011 8:27 am
by janjust
I'm glad to hear that it is finally working.
Thanks for digging into this - this is a good one for the FAQs !