nextcloud openotp signature problems

[Richard Palo]

I'm trying to get openotp auth and signatures working, auth seems ok, though I'm probably using compatibility mode.

Having enabled LDAP in nextcloud with  WebAPP+OpenLDAP, user logins seem fine

once I disabled my 'database' account.

That is, the 'database' account has the user_id that was my uid= equivalent.  

With 'ldap', that's different.  

Here is an extract from `occ user:list -i` for myself:

```

  - a129eeab-25dd-42d9-89de-51c233c135c8:
   - user_id: a129eeab-25dd-42d9-89de-51c233c135c8
   - display_name: Richard PALO
   - email: richard.palo@<mydomain.com>
   - cloud_id: a129eeab-25dd-42d9-89de-51c233c135c8@<mycompany.com>
   - enabled: true
   - groups:
     - 0: admin
   - quota: none
   - first_seen: 2025-04-30T08:03:15+00:00
   - last_seen: 2025-04-30T13:15:27+00:00
   - user_directory: /var/lib/nextcloud/data/a129eeab-25dd-42d9-89de-51c233c135c8
   - backend: LDAP
 - richard:
   - user_id: richard
   - display_name: Richard PALO
   - email: richard.palo@<mydomain.com>
   - cloud_id: richard@<mydomain.com>
   - enabled: false
   - groups:
     - 0: admin
   - quota: none
   - first_seen: unknown
   - last_seen: 2025-04-30T13:03:33+00:00
   - user_directory: /var/lib/nextcloud/data/richard
   - backend: Database

```

When I try to test self signing a document with openotp, the following popup shows:

In the webadm logs (having debug enabled), indeed the wrong value for uid= is given:

```

[2025-04-30 17:18:11] [192.168.0.3:47468] [OpenOTP:Q1DH0KKR] Enforcing client policy: Nextcloud Sign (matched client ID)
[2025-04-30 17:18:11] [192.168.0.3:47468] [OpenOTP:Q1DH0KKR] Registered openotpNormalConfirm request
[2025-04-30 17:18:11] [192.168.0.3:47468] [DEBUG:520394:watchd_frm.php:debug_log] Watchd LDAP server: LDAP Server
[2025-04-30 17:18:11] [192.168.0.3:47468] [DEBUG:520394:app_frm.php:debug_log] LDAP search: (&(objectclass=webadmaccount)(uid=a129eeab-25dd-42d9-89de-51c233c135c8)) (dc=mycompany,dc=com)
[2025-04-30 17:18:11] [192.168.0.3:47468] [DEBUG:520394:app_frm.php:debug_log] Searched attrs: cn,objectclass,fullname,displayname,useraccountcontrol,usercertificate,uid,samaccountnam
e,userprincipalname,preferredlanguage,mobile,mail,webadmdata,webadmsettings,uid,samaccountname,userprincipalname,memberof,groupmembership,gidnumber
[2025-04-30 17:18:11] [192.168.0.3:47468] [OpenOTP:Q1DH0KKR] User invalid or not found
[2025-04-30 17:18:11] [192.168.0.3:47468] [OpenOTP:Q1DH0KKR] Sent failure response

```

Isn't this a openotp plugin bug?

Seems to me it should perhaps have a config parameter to indicate which field(s) to use in the LDAP lookup, or at least of sequence of search actions.

Maybe the cloud_id should be stored in LDAP in order to be searched upon...

Anyway, here are the versions of the nextcloud 31.0.4 apps enabled:

