Troubleshooting

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.

WebADM/OpenOTP common issues

The first step when a login fails for an unknown reason is to check the log file at /opt/webadm/log/webadm.log to locate the relevant log entry. You can also access this log through the WebADM interface by navigating to WebADM > Databases > WebADM Server Log files.

Please note that this log is server-specific, so in a clustered environment, you'll need to check the log on each server individually.

User invalid or not found

Logs example :

[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] New openotpSimpleLogin SOAP request
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] > Username: mike.doe@rcdevsdocs.com
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] > Password: xxxxxxxx
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] > Client ID: RadTest
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] >  Options: RADIUS,-U2F
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] Registered openotpSimpleLogin request
[2024-08-28 17:59:12] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] Recorded alert in SQL database
[2024-08-28 17:59:13] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] Sent alert email to noreply@rcdevsdocs.com
[2024-08-28 17:59:13] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] User invalid or not found
[2024-08-28 17:59:13] [192.168.4.160:34798] [OpenOTP:D8XVEJEG] Sent failure response

Possible reasons/solutions :

The account doesn't exist in the LDAP.
The user account is not activated in WebADM (not licensed).
The username used during authentication (e.g., mike.doe@rcdevsdocs.com) doesn't match any user in the LDAP. The username attributes checked by WebADM can be found in the /opt/webadm/conf/webadm.conf file under the uid_attrs setting and can be reconfigured at the Client Policy level.

For Active Directory (AD), the default username attributes are:

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

The proxy_user configured in /opt/webadm/conf/webadm.conf does not have read permission on the user account.
The user is outside the user search base(s) configured in the corresponding WebADM Domain. Adjust the User search base setting in your WebADM domain to include the container where the user is located.

Logs example :

[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] New openotpNormalLogin SOAP request
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > Username: john.doe
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > Domain: rcdevsdocs
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > LDAP Password: xxxxxxxx
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > Client ID: OpenOTP
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > Source IP: 192.168.3.205
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] > Context: a3ce6ebb07573383a7ba56db13a96a4d
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Registered openotpNormalLogin request
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Resolved LDAP groups: it,enterprise admins (cached)
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Started transaction lock for user
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Found user language: EN
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Found 1 user mobiles: +33612345678
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Found 1 user emails: john.doe@rcdevsdocs.com
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=Yes,MaxWeak=1,BlockNotify=MAIL,ExpireNotify=MAIL,WeakNotify=MAIL,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Preferred,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Found 7 user data: ListInit,ListState,AppKeyInit,Device1Type,Device1Name,Device1Data,Device1State
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] OTP List present (0/50 passwords used)
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] User has no OTP token registered
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] No usable login method found
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Sent failure response

Possible reasons/solutions :

The authentication policy requires a second factor that the user cannot provide. In this case, the OpenOTP login mode is set to LDAP+OTP, and the OTP type is set to TOKEN, but the user does not have an OTP token registered. The solution is to register an OTP token on the user's account. Alternatively, you can configure a fallback method like MAIL. In that scenario, the OTP would be sent via email if the user account has an email address configured and an SMTP backend is set up within the WebADM framework.

With the User Self-Registration (SelfReg) application, you can automatically send a self-registration request by email or SMS to users who do not have a token registered or whose token has expired. To enable this feature, you need to configure the following setting under the OpenOTP configuration:

When this setting is enabled, you will see the following logs:

...
2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Resolved LDAP groups: it,enterprise admins (cached)
[2024-08-29 10:38:38] [127.0.0.1:58738] [OpenOTP:W8EOSWVF] Sent self-registration request for OpenOTP OTP

A self-registration request has been sent to the end user, who can now access the User Self-Registration application through the one-time link provided via email. After registering their token, they can retry the login.

Wrong TOTP/HOTP Password

Logs example :

