Issue Description
When creating a new Account/User via stalwart-cli the WebUI login fails against the SQL directory with the error:
ERROR Authentication error (auth.error) listenerId = "http", localPort = X, remoteIp = X, remotePort = X, causedBy = "crates/common/src/cache/directory.rs:145", details = "Failed to synchronize account with directory", reason = "Validation error: Property 'description' is required, ", remoteIp = X
The error seems to be caused by the fact that the Description property is set to null. Updating the Description property to have a string value allows login, however the Description property of the Account/User object is optional, and no value should be necessary.
"x:AccountSettings": {
"properties": {
"description": {
"description": "Description of the account",
"type": {
"type": "string",
"format": "string",
"nullable": true
},
"update": "mutable"
}
}
}
Expected Behavior
You should be able to authenticate to an account using external directory authentication whether or not it has a description.
Actual Behavior
The authentication fails, on the WebUI the message: “Invalid username or password. Please try again.” is displayed.
Reproduction Steps
- Configure stalwart with a SQL external directory
- Add an account without a description, in my tests I have been doing this using
stalwart-cli - Try to authenticate against that account using valid credentials
If it’s necessary to implement the exact SQL queries we have, they can be found in the previous thread: support.stalw.art/t/mysql-directory-parameters-are-limited-and-differ-from-the-docs-and-other-backends/823
Relevant Log Output
ERROR Authentication error (auth.error) listenerId = "http", localPort = X, remoteIp = X, remotePort = X, causedBy = "crates/common/src/cache/directory.rs:145", details = "Failed to synchronize account with directory", reason = "Validation error: Property 'description' is required, ", remoteIp = X
Stalwart Version
v0.16.x
Installation Method
Binary (Linux)
Database Backend
MySQL
Blob Storage
Filesystem
Search Engine
Internal
Directory Backend
SQL
Additional Context
We appreciate the work to add external directory support to Stalwart, but sadly we’re probably going to move away from external directories as they don’t really provide added value in our case. Going into this we had the idea that Stalwart would be able to pull account permissions and quotas from the external directory as well as allow us to avoid having to inject accounts or domains into Stalwart directly using the API.
We quickly realised that quotas and permissions couldn’t be pulled from the SQL directory as in the documentation it says:
There is no column mapping for a per-account disk quota: quotas are held on the Account and Tenant objects rather than read from the SQL directory (see Quotas).
The documentation doesn’t explicitly mention it but it’s the same for permissions too. That was OK, we still went ahead because we thought that at least users and domains would be created automatically and we could PATCH their attributes later.
However then we realised from trial and error (eventually finding this FAQ entry) that:
The Domain record is required even when accounts are stored in an external LDAP or SQL directory; those backends provide account authentication only.
So domains must be created manually first before any accounts can be consumed from the external directory.
So we have to create domains manually because they aren’t picked up from the external directory (even though it has that data, Stalwart just can’t consume it). We have to create accounts manually because we have to assign quota and permissions properties to them. And finally when we do so we still can’t authenticate through the external directory because of a validation error on an optional property. At this point the only thing we aren’t supplying to Stalwart through the API is the password hash, but that would be trivial to add to our already existing API requests.
Plus external auth seems to be flaky, requiring service restarts to resolve sync and cache issues. I’ve seen other reports of this with external directories too.
So all-in-all, external directories don’t seem to save us any time or effort and actually introduce complications and unreliability. They would be a nice feature for us if they could also be connected to other objects such as domains, and if they could supply more than just authentication data. But in their current form they offer limited utility for us.
In any case, thanks for your work and help.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on