otp over radius preauthentication

[Greg Hudson]

On 05/08/2014 02:50 PM, Frederic Van Espen wrote:
> May 08 20:43:17 obelix-clone krb5kdc[21126](info): preauth (otp)
> verify failure: Connection timed out
> May 08 20:43:17 obelix-clone krb5kdc[21126](info): AS_REQ (6 etypes
> {18 17 16 23 25 26}) 172.16.35.65: PREAUTH_FAILED:
> fes at ICT-DEV.ESCAUX.COM for
> krbtgt/ICT-DEV.ESCAUX.COM at ICT-DEV.ESCAUX.COM, Preauthentication failed

I think this is the root cause of your problem--FreeRADIUS is returning
successfully, but it's doing so too slowly.

You can try bumping up the "timeout" variable in your [otp] config
section, or you can try to figure out why FreeRADIUS is taking so long.
 Five seconds seems like a long time.  There are no timestamps in the
FreeRADIUS logs, so I can't verify that it's actually taking a long time
or figure out where it's all being spent.

> However, at this point it prompts again for the OTP token.

This side issue is making it a little harder to diagnose the main issue.
 You are prompted again because the library attempts to retry against
the master KDC, in case the initial request was against a slave KDC with
outdated information.  There are two problems here:

1. In your setup there is only one KDC, so retrying against the master
is pointless.
2. At least in this case, it would be better if the library reused the
response from the first prompt, instead of prompting twice.

Problem #2 is a difficult design problem, but we can fix #1 easily
enough through configuration.  The library tries to determine if the
first request went to the master KDC and suppresses the fallback if so,
but in your setup it's getting confused.

According to logs, your first request is sent to
kerberos.ict-dev.escaux.com (172.16.35.65) and your second is sent to
obelix-clone.ict-dev.escaux.com (also 172.16.35.65).  These are the same
IP address, but we only compare hostnames.

The name of the KDC for the first request (kerberos.ict-dev.escaux.com)
is coming from the "kdc" relation in krb5.conf.  The name of the master
KDC is coming from a SRV record:

    $ host -t srv _kerberos-master._udp.ict-dev.escaux.com
    _kerberos-master._udp.ICT-DEV.ESCAUX.COM has SRV record 0 0 88
obelix-clone.ict-dev.escaux.com.

If you put "master_kdc = kerberos.ict-dev.escaux.com" in your realm
section, that should suppress the spurious master KDC fallback, as the
library will be able to more easily tell that the master KDC is the same
as the one it tried in the first request.