```

$ sudo occ app:list --enabled
Enabled:
 - activity: 4.0.0
 - admin_audit: 1.21.0
 - analytics: 5.4.0
 - analytics_sourcepack: 0.0.3
 - announcementcenter: 7.1.1
 - app_api: 5.0.2
 - appointments: 2.4.3
 - approval: 2.2.0
 - bookmarks: 15.1.0
 - bruteforcesettings: 4.0.0
 - calendar: 5.2.2
 - calendar_resource_management: 0.9.0
 - circles: 31.0.0
 - cloud_federation_api: 1.14.0
 - collectives: 2.16.3
 - comments: 1.21.0
 - contacts: 7.0.6
 - contactsinteraction: 1.12.0
 - dashboard: 7.11.0
 - dav: 1.33.0
 - deck: 1.15.1
 - federatedfilesharing: 1.21.0
 - federation: 1.21.0
 - files: 2.3.1
 - files_accesscontrol: 2.0.0
 - files_antivirus: 6.0.0
 - files_downloadlimit: 4.0.0
 - files_pdfviewer: 4.0.0
 - files_reminders: 1.4.0
 - files_sharing: 1.23.1
 - files_trashbin: 1.21.0
 - files_versions: 1.24.0
 - firstrunwizard: 4.0.0
 - forms: 5.1.0
 - groupfolders: 19.0.4
 - integration_docusign: 2.0.4
 - integration_github: 3.1.1
 - integration_openstreetmap: 2.0.1
 - ldap_write_support: 1.13.0
 - limit_login_to_ip: 4.2.0
 - logreader: 4.0.0
 - lookup_server_connector: 1.19.0
 - mail: 5.0.3
 - nextcloud_announcements: 3.0.0
 - notes: 4.12.0
 - notifications: 4.0.0
 - notify_push: 1.0.0
 - oauth2: 1.19.1
 - openotp_auth: 1.31.1
 - openotp_sign: 1.31.0
 - password_policy: 3.0.0
 - photos: 4.0.0-dev.1
 - privacy: 3.0.0
 - profile: 1.0.0
 - provisioning_api: 1.21.0
 - related_resources: 2.0.0
 - serverinfo: 3.0.0
 - settings: 1.14.0
 - sharebymail: 1.21.0
 - spreed: 21.0.4
 - support: 3.0.0
 - survey_client: 3.0.0
 - suspicious_login: 9.0.1
 - systemtags: 1.21.1
 - tables: 0.9.2
 - tasks: 0.16.1
 - text: 5.0.0
 - text_templates: 1.2.0
 - theming: 2.6.1
 - twofactor_backupcodes: 1.20.0
 - twofactor_totp: 13.0.0-dev.0
 - updatenotification: 1.21.0
 - uppush: 2.3.0
 - user_ldap: 1.22.0
 - user_status: 1.11.0
 - viewer: 4.0.0
 - weather_status: 1.11.0
 - webhook_listeners: 1.2.0
 - workflowengine: 2.13.0
```

cheers

[Spyridon Gouliarmis (RCDevs)]

Is that an entryUUID? It's wiser than uid (or sAMAccountName, as the Nextcloud documentation says), but you end up with some ugliness, like the screenshot here. I'll ask the devs if displaying the Display Name in the signing pop up would be doable in the next versions.

In any case, the LDAP search (and the decision on which LDAP attribute to match) is done by OpenOTP, not the plugin, which just sends a SOAP request with the Username blindly filled with a value. Perhaps add entryUUID to the list for uid_attrs in webadm.conf, and reload/restart, then try again. Or better, in the Nextcloud Sign client policy, set UID Attributes to entryUUID.

[Richard Palo]

On Wednesday, April 30, 2025 at 6:12:24 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

Is that an entryUUID? It's wiser than uid (or sAMAccountName, as the Nextcloud documentation says), but you end up with some ugliness, like the screenshot here. I'll ask the devs if displaying the Display Name in the signing pop up would be doable in the next versions.

According to WebADM the Entryuid  is indeed 'a129eeab-25dd-42d9-89de-51c233c135c8'

 

In any case, the LDAP search (and the decision on which LDAP attribute to match) is done by OpenOTP, not the plugin, which just sends a SOAP request with the Username blindly filled with a value. Perhaps add entryUUID to the list for uid_attrs in webadm.conf, and reload/restart, then try again. Or better, in the Nextcloud Sign client policy, set UID Attributes to entryUUID.

I tried modifying the LDAP query in the LDAP/AD setup to:

`(&(|(objectclass=inetOrgPerson))(|(uid=%uid)(|(mailPrimaryAddress=%uid)(mail=%uid))(|(Entryuuid=%uid)(uid=%uid))))`

and indeed that finds the user...

But trying to auto-sign still gives

`Erreur : Utilisateur ou mot de passe incorrect`

with the following in webadm.log:

```

[2025-04-30 18:32:33] [192.168.0.3:53560] [DEBUG:520394:app_frm.php:debug_log] LDAP search: (&(objectclass=webadmaccount)(uid=a129eeab-25dd-42d9-89de-51c233c135c8)) (dc=mydomain,dc=com)
[2025-04-30 18:32:33] [192.168.0.3:53560] [DEBUG:520394:app_frm.php:debug_log] Searched attrs: cn,objectclass,fullname,displayname,useraccountcontrol,usercertificate,uid,samaccountnam
e,userprincipalname,preferredlanguage,mobile,mail,webadmdata,webadmsettings,uid,samaccountname,userprincipalname,memberof,groupmembership,gidnumber

This does look like it's generated by the plugin because it uses 'objectclass=webadmaccount'...

Is there any way I can add 'Entryuuid' to the searched attrs in Webadm?

```

 

