Otp Login Failed With Unknown Issue

By | May 28, 2022

1. Overview

In this document, we describe how to easily fix some common errors with WebADM, OpenOTP, Web Applications, Radius Bridge, Push login, License services, LDAP permissions etc.

2. WebADM/OpenOTP common issues

The first thing to do when a login failed for an unknown reason is to check the log file
/opt/webadm/log/webadm.log
and find the right log. In addition to the terminal session, you can find the log also in WebADM > Databases > WebADM Server Log files.

Please note that this log is per server, so in clustered environment you will need to check from each server separately.

2.1 User invalid or not found

Logs example :

          [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] New openotpSimpleLogin SOAP request [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] > Username: [email protected] [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] > Password: xxxxxx [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] > Client ID: RadTest [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] > Options: RADIUS,-U2F [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] Registered openotpSimpleLogin request [2017-07-21 09:13:16] [127.0.0.1] [OpenOTP:MKRVHYLX] User invalid or not found [2017-07-21 09:13:17] [127.0.0.1] [OpenOTP:MKRVHYLX] Sent failure response
          
        

Possible reasons/Solutions :

  • Account doesn’t exist in the LDAP;
  • The user account is not activated in WebADM;
  • Username used during the authentication (here [email protected]) doesn’t match any user in the LDAP (username attributs checked by WebADM can be founded in
    /otp/webadm/conf/webadm.conf
    setting
    uid_attrs).

For AD, the default username attributs are :

            uid_attrs
              "uid",
              "samAccountName",
              "userPrincipalName"
            
          

  • proxy_user configured in
    /otp/webadm/conf/webadm.conf
    do not have read permission on the user account.

  • The user is outside of the user search base(s) defined in WebADM > Admin > User Domains.

E.g : WebADM domain configuration


User search base is :
cn=users,dc=yorcdevs,dc=eu
The DN of my User is :
CN=test,CN=Internal,DC=yorcdevs,DC=eu

As you can see, the user search base configured in my WebADM domain does not include
CN=Internal,DC=yorcdevs,DC=eu
container, thus WebADM is not able to find the user. The solution is to change the User search base configured in your WebADM domain to include the container where your user is located.

E.g : User search base :
dc=yorcdevs,dc=eu

2.2 No usable login method found / User has no OTP token registered / Account missing required data or MFA enrolment needed