[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] New openotpNormalLogin SOAP request
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > Username: john.doe
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > Domain: rcdevsdocs
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > LDAP Password: xxxxxxxx
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > Client ID: OpenOTP
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > Source IP: 192.168.3.205
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] > Context: e0e39884b25f58ed744e838159b9024e
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Registered openotpNormalLogin request
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com (cached)
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Resolved LDAP groups: it,enterprise admins (cached)
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Started transaction lock for user
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found user language: EN
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found 1 user mobiles: +33612345678
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found 1 user emails: john.doe@rcdevsdocs.com
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,MaxWeak=1,BlockNotify=MAIL,ExpireNotify=MAIL,WeakNotify=MAIL,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Preferred,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found 12 user data: ListInit,ListState,AppKeyInit,Device1Type,Device1Name,Device1Data,Device1State,TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] OTP List present (0/50 passwords used)
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Found 1 registered OTP token (TOTP)
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Requested login factors: LDAP & OTP
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] LDAP password Ok
[2024-08-29 11:33:35] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Authentication challenge required
[2024-08-29 11:33:40] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Sent push notification for token #1 (session 2sgC1bGjVzBGgIWn)
[2024-08-29 11:33:40] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Started OTP authentication session of ID 2sgC1bGjVzBGgIWn valid for 90 seconds
[2024-08-29 11:33:40] [127.0.0.1:47574] [OpenOTP:5X6EZ1II] Sent login challenge response
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] New openotpChallenge SOAP request
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] > Username: john.doe
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] > Domain: rcdevsdocs
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] > Session: 2sgC1bGjVzBGgIWn
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] > OTP Password: xxxxxx
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Found authentication session started 2024-08-29 11:33:35
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Started transaction lock for user
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Wrong PUSH password (token #1)
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Wrong TOTP password (token #1)
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Updated user data
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Sent terminate notification for token #1
[2024-08-29 11:33:46] [127.0.0.1:37792] [OpenOTP:5X6EZ1II] Sent failure response

Possible reasons/Solutions :

A wrong OTP password was provided during the authentication request.
If the OTP was provided correctly but the login still fails, the token might be desynchronized. Try to resynchronize it through WebADM GUI > <USER_ACCOUNT> > MFA Authentication Server > Resynchronize Tokens or through Self-services and then retry the login.

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=John Doe,CN=Users,DC=rcdevsdocs,DC=com' (Insufficient access)
[2018-10-16 11:20:04] [10.10.0.3] [OpenOTP:L9RLQWCV] Could not set user data for 'CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com'

Possible reasons/Solutions :

This issue occurs because the proxy_user account configured in /opt/webadm/conf/webadm.conf lacks sufficient permissions to write metadata on the user account attempting to authenticate.

A similar error can happen with a super_admin account connected to the WebADM GUI or using the WebADM Manager API if it tries to edit LDAP objects without adequate permissions on the LDAP directory.

Refer to the proxy_user and super_admin ACL documentation for Active Directory for instructions on how to set the appropriate permissions for proxy_user and super_admins on AD.

Account is disabled in Active Directory

Logs example

[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] New openotpNormalLogin SOAP request
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > Username: john.doe
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > Domain: rcdevsdocs
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > LDAP Password: xxxxxxxx
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > Client ID: OpenOTP
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > Source IP: 192.168.3.205
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] > Context: 7d1cabb55b64a97056f2fa3834b97b18
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Registered openotpNormalLogin request
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Resolved LDAP groups: it,enterprise admins
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Started transaction lock for user
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Found user language: EN
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Found 1 user mobiles: +33612345678
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Found 1 user emails: john.doe@rcdevsdocs.com
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,MaxWeak=1,BlockNotify=MAIL,ExpireNotify=MAIL,WeakNotify=MAIL,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Preferred,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Found 12 user data: ListInit,ListState,AppKeyInit,Device1Type,Device1Name,Device1Data,Device1State,TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Account is disabled in AD
[2024-08-29 11:41:49] [127.0.0.1:45648] [OpenOTP:J2PKOZ1W] Sent failure response

Possible reasons/Solutions :

You may encounter this error if the user account is disabled in Active Directory. To resolve this, enable the account in AD and then retry the login.

Wrong LDAP password

Logs example

[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] New openotpNormalLogin SOAP request
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > Username: john.doe
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > Domain: rcdevsdocs
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > LDAP Password: xxxxxx
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > Client ID: OpenOTP
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > Source IP: 192.168.3.205
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] > Context: a20d46f0167156e6d9a6bf3df1e51afa
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Registered openotpNormalLogin request
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Resolved LDAP groups: it,enterprise admins
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Started transaction lock for user
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found user language: EN
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found 1 user mobiles: +33612345678
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found 1 user emails: john.doe@rcdevsdocs.com
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,MaxWeak=1,BlockNotify=MAIL,ExpireNotify=MAIL,WeakNotify=MAIL,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Preferred,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found 12 user data: ListInit,ListState,AppKeyInit,Device1Type,Device1Name,Device1Data,Device1State,TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] OTP List present (0/50 passwords used)
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Found 1 registered OTP token (TOTP)
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Requested login factors: LDAP & OTP
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Wrong LDAP password
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Updated user data
[2024-08-29 11:48:23] [127.0.0.1:36818] [OpenOTP:TJVE8U3B] Sent failure response

