WITHOUT2FA make one-time password screen be bypassed and not show and more

[PimpJuiceIT]

Using MultiOTP 5.9.0.3 server running Windows Server 2016 and the Credential Provider 5.9.0.3 on Windows 10 21H2.

I have it setup so it LDAP syncs with an AD group and created users that get WITHOUT2FA (the default). Out of 600+ users that may RDP or log into a machine locally, we do not want most of them to 2FA with the authenticator app. Probably less than 20 AD accounts will require 2FA and up to 20 local user accounts for Windows local logon or RDP login (just those with local admin access on machines). We want to use the authenticator app for this and not SMS or email by the way.

We need to enforce 2FA authentication and not make it optional though at logon. Based on these needs, I've gotten everything configured to work this way no problem and posted the configuration with sensitive information asterisks out or made a little more generic. So everything is working great and I posted my configurations beneath the 3 questions.

Questions

1. I want to know if there is a way or some configuration option I can set to make it so if the user authenticates and is a member of WITHOUT2FA in OTP, to make it so those end users will not have to press enter or click the arrow key on the Windows login screen for the 'one-time password' after entering their correct AD credentials? See screen shot attached and annotated.

2. Does the pro or enterprise appliance force you to buy a license for the WITHOUT2FA accounts? We prefer to not pay for license for those that bypass it, but they need setup as an account. I tested the pro appliance and the 1 limit user seemed too constrained to test for accuracy and couldn't get it listening on port 8112 for some reason.

3. I thought I set up the configs to use UPN but in my case, my 'base domain name' for the internal domain is different than the external domain. The clients with the CP always shows @netbios name or @in.domain123.org which is the internal domain name. Our AD accounts UPN name is @domain456.org but the CP lock screen, etc. never shows @UPN domain which our UPNs match up with email addresses for M365 logins and such. It also does not allow UPN login but if I uninstall CP, I can login fine with the UPN domain on machines.

Note: I couldn't find binary download to try CP 5.9.1.0 though.

Server Config [mutliotp.ini]