[Spyridon Gouliarmis (RCDevs)]

Did you modify the client policy on the WebADM side?

[Richard Palo]

sorry, I meant to say 'OpenOTP' server and not the plugin...

[Spyridon Gouliarmis (RCDevs)]

This LDAP search with only the uid attribute is preceded by "Enforcing client policy: Nextcloud Sign (matched client ID)", right? Because if you tell WebADM to use entryUUID in a client policy, the client policy is said to be applied, and it ignores entryUUID, then we might have a bug.

[Richard Palo]

On Wednesday, April 30, 2025 at 6:41:02 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

Did you modify the client policy on the WebADM side?

 

No, only added as per the doc 'Nextcloud Sign' to 'Client Name Aliases'

and the following to 'Default Application Settings'

```

OpenOTP.SignScope=Local
OpenOTP.CaDESMode=Embedded
OpenOTP.SignLongTerm=Yes

```

Is there something I could try, perhaps in 'UID Attributes' ('Restricted list of LDAP login attributes replacing the attributes configured via uid_attrs in webadm.conf.')

grepping for 'uid_attr' in  webadm.conf I find:

```

uid_attrs               "uid", "samAccountName", "userPrincipalName"
memberuid_attrs         "memberUid"

```

[Spyridon Gouliarmis (RCDevs)]

Yes, UID Attributes should contain entryUUID.

[Richard Palo]

On Wednesday, April 30, 2025 at 6:55:45 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

Yes, UID Attributes should contain entryUUID.

In webadm.conf or in the client policy/policies?

[Spyridon Gouliarmis (RCDevs)]

In the client policy, although both should work.

[Richard Palo]

On Wednesday, April 30, 2025 at 7:00:47 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

In the client policy, although both should work.

 

Super, I changed it in webadm.conf, and now I get 'Request failed with status code 504' while the little 1M pdf file is downloading to my cellphone.

Seems really slow, which are the appropriate timeout parameters to tweak? Any way to tune the file transfer?

[Richard Palo]

I have the debug log if necessary...

[Spyridon Gouliarmis (RCDevs)]

It goes through a bunch microservices on some French servers, last time I asked. That should just add ~500 ms though, I assume that's not what you're talking about.

The log would be useful, at the very least the support team (such as I) can grep for strings in the git repo.

No tuning that I know of, but tomorrow there'll be more people in the office who can answer this.

BTW, on the app side, you can tap the version number (in the settings screen, the little cog icon to the lower right) multiple times to get a log of what's going on.

[Richard Palo]

On Wednesday, April 30, 2025 at 7:24:11 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

It goes through a bunch microservices on some French servers, last time I asked. That should just add ~500 ms though, I assume that's not what you're talking about.

The log would be useful, at the very least the support team (such as I) can grep for strings in the git repo.

No tuning that I know of, but tomorrow there'll be more people in the office who can answer this.

BTW, on the app side, you can tap the version number (in the settings screen, the little cog icon to the lower right) multiple times to get a log of what's going on.

Here's an extract from the webadm.log and the android openotp app log 

[Spyridon Gouliarmis (RCDevs)]

We're still looking into this, but in the meantime, can you try again after setting cloud_wsproxy to Yes? (It should be uncommented right now, in /opt/webadm/conf/webadm.conf, and needs a service restart before being taken into account).

Also, what's your license ID? (It should be something like FREE_***)

[Richard Palo]

On Monday, May 5, 2025 at 11:41:53 AM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

We're still looking into this, but in the meantime, can you try again after setting cloud_wsproxy to Yes? (It should be uncommented right now, in /opt/webadm/conf/webadm.conf, and needs a service restart before being taken into account).

Also, what's your license ID? (It should be something like FREE_***)

Seems I did that to get thus far...

```

$ sudo grep wsprox conf/webadm.conf

cloud_wsproxy yes

$ sudo bin/webadm start
Checking library dependencies... Ok
Checking system architecture... Ok
Checking server configurations... Ok

Found Freeware license (FREE_E6728767344C2E9F)
Licensed by RCDevs Security SA to SAS BAOU
Licensed product(s): OpenOTP

Starting WebADM Session service... Ok
Starting WebADM Rsignd service... Ok
Starting WebADM Watchd service... Ok
Starting WebADM Update service... Ok
Starting WebADM HTTP service... Ok

Checking server connections...  
Connected LDAP server: LDAP Server (192.168.0.3)
Connected SQL server: ERROR (no server available)
Connected PKI server: PKI Server 1 (127.0.0.1)
Connected Session server: Session Server 1 (127.0.0.1)

Checking LDAP proxy user access... Ok
Checking PKI service access... Ok
Checking Cloud service access... Ok
Starting Cloud WSProxy connection... Ok
```