Logs example :

          [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] New openotpNormalLogin SOAP request [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > Username: test [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > Domain: yorcdevs.eu [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > LDAP Password: xxxxxxxx [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > Client ID: OpenOTP [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > Source IP: 192.168.3.64 [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] > Context ID: 7f869f80b588210691b32bb4e09248c5 [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] Registered openotpNormalLogin request [2022-04-14 13:33:14] [192.168.3.64] [OpenOTP:R4NOCMJR] Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] Started transaction lock for user [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] Found user fullname: test [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] Found 47 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] User has no OTP token registered [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] No usable login method found [2022-04-14 13:33:15] [192.168.3.64] [OpenOTP:R4NOCMJR] Sent failure response
          
        

Possible reasons/Solutions :

  • The authentication policy requires a 2nd factor which cannot be provided by the user. In this case the
    LoginMode=LDAPOTP
    but the user does not have OTP Token registered. The solution here is to register an OTP Token on the user account.

With the User Self-Registration (SelfReg) application, you can automatically send a self-registration request by email or SMS to the user who does not have any Token registered or whose Token has expired. For this, you need to enable the following setting under OpenOTP configuration :


When this setting is enable you can see the next following logs :

            
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              User has no OTP token registered
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              No usable login method found
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              Sent failure response
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu
              (cached)
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              Using Mail server
              'SMTP Server'
              [2022-04-14 13:56:04]
              [192.168.3.64]
              [OpenOTP:92K6RNIA]
              Sent self-registration request
              for
              OTP
            
          

A self-registration request has been sent to the end user :


User can now access SelfReg application through the one-time link to register a Token, after which they can retry the login.

2.3 Wrong TOTP/HOTP Password

Logs example :

          [2022-04-14 14:49:19] [192.168.3.64] [OpenOTP:JOVHS8WV] New openotpStatus SOAP request [2022-04-14 14:49:19] [192.168.3.64] [OpenOTP:JOVHS8WV] Sent status response (Ok) [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] New openotpNormalLogin SOAP request [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > Username: test [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > Domain: yorcdevs.eu [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > LDAP Password: xxxxxxxx [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > OTP Password: xxxxxx [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > Client ID: OpenOTP [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > Source IP: 192.168.3.64 [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] > Context ID: 8054c53df2b28b4e06233591d5651c1b [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Registered openotpNormalLogin request [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Started transaction lock for user [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Found user fullname: test [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Found 1 user emails: [email protected] [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Found 47 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Found 3 user data: TokenType,TokenKey,TokenState [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Found 1 registered OTP token (TOTP) [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Requested login factors: LDAP & OTP [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] LDAP password Ok [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Wrong TOTP password (token #1) [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Updated user data [2022-04-14 14:49:28] [192.168.3.64] [OpenOTP:D34LZB76] Sent failure response
          
        

Possible reasons/Solutions :

  • Wrong OTP password has been provided during the authentication request
  • If the OTP was provided correclty but the login still fails, it probably means the Token is desynchronized. Try to resynchronize it through
    WebADM GUI > <USER_ACCOUNT> > MFA Authentication Server > Resynchronize Tokens
    and retry to login.

2.4 Could not modify LDAP object / Could not set user data

Logs example

          [2018-10-16 11:20:04] [10.10.0.3] [OpenOTP:L9RLQWCV] Could not modify LDAP object 'CN=test,CN=Users,DC=yorcdevs,DC=eu' (Insufficient access) [2018-10-16 11:20:04] [10.10.0.3] [OpenOTP:L9RLQWCV] Could not set user data for 'CN=test,CN=Users,DC=yorcdevs,DC=eu'
          
        

Possible reasons/Solutions :

This issue is due to the
proxy_user
account configured in
/otp/webadm/conf/webadm.conf
not having sufficient permissions to write metadata on the user account which is trying to authenticate.

Same error can happens with a
super_admin
account connected to WebADM GUI or using WebADM Manager API which is trying to edit LDAP objects without enough permissions on the AD.

Please refer to the proxy_user or super_admins permissions documentations on MS Active Directory for instructions on how to set the permissions for
proxy_user
and
super_admins
on AD.

2.5 Account is disabled in AD

Logs example

          [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] New openotpNormalLogin SOAP request [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > Username: test [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > Domain: yorcdevs.eu [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > LDAP Password: xxxxxxxx [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > Client ID: OpenOTP [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > Source IP: 192.168.3.64 [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] > Context ID: 42d3589194785645086d7321af6bcdc6 [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Registered openotpNormalLogin request [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Started transaction lock for user [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Found user fullname: test [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Found 47 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Found 5 user data: TokenType,TokenKey,TokenState,TokenID,TokenSerial [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Account is disabled in AD [2022-04-14 13:03:31] [192.168.3.64] [OpenOTP:ON5915X4] Sent failure response
          
        

Possible reasons/Solutions :

You can see this error when the user account is disabled in Active Directory. Enable the account on the AD and retry to login.

2.6 Wrong LDAP password

Logs example

          [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] New openotpNormalLogin SOAP request [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > Username: test [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > Domain: yorcdevs.eu [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > LDAP Password: xxxxxxxx [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > Client ID: OpenOTP [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > Source IP: 192.168.3.64 [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] > Context ID: 60d8d725717df2ba6883c24d49e08aaa [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Registered openotpNormalLogin request [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Started transaction lock for user [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Found user fullname: test [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Found 1 user emails: [email protected] [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Found 47 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Found 5 user data: TokenType,TokenKey,TokenState,TokenID,TokenSerial [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Found 1 registered OTP token (TOTP) [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Requested login factors: LDAP & OTP [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Wrong LDAP password [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Updated user data [2022-04-14 17:05:18] [192.168.3.64] [OpenOTP:6VO7R9UY] Sent failure response
          
        

Possible reasons/Solutions :

  • Wrong LDAP password has been provided during the authentication process.
  • The user account is blocked on the LDAP server. Unblock the account to be able to use it.

2.7 Account has been blocked

Logs example

          [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] New openotpNormalLogin SOAP request [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > Username: test [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > Domain: yorcdevs.eu [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > LDAP Password: xxxxxxxxxxx [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > Client ID: OpenOTP [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > Source IP: 192.168.3.64 [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] > Context ID: efaf77b42566518314d7b2bcc726eee7 [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] Registered openotpNormalLogin request [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] Resolved LDAP user: CN=test,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-14 17:18:04] [192.168.3.64] [OpenOTP:XTIOD9VG] Started transaction lock for user [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Found user fullname: test [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Found 1 user emails: [email protected] [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Found 47 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,LockTimer=0,MaxTries=3,BlockTime=0,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,DeviceType=FIDO2,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Found 6 user data: TriesCount,TokenType,TokenKey,TokenState,TokenID,TokenSerial [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Account has been blocked permanently after 3 tries [2022-04-14 17:18:05] [192.168.3.64] [OpenOTP:XTIOD9VG] Sent failure response
          
        

Possible reasons/Solutions :

Account has been blocked permanently after 3 tries
means that the user account is blocked in OpenOTP because of multiple login failures. This can only happen if a blocking account policy is configured under OpenOTP configuration. If
block Time
setting of OpenOTP is set to 300s, then the user can not perform any login with OpenOTP during 300s from the blocking time. The account will be automatically unblocked after the 300s.

Max IDLE time
setting can also be the origin of a user blocking. This setting set a number of days after which an account is permanently blocked if it is not used. If this setting is enabled and the configured value is excedeed for a user account, a manual unblock by a WebADM administrator is required. The user can also unblock his account by himself through SelfDesk application.

To unblock the account through the WebADM admin portal, login on
WebADM GUI > <USER_ACCOUNT> > MFA Authentication Server > Unblock Account.

2.8 Account already under transaction / User under transaction

Logs example

          [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] New openotpSimpleLogin SOAP request [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Username: administrator [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Password: xxxxxxxx [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Client ID: RadTest [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Options: RADIUS,-U2F [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] Registered openotpSimpleLogin request [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] Resolved LDAP user: CN=Administrator,CN=Users,DC=yorcdevs,DC=eu (cached) [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] Resolved LDAP groups: group policy creator owners,domain admins,enterprise admins,schema admins,denied rodc password replication group [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second) [2022-04-15 12:49:02] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second) [2022-04-15 12:49:03] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second) [2022-04-15 12:49:04] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second) [2022-04-15 12:49:05] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second) [2022-04-15 12:49:06] [192.168.3.64] [OpenOTP:84YBCGAX] Account already under transaction [2022-04-15 12:49:06] [192.168.3.64] [OpenOTP:84YBCGAX] Sent failure response
          
        

Possible reasons/Solutions :

Popular:   Staples Hub for Associates Sign in

To prevent OTP replay attacks, the same user account can not initiate concurrent logins with OpenOTP. When a transaction login is started for a user account, you can see the following log in
webadm.log
for the login session :

          [2022-04-15 12:48:49] [192.168.3.64] [OpenOTP:XXQAGDA5] Started transaction lock for user
          
        

The transaction lock for the user is enabled until the end of login process.

If the user try to start a concurrent login during the lock period, the new login attempt will be rejected by OpenOTP with the following logs :

          [2022-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
          
        
  • This can happens if the user try to login simultanously on different systems consuming OpenOTP for authentications,
  • A too short
    timeout
    (e.g: 10s) with a login
    retry
    configured between OpenOTP clients and OpenOTP server can also be the origin of that kind of issue. The OpenOTP client
    timeout
    should be set to 30s without push login configured and 40s with push login. 0 or 1 for
    retry
    setting according to what is allowed by your clients is advised.

2.9 Domain xxx not existing

Logs example

          [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] New openotpNormalLogin SOAP request [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Username: administrator [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Domain: yorcdevs.eu [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Client ID: ADFS19 [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Source IP: 192.168.3.62 [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Context ID: xDRnnYukcsGfPuinwfXmgweA5zUppwYR [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Settings: LockTimer=0 [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] > Options: -LDAP [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] Enforcing client policy: ADFS19 (matched client ID) [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] Registered openotpNormalLogin request [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] Domain 'yorcdevs.eu' not existing [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] User invalid or not found [2022-04-15 13:30:38] [192.168.3.62] [OpenOTP:3UFSBKBW] Sent failure response
          
        

WebADM domain configuration :


Possible reasons/Solutions :

This error occurs when the domain provided during the authentication request do not match any user domain configured in WebADM. Here the domain provided is
yorcdevs.eu

To fix it, login on WebADM GUI > Admin > User Domain :

  • If an existing domain named
    Default
    already exist in your configuration and the user who is trying to authenticate is part of that domain, then you can add
    yorcdevs.eu
    as domain Name Aliases value in your current domain. You can also rename the
    Default
    domain name by
    yorcdevs.eu
    and add
    Default
    as Domain Name Aliases value. Please, take into account that if you choose to rename the domain by your custom value and you don’t want to put
    Default
    as Domain Name Alias of your domain, you need to edit each Web Applications and WebServices configuration to adjust the default domain value to the new one configured.
  • If user is not part of existing domain configured, then create a new WebADM domain with a user search base including users who need to authenticate under that domain.

2.10 Domain not provided and no default domain configured

Logs example

          [2022-04-07 10:32:55] [192.168.3.64] [Admin] Domain not provided and no default domain configured
          
        

Possible reasons/Solutions :

This error occurs if there is no default domain configured in WebADM and an authentication request does not include domain information. A default domain can be configured in
/opt/webadm/conf/webadm.conf. This default domain is used for logins on the WebADM admin portal and Web Applications.

          default_domain "yorcdevs.eu"
          
        

When this setting is configured, if I login on WebADM Admin GUI in UID, OTP or U2F mode by not providing any user domain, then the default one configured in webadm.conf will be automatically used.

2.11 Server is unwilling to perform

This error can happens for multiple reasons in WebADM and comes from Active Directory. When you see this error, it means the action attempt can not be performed on the remote Active Directory.

Logs example

          [2022-04-20 10:03:58] [192.168.3.1] [PwReset:DPIL2WTF] Could not modify LDAP object 'CN=Administrator,CN=Users,DC=yorcdevs,DC=com' (Server is unwilling to perform - 0000001F: SvcErr: DSID-031A12D2, problem 5003 (WILL_NOT_PERFORM), data 0) [2022-04-20 10:03:58] [192.168.3.1] [PwReset:DPIL2WTF] Could not set user password for 'CN=Administrator,CN=Users,DC=yorcdevs,DC=com' (Server is unwilling to perform)
          
        
          [2022-04-20 09:58:21] [192.168.3.1] [Admin:58SR60O3] Could not modify LDAP object 'CN=RCDevs,CN=Users,DC=yorcdevs,DC=com' (Server is unwilling to perform - 0000001F: SvcErr: DSID-031A12D2, problem 5003 (WILL_NOT_PERFORM), data 0)
          
        

Possible reasons/Solutions :

  • There is no encryption configured on the LDAP connection between WebADM and Active Directory. Active Directory refuses to change users passwords with unencrypted LDAP. Edit
    /opt/webadm/conf/servers.xml
    and configure your LDAP servers with SSL or TLS encryption (restart WebADM services to changes takes effect). SSL protocol use 636 port and TLS 389. To enable SSL or TLS between WebADM and Active Directory, AD must be first configured for LDAPS support. To check if LDAPS is enabled on your DCs, you can open powershell and execute the following command :
            PS C:\Users\Administrateur> netstat -na | Select-String "636"    TCP    0.0.0.0:636            0.0.0.0:0              LISTENING   TCP    [::]:636               [::]:0                 LISTENING
            
          

As you can see, LDAPS is enabled on my DC and 636 port is listening.

You can also check from WebADM if WebADM is able to communicate with the DC on port 636. Open an SSH session with your WebADM and use telnet to check :

            [[email protected] ~]# telnet 192.168.3.50 636 Trying 192.168.3.50... Connected to 192.168.3.50. Escape character is '^]'.
            
          

Port is open and reachable from WebADM Server, LDAPS can then be used.

  • You tried to change a user password (through WebApps or WebADM Admin GUI), but the new password provided doesn’t meet the Active Directory password policy.

2.12 Missing client certificate or subject

Logs example

            [2022-04-21 10:41:41] [192.168.3.68] [OpenOTP] Missing client certificate or subject
            
          

Possible reasons/Solutions :

This error can appear if the OpenOTP setting “Require Client Certificate” is enabled and the OpenOTP client doesn’t provide certificate during communications with OpenOTP.

  • Issue a client certificate through WebADM PKI for your OpenOTP client and configure the certificate on your client.
  • Disable the setting “Require Client Certificate” under OpenOTP configuration.

2.13 Checking LDAP proxy user access… ERROR

This error can occur when starting WebADM services.

Logs example

          [[email protected] ~]# /opt/webadm/bin/webadm start Found Trial Enterprise license (RCDEVSSUPPORT) Licensed by RCDevs Security SA to RCDevs Support Licensed product(s): OpenOTP,SpanKey,TiQR  Starting WebADM PKI server... Ok Starting WebADM Session server... Ok Starting WebADM Watchd server... Ok Starting WebADM HTTP server... Ok  Checking server connections... Connected LDAP server: LDAP Server (192.168.3.60) Connected SQL server: SQL Server (192.168.3.68) Connected PKI server: PKI Server (127.0.0.1) Connected Mail server: SMTP Server (78.141.172.203) Connected Push server: Push Server (91.134.128.157) Connected Session server: Session Server (::1) Connected License server: License Server (91.134.128.157)  Checking LDAP proxy user access... ERROR Checking SQL database access... Ok Checking PKI service access... Ok Checking Mail service access... Ok Checking Push service access... Ok Checking License service access... Ok
          
        

Possible reasons/Solutions :

  • Proxy_user account configured doesn’t exist in the AD,
  • Proxy_user password configured is incorrect,
  • Proxy_user DN configured in
    webadm.conf
    is wrong,

You have to concider the
ldap_treebase
setting in
/otp/webadm/conf/webadm.conf. If
ldap_treebase
setting is configured, then the treebase of your
proxy_user
must be removed (same for super_admin and WebADM containers definition).

E.g for domain name :
yorcdevs.eu

            ldap_treebase "dc=yorcdevs,dc=eu" proxy_user "cn=proxy_user,cn=Users" super_admins "cn=super_administrator,cn=Users" config_container "cn=WebADM"
            
          

If you configure the
ldap_treebase
setting and keep the
ldap_treebase
value in your proxy_user definition, WebADM will try to bind the AD with
cn=proxy_user,cn=User,dc=yorcdevs,dc=eu,dc=yorcdevs,dc=eu
as distinguished Name which will result of a failure. Remove your ldap_treebase value of your proxy_user, super_admins and container configurations.

2.14 Calling WebADM CA for certificate request signing… Failed (Could not sign certificate (rsign_sign_csr() failed))

This is an rsignd (PKI) error. Rsignd logs are available in
/opt/webadm/logs/rsignd.log

When that kind of error happens, double check the PKI password configured in
/opt/webadm/conf/servers.xml
and the password configured for the client in
/opt/webadm/conf/rsignd.conf.

Configuration Server/Client example

The secret I want to configure contain specials characters :
secret&!

/opt/webadm/conf/servers.xml

            
              <PkiServer
              name=
              "PKI Server"
              host=
              "192.168.3.64"
              port=
              "5000"
              secret=
              "secret&!"
              ca_file=
              ""
              />
            
          

/opt/webadm/conf/rsignd.conf

            client
              {
              hostname 192.168.3.64        secret secret&!
              }
            
          

As you can see, the secret is correctly configured on both sides but I can’t still issue SSL certificate from WebADM GUI.

Logs example


          [2022-04-24 09:50:36] [14342] New connection from 192.168.3.64 port 52698 [2022-04-24 09:50:36] [14342] Access refused
          
        

Possible reasons/Solutions :

First, specials characters like & or ! can not be used in that format in
/opt/webadm/conf/servers.xml. That will prevent WebADM to start due to xml parsing with an error like below :

            [email protected] ~]
              # /opt/webadm/bin/webadm restart
              Stopping WebADM Session server... Ok Stopping WebADM PKI server... Ok Checking libudev dependency... Ok Checking system architecture... Ok Checking server configurations... Failed Could not parse XML server definitions file
              '/opt/webadm/conf/servers.xml'
              (xmlParseEntityRef: no name)
            
          

To use that secret in servers.xml, if you’re running
WebADM version 2.0.*
you can encrypt the password with pwcrypt tool :

            
              [[email protected] ~]
              # /opt/webadm/bin/pwcrypt secret$!
              This script allows to encrypt some sensitive WebADM configuration settings like user passwords and encryption keys. You can also replace the cleartext passwords and keys with encrypted values in webadm.conf and servers.xml.  Encrypted:
              {wcrypt}hVe0tjVhHnQlRCUDcQMIfw=
              =
            
          

{wcrypt}hVe0tjVhHnQlRCUDcQMIfw==
value can be used as secret in both
servers.xml
and
rsignd.conf
files.

If you are running
WebADM version 1.7.*, you have two possibilities :

  • You have an entreprise license
    and, in that situation, you can encrypt the password with pwcrypt tool as the above procedure.

  • You don’t have any entreprise license, then you need to encode your password in xml format in
    servers.xml
    like below :

            
              <PkiServer
              name=
              "PKI Server"
              host=
              "192.168.3.64"
              port=
              "5000"
              secret=
              "secret&amp;!"
              ca_file=
              ""
              />
            
          

for
rsignd.conf, the password must be used as below :

          client {        hostname 192.168.3.64        secret secret&! }
          
        

Restart WebADM services to changes takes effect and try to generate a new SSL certificate from
WebADM GUI > Admin > Issue Server or Client SSL Certificate

You should now be able to issue client/server certificate.

2.15 RCDEvs Cloud Service access issue – Connection failed while calling LOGIN:CR_LOGIN

This is an error coming from WebADM (v2.x only) when RCDevs Cloud Services are enabled but can not be reach correctly. The url which must be reachable from your WebADM backends is
https://cloud.rcdevs.com

Logs example

Popular:   Which Post Office Serves My Address

That error can appears during the WebADM start like below :

            
              [[email protected] ~]
              # /opt/webadm/bin/webadm start
              Checking libudev dependency... Ok Checking system architecture... Ok Checking server configurations... Ok  Found Trial license
              (RCDEVSSUPPORT)
              Licensed by RCDevs Security SA to RCDevs Support Licensed product(s): OpenOTP,SpanKey,TiQR  Starting WebADM PKI service... Ok Starting WebADM Session service... Ok Starting WebADM Watchd service... Ok Starting WebADM HTTP service... Ok  Checking server connections...  Connected LDAP server: LDAP Server
              (192.168.3.60)
              Connected SQL server: SQL Server
              (192.168.3.68)
              Connected PKI server: PKI Server
              (127.0.0.1)
              Connected Proxy server: HTTP Proxy
              (192.168.3.1)
              Connected Session server: Session Server
              (::1)
              Checking LDAP proxy user access... Ok Checking SQL database access... Ok Checking PKI service access... Ok Checking Cloud service access... ERROR
              (connection failed
              while
              calling LOGIN:CR_LOGIN)
            
          

Or on the
Admin
tab through WebADM GUI like below :


Possible reasons/Solutions :

  • WebADM server(s) can not reach
    https://cloud.rcdevs.com
    or is/are not able to resolve the DNS name.
  • You are using an HTTP proxy between WebADM and
    https://cloud.rcdevs.com. If you are using a proxy, then be sure
    https://cloud.rcdevs.com
    is reachable from the proxy. The SSL connection between WebADM servers and
    https://cloud.rcdevs.com
    can not be broken by the proxy for SSL interception mode. Your proxy must work in “Transparent” mode.
  • Check that your firewall(s) allow WebADM server(s) to reach
    https://cloud.rcdevs.com
  • Your proxy server configuration on WebADM is wrong. Double check your proxy configuration in
    /opt/webadm/conf/servers.xml
    file.

Tests :

To test the communications with cloud.rcdevs.com from your WebADM server(s), you can use OpenSSL from WebADM server(s) to test the SSL connectivity with RCDevs Cloud Services :


[[email protected] ~]
# openssl s_client -connect cloud.rcdevs.com:443
CONNECTED(00000003)
depth=
2
O
=
Digital Signature Trust Co., CN
=
DST Root CA X3 verify
return:1 depth=
1
C
=
US, O
=
Let's Encrypt, CN = Let's Encrypt Authority X3 verify
return:1 depth=

CN
=
cloud.rcdevs.com verify
return:1 --- Certificate chain

s:CN
=
cloud.rcdevs.com    i:C
=
US, O
=
Let's Encrypt, CN = Let's Encrypt Authority X3
1
s:C
=
US, O
=
Let's Encrypt, CN = Let's Encrypt Authority X3    i:O
=
Digital Signature Trust Co., CN
=
DST Root CA X3 --- Server certificate -----BEGIN CERTIFICATE----- MIIFWjCCBEKgAwIBAgISBAj/h3KAZMgCCOQsXsHCDjWmMA0GCSqGSIb3DQEBCwUA MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMzAeFw0yMDA5MjUyMTAwNTFaFw0y MDEyMjQyMTAwNTFaMBsxGTAXBgNVBAMTEGNsb3VkLnJjZGV2cy5jb20wggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+qvuB7ynZ+g1hQPhojOoRPwbSKYvh JxWCm9WYjt3zEBIPj4XvyecWPmE/unoIfu9O7R65ZKStlGIiODwx0wabLXH/xn/i dvn5mAs0PoUBRd+AWC99RAG3TFf7Yr+vGeFqSbx+V42BcBF+W+KXIAn8TyNb8H7q nvRvZkl6OGHJLYi9N+43E3AJoBXrZQxhQPWxAoX/mg+jtKMnqODknWkY+bIZyQno 7AIzwH0w2u26mmelDoFdQ15U/2tvGnm8orDelmDEEPSf2ovsqBoeH5vcQIU5NNCt KisIupcr08vn9NdkFn/kJwKVGu6N2G5Mn/MIFAsmc5/0GZY3tgBGEi+NAgMBAAGj ggJnMIICYzAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsG AQUFBwMCMAwGA1UdEwEB/wQCMAAwHQYDVR0OBBYEFEIZtJGnyZZlry9ZLFLdel5B Kty0MB8GA1UdIwQYMBaAFKhKamMEfd265tE5t6ZFZe/zqOyhMG8GCCsGAQUFBwEB BGMwYTAuBggrBgEFBQcwAYYiaHR0cDovL29jc3AuaW50LXgzLmxldHNlbmNyeXB0 Lm9yZzAvBggrBgEFBQcwAoYjaHR0cDovL2NlcnQuaW50LXgzLmxldHNlbmNyeXB0 Lm9yZy8wGwYDVR0RBBQwEoIQY2xvdWQucmNkZXZzLmNvbTBMBgNVHSAERTBDMAgG BmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIBFhpodHRwOi8vY3Bz LmxldHNlbmNyeXB0Lm9yZzCCAQYGCisGAQQB1nkCBAIEgfcEgfQA8gB3AAe3XBvl fWj/8bDGHSMVx7rmV3xXlLdq7rxhOhpp06IcAAABdMdIgwkAAAQDAEgwRgIhANdk G9lcmfJPuqG7S3fFD5/YgxJaGa3ejWrogMEDC3hDAiEA2FyrTvPJGYNmvgop2nHj MYtjBPDzD6oczCLGGYJ2mKoAdwBvU3asMfAxGdiZAKRRFf93FRwR2QLBACkGjbII mjfZEwAAAXTHSINgAAAEAwBIMEYCIQCw1//Q2lr2DgAJKRsSvfcaLXLsBLKp9B42 NEDwGz56ZwIhAKbIQUYn4oB9L68ECIwZ+F0vSOLXfsPPxa/s0KFfvXIbMA0GCSqG SIb3DQEBCwUAA4IBAQCROunneQaxr/gY6q8MQ25AU02w2LvxxO0V3uoYOloWFwvr qBgXeUa0sy8zFSUPugd5AStrkERFHOPquZBr481kz4GtEKx/96TgsUTYAUb+tJN3 VrwhmvfIB2Mw6CTRwElRL++cGUeJu/gjB65ojXDtmOmQdTH61K2IMbwk8mNCGKiI Cny3+Itn3PtXrwkQLD/eFLVEAX/svZovHkPcfK1qUdmcPk4YgZJpcllrmtf+B1V1 2w02KWiun7vSB2EKw+gAcapwJxnZWIGz7ZrKdOTz8SE3Q4Kl6aVB9kSJYIkbstyA bjrEnTXtkRtvvuHumR3yyVwiSl5EEiYml6tUgRaO -----END CERTIFICATE----- subject=CN
=
cloud.rcdevs.com  issuer=C
=
US, O
=
Let's Encrypt, CN = Let's Encrypt Authority X3  --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519,
253
bits --- SSL handshake has read
3113
bytes and written
404
bytes Verification: OK --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is
2048
bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify
return
code:

(ok)
--- --- Post-Handshake New Session Ticket arrived: SSL-Session:     Protocol  : TLSv1.3     Cipher    : TLS_AES_256_GCM_SHA384     Session-ID: 8BC21B5E13E2463DDB09CA9640BA76C34180521630CF62B30A27EA605A045A8C     Session-ID-ctx:      Resumption PSK: FC21ADFF2B99BFF5EEF5BC7BF449EF556359A12ECDF7C7B99FB5F46908C8C292D919047D8A8526308D4DDC877A6C4B65     PSK identity: None     PSK identity hint: None     SRP username: None     TLS session ticket lifetime hint:
300
(seconds)
TLS session ticket:
0000
-
81
6c 7a 6d a3
42
f2 cc-1e f8 c8 5a
82
71
9d
05
.lzm.B.....Z.q..
0010
-
94
57
17
53
8c 7b fb 69-ed e8
83
13
c5
54
d7 6b   .W.S.{.i.....T.k
0020
-
53
25
df 0f 4b 5f ad d1-f9
57
5f
42
3c 7a
47
2d   S%..K_...W_B<zG-
0030
- eb 3e
98
6c
65
93
c7 90-d1
83
d1 6e dc e2 7d a6   .>.le......n..}.
0040
- 1c
37
34
87
55
53
6c 9b-67 d4
54
fc e8 a0
30
f6   .74.USl.g.T...0.
0050
- d2 fc f2 fd 3b
92
99
c0-5c 6f 4e
79
43
5a 9c 5e   ....;...\oNyCZ.^
0060
-
34
eb
26
69
aa bc 8d 79-ca 5e 4f 2c 2f 5c f1 8f   4.&i...y.^O,/\..
0070
- 6a
11
9c
10
74
12
65
8c-9c d9 d4 b3 0b 4b cb 4b   j...t.e......K.K
0080
-
46
5d 0a a8 4b
04
13
e3-7f
91
65
c5
08
a4 ed 6d   F]..K.....e....m
0090
- cc 4e ec e4 c1 a2
73
1d-92 8f a8
13
aa cd
39
03
.N....s.......9.     00a0 -
67
53
f7 e7 c0
79
03
ff-bf
29
5a d4 ed
58
03
a5   gS...y...)Z..X..     00b0 - 2f
34
ec be bd ff a2 ee-e7
73
37
8e 6b
91
db 3e   /4.......s7.k..>     00c0 - db
82
04
08
68
6e bf da-11 5e
24
69
21
5d 5b 9f   ....hn...^$i!]
[.     00d0 -
16
8a
46
09
be
23
d9 54-8f e5 6e dc b7
88
86
6b   ..F..#.T..n....k     00e0 -
77
c9 ea
76
8a
18
65
81-b9 c5
13
e5
82
a3 d4
56
w..v..e........V     00f0 -
43
38
72
3e
22
60
b1 e5-5e
01
45
10
4a f8
51
60
C8r>"
`..^.E.J.Q`




Start Time: 1605546287


Timeout   : 7200 (sec)


Verify return code: 0 (ok)


Extended master secret: no


Max Early Data: 0

---

read R BLOCK

---

Post-Handshake New Session Ticket arrived:

SSL-Session:


Protocol  : TLSv1.3


Cipher    : TLS_AES_256_GCM_SHA384


Session-ID: 50FB63F81369F8E7BDF032FA97C598ACDD8FB70DD64CA29BB2C983B8142EFD73


Session-ID-ctx:


Resumption PSK: 706BEB47601374B788E1A1608CC30E9A2FDEC87310349431BC112FBF41E65A1A1446C7089B8F60A605B00E6CACCE9F78


PSK identity: None


PSK identity hint: None


SRP username: None


TLS session ticket lifetime hint: 300 (seconds)


TLS session ticket:


0000 - 81 6c 7a 6d a3 42 f2 cc-1e f8 c8 5a 82 71 9d 05   .lzm.B.....Z.q..


0010 - 51 5a 06 2b 79 a0 1a f9-e8 8b ed 8b de 59 cf 44   QZ.+y........Y.D


0020 - e1 9d 8a c3 a8 30 f1 5d-c3 12 cf 68 d2 91 e2 36   .....0.]...h...6


0030 - 72 85 f7 16 bc 0c e4 4a-72 0f 7a 42 14 53 6d 4b   r......Jr.zB.SmK


0040 - 52 90 29 55 0a 07 66 3b-77 e8 d5 07 b2 54 02 3c   R.)U..f;w....T.<


0050 - c0 35 1b a9 5c 8c ea 32-81 b8 5f 1c e9 dd 82 42   .5..\..2.._....B


0060 - 20 5d 97 d3 7a 25 28 4a-ab 61 5b fc cf 39 10 5d    ]..z%(J.a[..9.]


0070 - c5 e1 20 54 f7 b5 41 c6-5e 3e 01 c1 9b 80 a3 90   .. T..A.^>......


0080 - 02 1a 9e e1 bb c0 18 d8-9e a2 d4 d4 c4 32 c9 73   .............2.s


0090 - e3 d3 24 53 fb 5f 0f d2-53 6f 14 17 84 20 eb 1c   ..$S._..So... ..


00a0 - 61 5e 29 7c 5b 7c fd 2c-8f 2d 06 03 5a 8b 14 e4   a^)|[|.,.-..Z...


00b0 - 7f 26 d0 91 85 7f df 0e-ef fc 4f 03 f6 ff 90 7d   .&........O....}


00c0 - 4b 7c b1 51 c8 46 43 77-44 a3 69 65 00 03 e5 bc   K|.Q.FCwD.ie....


00d0 - 13 e3 0c 3b 99 b2 d5 a2-1c 06 14 c3 dd 15 7d ca   ...;..........}.


00e0 - 0c 6e 0d 81 ce 7b ed ad-b6 16 c7 fe 95 67 a3 d3   .n...{.......g..


00f0 - 69 99 55 2f f3 f2 2a 1c-81 06 60 81 77 f9 70 8a   i.U/..*...`.w.p.




Start Time: 1605546287


Timeout   : 7200 (sec)


Verify return code: 0 (ok)


Extended master secret: no


Max Early Data: 0

---

read R BLOCK

closed


Note

The result of the OpennSSL command may change according to the certificate renewal.

3. Push issues

3.1 Oops, something went wrong (message during push Token registration)

This error appears on OpenOTP Token application when the mobile can not contact the OpenOTP mobile endpoint URL.

Logs example


Possible reasons/Solutions :

  • Check your OpenOTP mobile end point URL under OpenOTP graphical configuration.
  • Check from the mobile if the mobile endpoint URL is reachable.
  • DNS resolution timeout of your mobile endpoint URL can be the origin of that kind of issue if the mobile takes to much time to resolve it.

3.2 Approve/Reject timer is too short when push notification arrives on the phone and prevent you to approve the login request or push notification never arrives to phone

To be compatible with every clients integrations, it’s strongly recommended to keep the default “Mobile Response Timeout” value configured to 30 seconds.

In good networks conditions, the push notification should be delivered on the phone with a timeout arround 25 seconds. The notification takes between 2-5 seconds to appear on the phone when push login request is sent from OpenOTP. You can easily know when the notification has been sent by OpenOTP server with the timestamp in webadm.log :


[2022-04-14 15:55:36]
[192.168.3.64]
[OpenOTP:PT8SDGLY]
Sent push notification
for
token
#1
[2022-04-14 15:55:36]
[192.168.3.64]
[OpenOTP:PT8SDGLY]
Waiting
28
seconds
for
mobile response

At this step of the login process, the push has been sent to the end-user’s phone and OpenOTP wait 28s for push response. Without response within 28s, OpenOTP will send back a challenge-response to the client to allow end users to manually enter their OTP.


[2022-04-14 15:56:04]
[192.168.3.64]
[OpenOTP:PT8SDGLY]
Started OTP authentication session of ID b0oMbEJXS3CdcBAh valid
for
90
seconds
[2022-04-14 15:56:04]
[192.168.3.64]
[OpenOTP:PT8SDGLY]
Sent login challenge response

It’s easy to calculate the timeout value who must appear when you receive the notification on the phone.

  • Notification Timeout start to 28 secs. If notification takes 5s to arrive on the phone, then the timer should be arround 23s.(if the application is not open when receiving the push login request, take into account the time it takes to start the app and popup the login request.) Then the user will have 23s to approve or reject the login before OpenOTP send back a Challenge-reponse and invalid the simple push request. If the notification take more time to be delivered on the end-user phone, it can comes from Apple/Google push services latencies.

  • If the notification takes between 2-5 seconds to appear on the phone and you see a timer much lower than expected (e.g 10s), then it probably means the mobile is not well synchronize with an NTP server. Check NTP synchronization on phone and on WebADM. If the NTP desynchronization is too big (more than 28s), then the push with approve/deny will not be prompted at all on the phone because the request is already expired for the OpenOTP Token application.

  • If it takes more than 5 seconds to appear on the phone, it comes from network latencies between RCDevs Push services and the mobile.

  • If push notification never arrives on the phone, check 3G/4G or Wifi connectivity of your phone.

  • If either the phone time or OpenOTP server time is inaccurate, the timer will be incorrectly calcualted. Please enable network time on the phone and configure NTP sync on the server.

4.3 Could not send push notification to AND:xxx or IOS:xxx

Logs example

[Tue Apr 14 16:09:54.637723 2022] [192.168.3.64] [OpenOTP:H3A5WF97] Could not send push notification to 'AND:eVjRDk5VrZg:APA91bF1v...' [Tue Apr 14 16:10:18.716921 2022] [192.168.3.64] [OpenOTP:JTIRFVI1] Could not send push notification to 'IOS:76e2f09e06f002b40a027...'

Possible reasons/Solutions :

  • If this error appear, check if WebADM server is able to communicate with RCDevs push services. RCDevs Push services are configured in
    /opt/webadm/conf/servers.xml
  • If RCDevs Push services are reachable from your WebADM servers, then the issue comes from the device ID used to push notification on the mobile. Try to register a new token and perform a login to see if the problem persist.
Popular:   Http Prod Sasretail Com en Field

3.4 Invalid mobile registration response

Logs example

[2022-03-20 11:39:29] [195.218.27.170] [OpenOTP:WNXPLREL] Invalid mobile registration response (missing pushid parameter)

This error appears when the mobile response for a Push Token registration is invalid. During Push Token registration, after scanning the QRCode with OpenOTP Token, the mobile communicates with the OpenOTP mobile endpoint URL and forwards following information regarding the device/Token :

  • Session registration ID : Must match with a session registration currently open in OpenOTP.
  • Secret : The final secret is not in the QR code but negotiated between server and token with a key exchange protocol.
  • PIN Code: PIN code is sent for validation if enrolment is protected by a PIN
  • OS Type : IOS or AND.
  • Push ID : Unique identifier used to push notifications on the phone.
  • Serial: Metadata stored on user account,
  • Phone model: Metadata stored on user account.
  • Offset: Only used for HOTP tokens to synchronize the counter between token and server.

Possible reasons/Solutions :

  • iPhone or Android device is jailbreaked or rooted For Android :
  • Google services are not running/installed on the Andoird device
  • Google API call to retrieve the mobile Push ID doesn’t return any value for that device. Push login can not be used in these conditions.

3.5 Connected Push server: ERROR (no server available)

This error can occur when starting WebADM services..

Logs example

[[email protected] ~]# /opt/webadm/bin/webadm restart Stopping WebADM HTTP server... Ok Stopping WebADM Watchd server.... Ok Stopping WebADM Session server... Ok Stopping WebADM PKI server... Ok Checking libudev dependency... Ok Checking system architecture... Ok Checking server configurations... Ok  Found Trial Enterprise license (RCDEVSSUPPORT) Licensed by RCDevs Security SA to RCDevs Support Licensed product(s): OpenOTP,SpanKey,TiQR  Starting WebADM PKI server... Ok Starting WebADM Session server... Ok Starting WebADM Watchd server... Ok Starting WebADM HTTP server... Ok  Checking server connections... Connected LDAP server: LDAP Server (192.168.3.60) Connected SQL server: SQL Server (192.168.3.68) Connected PKI server: PKI Server (127.0.0.1) Connected Mail server: SMTP Server (78.141.172.203) Connected Push server: ERROR (no server available) Connected Session server: Session Server (::1) Connected License server: License Server (91.134.128.157)  Checking LDAP proxy user access... Ok Checking SQL database access... Ok Checking PKI service access... Ok Checking Mail service access... Ok Checking License service access... Ok

Possible reason/Solution :

  • WebADM can not communicate with RCDevs Push services. Check with telnet if push.rcdevs.com and destination port are reachable from WebADM server(s). If not, then check your firewall.

3.6 Checking Push service access… ERROR

This error can occur when starting WebADM services.

Logs example

[[email protected] ~]# /opt/webadm/bin/webadm restart Stopping WebADM HTTP server... Ok Stopping WebADM Watchd server..... Ok Stopping WebADM Session server... Ok Stopping WebADM PKI server... Ok Checking libudev dependency... Ok Checking system architecture... Ok Checking server configurations... Ok  Found Trial Enterprise license (RCDEVSSUPPORT) Licensed by RCDevs Security SA to RCDevs Support Licensed product(s): OpenOTP,SpanKey,TiQR  Starting WebADM PKI server... Ok Starting WebADM Session server... Ok Starting WebADM Watchd server... Ok Starting WebADM HTTP server... Ok  Checking server connections... Connected LDAP server: LDAP Server (192.168.3.60) Connected SQL server: SQL Server (192.168.3.68) Connected PKI server: PKI Server (127.0.0.1) Connected Mail server: SMTP Server (78.141.172.203) Connected Push server: Push Server (91.134.128.157) Connected Session server: Session Server (::1) Connected License server: License Server (91.134.128.157)  Checking LDAP proxy user access... Ok Checking SQL database access... Ok Checking PKI service access... Ok Checking Mail service access... Ok Checking Push service access... ERROR Checking License service access... Ok

Possible reasons/Solutions :

After connections checks during WebADM services start, WebADM will try to perform an authentication to RCDevs push services. The authentication is done by different ways if your are an enterprise or a freeware customer.

Freeware:

Freeware users must have a freeware license to communicate with RCDevs cloud services. Once freeware license is created, you receive an email with a link to download your license.key file which must be located in
/opt/webadm/conf/
folder.

Entreprise:

Your entreprise license is used for authentication and nothing more needs to be configured. You should have a configuration like below :

<PushServer name=
"Push Server"
host=
"push.rcdevs.com"
port=
"7000"
user=
""
password=
""
ca_file=
""
/>

New licenses are pushed every hours on RCDevs licenses servers. Your license needs to be pushed on RCDevs licenses servers first in order to be used with RCDevs Push services. You can encountered this issue if your license has been generated by RCDevs Sales team at 3:10 pm for example and your tried to use it before 4:00 pm. If the problem persists after 1 hour, contact RCDevs support.

4. License issues

Please, have a look on the License Server documentation for any known issues.

5. OpenOTP Token issues

RCDevs provided an update of OpenOTP Token application in December, 2021 for Android and iOS. We reached 100% of the rollout for Android which mean the update is available for all Android devices.

For iOS only 5% of the devices has been updated and the rollout has been stopped until bugs we encountered be fixed by RCDevs.

That update is a major migration from Titanium Framework to React and unfortunately, some issues can be encountered post migration. The issues and possible solutions are listed below.

5.1 Duplicate entries for same Token

It appears on some devices, after the update of the application, Tokens are duplicated. This issue prevent push login login to work properly.

If you entered in that scenario and you are using Push login to authenticate on systems, the solution to that problem is to disable all network connections (4G, Wifi) and remove the duplicated token entry. It doesn’t matter which entry of the duplicated token you remove. Click on one duplicated Token and then press
Delete
button. A confirmation screen appears, press
Yes
:


When you remove Push Tokens with no network connection, a warning like below will appear. Click
Continue
button.


Repeat the operation for all duplicated tokens. Once the duplicated entries are removed, the Push functionnality should be back for the corresponding token(s). You can re-enable network on your phone and try to login with Push notification.

5.2 Prompted for PIN but user do not remember the PIN previously configured

The migration from Titanium to React involves the application protection enabled even if the user disabled it in the past. That setting value could not be kept by the migration process due to technical limitations. It appears that even after uninstall and reinstall the application, the old PIN is still configured. RCDevs is working on that problem.

There is 2 scenarios for that issue and to solve it:

  • The first scenario is, for devices which support biometric protection, enable the biometric feature of your phone and unlock the application with biometric check. In that case, PIN code should be overriden by biometric check. To check that the biometric feature is allowed to be used by OpenOTP token, go on
    Settings
    >
    OpenOTP Token
    and you will see biometric autorization (here Face ID). Take care that feature is enabled. Kill the application and start it again. You should be prompted for biometric unlock. For iOS users which do not have Face ID but have Touch ID, it seems the behavior is a bit different and there is no authorization to allow the app to use the Touch ID. It is allowed by default. Same procedure can be used on Android but Android devices should not be impacted by this.



The biometric unlock is prompted.


  • For Android users which are experiencing that issue and which have biometric support on their phone, if biometric has been enabled for the app, then they should be able to open the app and unlock it via the biometric feature of your phone. If biometric feature is enabled on your phone but has not been specifically enabled for that OpenOTP Token application, enable it for OpenOTP Token application. If user do not have biometric feature on their phone, then they should remove all data and cache information of OpenOTP Token application, uninstall the application, reinstall the application.

If you removed and re-installed the application (version 1.5.3 build 62479804), you should not be prompted for the PIN at the first start.

5.3 Push responses not working anymore

This issue can happen for customers which are not using WebADM Publishing Proxy (WAProxy) and are using another reverse proxy.

If user correctly receive the push notifications as below:


but when they approve the login or signature request, they have a failure like below:


It is probably due to your Web Application Firewall or reverse proxy which is filtering push responses and which do no accept the new parameters with last version of the application.

Found on the following documentation, all parameters which can be forwarded in Push responses and user agent used by iOS and Android for the last version.

An extra note for OPNSense appliances, bot protection is droping mobile Push responses for Android. Have a look on the following github article. Disable the bot protection feature has restaured Push responses forwarding.

6. ___(nothing)

If you have nothing in the webadm.log, it means the request does not arrive in OpenOTP.

Verify that the OpenOTP webservice port 8443 is reachable from the authentication clients, you can check if the client traffic arrives with
tcpdump
command:
tcpdump -i any port 8080 or port 8443
during the authentication.

The next step is to continue troubleshooting in the adapter component (radiusd
/
ldproxy) or client (
Windows Credential Provider
,
ADFS Plugin
etc.).

For a RADIUS authentication with
radiusd, see the troubleshooting chapter in Radius Bridge Manual

For an ldap authentication with
ldproxy, we can verify with
tcpdump -i any port 389 or port 636.

If the result is empty, we check that the port is open from the client. We can use
telnet <webadm server> <port number>.

If it doesn’t respond you have to check firewall rules (don’t forget the local firewall on the server) and routing.

Otp Login Failed With Unknown Issue

Source: https://docs.rcdevs.com/howtos/troubleshooting/troubleshooting/