encryption_hash=*****************
actual_version=5.9.0.3
admin_password_hash:*************
anonymous_stat=1
anonymous_stat_last_update=1655415199
anonymous_stat_random_id=*************
attributes_to_encrypt=
auto_resync=1
backend_encoding=UTF-8
backend_type=files
backend_type_validated=0
cache_data=0
cache_ldap_hash=1
case_sensitive_users=0
challenge_response_enabled=0
clear_otp_attribute=
console_authentication=0
create_host=DOMAINOTP01
create_time=1655415103
debug=1
default_algorithm=totp
default_dialin_ip_mask=
default_user_group=
default_request_ldap_pwd=1
default_request_prefix_pin=0
demo_mode=0
developer_mode=0
display_log=0
domain_name=
email_admin_address=
email_code_allowed=0
email_code_timeout=600
email_digits=6
encode_file_id=0
encryption_key_full_path=
failure_delayed_time=300
group_attribute=Filter-Id
hash_salt_full_path=
issuer=multiOTP
language=en
last_failed_white_delay=60
last_sync_update=0
last_sync_update_host=
last_update=1655617077
last_update_host=DOMAINOTP01
ldap_expired_password_valid=1
ldap_account_suffix=
ldap_activated=1
ldap_base_dn=DC=in,DC=domain123,DC=org
ldap_bind_dn=CN=multiotpLDAP,CN=Users,DC=in,DC=domain123,DC=org
ldap_cache_folder=
ldap_cache_on=1
ldap_cn_identifier=userPrincipalName
ldap_default_algorithm=without2fa
ldap_domain_controllers=domaindc01.in.domain123.org,domaindc03.in.domain123.org
ldap_group_attribute=memberOf
ldap_group_cn_identifier=sAMAccountName
ldap_users_dn=
ldap_hash_cache_time=604800
ldap_in_group=MultiOTP-WITHOUT2FA
ldap_language_attribute=preferredLanguage
ldap_network_timeout=10
ldap_port=636
ldap_recursive_cache_only=0
ldap_recursive_groups=1
ldap_server_password:=*********
ldap_server_type=1
ldap_ssl=1
ldap_synced_user_attribute=
ldap_time_limit=30
ldaptls_reqcert=
ldaptls_cipher_suite=
log=1
max_block_failures=6
max_delayed_failures=3
max_event_resync_window=500
max_event_window=100
max_time_resync_window=90000
max_time_window=600
multiple_groups=0
ntp_server=pool.ntp.org
overwrite_request_ldap_pwd=1
radius_error_reply_message=1
radius_reply_attributor= += 
radius_reply_separator_hex=2c
radius_tag_prefix=
scratch_passwords_digits=6
scratch_passwords_amount=10
self_registration=1
server_cache_level=1
server_cache_lifetime=15552000
server_secret:=*********
server_timeout=5
server_type=
server_url=
sms_api_id:=
sms_basic_auth=0
sms_code_allowed=1
sms_content_encoding=
sms_content_success=
sms_digits=6
sms_encoding=
sms_header=
sms_international_format=0
sms_ip=
sms_message_prefix=
sms_method=
sms_no_double_zero=0
sms_originator=multiOTP
sms_password:=
sms_port=
sms_provider=
sms_send_template=
sms_status_success=
sms_timeout=180
sms_url=
sms_userkey:=
smtp_auth=0
smtp_password:=
smtp_port=25
smtp_sender=
smtp_sender_name=
smtp_server=
smtp_ssl=0
smtp_username=
sql_server=
sql_username=
sql_password:=
sql_database=
sql_schema=
sql_config_table=multiotp_config
sql_cache_table=multiotp_cache
sql_ddns_table=multiotp_ddns
sql_devices_table=multiotp_devices
sql_groups_table=multiotp_groups
sql_log_table=multiotp_log
sql_stat_table=multiotp_stat
sql_tokens_table=multiotp_tokens
sql_users_table=multiotp_users
sync_delete_retention_days=1
syslog_facility=7
syslog_level=5
syslog_port=514
syslog_server=
tel_default_country_code=
timezone=Europe/Zurich
token_serial_number_length=12 10 15 11
token_otp_list_of_length=6 8
verbose_log_prefix=
sms_challenge_enabled=0
text_sms_challenge=
text_token_challenge=

Credential Provider Config [mutliotp.ini]

encryption_hash=*********
actual_version=5.9.0.3
admin_password_hash:=
anonymous_stat=1
anonymous_stat_last_update=1656197012
anonymous_stat_random_id=
attributes_to_encrypt=
auto_resync=1
backend_encoding=UTF-8
backend_type=files
backend_type_validated=0
cache_data=0
cache_ldap_hash=1
case_sensitive_users=0
challenge_response_enabled=0
clear_otp_attribute=
console_authentication=0
create_host=TEST01
create_time=1655307684
debug=0
default_algorithm=totp
default_dialin_ip_mask=
default_user_group=
default_request_ldap_pwd=1
default_request_prefix_pin=1
demo_mode=0
developer_mode=0
display_log=0
domain_name=domain123.org
email_admin_address=
email_code_allowed=0
email_code_timeout=600
email_digits=6
encode_file_id=0
encryption_key_full_path=
failure_delayed_time=300
group_attribute=Filter-Id
hash_salt_full_path=
issuer=multiOTP
language=en
last_failed_white_delay=60
last_sync_update=0
last_sync_update_host=
last_update=1656197012

Credential Provider Registry Configs

[multiOTP]

Hello,

>1: I want to know if there is a way or some configuration option I can set to make it so if the user authenticates and is a member of WITHOUT2FA in OTP, to make it so those end users will not have to press enter or click the arrow key on the Windows login screen for the 'one-time password' after entering their correct AD credentials? See screen shot attached and annotated. No, the Credential Provider is always enabled, it's the server side which knows that the 2FA token is empty. There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account.

