Hello,
Radiator 4.14 includes configuration option 'EAP_GTC_PAP_Convert' that
converts EAP-GTC to standard PAP authentication to allow combining
multiple authentication sources with EAP-GTC.
You can have a handler that process EAP-messages, does the conversion
and then use same chain as for PAP authentication.
like this:
<Handler EAP-Message=/.+/>
<AuthBy FILE>
Filename /dev/null
EAPType Generic-Token
EAP_GTC_PAP_Convert
</AuthBy>
</Handler>
<Handler>
AuthByPolicy ContinueWhileAccept
<AuthBy LDAP2>
.....
</AuthBy LDAP2>
<AuthBy SQLTOTP>
.....
</AuthBy>
</Handler>
Converted packet includes attribute ConvertedFromGTC=1 that you can use
if you want to use separate handler.
like this:
<Handler ConvertedFromGTC=1>
......
</Handler>
Best Regards,
Sami
On 08/04/2014 10:13 AM, Thomas Neumann wrote:
> Hi Hugh,
>
> Am 04.08.14 01:03, schrieb Hugh Irvine:
>>
>> There is an example of how to do this sort of thing in:
>>
>> goodies/digipassStatic.txt and goodies/digipassStatic.cfg
>
>
> Thanks for the pointer. That looks very helpful.
>
> Of course SQLTOTP/SQLHOTP will still need to have the username along
> with the OTP secret in their respective SQL tables, which kind of
> defeats the purpose of having Active Directory as the only source of
> user management (as requested by my client), but I think I'm going to
> solve this by storing the hex representation of the OTP secret in an
> unused Active Directory LDAP attribute of the user account (such as
> "employeeNumber", that allows me to get away without an AD schema
> extension), then I'll implement a small script that uses ldapsearch to
> fetch all AD users below a given OU that have the employeeNumber field
> set and belong to some "OTP-Login" group in AD and the fetched username
> and matching OTP secret (from the employeeNumber attribute) will be
> stored in the SQLTOTP table if not already present. That way I wont need
> to create every user twice, once in AD and then again in the SQLTOTP
> table. Every once in a while a garbage collection script would run that
> removes users from the SQLTOTP table that are no longer present in AD. I
> think that should do the trick.
>
> Thanks again!
>
> Regards,
>
> --Tom
>
>
> _______________________________________________
> radiator mailing list
> [email protected]
> http://www.open.com.au/mailman/listinfo/radiator
>
--
Sami Keski-Kasari <[email protected]>
Radiator: the most portable, flexible and configurable RADIUS server
anywhere. SQL, proxy, DBM, files, LDAP, NIS+, password, NT, Emerald,
Platypus, Freeside, TACACS+, PAM, external, Active Directory, EAP, TLS,
TTLS, PEAP, TNC, WiMAX, RSA, Vasco, Yubikey, MOTP, HOTP, TOTP,
DIAMETER etc. Full source on Unix, Windows, MacOSX, Solaris, VMS,
NetWare etc.
_______________________________________________
radiator mailing list
[email protected]
http://www.open.com.au/mailman/listinfo/radiator
