![]() in case of a OTP pre-auth page the user can retry up to 5 times to enter the code (it happens very often to me to enter a wrong digit -_-, and I didn't want the mail client to say that the account settings are wrong at the first OTP error, given that I need to input OTP codes frequently). This means the following form works: OtpPreAuthUserName"SecondayUserName|DOMAIN\ExchangeUser the doublequote separator for the OTP pre-auth specific username also works if the user needs to put two different usernames in the previous way. If the user needs a different username for OTP pre-auth he can configure it inside the mail client username field as: OtpPreAuthUserName"DOMAIN\ExchangeUser (the double-quote character is used as a separator: it can't be used as part of the username in email addresses anyway). support for a different username in the OTP pre-auth (if required: it works also if the username is the same used inside Exchange). support for the workflow explained above, as transparently as possible for the user (if the RSA username is the same as the Exchange one, nothing changes for him) If I connect from the Internet (without VPN, which is what I usually do) I get a RSA webpage asking for username OTP (and the username is actually DIFFERENT from my Exchange username) and only after a successful RSA login I get redirected (with a javascript redirect) to the real Exchange authentication form. If I connect to Exchange using my company's VPN/LAN I get the regular (basic auth or form) Exchange login page. ![]() I started working on this patch because I encountered exactly the same setup as him, or another recent user from alcatel ( ): This is exactly what a user asked a couple of years ago (see feature request tracker id 3003467 => ). The attached patch adds support for Exchange configurations where there is a RSA (OTP) authentication form that is distinct (and precedes) the real/regular Exchange authentication methods. ![]()
0 Comments
Leave a Reply. |