Possible reasons/Solutions :

Wrong LDAP password has been provided during the authentication process.
The user account is locked through the OpenOTP badging feature and the corresponding Option Sets configured matching that account. The account will remain unusable until the user completes the badging process.
> With ActiveDirectory the logonHours attribute is used to prevent login.
> With OpenLDAP the pwdAccountLockedTime is used (password lockout must be enabled in the password policy object).
> With Novell eDirectory, the loginDisabled attribute is used.
> With DS389 directory the nsAccountLock attribute is used.

Refer to Option Sets and OpenOTP Badging documentations.

Account has been blocked / Blocking account permanently after x failures

Logs example

[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] New openotpNormalLogin SOAP request
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > Username: john.doe
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > Domain: rcdevsdocs
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > LDAP Password: xxxxxxxxx
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > Client ID: OpenOTP
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > Source IP: 192.168.3.205
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] > Context: d89d9aa821c6d41172a4d9f0d0e88b2b
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Registered openotpNormalLogin request
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Resolved LDAP user: CN=John Doe,CN=Users,DC=rcdevsdocs,DC=com
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Resolved LDAP groups: it,badged_users,office_badged_users,enterprise admins
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Started transaction lock for user
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found user language: EN
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found 1 user mobiles: +33612345678
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found 1 user emails: john.doe@rcdevsdocs.com
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found 50 user settings: LoginMode=LDAPOTP,OTPType=TOKEN,PushLogin=No,MaxTries=1,MaxWeak=1,BlockNotify=MAIL,ExpireNotify=MAIL,WeakNotify=MAIL,ChallengeMode=Yes,ChallengeTimeout=90,OTPLength=6,OfflineExpire=30,MobileTimeout=30,EnableLogin=Yes,SelfRegister=Yes,PasswordReset=Yes,HOTPLookAheadWindow=25,TOTPTimeStep=30,TOTPTimeOffsetWindow=120,OCRASuite=OCRA-1:HOTP-SHA1-6:QN06-T1M,U2FPINMode=Preferred,SMSType=Normal,SMSMode=Ondemand,MailMode=Ondemand,PrefetchExpire=10,LastOTPTime=300,ListChallengeMode=ShowID
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found 12 user data: ListInit,ListState,AppKeyInit,Device1Type,Device1Name,Device1Data,Device1State,TokenType,TokenKey,TokenState,TokenID,TokenSerial
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] OTP List present (0/50 passwords used)
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Found 1 registered OTP token (TOTP)
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Requested login factors: LDAP & OTP
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Wrong LDAP password
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Blocking account permanently after 3 failures
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Recorded alert in SQL database
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Sent alert email to yoann@rcdevs.com
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Sent blocking email to john.doe@rcdevsdocs.com
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Updated user data
[2024-08-29 12:00:58] [127.0.0.1:43632] [OpenOTP:WGVU8536] Sent failure response

Possible reasons/Solutions :

Blocking account permanently after x failures means that the user account is blocked in OpenOTP due to multiple login failures. This occurs if blocking account settings are configured in the OpenOTP configuration.

To unblock the account through the WebADM Administrator Portal, log in to WebADM GUI > <USER_ACCOUNT> > MFA Authentication Server > Unblock Account.

Account already under transaction / User under transaction

Logs example

