[Bug] LDAP/AD Authentication Failure: "Logon failed. Please verify your credentials and try again."

## Describe the bug
I'm unable to log in to ocis using my Active Directory credentials. The login page shows the error message "Logon failed. Please verify your credentials and try again." despite the credentials being correct and the LDAP bind user successfully connecting to the AD server.

## System Environment

- Operating System: TrueNAS SCALE Fangtooth 25.04

- AD Domain Controller: Windows Server 2022(Virtual machine installed on TrueNAS)

- Docker Image: owncloud/ocis:latest (Version 7.1.4, Install using Docker Compose)

## Steps to reproduce

1. Set up the Active Directory Domain Controller:

- Log in to Windows Server 2022.

- Open Server Manager, go to Manage > Add Roles and Features.

- Select and install the Active Directory Domain Services role.

- Promote the server to a domain controller and configure a new forest with the domain name `ad.internal`.

2. Deploy oCIS Container:

- Log in to TrueNAS instance.

- Use the Docker service to pull the latest owncloud/ocis:latest image (version 7.1.4).

- Start the container using the provided docker-compose.yml configuration below. Ensure the TrueNAS host can resolve the ad.internal domain name.

3. Attempt User Login:

- Open a web browser and navigate to the oCIS login page (e.g., https://10.0.0.3:40000).

- I tried using different usernames, such as `Administrator`, `AD\Administrator`, or `Administrator@ad.internal`, but all failed. The login page displayed a message saying "Logon failed. Please verify your credentials and try again."

## Expected behavior
The user should be successfully authenticated and logged into the ocis instance.

## Actual behavior
The login fails with the error message "Logon failed. Please verify your credentials and try again." on the web UI.

## Technical Details & Logs

I have verified that the LDAP bind user (`CN=Administrator,CN=Users,DC=ad,DC=internal`) and password (`MYPASSWORD`) are correct by using the `ldapsearch` command from within the ocis container(ldapsearch does not exist in the container. I used the apk command to download and use the ldapsearch command). The ldapsearch command successfully binds and queries the user's information.

Successful `ldapsearch` command and output:

```
# ldapsearch -x -H ldap://ad.internal:389 -D "CN=Administrator,CN=Users,DC=ad,DC=internal" -w "MYPASSWORD" -b "CN=Users,DC=ad,DC=internal" sAMAccountName=Administrator
# extended LDIF
...
# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
```

However, I've found that the oCIS container logs show the login request as successful. This indicates that the backend authentication process is working correctly, but the issue may be with the oCIS frontend (web UI) or the communication between the frontend and the backend.

## Docker logs
```
ocis | {"level":"debug","service":"users","service":{"name":"com.owncloud.api.users","version":"7.1.4","metadata":null,"endpoints":[],"nodes":[{"metadata":{"protocol":"grpc","registry":"cache","server":"grpc","transport":"tcp"},"id":"com.owncloud.api.users-002d291f-5aac-4466-9ced-bc614163811a","address":"127.0.0.1:9144"}]},"time":"2025-09-16T13:55:42Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/registry/register.go:43","message":"refreshing external service-registration"}
ocis | {"level":"debug","service":"idp","request-id":"","proto":"HTTP/1.1","method":"POST","status":204,"path":"/signin/v1/identifier/_/logon","duration":6.017625,"bytes":0,"time":"2025-09-16T13:55:42Z","line":"github.com/owncloud/ocis/v2/ocis-pkg/middleware/logger.go:27"}
```

## My docker-compose.yml file

My environment variables refer to this document: https://owncloud.dev/ocis/identity-provider/ldap-active-directory/

```
version: '3.8'

services:
ocis:
image: owncloud/ocis
container_name: ocis
ports:
- "40000:9200"
environment:
OCIS_INSECURE: true
PROXY_HTTP_ADDR: "0.0.0.0:9200"
OCIS_URL: "https://10.0.0.3:40000"
IDP_LOG_LEVEL: debug
USERS_LOG_LEVEL: debug
# AD
OCIS_LDAP_URI: ldap://ad.internal:389
OCIS_LDAP_INSECURE: true
OCIS_LDAP_BIND_DN: "CN=Administrator,CN=Users,DC=ad,DC=internal"
OCIS_LDAP_BIND_PASSWORD: "MYPASSWORD"
OCIS_LDAP_DISABLE_USER_MECHANISM: none
OCIS_LDAP_GROUP_BASE_DN: "dc=ad,dc=internal"
OCIS_LDAP_GROUP_OBJECTCLASS: "group"
OCIS_LDAP_GROUP_SCHEMA_ID: "objectGUID"
OCIS_LDAP_GROUP_SCHEMA_ID_IS_OCTETSTRING: true
OCIS_LDAP_GROUP_SCHEMA_GROUPNAME: "cn"
OCIS_LDAP_USER_BASE_DN: "dc=ad,dc=internal"
OCIS_LDAP_USER_OBJECTCLASS: "user"
OCIS_LDAP_USER_SCHEMA_ID: "objectGUID"
OCIS_LDAP_USER_SCHEMA_ID_IS_OCTETSTRING: true
OCIS_LDAP_USER_SCHEMA_USERNAME: "sAMAccountName"
OCIS_LDAP_LOGIN_ATTRIBUTES: "sAMAccountName"
IDP_LDAP_LOGIN_ATTRIBUTE: "sAMAccountName"
IDP_LDAP_UUID_ATTRIBUTE: "objectGUID"
IDP_LDAP_UUID_ATTRIBUTE_TYPE: binary
GRAPH_LDAP_SERVER_WRITE_ENABLED: "false"
OCIS_EXCLUDE_RUN_SERVICES: idm
OCIS_ADMIN_USER_ID: "375673d4-507b-450d-a0eb-dac08df77e91"
volumes:
- ./ocis/etc/ocis:/etc/ocis
- /mnt/xxxxx/ocis-data/var/lib/ocis:/var/lib/ocis
user: "1000:1000"
restart: unless-stopped
```

## Additional Context

This new finding suggests that the backend IDP service is successfully authenticating against AD, but the login process is failing somewhere else—potentially with session management, redirection, or token exchange between the backend and the web UI.