>2: Does the pro or enterprise appliance force you to buy a license for the WITHOUT2FA accounts? We prefer to not pay for license for those that bypass it, but they need setup as an account. I tested the pro appliance and the 1 limit user seemed too constrained to test for accuracy and couldn't get it listening on port 8112 for some reason. We have recently changed the licence attribution on our commercial edition, and since 5.8.6.1, the accounts with "WITHOUT2FA" tokens don't need any licence. Commercial appliance is listening on regular https port (443), 8112 (http) and 8113 (https) are specific ports pre-configured to avoid interference when running Nginx as a Windows web service with the community edition.

>3: I thought I set up the configs to use UPN but in my case, my 'base domain name' for the internal domain is different than the external domain. The clients with the CP always shows @netbios name or @in.domain123.org which is the internal domain name. Our AD accounts UPN name is @domain456.org but the CP lock screen, etc. never shows @UPN domain which our UPNs match up with email addresses for M365 logins and such. It also does not allow UPN login but if I uninstall CP, I can login fine with the UPN domain on machines. Please note that when you select UPN in the credential provider installation, it means that you are sending the UPN to the multiOTP server. If you have synchronized your AD/LDAP with the sAMAccountName, you must NOT select the UPN option. The 5.9.1.0 version of Credential Provider has been enhanced and will be available for download later this week on https://download.multiotp.net/credential-provider/

Regards,

Andre

[PimpJuiceIT]

Thanks for the feedback, I'm working on getting a Duo demo setup this week but management will make the final decision. The initial feedback was they did not like that the WITHOUT2FA users (which is 98% of our setup), will require those end-users to do something further so I thought I'd ask if it was possible or not so I will let them know it is not with this solution and go from there.

Based on the current configuration files I provided, I can login via netbios\username or username@in.domain123.org with the server configuration set as ldap_cn_identifier=userPrincipalName and per the registry screen shot the multiOPTUPNFormat has a value of 1 so I'm not sure what specific setting/property values of either of those configurations need to be for what you are saying must NOT be.

My concern is for UPN of users logging in and not the account that does the LDAP sync so it sounds like you are saying UPN for username at CP login only isn't supported.

I will check back in on the latest pro edition of the commercial product after I figure out this Duo for demo since my MultiOTP demo is done per your feedback here for the company. I may have not configured something properly but I couldn't get it working for whatever reason. I got the more complex setup of MultiOTP to work for the open source solution working on Windows, but was trying to avoid all that using the appliance after getting it configured.

Regardless of what they go with, I'll be keeping tabs on MultiOTP for future enhancements, etc. to see if the credential provider stuff becomes more robust on the configuration side. While we don't care of extra hoops the local admins may have to go through to login, I know management prefers to make this change more transparent to the other end-users so I have a feeling this will be a show stopped for them as silly as that sounds. I'm hoping Duo has the same issue though because I really like MultiOTP.

[multiOTP]

Hello, Thanks for your feedback. Please note that we have a beta test in order to have an extra option to remove the second step for users without token requests (WITHOUT2FA). Regards,

[devopsido]

Is the beta available for anyone who wishes to test?

I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary?

Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed...

Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page.

Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

[multiOTP]

Is the beta available for anyone who wishes to test?

I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary?

Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed...

Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page.

Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

Hello, Unfortunately, there is no solution for a RDP server to know for sure the source IP address. The source IP address is provided by the RDP client, which can be (too) easily forged. Concerning the hardcoded excluded account, you have to write it in the related registry entry named "excluded_account", as written in the readme file. Regards,

[PimpJuiceIT]

Is the beta available for anyone who wishes to test?

I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary?

Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed...

Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page.

Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

For the public IP and session login control, you'll want to find a cloud based solution like M365 conditional access policies or a Duo with policy configured accordingly.

MultiOTP that I've used/tested/looked at is for on-prem solution where IPs going to RDP session should be from the Internal trusted network. That's why I like MultiOTP so well, it's on-prem. The configuration was a bit tough but I made my way through it (sysadmin\engineer).