[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] New openotpSimpleLogin SOAP request
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Username: administrator
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Password: xxxxxxxx
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Client ID: RadTest
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] > Options: RADIUS,-U2F
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] Registered openotpSimpleLogin request
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] Resolved LDAP user: CN=Administrator,CN=Users,DC=yorcdevs,DC=eu (cached)
[2020-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
[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
[2020-04-15 12:49:02] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
[2020-04-15 12:49:03] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
[2020-04-15 12:49:04] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
[2020-04-15 12:49:05] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)
[2020-04-15 12:49:06] [192.168.3.64] [OpenOTP:84YBCGAX] Account already under transaction
[2020-04-15 12:49:06] [192.168.3.64] [OpenOTP:84YBCGAX] Sent failure response

Possible reasons/Solutions :

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 :

[2020-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 :

[2020-04-15 12:49:01] [192.168.3.64] [OpenOTP:84YBCGAX] User under transaction (retrying user lock in 1 second)

This can happen if the user try to log in simultaneously 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.

Domain xxx not existing

Logs example

[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] > Username: administrator
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] > Domain: docsrcdevs
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] > Password: xxxxxxxxxxxx
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] > Client ID: LDAP
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] > Source IP: 8.8.8.8
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] Registered openotpSimpleLogin request
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] Checking OpenOTP license for RCDevs Documentation
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] License Ok (4/10 active users)
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] Domain 'docsrcdevs' not existing
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] User invalid or not found
[2024-08-30 09:48:42] [192.168.3.205:61874] [OpenOTP:846C8MVC] Sent failure response

Possible reasons/solutions :

This error occurs when the domain provided during the authentication request does not match any user domain configured in WebADM. In this case, the provided domain is docsrcdevs.

To fix this, follow these steps in the WebADM GUI:

Check Existing Domains:
- Go to WebADM GUI > Admin > User Domain.
- If a domain named Default already exists in your configuration and the user attempting to authenticate is part of that domain, you can add docsrcdevs as a Domain Name Alias in the existing domain.
- Alternatively, you can rename the Default domain to docsrcdevs and add Default as a Domain Name Alias.
Considerations When Renaming Domains:
- If you choose to rename the domain to a custom value like docsrcdevs and do not want to use Default as a Domain Name Alias, you'll need to edit each Web Application and WebService configuration to adjust the default domain value to the new one.
Creating a New Domain:
- If the user is not part of an existing configured domain, create a new WebADM domain with a user search base that includes the users who need to authenticate under the docsrcdevs domain.

Domain not provided and no default domain configured

Logs example

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

Possible reasons/Solutions :

This error occurs when there is no default domain configured in WebADM, Web Services, or Web Applications, and an authentication request does not include domain information.

The domain can be enforced at multiple levels within the WebADM framework, such as in the applications/services configuration, under client policies, or in the webadm.conf file.

To resolve this, configure the domain accordingly or provide a domain value in the authentication request.

Server is unwilling to perform

This error can occur for multiple reasons in WebADM and originates from Active Directory. When you see this error, it indicates that the attempted action cannot be performed on the remote Active Directory.

Logs example

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

[2020-04-20 09:58:21] [192.168.3.1] [Admin:58SR60O3] Could not modify LDAP object 'CN=RCDevs,CN=Users,DC=rcdevsdocs,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, which causes Active Directory to refuse password changes over an unencrypted connection. To fix this issue, you need to secure the connection by configuring SSL or TLS encryption.

There is multiple ways to check if LDAPS is enabled on your Active Directory infrastructure. Here, we will check with OpenSSL:

openssl s_client -connect 192.168.4.2:636

CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = AD1.rcdevsdocs.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = AD1.rcdevsdocs.com
verify error:num=21:unable to verify the first certificate
verify return:1
depth=0 CN = AD1.rcdevsdocs.com
verify return:1
---
Certificate chain
 0 s:CN = AD1.rcdevsdocs.com
   i:DC = com, DC = rcdevsdocs, CN = ADCA
   a:PKEY: rsaEncryption, 2048 (bit); sigalg: RSA-SHA256
   v:NotBefore: Nov 29 09:45:26 2023 GMT; NotAfter: Nov 28 09:45:26 2024 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIGjTCCBXWgAwIBAgITHAAAALo6avTg+FFoTQAAAAAAujANBgkqhkiG9w0BAQsF
ADBZMRMwEQYKCZImiZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGcmNkZXZz
MRcwFQYKCZImiZPyLGQBGRYHc3VwcG9ydDERMA8GA1UEAxMIU1VQQ0FBRDIwHhcN
MjMxMTI5MDk0NTI2WhcNMjQxMTI4MDk0NTI2WjAkMSIwIAYDVQQDExlBRDIyLTEu
c3VwcG9ydC5yY2RldnMuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC
AQEAt4VN7XzqUBYj5JQrQMlTx0vsrCatLosQbdRiQzh5YwiyVpqKXL2q0WLLRVxZ
/N36iIaGFq+9HjlvHdLJOSn9b0UhgrDZGHPYPcll5q+DGhk7MSZZNBSC8DU51drl
kCRwHCV18fCV+94VnWNEfcZBpPglLbXrMbM3FSGgDv8CgHm0rFOo4MVC9MMZuTPQ
s+3FQPDQqRooUvLBRkgD1pwaKvFOBv8pOMKOPwjhfRC4GEy8Sv2ZTVjIVBuj2T7Q
oS8W5O3Qz5F8HwLR+RVbzrxsX9S1dZCRuTbK6204g/YqMRgn4wI0BXEd0+4kl+Zd
aXHD6EzVi9h5F2DxTLDGg9sRHQIDAQABo4IDgTCCA30wLwYJKwYBBAGCNxQCBCIe
IABEAG8AbQBhAGkAbgBDAG8AbgB0AHIAbwBsAGwAZQByMB0GA1UdJQQWMBQGCCsG
AQUFBwMCBggrBgEFBQcDATAOBgNVHQ8BAf8EBAMCBaAweAYJKoZIhvcNAQkPBGsw
aTAOBggqhkiG9w0DAgICAIAwDgYIKoZIhvcNAwQCAgCAMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEAS0wCwYJYIZIAWUDBAECMAsGCWCGSAFlAwQBBTAHBgUrDgMCBzAK
BggqhkiG9w0DBzAdBgNVHQ4EFgQUv7DRpx6gbUdaRiHBWFABeHY6m/QwHwYDVR0j
BBgwFoAU2vCNPJTo59rA87s0RIotTU4axd8wgc8GA1UdHwSBxzCBxDCBwaCBvqCB
u4aBuGxkYXA6Ly8vQ049U1VQQ0FBRDIsQ049QUQxOS0yLENOPUNEUCxDTj1QdWJs
aWMlMjBLZXklMjBTZXJ2aWNlcyxDTj1TZXJ2aWNlcyxDTj1Db25maWd1cmF0aW9u
LERDPXN1cHBvcnQsREM9cmNkZXZzLERDPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRp
b25MaXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwgfcG
CCsGAQUFBwEBBIHqMIHnMIGxBggrBgEFBQcwAoaBpGxkYXA6Ly8vQ049U1VQQ0FB
RDIsQ049QUlBLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2Vz
LENOPUNvbmZpZ3VyYXRpb24sREM9c3VwcG9ydCxEQz1yY2RldnMsREM9Y29tP2NB
Q2VydGlmaWNhdGU/YmFzZT9vYmplY3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9y
aXR5MDEGCCsGAQUFBzABhiVodHRwOi8vQUQxOS0yLnN1cHBvcnQucmNkZXZzLmNv
bS9vY3NwMEUGA1UdEQQ+MDygHwYJKwYBBAGCNxkBoBIEEPt33dwit8VIpkoX8x4R
/mqCGUFEMjItMS5zdXBwb3J0LnJjZGV2cy5jb20wTgYJKwYBBAGCNxkCBEEwP6A9
BgorBgEEAYI3GQIBoC8ELVMtMS01LTIxLTI1NTY3ODgxNDgtMjY1MDY4NjczMi01
MDYyMDUwNDktMjE5NTANBgkqhkiG9w0BAQsFAAOCAQEAL4Iuoe+M/zyp54T9Ictn
+QiWaQNbWfq5o/z4xS0kFpS8BBvGcsopxvPQQsLrnsaFDh6p2swYjE59mbXNS2PR
wUDdToNO1xGnM4PjNNMHoIDggsST/+T+TWKiiQuF35q3MaCq3kN5Gr9Nq4UwukQS
2Q8FBkHaDLqTtYGiTo8+LvmSrVgGJUtC6CFAGv+ZIulXC5kWphThmqEiz36RTxvv
BoT+MjLXlW2Bfr4TnxIt+VFd8fpisaBI5GZQ9UkotA2+mM9iAONw8RRp+hcRCPYt
lnSfRR95HCYZ/3dShoXAjchlBUP/xBGeVxWmiEeHuWlXCu9PEJslEVdSU5UOQfCs
2A==
-----END CERTIFICATE-----
subject=CN = AD1.rcdevsdocs.com
issuer=DC = com, DC = rcdevsdocs, CN = ADCA
---
No client certificate CA names sent
Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:0x01+0x02:ECDSA+SHA256:ECDSA+SHA384:0x03+0x02:0x02+0x02:RSA+SHA512:ECDSA+SHA512
Shared Requested Signature Algorithms: RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:ECDSA+SHA256:ECDSA+SHA384:RSA+SHA512:ECDSA+SHA512
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2208 bytes and written 405 bytes
Verification error: unable to verify the first certificate
---
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: 21 (unable to verify the first certificate)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Session-ID: 9EB7DED8B6CCEFA35CEFC76ECADC5629C79A359FCEBA1C1BC17C55A1DA772DD8
    Session-ID-ctx: 
    Resumption PSK: 24B1E6CF8AE233B5B419CDC96230F00188BC9204A2E166B7F4992648D2E912738D9B61726E17B71BB9B7541C5B762AE8
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket lifetime hint: 36000 (seconds)
    TLS session ticket:
    0000 - 62 35 00 00 ec 39 a6 c4-3f e9 25 b5 f9 b3 1d e1   b5...9..?.%.....
    0010 - 4c 2a 01 cc 7f 47 8f 6d-3e c7 ec 3b ec eb 63 6e   L*...G.m>..;..cn

    Start Time: 1725005820
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
    Max Early Data: 0
