I'd like to use AuthSQLTOTP (or maybe also AuthSQLHOTP for that matter) in a way where the static password (PIN) is not stored in AuthSQLTOTP's SQL table but is verified against another auth source, such as existing Active Directory accounts checked by AuthLDAP2.
Any idea if/how that might work? >From looking at the source I think it's currently not possible, even if I were to chain Authby LDAP2 and Authby SQLTOTP in one handler and use ContinueUntilReject or something like that, because Authby LDAP2 would need to know that it must strip the OTP part of the password (say the last six chars) before it checks the password against LDAP, and later on Authby SQLTOTP would insist on having the user in its own SQL user table. To solve this in the most flexible way would require a method of stripping the OTP part (last N chars) from the password before it gets handled by some other auth method (LDAP2 or anything else that can check static passwords) and SQLTOTP would need to be modified to use its SQL table for bookkeeping (per-user num of failed logins, brute-force defense, ...) only, not as a primary source of usernames and static passwords. Any idea on how to solve this? --Tom _______________________________________________ radiator mailing list [email protected] http://www.open.com.au/mailman/listinfo/radiator