[Richard Palo]

Now what's [newly] strange , is that I login into NC via  client app, I get the notification for TOTP on OpenOTP,

I enter the code generated and NC displays:

```

Accès non autorisé

Les jetons de statut ne correspondent pas

```

When I try again directly on the website access, seems okay.

I logout and try the NC client again, this time ok, but then it seems to loop

try to log me in over and over again.

Doesn't seem too stable.

How could I clean this up?

[Spyridon Gouliarmis (RCDevs)]

I'm being told we have a 10MB limit on files to be signed. The error is still puzzling, but just in case, can you try with something much lighter (5MB, say)?

[Richard Palo]

On Monday, May 5, 2025 at 3:15:11 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

I'm being told we have a 10MB limit on files to be signed. The error is still puzzling, but just in case, can you try with something much lighter (5MB, say)?

Odd, I tried Nextcloud flyer.pdf which is only 1MB as well as another pdf half that size.

[Spyridon Gouliarmis (RCDevs)]

Nevermind, I saw the "1083339 Bytes" in the log and thought I read 10 million. We just tried with a too-big file, and it doesn't give the error you got. We're still looking at your logs.

Concerning the recent change in behaviour, you get a number of free signatures with a free/trial license, and after that you have to pay. I would bet on this. Contact the sales with your license number and ask for a few more signing credits, and mention you're currently debugging your setup with the support team for the moment.

[Spyridon Gouliarmis (RCDevs)]

We see this in your app logs:

2025-04-30T17:06:57.616Z [INFO]  Presenting request data.
2025-04-30T17:08:45.642Z [INFO]  Setting new active screen: HomeTabBar

Normally, "presenting request data" should quickly be followed by "setting new active screen: document review screen", because you have tapped "suivant"/"next" when presented with a signature request. Can you perhaps find a recent request (<24h) by tapping the bell icon at the top right?

[Richard Palo]

On Monday, May 5, 2025 at 3:37:13 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

Nevermind, I saw the "1083339 Bytes" in the log and thought I read 10 million. We just tried with a too-big file, and it doesn't give the error you got. We're still looking at your logs.

Concerning the recent change in behaviour, you get a number of free signatures with a free/trial license, and after that you have to pay. I would bet on this. Contact the sales with your license number and ask for a few more signing credits, and mention you're currently debugging your setup with the support team for the moment.

?? As of yet, there has not been a successful signature all the way back to NC with the filename indicating '_signé' like it is configured.

Certainly sounds like anomalous processing of the signed (or *not* signed) document all the way back to the initiator.

[Richard Palo]

On Monday, May 5, 2025 at 3:44:20 PM UTC+2 Spyridon Gouliarmis (RCDevs) wrote:

We see this in your app logs:

2025-04-30T17:06:57.616Z [INFO]  Presenting request data.
2025-04-30T17:08:45.642Z [INFO]  Setting new active screen: HomeTabBar

Normally, "presenting request data" should quickly be followed by "setting new active screen: document review screen", because you have tapped "suivant"/"next" when presented with a signature request. Can you perhaps find a recent request (<24h) by tapping the bell icon at the top right?

There is nothing left to process according to OpenOTP on my smartphone.

I'll try again but with a different document.

 

[Richard Palo]

Tried a different document, not really different.  Though I should mention that it appears there is some illegible garbage thrown on the top left corner of the signed document.

It's strange that it takes almost two minutes to download a very very small file.

The 'signed' file is not indicating the filename update as configured.

Also, 'sealing' appears to be a NO-OP, as nothing happens, whereas it should have the digital signature without the visible part in the document.

[Spyridon Gouliarmis (RCDevs)]

You have signed documents appearing in Nextcloud? I though you were stuck at the point where the document is supposed to be presented to you on your smartphone, and you have to start the signing process.

Can you sign a document starting from OpenOTP, without including Nexcloud? When viewing an activated user in WebADM -> Application Actions -> MFA Authentication Server -> Test Signature and Confirmation.

[Spyridon Gouliarmis (RCDevs)]

Also, what's the version of your mobile app?