... or ones we think people might ask.
You may have noticed that Kanidm requires you to configure TLS in your container or server install.
We are a secure-by-design rather than secure-by-configuration system, so TLS for all connections is considered mandatory and a default rather than an optional feature you add later.
Because Kanidm is one of the keys to a secure network, and insecure connections to them are not best practice. This can allow account hijacking, privilege escalation, credential disclosures, personal information leaks and more.
secure-cookies is a flag set in cookies that asks a client to transmit them back to the origin
site if and only if the client sees HTTPS is present in the URL.
Certificate authority (CA) verification is not checked - you can use invalid, out of date
certificates, or even certificates where the
subjectAltName does not match, but the client must
see https:// as the destination else it will not send the cookies.
Kanidm's authentication system is a stepped challenge response design, where you initially request an "intent" to authenticate. Once you establish this intent, the server sets up a session-id into a cookie, and informs the client of what authentication methods can proceed.
If you do NOT have a HTTPS URL, the cookie with the session-id is not transmitted. The server detects this as an invalid-state request in the authentication design, and immediately breaks the connection, because it appears insecure. This prevents credential disclosure since the authentication session was not able to be established due to the lost session-id cookie.
Simply put, we are trying to use settings like
secure_cookies to add constraints to the server so
that you must perform and adhere to best practices - such as having TLS present on your
No, it is not possible swap out the SQLite database for any other type of SQL server.
ATTEMPTING THIS WILL BREAK YOUR KANIDM INSTANCE IRREPARABLY
This question is normally asked because people want to setup multiple Kanidm servers connected to a single database.
Kanidm does not use SQL as a database. Kanidm uses SQL as a durable key-value store and Kanidm implements it's own database, caching, querying, optimisation and indexing on top of that key-value store.
As a result, because Kanidm specifically implements it's own cache layer above the key-value store (sqlite in this example) then if you were to connect two Kanidm instances to the same key-value store, as each server has it's own cache layer and they are not in contact, it is possible for writes on one server to never be observed by the second, and if the second were to then write over those entries it will cause loss of the changes from the first server.
It's a rust thing.
Probably, on an infinite time-scale! As long as it's not STARTTLS. Please log an issue and start the discussion!
Snaps rely on AppArmor and
AppArmor doesn't follow symlinks. When
home_alias is any value other than
none a symlink will be created and pointing to
It is recommended to use alternative software packages to snaps.
All users in Kanidm can change their name (and their spn) at any time. If you change
uuid you must have a plan on how to manage these directory renames in your system.
Look, people just haven't asked many questions yet.