Have your remote folks connect to a VPN and then allow RDP to the machines on the applicable port from the VPN subnet. This way you only allow them to connect from there and then use a MultiOTP post AD authentication to 2FA\MFA via OTP.

[multiOTP]

For the public IP and session login control, you'll want to find a cloud based solution like M365 conditional access policies or a Duo with policy configured accordingly.

Hello, Even with a cloud based solution, I'm not sure that the RDP client public IP cannot be fooled... Anyway, on our side, we are perhaps "old school", but we are convinced that protecting internal infrastructure with 2FA should be done on-prem and never using the cloud. Even our commercial products don't need any Internet connection to work correctly ;-) Regards,

[devopsido]

Is the beta available for anyone who wishes to test? I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary? Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed... Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page. Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

Hello, Unfortunately, there is no solution for a RDP server to know for sure the source IP address. The source IP address is provided by the RDP client, which can be (too) easily forged. Concerning the hardcoded excluded account, you have to write it in the related registry entry named "excluded_account", as written in the readme file. Regards,

Humm. I don't see how this could be true. If an RDP client uses a "spoofed" IP, the traffic from the RDP server would not find its way back to said client. There wouldn't be a connection at all. I'm trying to think that through to find any holes in my thinking.

We have some configurations with an RD Gateway (with authentication, obviously) and NLA before they even get to the MultiOTP Credential Provider. So, for the RD Gateway users, the RDP client connection is always from the RD Gateway; it would be nice if we could pick and choose to:

• bypass MultiOTP for certain Public IPs (clients to the RD Gateway) - maybe choose to verify from a location every 24 hours (or something)
• bypass MultiOTP to the folks who VPN rather than RD Gateway (connections from the RD Gateway IP(s) require OTP, connections from certain VPN subnets do not)
• bypass MultiOTP for specified client IPs

I certainly don't want to do anything to encourage less secure connections, but I thought that (if) a solution for PimpJuiceIT's request might be able to bring some flexibility to other situations where bypassing the OTP under certain circumstances might be handy. I don't know what kind of flexibility (if any) we have to pick and choose credential providers on the fly or based on certain conditions..

THANK YOU for the info on the excluded account. I missed that in the readme! Thank you for your work on MultiOTP!

[devopsido]

Is the beta available for anyone who wishes to test? I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary? Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed... Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page. Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

For the public IP and session login control, you'll want to find a cloud based solution like M365 conditional access policies or a Duo with policy configured accordingly.

MultiOTP that I've used/tested/looked at is for on-prem solution where IPs going to RDP session should be from the Internal trusted network. That's why I like MultiOTP so well, it's on-prem. The configuration was a bit tough but I made my way through it (sysadmin\engineer).

Have your remote folks connect to a VPN and then allow RDP to the machines on the applicable port from the VPN subnet. This way you only allow them to connect from there and then use a MultiOTP post AD authentication to 2FA\MFA via OTP.

Thank you for your thoughts and I hope that I am not hijacking your post!

We have used Duo a fair bit over the years, and their push notifications are very nice for RD Gateway installations, but an on-premise solution has great appeal. I had thought that your request to bypass OTP without showing the screen and some conditional bypasses might dovetail in a way that might make sense.

[multiOTP]

Humm. I don't see how this could be true. If an RDP client uses a "spoofed" IP, the traffic from the RDP server would not find its way back to said client. There wouldn't be a connection at all. I'm trying to think that through to find any holes in my thinking.

Technically speaking, you have various TCP/UDP RDP sessions established with the real IP addresses of the client, but during the login check, you can only check the local IP address of the client which is given through the RDP protocol. If you want to match the remote IP of the client, it's not directly available, and you have to trickl with the session ID and the TCP/IP stack.

[multiOTP]