---
read R BLOCK

Port is open and reachable from WebADM Server, LDAPS can then be used.
Edit /opt/webadm/conf/servers.xml file.

Another possible reason is that the provided password does not meet the Active Directory password policy requirements.

Missing client certificate or subject

Logs example

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

Possible reasons/solutions :

This error can occur if the OpenOTP setting "Require Client Certificate" is enabled and the OpenOTP client doesn't provide a client certificate during communication with OpenOTP.

To resolve this issue:

Issue a Client Certificate: Use WebADM PKI to issue a client certificate for your OpenOTP client and configure the certificate on the client.
Disable the Setting: Alternatively, you can disable the "Require Client Certificate" setting in the OpenOTP configuration.

Checking LDAP proxy user access... ERROR

This error can occur when starting WebADM services.

Logs example

[root@webadm1 ~]# /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

Possible reasons/Solutions :

The proxy_user account configured does not exist in Active Directory.
The proxy_user password configured is incorrect.
The proxy_user DN configured in webadm.conf is incorrect.

You need to consider the ldap_treebase setting in /opt/webadm/conf/webadm.conf. If the ldap_treebase setting is configured, the treebase for your proxy_user must be removed. This also applies to super_admin accounts and WebADM container definitions.

E.g for domain name: rcdevsdocs

ldap_treebase "dc=rcdevsdocs,dc=com"
proxy_user "cn=proxy_user,cn=Users"
super_admins "cn=super_admins,cn=Users"
config_container "cn=WebADM"

If you configure the ldap_treebase setting and retain the ldap_treebase value in your proxy_user definition, WebADM will attempt to bind to AD using a distinguished name like cn=proxy_user,cn=User,dc=rcdevsdocs,dc=com,dc=rcdevsdocs,dc=com, which will result in a failure.

Remove the ldap_treebase value from your proxy_user, super_admin, and container configurations to resolve this issue.

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

This is a RSignd (PKI service) error. The rsignd logs can be found in /opt/webadm/logs/rsignd.log.

When this error occurs, double-check the following:

The PKI password configured in /opt/webadm/conf/servers.xml.
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 still can't issue an SSL certificate from the WebADM GUI.

Logs example

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

Possible reasons/Solutions :

First, special characters such as & or ! cannot be used in that format in /opt/webadm/conf/servers.xml. Using these characters will prevent WebADM from starting due to XML parsing errors. You might see an error like this:

root@webadm1 ~]# /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 this secret in servers.xml, you can encrypt the password with the pwcrypt tool. Note that the pwcrypt tool requires an enterprise or Trial license to be used. Freeware license can not use it.

[root@webadm1 ~]# /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 don't have any enterprise/Trial 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.

RCDevs Cloud Service access issue - Connection failed while calling LOGIN:CR_LOGIN

This error occurs in WebADM (v2.x only) when RCDevs Cloud Services are enabled but cannot be reached correctly. The URL that must be reachable from your WebADM backends is https://cloud.rcdevs.com.

Logs example

That error can appear during the WebADM startup, as shown below or through the WebADM GUI.

[root@webadm1 ~]# /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)

Possible reasons/solutions :

WebADM server(s) cannot reach https://cloud.rcdevs.com or are unable to resolve the DNS name.
An HTTP proxy is used between WebADM and https://cloud.rcdevs.com. Ensure that https://cloud.rcdevs.com is reachable from the proxy. The SSL connection between WebADM servers and https://cloud.rcdevs.com should not be broken by the proxy in SSL interception mode. The proxy must operate in "Transparent" mode.
Verify that your firewall(s) allow WebADM server(s) to reach https://cloud.rcdevs.com.
The proxy server configuration on WebADM may be incorrect. Double-check your proxy settings in the /opt/webadm/conf/servers.xml file.

Tests:
To test communication with cloud.rcdevs.com from your WebADM server(s), you can use OpenSSL to check SSL connectivity with RCDevs Cloud Services. Use the following command:

[root@webadm1 ~]# 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=0 CN = cloud.rcdevs.com
verify return:1
---
Certificate chain
 0 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: 0 (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

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

Push issues

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

This error appears on the OpenOTP Token application when the mobile device cannot contact the OpenOTP mobile endpoint URL.

Possible Reasons/Solutions:

Verify Endpoint URL: Check the OpenOTP mobile endpoint URL in the OpenOTP graphical configuration.
Check Connectivity: Ensure the mobile device can reach the mobile endpoint URL.
DNS Resolution Issues: A DNS resolution timeout for the mobile endpoint URL could cause this issue if it takes too long for the mobile device to resolve the URL.

To ensure compatibility with all client integrations, it is strongly recommended to keep the default "Mobile Response Timeout" value set to 30 seconds in the OpenOTP configuration.

Under optimal network conditions, the push notification should be delivered to the phone within approximately 25 seconds. The notification typically appears on the phone within 2-5 seconds after the push login request is sent from OpenOTP. You can verify when the notification was sent by checking the timestamp in the webadm.log file.

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

At this stage of the login process, the push notification has been sent to the end-user's phone, and OpenOTP waits for a response for 28 seconds. If no response is received within 28 seconds, OpenOTP will prompt the client with a challenge-response, allowing the end user to manually enter their OTP.

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

It’s easy to calculate the timeout value that should appear when you receive the notification on your phone.

Notification Timeout: The notification timeout starts at 28 seconds. If the notification takes 5 seconds to arrive on the phone, the remaining timer should be around 23 seconds. If the application is not open when the push login request arrives, account for the time it takes to start the app and display the login request. The user will have 23 seconds to approve or reject the login before OpenOTP sends a challenge-response and invalidates the push request. Longer delivery times may be due to latencies in Apple/Google push services.
Shorter Timer: If the notification takes between 2-5 seconds to appear on the phone, but you see a timer much shorter than expected (e.g., 10 seconds), this may indicate that the mobile device is not properly synchronized with an NTP server. Check NTP synchronization on both the phone and WebADM. Significant NTP desynchronization (more than 28 seconds) can cause the push request to expire before the approval/denial prompt is displayed.
Network Latencies: If it takes more than 5 seconds for the notification to appear on the phone, network latencies between RCDevs Push services and the mobile device may be the cause.
No Notification: If the push notification never arrives on the phone, check the 3G/4G or Wi-Fi connectivity of the device.
Time Accuracy: If either the phone's time or the OpenOTP server time is inaccurate, the timer calculation will be incorrect. Ensure that network time is enabled on the phone and configure NTP synchronization on the server.

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

Logs example

[Tue Apr 14 16:09:54.637723 2020] [192.168.3.64] [OpenOTP:H3A5WF97] Could not send push notification to 'AND:eVjRDk5VrZg:APA91bF1v...'

[Tue Apr 14 16:10:18.716921 2020] [192.168.3.64] [OpenOTP:JTIRFVI1] Could not send push notification to 'IOS:76e2f09e06f002b40a027...'

Possible reasons/Solutions :

If this error appears, check if the WebADM server can communicate with RCDevs Push services. The RCDevs Push services are configured in /opt/webadm/conf/servers.xml.
If RCDevs Push services are reachable from your WebADM servers, the issue may be related to the device ID used to push notifications to the mobile. Try registering a new token and perform a login to see if the problem persists.

Invalid mobile registration response

Logs example

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

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

Session Registration ID: Must match a session registration currently open in OpenOTP.
Secret: The final secret is not in the QR code but is negotiated between the server and token using a key exchange protocol.
PIN Code: Sent for validation if enrollment is protected by a PIN.
OS Type: Indicates whether the device is iOS or Android.
Push ID: A unique identifier used to push notifications to the phone.
Serial: Metadata stored on the user account.
Phone Model: Metadata stored on the user account.
Offset: Used only for HOTP tokens to synchronize the counter between the token and server.

Possible reasons/Solutions :

Jailbroken or Rooted Device: The iPhone or Android device is jailbroken or rooted.

For Android:

Google Services: Google services are not running or installed on the Android device.
Google API: The Google API call to retrieve the mobile Push ID does not return any value for the device. Push login cannot be used under these conditions.

License issues

Given Token is out of Sync

When you restore a snapshot, the previous One-Time License Token is also restored, which is often invalid. The token rotates every time WebADM connects to the license services. If you reuse an old token (e.g., after a snapshot restore), the token between the license services and WebADM will be out of sync.

If your license pool is full (2 nodes by default), WebADM will not automatically reconnect to the license service and perform a resync. In this case, you need to manually unbind the old client to free up a license client slot for the restored version of WebADM.

To do this:

Log in to the GUI of your restored WebADM server.
Click on the 'Admin' tab and then 'Software License Details'.
Scroll down to the 'License Server Client' section.
Click the 'Unbind' button to release the old license client slot.

Server Pool - No license slot left in the corresponding pool

The licensing model is based on the number of users and the number of WebADM instances that you want to configure.

WebADM Servers IPs doesn't matter anymore with license servers. You have now a pool with x servers allowed according to the license you ordered. If your pool is full, and you want to connect another WebADM instance in this pool, you need to unbind one server to free up one slot in your pool. To remove an instance from your server pool, log into the WebADM Admin GUI, click on the Admin tab, Software License Details and in License Server Client, find the client in question and click Unbind Client to remove the client from your pool.

License error for product OpenOTP (active users limit exceeded)

This error appears when you have activated more users than your license allows. Freeware licenses permit activation of up to 20 users. You can check the number of activated users through the WebADM GUI by navigating to Admin > Software License Details.

Logs example

[2020-04-17 18:50:45] [192.168.3.64] [OpenOTP:RCKOG0P2] License error for product OpenOTP (active users limit exceeded)

Solutions :

Contact RCDevs Sales Team: Reach out to the RCDevs sales team to order or extend your license to accommodate the number of activated users.
Deactivate Accounts: Deactivate enough accounts to bring the number of activated users within the limit of your current license.

After deactivating users, you can manually clear the license cache to update the count of activated users. To clear the WebADM license cache, log in to the WebADM GUI and navigate to Admin > Clear WebADM License Cache, or restart the WebADM services.

Troubleshooting

Overview

WebADM/OpenOTP common issues

User invalid or not found

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

Wrong TOTP/HOTP Password

Could not modify LDAP object / Could not set user data

Account is disabled in Active Directory

Wrong LDAP password

Account has been blocked / Blocking account permanently after x failures

Account already under transaction / User under transaction

Domain xxx not existing

Domain not provided and no default domain configured

Server is unwilling to perform

Missing client certificate or subject

Checking LDAP proxy user access... ERROR

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

RCDevs Cloud Service access issue - Connection failed while calling LOGIN:CR_LOGIN

Push issues

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

The approve/reject timer may be too short when a push notification arrives on your phone, preventing you from approving the login request, or the push notification may never arrive on your phone.

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

Invalid mobile registration response

License issues

Given Token is out of Sync

Server Pool - No license slot left in the corresponding pool

License error for product OpenOTP (active users limit exceeded)