Is the beta available for anyone who wishes to test? I don't want to hijack this request, but I am wondering if my question it may be related -- Is it possible (now or as an enhancement) to configure a certain IP or range(s) of IPs, or to provide a list (or a dynamic list) of IPs from which no MFA is necessary? Example: a branch office might only need to verify MFA every X days. If a user has logged in from an IP in the last 24 hours, the OTP page can be bypassed... Please let me know if I should delete this and submit it as a new topic, but I wonder if such a solution might help PimpJuiceIT who might be able to set certain subnets (or something) to bypass the OTP page. Also: "There is currently no option to bypass this beaviour, except for one hardcoded exlcuded account." What account is that? Is there documentation?

For the public IP and session login control, you'll want to find a cloud based solution like M365 conditional access policies or a Duo with policy configured accordingly. MultiOTP that I've used/tested/looked at is for on-prem solution where IPs going to RDP session should be from the Internal trusted network. That's why I like MultiOTP so well, it's on-prem. The configuration was a bit tough but I made my way through it (sysadmin\engineer). Have your remote folks connect to a VPN and then allow RDP to the machines on the applicable port from the VPN subnet. This way you only allow them to connect from there and then use a MultiOTP post AD authentication to 2FA\MFA via OTP.

Thank you for your thoughts and I hope that I am not hijacking your post!

We have used Duo a fair bit over the years, and their push notifications are very nice for RD Gateway installations, but an on-premise solution has great appeal. I had thought that your request to bypass OTP without showing the screen and some conditional bypasses might dovetail in a way that might make sense.

Please note that we are developing an open source multiOTP software token app for Android/iOS that will also support notification in a second phase. With this option activated, the multiOTP server will still be on-prem and without direct Internet access, and a notification gateway will be added (and contacted by the multiOTP server when needed). Details will follow in the next monthes. Regards,

[multiOTP]

• bypass MultiOTP to the folks who VPN rather than RD Gateway (connections from the RD Gateway IP(s) require OTP, connections from certain VPN subnets do not)
• bypass MultiOTP for specified client IPs

Not sure that is so easy, but already on the "nice to have" list. Regards,

[multiOTP]

We keep this ticket open until the bypass of the 2FA prompt for WITHOUT2FA tokens is published. Regards,

[PimpJuiceIT]

FYI.... I believe the Duo is going to be a no-go because if the users with it bypasses 2FA and the Internet is down, it does not allow them to log into the workstation. They have a way to register for 'offline' mode, but for the users that bypass the 2FA with it (setup as the default), they cannot register with it for the offline access.

When I tested with MultiOTP, I shut the server down completely, and based on my configuration from accounts that had already logged in since MultiOTP authenticated them (including WITHOUT2FA) it still allowed them to login no problem.

More than likely, we won't ever have a problem with the MultiOTP server being inaccessible on the local network but even if so, the testing was good there. We are more likely to have Internet connectivity issues than with the local trusted network.

Thank you MultiOTP and all your developers and contributors. This product is great. I'll likely be testing the pro appliance next when I hear back on the bypass of 2FA prompt for WITHOUT2FA. If I can get the pro appliance to work with this configuration, that will be absolutely perfect.

[JonathonFS]

Subscribed. Looking forward to WITHOUT2FA bypassing the 2FA prompt.

Also interested in knowing if there's anyway to bypass the 2FA prompt for Azure AD users? We already have them covered for MFA, by using the Windows option to force AAD users to use WHFB.

[multiOTP]

Users without any 2FA token (WITHOUT2FA ) are now bypassed by the 2FA prompt. Please be sure to upgrade the Credential Provider (https://github.com/multiOTP/multiOTPCredentialProvider/releases/latest) and the multiOTP server (https://github.com/multiOTP/multiotp/releases/latest) to at least version 5.9.2.1

[multiOTP]

Subscribed. Looking forward to WITHOUT2FA bypassing the 2FA prompt.

Also interested in knowing if there's anyway to bypass the 2FA prompt for Azure AD users? We already have them covered for MFA, by using the Windows option to force AAD users to use WHFB.

Hello, Give these users "WITHOUT2FA" tokens, it should do the trick. Regards,

[multiOTP]

Hello, the version 5.9.3.1 handles correctly WITHOUT2FA users by downloading cache directly. Best regards