2022-05-01 06:11:32 +02:00
<!DOCTYPE HTML>
< html lang = "en" class = "sidebar-visible no-js light" >
< head >
<!-- Book generated using mdBook -->
< meta charset = "UTF-8" >
< title > Kanidm Administration< / title >
< meta name = "robots" content = "noindex" / >
<!-- Custom HTML head -->
< meta content = "text/html; charset=utf-8" http-equiv = "Content-Type" >
< meta name = "description" content = "" >
< meta name = "viewport" content = "width=device-width, initial-scale=1" >
< meta name = "theme-color" content = "#ffffff" / >
< link rel = "icon" href = "favicon.svg" >
< link rel = "shortcut icon" href = "favicon.png" >
< link rel = "stylesheet" href = "css/variables.css" >
< link rel = "stylesheet" href = "css/general.css" >
< link rel = "stylesheet" href = "css/chrome.css" >
< link rel = "stylesheet" href = "css/print.css" media = "print" >
<!-- Fonts -->
< link rel = "stylesheet" href = "FontAwesome/css/font-awesome.css" >
< link rel = "stylesheet" href = "fonts/fonts.css" >
<!-- Highlight.js Stylesheets -->
< link rel = "stylesheet" href = "highlight.css" >
< link rel = "stylesheet" href = "tomorrow-night.css" >
< link rel = "stylesheet" href = "ayu-highlight.css" >
<!-- Custom theme stylesheets -->
< / head >
< body >
<!-- Provide site root to javascript -->
< script type = "text/javascript" >
var path_to_root = "";
var default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? "navy" : "light";
< / script >
<!-- Work around some values being stored in localStorage wrapped in quotes -->
< script type = "text/javascript" >
try {
var theme = localStorage.getItem('mdbook-theme');
var sidebar = localStorage.getItem('mdbook-sidebar');
if (theme.startsWith('"') & & theme.endsWith('"')) {
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
}
if (sidebar.startsWith('"') & & sidebar.endsWith('"')) {
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
}
} catch (e) { }
< / script >
<!-- Set the theme before any content is loaded, prevents flash -->
< script type = "text/javascript" >
var theme;
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
if (theme === null || theme === undefined) { theme = default_theme; }
var html = document.querySelector('html');
html.classList.remove('no-js')
html.classList.remove('light')
html.classList.add(theme);
html.classList.add('js');
< / script >
<!-- Hide / unhide sidebar before it is displayed -->
< script type = "text/javascript" >
var html = document.querySelector('html');
var sidebar = 'hidden';
if (document.body.clientWidth >= 1080) {
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
sidebar = sidebar || 'visible';
}
html.classList.remove('sidebar-visible');
html.classList.add("sidebar-" + sidebar);
< / script >
< nav id = "sidebar" class = "sidebar" aria-label = "Table of contents" >
< div class = "sidebar-scrollbox" >
2022-06-05 07:20:33 +02:00
< ol class = "chapter" > < li class = "chapter-item expanded " > < a href = "intro.html" > < strong aria-hidden = "true" > 1.< / strong > Introduction to Kanidm< / a > < / li > < li class = "chapter-item expanded " > < a href = "installing_the_server.html" > < strong aria-hidden = "true" > 2.< / strong > Installing the Server< / a > < / li > < li > < ol class = "section" > < li class = "chapter-item expanded " > < a href = "server_configuration.html" > < strong aria-hidden = "true" > 2.1.< / strong > Server Configuration< / a > < / li > < li class = "chapter-item expanded " > < a href = "security_hardening.html" > < strong aria-hidden = "true" > 2.2.< / strong > Security Hardening< / a > < / li > < / ol > < / li > < li class = "chapter-item expanded " > < a href = "client_tools.html" > < strong aria-hidden = "true" > 3.< / strong > Client Tools< / a > < / li > < li > < ol class = "section" > < li class = "chapter-item expanded " > < a href = "installing_client_tools.html" > < strong aria-hidden = "true" > 3.1.< / strong > Installing client tools< / a > < / li > < / ol > < / li > < li class = "chapter-item expanded " > < a href = "accounts_and_groups.html" > < strong aria-hidden = "true" > 4.< / strong > Accounts and Groups< / a > < / li > < li class = "chapter-item expanded " > < a href = "administrivia.html" > < strong aria-hidden = "true" > 5.< / strong > Administrative Tasks< / a > < / li > < li > < ol class = "section" > < li class = "chapter-item expanded " > < a href = "monitoring.html" > < strong aria-hidden = "true" > 5.1.< / strong > Monitoring the platform< / a > < / li > < li class = "chapter-item expanded " > < a href = "password_quality.html" > < strong aria-hidden = "true" > 5.2.< / strong > Password Quality and Badlisting< / a > < / li > < li class = "chapter-item expanded " > < a href = "posix_accounts.html" > < strong aria-hidden = "true" > 5.3.< / strong > POSIX Accounts and Groups< / a > < / li > < li class = "chapter-item expanded " > < a href = "ssh_key_dist.html" > < strong aria-hidden = "true" > 5.4.< / strong > SSH Key Distribution< / a > < / li > < li class = "chapter-item expanded " > < a href = "recycle_bin.html" > < strong aria-hidden = "true" > 5.5.< / strong > The Recycle Bin< / a > < / li > < li class = "chapter-item expanded " > < a href = "why_tls.html" > < strong aria-hidden = "true" > 5.6.< / strong > Why TLS?< / a > < / li > < / ol > < / li > < li class = "chapter-item expanded " > < li class = "part-title" > For Developers< / li > < li class = "chapter-item expanded " > < a href = "DEVELOPER_README.html" > < strong aria-hidden = "true" > 6.< / strong > Developer Guide< / a > < / li > < li class = "chapter-item expanded affix " > < li class = "part-title" > Integrations< / li > < li class = "chapter-item expanded " > < a href = "integrations/oauth2.html" > < strong aria-hidden = "true" > 7.< / strong > Oauth2< / a > < / li > < li class = "chapter-item expanded " > < a href = "integrations/pam_and_nsswitch.html" > < strong aria-hidden = "true" > 8.< / strong > PAM and nsswitch< / a > < / li > < li class = "chapter-item expanded " > < a href = "integrations/radius.html" > < strong aria-hidden = "true" > 9.< / strong > RADIUS< / a > < / li > < li class = "chapter-item expanded " > < a href = "integrations/ldap.html" > < strong aria-hidden = "true" > 10.< / strong > LDAP< / a > < / li > < / ol >
2022-05-01 06:11:32 +02:00
< / div >
< div id = "sidebar-resize-handle" class = "sidebar-resize-handle" > < / div >
< / nav >
< div id = "page-wrapper" class = "page-wrapper" >
< div class = "page" >
< div id = "menu-bar-hover-placeholder" > < / div >
< div id = "menu-bar" class = "menu-bar sticky bordered" >
< div class = "left-buttons" >
< button id = "sidebar-toggle" class = "icon-button" type = "button" title = "Toggle Table of Contents" aria-label = "Toggle Table of Contents" aria-controls = "sidebar" >
< i class = "fa fa-bars" > < / i >
< / button >
< button id = "theme-toggle" class = "icon-button" type = "button" title = "Change theme" aria-label = "Change theme" aria-haspopup = "true" aria-expanded = "false" aria-controls = "theme-list" >
< i class = "fa fa-paint-brush" > < / i >
< / button >
< ul id = "theme-list" class = "theme-popup" aria-label = "Themes" role = "menu" >
< li role = "none" > < button role = "menuitem" class = "theme" id = "light" > Light (default)< / button > < / li >
< li role = "none" > < button role = "menuitem" class = "theme" id = "rust" > Rust< / button > < / li >
< li role = "none" > < button role = "menuitem" class = "theme" id = "coal" > Coal< / button > < / li >
< li role = "none" > < button role = "menuitem" class = "theme" id = "navy" > Navy< / button > < / li >
< li role = "none" > < button role = "menuitem" class = "theme" id = "ayu" > Ayu< / button > < / li >
< / ul >
< button id = "search-toggle" class = "icon-button" type = "button" title = "Search. (Shortkey: s)" aria-label = "Toggle Searchbar" aria-expanded = "false" aria-keyshortcuts = "S" aria-controls = "searchbar" >
< i class = "fa fa-search" > < / i >
< / button >
< / div >
< h1 class = "menu-title" > Kanidm Administration< / h1 >
< div class = "right-buttons" >
< a href = "print.html" title = "Print this book" aria-label = "Print this book" >
< i id = "print-button" class = "fa fa-print" > < / i >
< / a >
< / div >
< / div >
< div id = "search-wrapper" class = "hidden" >
< form id = "searchbar-outer" class = "searchbar-outer" >
< input type = "search" id = "searchbar" name = "searchbar" placeholder = "Search this book ..." aria-controls = "searchresults-outer" aria-describedby = "searchresults-header" >
< / form >
< div id = "searchresults-outer" class = "searchresults-outer hidden" >
< div id = "searchresults-header" class = "searchresults-header" > < / div >
< ul id = "searchresults" >
< / ul >
< / div >
< / div >
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
< script type = "text/javascript" >
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
});
< / script >
< div id = "content" class = "content" >
< main >
< h1 id = "introduction-to-kanidm" > < a class = "header" href = "#introduction-to-kanidm" > Introduction to Kanidm< / a > < / h1 >
< p > Kanidm is an identity management server, acting as an authority on account information, authentication
and authorisation within a technical environment.< / p >
< p > The intent of the Kanidm project is to:< / p >
< ul >
< li > Provide a single truth source for accounts, groups and privileges.< / li >
< li > Enable integrations to systems and services so they can authenticate accounts.< / li >
< li > Make system, network, application and web authentication easy and accessible.< / li >
< / ul >
< blockquote >
< p > < strong > NOTICE:< / strong >
This is a pre-release project. While all effort has been made to ensure no data loss
or security flaws, you should still be careful when using this in your environment.< / p >
< / blockquote >
< h2 id = "library-documentation" > < a class = "header" href = "#library-documentation" > Library documentation< / a > < / h2 >
2022-05-18 03:34:13 +02:00
< p > Looking for the < code > rustdoc< / code > documentation for the libraries themselves? < a href = "https://kanidm.com/documentation/" > Click here!< / a > < / p >
2022-05-01 06:11:32 +02:00
< h2 id = "why-do-i-want-kanidm" > < a class = "header" href = "#why-do-i-want-kanidm" > Why do I want Kanidm?< / a > < / h2 >
< p > Whether you work in a business, a volunteer organisation, or are an enthusiast who manages
2022-05-18 03:34:13 +02:00
their personal services, you need methods of authenticating and identifying
to your systems, and subsequently, ways to determine what authorisation and privileges you have
2022-05-01 06:11:32 +02:00
while accessing these systems.< / p >
< p > We've probably all been in workplaces where you end up with multiple accounts on various
systems - one for a workstation, different SSH keys for different tasks, maybe some shared
account passwords. Not only is it difficult for people to manage all these different credentials
and what they have access to, but it also means that sometimes these credentials have more
access or privilege than they require.< / p >
< p > Kanidm acts as a central authority of accounts in your organisation and allows each account to associate
many devices and credentials with different privileges. An example of how this looks:< / p >
< pre > < code > ┌──────────────────┐
┌┴─────────────────┐│
│ ││
┌───────────────┬───▶│ Kanidm │◀─────┬─────────────────────────┐
│ │ │ ├┘ │ │
│ │ └──────────────────┘ │ Verify
Account Data │ ▲ │ Radius
References │ │ │ Password
│ │ │ │ │
│ │ │ │ ┌────────────┐
│ │ │ │ │ │
│ │ │ Verify │ RADIUS │
┌────────────┐ │ Retrieve SSH Application │ │
│ │ │ Public Keys Password └────────────┘
│ Database │ │ │ │ ▲
│ │ │ │ │ │
└────────────┘ │ │ │ ┌────────┴──────┐
▲ │ │ │ │ │
│ │ │ │ │ │
┌────────────┐ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐
│ │ │ │ │ │ │ │ │ │ │
│ Web Site │ │ │ SSH │ │ Email │ │ WIFI │ │ VPN │
│ │ │ │ │ │ │ │ │ │ │
└────────────┘ │ └────────────┘ └────────────┘ └────────────┘ └────────────┘
▲ │ ▲ ▲ ▲ ▲
│ │ │ │ │ │
│ │ │ │ │ │
│ Login To │ │ │ │
SSO/Oauth Oauth/SSO SSH Keys Application Radius Radius
│ │ │ Password Password Password
│ │ │ │ │ │
│ │ │ │ │ │
│ │ │ │ │ │
│ │ ┌──────────┐ │ │ │
│ │ │ │ │ │ │
└──────────────┴────────│ Laptop │──────────┴───────────────┴───────────────┘
│ │
└──────────┘
▲
│
│
┌──────────┐
│ You │
└──────────┘
< / code > < / pre >
< p > A key design goal is that you authenticate with your device in some manner, and then your device will
2022-05-18 03:34:13 +02:00
continue to authenticate you in the future. Each of these different types of credentials, from SSH keys,
application passwords, to RADIUS passwords and others, are " things your device knows" . Each password
2022-05-01 06:11:32 +02:00
has limited capability, and can only access that exact service or resource.< / p >
< p > This helps improve security; a compromise of the service or the network transmission does not
grant you unlimited access to your account and all its privileges. As the credentials are specific
to a device, if a device is compromised you can revoke its associated credentials. If a
specific service is compromised, only the credentials for that service need to be revoked.< / p >
< p > Due to this model, and the design of Kanidm to centre the device and to have more per-service credentials,
workflows and automation are added or designed to reduce human handling. An example of this
2022-05-18 03:34:13 +02:00
is the use of QR codes with deployment profiles to automatically enroll wireless credentials.< / p >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "installing-the-server" > < a class = "header" href = "#installing-the-server" > Installing the Server< / a > < / h1 >
< blockquote >
2022-05-18 03:34:13 +02:00
< p > < strong > NOTE< / strong > Our preferred deployment method is in containers, the documentation assumes you're running in docker. Kanidm will run in traditional compute, and server builds are available for multiple platforms, or you can build the binaries yourself if you prefer this option.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
< p > Currently we have docker images for the server components. They can be found at:< / p >
< ul >
< li > < a href = "https://hub.docker.com/r/kanidm/server" > https://hub.docker.com/r/kanidm/server< / a > < / li >
< li > < a href = "https://hub.docker.com/r/kanidm/radius" > https://hub.docker.com/r/kanidm/radius< / a > < / li >
< / ul >
< p > You can fetch these by running the commands:< / p >
< pre > < code > docker pull kanidm/server:latest
docker pull kanidm/radius:latest
< / code > < / pre >
< p > If you wish to use an x86_64 cpu-optimised version (See System Requirements CPU), you should use:< / p >
< pre > < code > docker pull kanidm/server:x86_64_latest
< / code > < / pre >
< p > You may need to adjust your example commands throughout this document to suit.< / p >
< h2 id = "development-version" > < a class = "header" href = "#development-version" > Development Version< / a > < / h2 >
< p > If you are interested in running the latest code from development, you can do this by changing the
docker tag to < code > kanidm/server:devel< / code > or < code > kanidm/server:x86_64_v3_devel< / code > instead.< / p >
< h2 id = "system-requirements" > < a class = "header" href = "#system-requirements" > System Requirements< / a > < / h2 >
< h4 id = "cpu" > < a class = "header" href = "#cpu" > CPU< / a > < / h4 >
< p > If you are using the x86_64 cpu-optimised version, you must have a CPU that is from 2013 or newer
(Haswell, Ryzen). The following instruction flags are used.< / p >
< pre > < code > cmov, cx8, fxsr, mmx, sse, sse2, cx16, sahf, popcnt, sse3, sse4.1, sse4.2, avx, avx2,
bmi, bmi2, f16c, fma, lzcnt, movbe, xsave
< / code > < / pre >
2022-05-18 03:34:13 +02:00
< p > Older or unsupported CPUs may raise a SIGIL (Illegal Instruction) on hardware that is not supported
2022-05-01 06:11:32 +02:00
by the project.< / p >
< p > In this case, you should use the standard server:latest image.< / p >
< p > In the future we may apply a baseline of flags as a requirement for x86_64 for the server:latest
image. These flags will be:< / p >
< pre > < code > cmov, cx8, fxsr, mmx, sse, sse2
< / code > < / pre >
< h4 id = "memory" > < a class = "header" href = "#memory" > Memory< / a > < / h4 >
< p > Kanidm extensively uses memory caching, trading memory consumption to improve parallel throughput.
You should expect to see 64KB of ram per entry in your database, depending on cache tuning and settings.< / p >
< h4 id = "disk" > < a class = "header" href = "#disk" > Disk< / a > < / h4 >
< p > You should expect to use up to 8KB of disk per entry you plan to store. At an estimate 10,000 entry
databases will consume 40MB, 100,000 entry will consume 400MB.< / p >
2022-05-18 03:34:13 +02:00
< p > For best performance, you should use non-volatile memory express (NVME), or other Flash storage media.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "tls" > < a class = "header" href = "#tls" > TLS< / a > < / h2 >
< p > You'll need a volume where you can place configuration, certificates, and the database:< / p >
< pre > < code > docker volume create kanidmd
< / code > < / pre >
< p > You should have a chain.pem and key.pem in your kanidmd volume. The reason for requiring
2022-05-18 03:34:13 +02:00
Transport Layer Security (TLS, which replaces the deprecated Secure Sockets Layer, SSL) is explained in < a href = "./why_tls.html" > why tls< / a > . In summary, TLS is our root of trust between the
2022-05-01 06:11:32 +02:00
server and clients, and a critical element of ensuring a secure system.< / p >
< p > The key.pem should be a single PEM private key, with no encryption. The file content should be
similar to:< / p >
< pre > < code > -----BEGIN RSA PRIVATE KEY-----
MII...< base64>
-----END RSA PRIVATE KEY-----
< / code > < / pre >
< p > The chain.pem is a series of PEM formatted certificates. The leaf certificate, or the certificate
that matches the private key should be the first certificate in the file. This should be followed
by the series of intermediates, and the final certificate should be the CA root. For example:< / p >
< pre > < code > -----BEGIN CERTIFICATE-----
< leaf certificate>
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
< intermediate certificate>
-----END CERTIFICATE-----
[ more intermediates if needed ]
-----BEGIN CERTIFICATE-----
< ca/croot certificate>
-----END CERTIFICATE-----
< / code > < / pre >
< blockquote >
< p > < strong > HINT< / strong >
If you are using Let's Encrypt the provided files " fullchain.pem" and " privkey.pem" are already
correctly formatted as required for Kanidm.< / p >
< / blockquote >
< p > You can validate that the leaf certificate matches the key with the command:< / p >
< pre > < code > # openssl rsa -noout -modulus -in key.pem | openssl sha1
d2188932f520e45f2e76153fbbaf13f81ea6c1ef
# openssl x509 -noout -modulus -in chain.pem | openssl sha1
d2188932f520e45f2e76153fbbaf13f81ea6c1ef
< / code > < / pre >
< p > If your chain.pem contains the CA certificate, you can validate this file with the command:< / p >
< pre > < code > openssl verify -CAfile chain.pem chain.pem
< / code > < / pre >
< p > If your chain.pem does not contain the CA certificate (Let's Encrypt chains do not contain the CA
for example) then you can validate with this command.< / p >
< pre > < code > openssl verify -untrusted fullchain.pem fullchain.pem
< / code > < / pre >
< blockquote >
< p > < strong > NOTE< / strong > Here " -untrusted" flag means a list of further certificates in the chain to build up
to the root is provided, but that the system CA root should be consulted. Verification is NOT bypassed
or allowed to be invalid.< / p >
< / blockquote >
< p > If these verifications pass you can now use these certificates with Kanidm. To put the certificates
in place you can use a shell container that mounts the volume such as:< / p >
< pre > < code > docker run --rm -i -t -v kanidmd:/data -v /my/host/path/work:/work opensuse/leap:latest /bin/sh -c " cp /work/* /data/"
< / code > < / pre >
< p > OR for a shell into the volume:< / p >
< pre > < code > docker run --rm -i -t -v kanidmd:/data opensuse/leap:latest /bin/sh
< / code > < / pre >
< h1 id = "continue-on-to-configuring-the-server" > < a class = "header" href = "#continue-on-to-configuring-the-server" > Continue on to < a href = "server_configuration.html" > Configuring the Server< / a > < / a > < / h1 >
< div style = "break-before: page; page-break-before: always;" > < / div > < h2 id = "configuring-the-server" > < a class = "header" href = "#configuring-the-server" > Configuring the Server< / a > < / h2 >
< h3 id = "configuring-servertoml" > < a class = "header" href = "#configuring-servertoml" > Configuring server.toml< / a > < / h3 >
2022-05-18 03:34:13 +02:00
< p > You need a configuration file in the volume named < code > server.toml< / code > . (Within the container it should be < code > /data/server.toml< / code > .) Its contents should be as follows:< / p >
< pre > < code > # The webserver bind address. Will use HTTPS if tls_*
# is provided.
2022-05-01 06:11:32 +02:00
# Defaults to " 127.0.0.1:8443"
bindaddress = " [::]:8443"
#
2022-05-18 03:34:13 +02:00
# The read-only ldap server bind address. The server
# will use LDAPS if tls_* is provided.
2022-05-01 06:11:32 +02:00
# Defaults to " " (disabled)
# ldapbindaddress = " [::]:3636"
#
# The path to the kanidm database.
db_path = " /data/kanidm.db"
#
2022-05-18 03:34:13 +02:00
# If you have a known filesystem, kanidm can tune sqlite
# to match. Valid choices are:
2022-05-01 06:11:32 +02:00
# [zfs, other]
2022-05-18 03:34:13 +02:00
# If you are unsure about this leave it as the default
# (other). After changing this
2022-05-01 06:11:32 +02:00
# value you must run a vacuum task.
# - zfs:
2022-05-18 03:34:13 +02:00
# * sets sqlite pagesize to 64k. You must set
# recordsize=64k on the zfs filesystem.
2022-05-01 06:11:32 +02:00
# - other:
2022-05-18 03:34:13 +02:00
# * sets sqlite pagesize to 4k, matching most
# filesystems block sizes.
2022-05-01 06:11:32 +02:00
# db_fs_type = " zfs"
#
2022-05-18 03:34:13 +02:00
# The number of entries to store in the in-memory cache.
# Minimum value is 256. If unset
2022-05-01 06:11:32 +02:00
# an automatic heuristic is used to scale this.
# db_arc_size = 2048
#
2022-05-18 03:34:13 +02:00
# TLS chain and key in pem format. Both must be
# commented, or both must be present
2022-05-01 06:11:32 +02:00
# tls_chain = " /data/chain.pem"
# tls_key = " /data/key.pem"
#
2022-05-18 03:34:13 +02:00
# The log level of the server. May be default, verbose,
# perfbasic, perffull
2022-05-01 06:11:32 +02:00
# Defaults to " default"
# log_level = " default"
#
2022-05-18 03:34:13 +02:00
# The DNS domain name of the server. This is used in a
# number of security-critical contexts
# such as webauthn, so it *must* match your DNS
# hostname. It is used to create
# security principal names such as `william@idm.example.com`
# so that in a (future)
# trust configuration it is possible to have unique Service
# Principal Names (spns) throughout the topology.
2022-05-01 06:11:32 +02:00
# ⚠️ WARNING ⚠️
2022-05-18 03:34:13 +02:00
# Changing this value WILL break many types of registered
# credentials for accounts
2022-05-01 06:11:32 +02:00
# including but not limited to webauthn, oauth tokens, and more.
2022-05-18 03:34:13 +02:00
# If you change this value you *must* run
# `kanidmd domain_name_change` immediately after.
2022-05-01 06:11:32 +02:00
domain = " idm.example.com"
#
2022-05-18 03:34:13 +02:00
# The origin for webauthn. This is the url to the server,
# with the port included if
# it is non-standard (any port except 443). This must match
# or be a descendent of the
# domain name you configure above. If these two items are
# not consistent, the server WILL refuse to start!
# origin = " https://idm.example.com"
2022-05-01 06:11:32 +02:00
origin = " https://idm.example.com:8443"
#
2022-05-18 03:34:13 +02:00
# The role of this server. This affects available features
# and how replication may interact.
2022-05-01 06:11:32 +02:00
# Valid roles are:
# - WriteReplica
2022-05-18 03:34:13 +02:00
# This server provides all functionality of Kanidm. It
# allows authentication, writes, and
2022-05-01 06:11:32 +02:00
# the web user interface to be served.
# - WriteReplicaNoUI
2022-05-18 03:34:13 +02:00
# This server is the same as a WriteReplica, but does NOT
# offer the web user interface.
2022-05-01 06:11:32 +02:00
# - ReadOnlyReplica
2022-05-18 03:34:13 +02:00
# This server will not writes initiated by clients. It
# supports authentication and reads,
# and must have a replication agreement as a source of
# its data.
2022-05-01 06:11:32 +02:00
# Defaults to " WriteReplica" .
# role = " WriteReplica"
#
# [online_backup]
# The path to the output folder for online backups
# path = " /var/lib/kanidm/backups/"
2022-05-18 03:34:13 +02:00
# The schedule to run online backups (see https://crontab.guru/)
2022-05-01 06:11:32 +02:00
# every day at 22:00 UTC (default)
# schedule = " 00 22 * * *"
# four times a day at 3 minutes past the hour, every 6th hours
# schedule = " 03 */6 * * *"
# Number of backups to keep (default 7)
# versions = 7
#
< / code > < / pre >
< p > An example is located in < a href = "../../examples/server.toml" > examples/server.toml< / a > .< / p >
< blockquote >
< p > < strong > WARNING< / strong > You MUST set the < code > domain< / code > name correctly, aligned with your < code > origin< / code > , else the server
may refuse to start, or some features (e.g. webauthn, oauth) may not work correctly!< / p >
< / blockquote >
< h3 id = "check-the-configuration-is-valid" > < a class = "header" href = "#check-the-configuration-is-valid" > Check the configuration is valid.< / a > < / h3 >
< p > You should test your configuration is valid before you proceed.< / p >
2022-05-23 04:11:43 +02:00
< pre > < code > docker run --rm -i -t -v kanidmd:/data \
2022-05-01 06:11:32 +02:00
kanidm/server:latest /sbin/kanidmd configtest -c /data/server.toml
< / code > < / pre >
< h3 id = "default-admin-account" > < a class = "header" href = "#default-admin-account" > Default Admin Account< / a > < / h3 >
< p > Then you can setup the initial admin account and initialise the database into your volume.< / p >
< pre > < code > docker run --rm -i -t -v kanidmd:/data \
kanidm/server:latest /sbin/kanidmd recover_account -c /data/server.toml -n admin
< / code > < / pre >
< h3 id = "run-the-server" > < a class = "header" href = "#run-the-server" > Run the Server< / a > < / h3 >
< p > Now we can run the server so that it can accept connections. This defaults to using < code > -c /data/server.toml< / code > < / p >
< pre > < code > docker run -p 8443:8443 -v kanidmd:/data kanidm/server:latest
< / code > < / pre >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "security-hardening" > < a class = "header" href = "#security-hardening" > Security Hardening< / a > < / h1 >
< p > Kanidm ships with a secure-by-default configuration, however that is only as strong
as the platform that Kanidm operates in. This could be your container environment
or your Unix-like system.< / p >
< p > This chapter will detail a number of warnings and security practices you should
follow to ensure that Kanidm operates in a secure environment.< / p >
< p > The main server is a high-value target for a potential attack, as Kanidm serves as
the authority on identity and authorisation in a network. Compromise of the Kanidm
2022-05-27 01:20:56 +02:00
server is equivalent to a full-network take over, also known as " game over" .< / p >
2022-05-01 06:11:32 +02:00
< p > The unixd resolver is also a high value target as it can be accessed to allow unauthorised
access to a server, to intercept communications to the server, or more. This also must be protected
2022-05-27 01:20:56 +02:00
carefully.< / p >
2022-05-01 06:11:32 +02:00
< p > For this reason, Kanidm's components must be protected carefully. Kanidm avoids many classic
attacks by being developed in a memory safe language, but risks still exist.< / p >
< h2 id = "startup-warnings" > < a class = "header" href = "#startup-warnings" > Startup Warnings< / a > < / h2 >
< p > At startup Kanidm will warn you if the environment it is running in is suspicious or
has risks. For example:< / p >
< pre > < code > kanidmd server -c /tmp/server.toml
WARNING: permissions on /tmp/server.toml may not be secure. Should be readonly to running uid. This could be a security risk ...
WARNING: /tmp/server.toml has 'everyone' permission bits in the mode. This could be a security risk ...
WARNING: /tmp/server.toml owned by the current uid, which may allow file permission changes. This could be a security risk ...
WARNING: permissions on ../insecure/ca.pem may not be secure. Should be readonly to running uid. This could be a security risk ...
WARNING: permissions on ../insecure/cert.pem may not be secure. Should be readonly to running uid. This could be a security risk ...
WARNING: permissions on ../insecure/key.pem may not be secure. Should be readonly to running uid. This could be a security risk ...
WARNING: ../insecure/key.pem has 'everyone' permission bits in the mode. This could be a security risk ...
WARNING: DB folder /tmp has 'everyone' permission bits in the mode. This could be a security risk ...
< / code > < / pre >
< p > Each warning highlights an issue that may exist in your environment. It is not possible for us to
prescribe an exact configuration that may secure your system. This is why we only present
possible risks.< / p >
2022-05-27 01:20:56 +02:00
< h3 id = "should-be-read-only-to-running-uid" > < a class = "header" href = "#should-be-read-only-to-running-uid" > Should be Read-only to Running UID< / a > < / h3 >
< p > Files, such as configuration files, should be read-only to the UID of the Kanidm daemon. If an attacker is
able to gain code execution, they are then unable to modify the configuration to write, or to over-write
2022-05-01 06:11:32 +02:00
files in other locations, or to tamper with the systems configuration.< / p >
< p > This can be prevented by changing the files ownership to another user, or removing " write" bits
from the group.< / p >
2022-05-27 01:20:56 +02:00
< h3 id = "everyone-permission-bits-in-the-mode" > < a class = "header" href = "#everyone-permission-bits-in-the-mode" > 'everyone' Permission Bits in the Mode< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > This means that given a permission mask, " everyone" or all users of the system can read, write or
execute the content of this file. This may mean that if an account on the system is compromised the
attacker can read Kanidm content and may be able to further attack the system as a result.< / p >
2022-05-27 01:20:56 +02:00
< p > This can be prevented by removing " everyone: execute bits from parent directories containing the
configuration, and removing " everyone" bits from the files in question.< / p >
< h3 id = "owned-by-the-current-uid-which-may-allow-file-permission-changes" > < a class = "header" href = "#owned-by-the-current-uid-which-may-allow-file-permission-changes" > Owned by the Current UID, Which May Allow File Permission Changes< / a > < / h3 >
< p > File permissions in UNIX systems are a discretionary access control system, which means the
named UID owner is able to further modify the access of a file regardless of the current
2022-05-01 06:11:32 +02:00
settings. For example:< / p >
< pre > < code > [william@amethyst 12:25] /tmp > touch test
[william@amethyst 12:25] /tmp > ls -al test
-rw-r--r-- 1 william wheel 0 29 Jul 12:25 test
[william@amethyst 12:25] /tmp > chmod 400 test
[william@amethyst 12:25] /tmp > ls -al test
-r-------- 1 william wheel 0 29 Jul 12:25 test
[william@amethyst 12:25] /tmp > chmod 644 test
[william@amethyst 12:26] /tmp > ls -al test
-rw-r--r-- 1 william wheel 0 29 Jul 12:25 test
< / code > < / pre >
< p > Notice that even though the file was set to " read only" to william, and no permission to any
2022-05-27 01:20:56 +02:00
other users, user " william" can change the bits to add write permissions back or permissions
2022-05-01 06:11:32 +02:00
for other users.< / p >
2022-05-27 01:20:56 +02:00
< p > This can be prevent by making the file owner a different UID than the running process for kanidm.< / p >
< h3 id = "a-secure-example" > < a class = "header" href = "#a-secure-example" > A Secure Example< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > Between these three issues it can be hard to see a possible strategy to secure files, however
2022-05-27 01:20:56 +02:00
one way exists - group read permissions. The most effective method to secure resources for Kanidm
2022-05-01 06:11:32 +02:00
is to set configurations to:< / p >
< pre > < code > [william@amethyst 12:26] /etc/kanidm > ls -al server.toml
-r--r----- 1 root kanidm 212 28 Jul 16:53 server.toml
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > The Kanidm server should be run as " kanidm:kanidm" with the appropriate user and user private
2022-05-01 06:11:32 +02:00
group created on your system. This applies to unixd configuration as well.< / p >
< p > For the database your data folder should be:< / p >
< pre > < code > [root@amethyst 12:38] /data/kanidm > ls -al .
total 1064
drwxrwx--- 3 root kanidm 96 29 Jul 12:38 .
-rw-r----- 1 kanidm kanidm 544768 29 Jul 12:38 kanidm.db
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > This means 770 root:kanidm. This allows Kanidm to create new files in the folder, but prevents
Kanidm from being able to change the permissions of the folder. Because the folder does not have
" everyone" mode bits, the content of the database is secure because users can now cd/read
2022-05-01 06:11:32 +02:00
from the directory.< / p >
2022-05-27 01:20:56 +02:00
< p > Configurations for clients, such as /etc/kanidm/config, should be secured with read-only permissions
and owned by root:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > [william@amethyst 12:26] /etc/kanidm > ls -al config
2022-05-27 01:20:56 +02:00
-r--r--r-- 1 root root 38 10 Jul 10:10 config
2022-05-01 06:11:32 +02:00
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > This file should be " everyone" -readable, which is why the bits are defined as such.< / p >
2022-05-01 06:11:32 +02:00
< blockquote >
< p > NOTE: Why do you use 440 or 444 modes?< / p >
< p > A bug exists in the implementation of readonly() in rust that checks this as " does a write
2022-05-27 01:20:56 +02:00
bit exist for any user" vs " can the current UID write the file?" . This distinction is subtle
but it affects the check. We don't believe this is a significant issue though, because
2022-05-01 06:11:32 +02:00
setting these to 440 and 444 helps to prevent accidental changes by an administrator anyway< / p >
< / blockquote >
2022-05-27 01:20:56 +02:00
< h2 id = "running-as-non-root-in-docker" > < a class = "header" href = "#running-as-non-root-in-docker" > Running as Non-root in docker< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > The commands provided in this book will run kanidmd as " root" in the container to make the onboarding
smoother. However, this is not recommended in production for security reasons.< / p >
2022-05-27 01:20:56 +02:00
< p > You should allocate unique UID and GID numbers for the service to run as on your host
2022-05-01 06:11:32 +02:00
system. In this example we use < code > 1000:1000< / code > < / p >
< p > You will need to adjust the permissions on the < code > /data< / code > volume to ensure that the process
can manage the files. Kanidm requires the ability to write to the < code > /data< / code > directory to create
2022-05-27 01:20:56 +02:00
the sqlite files. This UID/GID number should match the above. You could consider the following
2022-05-01 06:11:32 +02:00
changes to help isolate these changes:< / p >
< pre > < code > docker run --rm -i -t -v kanidmd:/data opensuse/leap:latest /bin/sh
2022-05-27 01:20:56 +02:00
mkdir /data/db/
chown 1000:1000 /data/db/
chmod 750 /data/db/
sed -i -e " s/db_path.*/db_path = \" \/data\/db\/kanidm.db\" /g" /data/server.toml
chown root:root /data/server.toml
chmod 644 /data/server.toml
< / code > < / pre >
< p > Note that the example commands all run inside the docker container.< / p >
< p > You can then use this to run the Kanidm server in docker with a user:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > docker run --rm -i -t -u 1000:1000 -v kanidmd:/data kanidm/server:latest /sbin/kanidmd ...
< / code > < / pre >
< blockquote >
< p > < strong > HINT< / strong >
2022-05-27 01:20:56 +02:00
You need to use the UID or GID number with the < code > -u< / code > argument, as the container can't resolve
2022-05-01 06:11:32 +02:00
usernames from the host system.< / p >
< / blockquote >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "client-tools" > < a class = "header" href = "#client-tools" > Client tools< / a > < / h1 >
2022-06-02 03:20:33 +02:00
< p > To interact with Kanidm as an administrator, you'll need to use our command
line tools. If you haven't installed them yet,
< a href = "installing_client_tools.html" > install them now< / a > .< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "kanidm-configuration" > < a class = "header" href = "#kanidm-configuration" > Kanidm configuration< / a > < / h2 >
2022-05-27 01:20:56 +02:00
< p > You can configure < code > kanidm< / code > to help make commands simpler by modifying < code > ~/.config/kanidm< / code >
or < code > /etc/kanidm/config< / code > .< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > uri = " https://idm.example.com"
verify_ca = true|false
verify_hostnames = true|false
ca_path = " /path/to/ca.pem"
< / code > < / pre >
< p > Once configured, you can test this with:< / p >
< pre > < code > kanidm self whoami --name anonymous
< / code > < / pre >
< h2 id = "session-management" > < a class = "header" href = "#session-management" > Session Management< / a > < / h2 >
2022-05-27 01:20:56 +02:00
< p > To authenticate as a user (for use with the command line), you need to use the < code > login< / code > command
2022-05-01 06:11:32 +02:00
to establish a session token.< / p >
< pre > < code > kanidm login --name USERNAME
kanidm login --name admin
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > Once complete, you can use < code > kanidm< / code > without re-authenticating for a period of time for administration.< / p >
2022-05-01 06:11:32 +02:00
< p > You can list active sessions with:< / p >
< pre > < code > kanidm session list
< / code > < / pre >
< p > Sessions will expire after a period of time (by default 1 hour). To remove these expired sessions
locally you can use:< / p >
< pre > < code > kanidm session cleanup
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > To log out of a session:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm logout --name USERNAME
2022-05-27 01:20:56 +02:00
kanidm logout --name admin< / code > < / pre >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "installing-client-tools" > < a class = "header" href = "#installing-client-tools" > Installing Client Tools< / a > < / h1 >
< blockquote >
2022-05-27 01:20:56 +02:00
< p > < strong > NOTE< / strong > As this project is in a rapid development phase, running different
release versions will likely present incompatibilities. Ensure you're running
matching release versions of client and server binaries. If you have any issues,
check that you are running the latest software.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
< h2 id = "from-packages" > < a class = "header" href = "#from-packages" > From packages< / a > < / h2 >
2022-05-27 01:20:56 +02:00
< p > Kanidm currently supports the following Linux distributions:< / p >
2022-05-01 06:11:32 +02:00
< ul >
< li > OpenSUSE Tumbleweed< / li >
< li > OpenSUSE Leap 15.3/15.4< / li >
< li > Fedora 34/35< / li >
2022-05-10 03:03:16 +02:00
< li > CentOS Stream 9< / li >
2022-05-01 06:11:32 +02:00
< / ul >
2022-05-31 06:26:03 +02:00
< p > The < code > kanidm< / code > client has been built and tested from Windows, but is not (yet) packaged routinely.< / p >
2022-05-01 06:11:32 +02:00
< h3 id = "opensuse-tumbleweed" > < a class = "header" href = "#opensuse-tumbleweed" > OpenSUSE Tumbleweed< / a > < / h3 >
2022-05-27 01:20:56 +02:00
< p > Kanidm has been part of OpenSUSE Tumbleweed since October 2020. You can install
2022-05-01 06:11:32 +02:00
the clients with:< / p >
< pre > < code > zypper ref
zypper in kanidm-clients
< / code > < / pre >
< h3 id = "opensuse-leap-153154" > < a class = "header" href = "#opensuse-leap-153154" > OpenSUSE Leap 15.3/15.4< / a > < / h3 >
2022-05-27 01:20:56 +02:00
< p > Leap 15.3/15.4 does not have full Kanidm support. For an experimental client, you can
2022-05-01 06:11:32 +02:00
try the development repository. Using zypper you can add the repository with:< / p >
< pre > < code > zypper ar -f obs://network:idm network_idm
< / code > < / pre >
< p > Then you need to refresh your metadata and install the clients.< / p >
< pre > < code > zypper ref
zypper in kanidm-clients
< / code > < / pre >
< h3 id = "fedora--centos-stream" > < a class = "header" href = "#fedora--centos-stream" > Fedora / Centos Stream< / a > < / h3 >
2022-05-27 01:20:56 +02:00
< p > Fedora has limited support through the development repository. You need to add the repository
metadata into the correct directory:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > cd /etc/yum.repos.d
# Fedora 34
2022-05-27 01:20:56 +02:00
wget https://download.opensuse.org/repositories/network:/idm/Fedora_34/network:idm.repo
2022-05-01 06:11:32 +02:00
# Fedora 35
2022-05-27 01:20:56 +02:00
wget https://download.opensuse.org/repositories/network:/idm/Fedora_35/network:idm.repo
2022-05-01 06:11:32 +02:00
# Centos Stream 9
2022-05-27 01:20:56 +02:00
wget https://download.opensuse.org/repositories/network:/idm/CentOS_9_Stream/network:idm.repo
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< p > You can then install with:< / p >
2022-05-27 01:20:56 +02:00
< pre > < code > dnf install kanidm-clients
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< h2 id = "from-source-cli-only-not-recommended" > < a class = "header" href = "#from-source-cli-only-not-recommended" > From source (CLI only, not recommended)< / a > < / h2 >
< p > After you check out the source (see < a href = "https://github.com/kanidm/kanidm" > GitHub< / a > ), navigate to:< / p >
< pre > < code > cd kanidm_tools
cargo install --path .
< / code > < / pre >
< h2 id = "checking-that-the-tools-work" > < a class = "header" href = "#checking-that-the-tools-work" > Checking that the tools work< / a > < / h2 >
< p > Now you can check your instance is working. You may need to provide a CA certificate for verification
with the -C parameter:< / p >
< pre > < code > kanidm login --name anonymous
kanidm self whoami -C ../path/to/ca.pem -H https://localhost:8443 --name anonymous
kanidm self whoami -H https://localhost:8443 --name anonymous
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > Now you can take some time to look at what commands are available - please
< a href = "https://github.com/kanidm/kanidm#getting-in-contact--questions" > ask for help at any time< / a > .< / p >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "accounts-and-groups" > < a class = "header" href = "#accounts-and-groups" > Accounts and groups< / a > < / h1 >
2022-05-26 07:08:02 +02:00
< p > Accounts and Groups are the primary reasons for Kanidm to exist. Kanidm is optimised as a repository
for these data. As a result, there are many concepts and important details to understand.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "default-accounts-and-groups" > < a class = "header" href = "#default-accounts-and-groups" > Default Accounts and Groups< / a > < / h2 >
2022-05-26 07:08:02 +02:00
< p > Kanidm ships with a number of default accounts and groups. This is to give you the best
out-of-box experience possible, as well as supplying best practice examples related to modern
Identity Management (IDM) systems.< / p >
< p > The system administrator account has limited privileges (see
< a href = "accounts_and_groups.html#recovering-the-initial-idm_admin-account" > Recovering the Initial idm_admin Account< / a > ) to learn
how to access the inbuilt admin account).
It manages only high-privilege accounts and services. This is to help separate system administration
from identity administration actions. An idm_admin user is also provided that is only for management
2022-05-01 06:11:32 +02:00
of accounts and groups.< / p >
2022-05-26 07:08:02 +02:00
< p > Both the admin and the idm_admin user should < em > NOT< / em > be used for daily activities - they exist for initial
2022-05-01 06:11:32 +02:00
system configuration, and for disaster recovery scenarios. You should delegate permissions
as required to named user accounts instead.< / p >
< p > The majority of the provided content is privilege groups that provide rights over Kanidm
administrative actions. These include groups for account management, person management (personal
and sensitive data), group management, and more.< / p >
< h2 id = "recovering-the-initial-idm_admin-account" > < a class = "header" href = "#recovering-the-initial-idm_admin-account" > Recovering the Initial idm_admin Account< / a > < / h2 >
2022-05-26 07:08:02 +02:00
< p > By default the idm_admin user has no password, and can not be accessed. You should recover it with the
2022-05-01 06:11:32 +02:00
admin (system admin) account. We recommend the use of " reset_credential" as it provides a high
strength, random, machine only password.< / p >
< pre > < code > kanidm account credential reset_credential --name admin idm_admin
Generated password for idm_admin: tqoReZfz....
< / code > < / pre >
< h2 id = "creating-accounts" > < a class = "header" href = "#creating-accounts" > Creating Accounts< / a > < / h2 >
2022-05-26 07:08:02 +02:00
< p > You can now use the idm_admin user to create initial groups and accounts.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm group create demo_group --name idm_admin
kanidm account create demo_user " Demonstration User" --name idm_admin
kanidm group add_members demo_group demo_user --name idm_admin
kanidm group list_members demo_group --name idm_admin
kanidm account get demo_user --name idm_admin
< / code > < / pre >
< p > You can also use anonymous to view users and groups - note that you won't see as many fields due
2022-05-26 07:08:02 +02:00
to the different anonymous access profile limits.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account get demo_user --name anonymous
< / code > < / pre >
< h2 id = "viewing-default-groups" > < a class = "header" href = "#viewing-default-groups" > Viewing Default Groups< / a > < / h2 >
< p > You should take some time to inspect the default groups which are related to
default permissions. These can be viewed with:< / p >
< pre > < code > kanidm group list
kanidm group get < name>
< / code > < / pre >
< h2 id = "resetting-account-credentials" > < a class = "header" href = "#resetting-account-credentials" > Resetting Account Credentials< / a > < / h2 >
2022-05-26 07:08:02 +02:00
< p > Members of the < code > idm_account_manage_priv< / code > group have the rights to manage other users'
2022-05-01 06:11:32 +02:00
accounts security and login aspects. This includes resetting account credentials.< / p >
2022-05-26 07:08:02 +02:00
< p > You can perform a password reset on the demo_user, for example as the idm_admin user, who is
2022-05-01 06:11:32 +02:00
a default member of this group.< / p >
< pre > < code > kanidm account credential set_password demo_user --name idm_admin
kanidm self whoami --name demo_user
< / code > < / pre >
< h2 id = "nested-groups" > < a class = "header" href = "#nested-groups" > Nested Groups< / a > < / h2 >
< p > Kanidm supports groups being members of groups, allowing nested groups. These nesting relationships
are shown through the " memberof" attribute on groups and accounts.< / p >
2022-05-26 07:08:02 +02:00
< p > Kanidm makes all group membership determinations by inspecting an entry's " memberof" attribute.< / p >
2022-05-01 06:11:32 +02:00
< p > An example can be easily shown with:< / p >
< pre > < code > kanidm group create group_1 --name idm_admin
kanidm group create group_2 --name idm_admin
kanidm account create nest_example " Nesting Account Example" --name idm_admin
kanidm group add_members group_1 group_2 --name idm_admin
kanidm group add_members group2 nest_example --name idm_admin
kanidm account get nest_example --name anonymous
< / code > < / pre >
< h2 id = "account-validity" > < a class = "header" href = "#account-validity" > Account Validity< / a > < / h2 >
2022-05-26 07:08:02 +02:00
< p > Kanidm supports accounts that are only able to be authenticated between specific date and time
2022-05-01 06:11:32 +02:00
windows. This takes the form of a " valid from" attribute that defines the earliest start
date where authentication can succeed, and an expiry date where the account will no longer
allow authentication.< / p >
< p > This can be displayed with:< / p >
< pre > < code > kanidm account validity show demo_user --name idm_admin
valid after: 2020-09-25T21:22:04+10:00
expire: 2020-09-25T01:22:04+10:00
< / code > < / pre >
< p > These datetimes are stored in the server as UTC, but presented according to your local system time
to aid correct understanding of when the events will occur.< / p >
< p > To set the values, an account with account management permission is required (for example, idm_admin).
Again, these values will correctly translated from the entered local timezone to UTC.< / p >
< pre > < code > # Set the earliest time the account can start authenticating
kanidm account validity begin_from demo_user '2020-09-25T11:22:04+00:00' --name idm_admin
# Set the expiry or end date of the account
kanidm account validity expire_at demo_user '2020-09-25T11:22:04+00:00' --name idm_admin
< / code > < / pre >
< p > To unset or remove these values the following can be used:< / p >
< pre > < code > kanidm account validity begin_from demo_user any|clear --name idm_admin
kanidm account validity expire_at demo_user never|clear --name idm_admin
< / code > < / pre >
2022-05-26 07:08:02 +02:00
< p > To " lock" an account, you can set the expire_at value to the past, or unix epoch. Even in the situation
2022-05-01 06:11:32 +02:00
where the " valid from" is < em > after< / em > the expire_at, the expire_at will be respected.< / p >
< pre > < code > kanidm account validity expire_at demo_user 1970-01-01T00:00:00+00:00 --name idm_admin
< / code > < / pre >
< p > These validity settings impact all authentication functions of the account (kanidm, ldap, radius).< / p >
< h2 id = "people-accounts" > < a class = "header" href = "#people-accounts" > People Accounts< / a > < / h2 >
< p > Kanidm allows extending accounts to include additional " people" attributes,
such as their legal name and email address.< / p >
< p > Initially, an account does not have these attributes. If desired, an account
may be modified to have these " person" attributes like so:< / p >
< pre > < code > # Note, both the --legalname and --mail flags may be omitted
kanidm account person extend demo_user --legalname " initial name" --mail " initial@email.address"
< / code > < / pre >
< p > Once an account has been extended, the " person" attributes may be set by the
user of the account, or anyone with enough privileges.< / p >
< p > Whether an account is currently a " person" or not can be identified from the " account get" output:< / p >
< pre > < code > kanidm account get demo_user
# ---
# class: person
# ... (other output omitted)
< / code > < / pre >
< p > The presence of a " class: person" stanza indicates that this account may have
" people" attributes.< / p >
< h3 id = "allowing-people-accounts-to-change-their-mail-attribute" > < a class = "header" href = "#allowing-people-accounts-to-change-their-mail-attribute" > Allowing people accounts to change their mail attribute< / a > < / h3 >
< p > By default, Kanidm allows an account to change some attributes, but not their
mail address.< / p >
< p > Adding the user to the < code > idm_people_self_write_mail< / code > group, as shown
below, allows the user to edit their own mail.< / p >
< pre > < code > kanidm group add_members idm_people_self_write_mail_priv demo_user --name idm_admin
< / code > < / pre >
< h2 id = "why-cant-i-change-admin-with-idm_admin" > < a class = "header" href = "#why-cant-i-change-admin-with-idm_admin" > Why Can't I Change admin With idm_admin?< / a > < / h2 >
< p > As a security mechanism there is a distinction between " accounts" and " high permission
accounts" . This is to help prevent elevation attacks, where say a member of a
service desk could attempt to reset the password of idm_admin or admin, or even a member of
HR or System Admin teams to move laterally.< / p >
< p > Generally, membership of a " privilege" group that ships with Kanidm, such as:< / p >
< ul >
< li > idm_account_manage_priv< / li >
< li > idm_people_read_priv< / li >
< li > idm_schema_manage_priv< / li >
< li > many more ...< / li >
< / ul >
2022-05-26 07:08:02 +02:00
< p > ...indirectly grants you membership to " idm_high_privilege" . If you are a member of
2022-05-01 06:11:32 +02:00
this group, the standard " account" and " people" rights groups are NOT able to
alter, read or manage these accounts. To manage these accounts higher rights
are required, such as those held by the admin account are required.< / p >
< p > Further, groups that are considered " idm_high_privilege" can NOT be managed
by the standard " idm_group_manage_priv" group.< / p >
< p > Management of high privilege accounts and groups is granted through the
the " hp" variants of all privileges. A non-conclusive list:< / p >
< ul >
< li > idm_hp_account_read_priv< / li >
< li > idm_hp_account_manage_priv< / li >
< li > idm_hp_account_write_priv< / li >
< li > idm_hp_group_manage_priv< / li >
< li > idm_hp_group_write_priv< / li >
< / ul >
< p > Membership of any of these groups should be considered to be equivalent to
system administration rights in the directory, and by extension, over all network
resources that trust Kanidm.< / p >
< p > All groups that are flagged as " idm_high_privilege" should be audited and
monitored to ensure that they are not altered.< / p >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "administration-tasks" > < a class = "header" href = "#administration-tasks" > Administration Tasks< / a > < / h1 >
2022-05-26 07:08:02 +02:00
< p > This chapter describes some of the routine administration tasks for running
a Kanidm server, such as making backups and restoring from backups, testing
server configuration, reindexing, verifying data consistency, and renaming
your domain.< / p >
2022-05-01 06:11:32 +02:00
< h1 id = "backup-and-restore" > < a class = "header" href = "#backup-and-restore" > Backup and Restore< / a > < / h1 >
2022-05-26 07:08:02 +02:00
< p > With any Identity Management (IDM) software, it's important you have the capability to restore in
case of a disaster - be that physical damage or a mistake. Kanidm supports backup
and restore of the database with three methods.< / p >
< h2 id = "method-1-preferred" > < a class = "header" href = "#method-1-preferred" > Method 1 (Preferred)< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > Method 1 involves taking a backup of the database entry content, which is then re-indexed on restore.
This is the preferred method.< / p >
< p > To take the backup (assuming our docker environment) you first need to stop the instance:< / p >
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data -v kanidmd_backups:/backup \
kanidm/server:latest /sbin/kanidmd backup -c /data/server.toml \
/backup/kanidm.backup.json
docker start < container name>
< / code > < / pre >
< p > You can then restart your instance. DO NOT modify the backup.json as it may introduce
data errors into your instance.< / p >
< p > To restore from the backup:< / p >
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data -v kanidmd_backups:/backup \
kanidm/server:latest /sbin/kanidmd restore -c /data/server.toml \
/backup/kanidm.backup.json
docker start < container name>
< / code > < / pre >
< p > That's it!< / p >
< h2 id = "method-2" > < a class = "header" href = "#method-2" > Method 2< / a > < / h2 >
< p > This is a simple backup of the data volume.< / p >
< pre > < code > docker stop < container name>
# Backup your docker's volume folder
docker start < container name>
< / code > < / pre >
< h2 id = "method-3" > < a class = "header" href = "#method-3" > Method 3< / a > < / h2 >
< p > Automatic backups can be generated online by a < code > kanidmd server< / code > instance
by including the < code > [online_backup]< / code > section in the < code > server.toml< / code > .
This allows you to run regular backups, defined by a cron schedule, and maintain
2022-05-26 07:08:02 +02:00
the number of backup versions to keep. An example is located in
< a href = "https://github.com/kanidm/kanidm/blob/master/examples/server.toml" > examples/server.toml< / a > .< / p >
2022-05-01 06:11:32 +02:00
< h1 id = "configuration-test" > < a class = "header" href = "#configuration-test" > Configuration Test< / a > < / h1 >
< p > You can test your configuration will correctly start with the server.< / p >
< blockquote >
< p > < strong > WARNING:< / strong > While this is a configuration test, it still needs to open the database so that
it can check a number of internal values are consistent with the configuration. As a result,
this requires the instance under config test to be stopped!< / p >
< / blockquote >
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data \
kanidm/server:latest /sbin/kanidmd configtest -c /data/server.toml
docker start < container name>
< / code > < / pre >
< h1 id = "reindexing-after-schema-extension" > < a class = "header" href = "#reindexing-after-schema-extension" > Reindexing after schema extension< / a > < / h1 >
< p > In some (rare) cases you may need to reindex.
Please note the server will sometimes reindex on startup as a result of the project
changing its internal schema definitions. This is normal and expected - you may never need
to start a reindex yourself as a result!< / p >
2022-05-26 07:08:02 +02:00
< p > You'll likely notice a need to reindex if you add indexes to schema and you see a message in
your logs such as:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > Index EQUALITY name not found
Index {type} {attribute} not found
< / code > < / pre >
< p > This indicates that an index of type equality has been added for name, but the indexing process
has not been run. The server will continue to operate and the query execution code will correctly
process the query - however it will not be the optimal method of delivering the results as we need to
disregard this part of the query and act as though it's un-indexed.< / p >
< p > Reindexing will resolve this by forcing all indexes to be recreated based on their schema
definitions (this works even though the schema is in the same database!)< / p >
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data \
kanidm/server:latest /sbin/kanidmd reindex -c /data/server.toml
docker start < container name>
< / code > < / pre >
< p > Generally, reindexing is a rare action and should not normally be required.< / p >
< h1 id = "vacuum" > < a class = "header" href = "#vacuum" > Vacuum< / a > < / h1 >
< p > < a href = "https://www.sqlite.org/lang_vacuum.html" > Vacuuming< / a > is the process of reclaiming un-used pages
from the sqlite freelists, as well as performing some data reordering tasks that may make some
queries more efficient . It is recommended that you vacuum after a reindex is performed or
when you wish to reclaim space in the database file.< / p >
< p > Vacuum is also able to change the pagesize of the database. After changing < code > db_fs_type< / code > (which affects
2022-05-26 07:08:02 +02:00
pagesize) in server.toml, you must run a vacuum for this to take effect:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data \
kanidm/server:latest /sbin/kanidmd vacuum -c /data/server.toml
docker start < container name>
< / code > < / pre >
< h1 id = "verification" > < a class = "header" href = "#verification" > Verification< / a > < / h1 >
< p > The server ships with a number of verification utilities to ensure that data is consistent such
as referential integrity or memberof.< / p >
< p > Note that verification really is a last resort - the server does < em > a lot< / em > to prevent and self-heal
from errors at run time, so you should rarely if ever require this utility. This utility was
developed to guarantee consistency during development!< / p >
< p > You can run a verification with:< / p >
< pre > < code > docker stop < container name>
docker run --rm -i -t -v kanidmd:/data \
kanidm/server:latest /sbin/kanidmd verify -c /data/server.toml
docker start < container name>
< / code > < / pre >
< p > If you have errors, please contact the project to help support you to resolve these.< / p >
< h1 id = "rename-the-domain" > < a class = "header" href = "#rename-the-domain" > Rename the domain< / a > < / h1 >
< p > There are some cases where you may need to rename the domain. You should have configured
this initially in the setup, however you may have a situation where a business is changing
name, merging, or other needs which may prompt this needing to be changed.< / p >
< blockquote >
< p > < strong > WARNING:< / strong > This WILL break ALL u2f/webauthn tokens that have been enrolled, which MAY cause
accounts to be locked out and unrecoverable until further action is taken. DO NOT CHANGE
the domain name unless REQUIRED and have a plan on how to manage these issues.< / p >
< / blockquote >
< blockquote >
< p > < strong > WARNING:< / strong > This operation can take an extensive amount of time as ALL accounts and groups
2022-05-26 07:08:02 +02:00
in the domain MUST have their Security Principal Names (SPNs) regenerated. This WILL also cause
a large delay in replication once the system is restarted.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
2022-05-26 07:08:02 +02:00
< p > You should make a backup before proceeding with this operation.< / p >
2022-05-01 06:11:32 +02:00
< p > When you have a created a migration plan and strategy on handling the invalidation of webauthn,
you can then rename the domain.< / p >
< p > First, stop the instance.< / p >
< pre > < code > docker stop < container name>
< / code > < / pre >
< p > Second, change < code > domain< / code > and < code > origin< / code > in < code > server.toml< / code > .< / p >
< p > Third, trigger the database domain rename process.< / p >
2022-05-23 04:11:43 +02:00
< pre > < code > docker run --rm -i -t -v kanidmd:/data \
2022-05-01 06:11:32 +02:00
kanidm/server:latest /sbin/kanidmd domain_name_change -c /data/server.toml
< / code > < / pre >
< p > Finally, you can now start your instance again.< / p >
< pre > < code > docker start < container name>
< / code > < / pre >
< h1 id = "raw-actions" > < a class = "header" href = "#raw-actions" > Raw actions< / a > < / h1 >
< p > The server has a low-level stateful API you can use for more complex or advanced tasks on large numbers
of entries at once. Some examples are below, but generally we advise you to use the APIs as listed
above.< / p >
< pre > < code > # Create from json (group or account)
kanidm raw create -H https://localhost:8443 -C ../insecure/ca.pem -D admin example.create.account.json
kanidm raw create -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin example.create.group.json
# Apply a json stateful modification to all entries matching a filter
kanidm raw modify -H https://localhost:8443 -C ../insecure/ca.pem -D admin '{" or" : [ {" eq" : [" name" , " idm_person_account_create_priv" ]}, {" eq" : [" name" , " idm_service_account_create_priv" ]}, {" eq" : [" name" , " idm_account_write_priv" ]}, {" eq" : [" name" , " idm_group_write_priv" ]}, {" eq" : [" name" , " idm_people_write_priv" ]}, {" eq" : [" name" , " idm_group_create_priv" ]} ]}' example.modify.idm_admin.json
kanidm raw modify -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin '{" eq" : [" name" , " idm_admins" ]}' example.modify.idm_admin.json
# Search and show the database representations
kanidm raw search -H https://localhost:8443 -C ../insecure/ca.pem -D admin '{" eq" : [" name" , " idm_admin" ]}'
# Delete all entries matching a filter
kanidm raw delete -H https://localhost:8443 -C ../insecure/ca.pem -D idm_admin '{" eq" : [" name" , " test_account_delete_me" ]}'
< / code > < / pre >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "monitoring-the-platform" > < a class = "header" href = "#monitoring-the-platform" > Monitoring the platform< / a > < / h1 >
2022-05-25 23:52:53 +02:00
< p > The monitoring design of Kanidm is still very much in its infancy -
< a href = "https://github.com/kanidm/kanidm/issues/216" > take part in the dicussion at github.com/kanidm/kanidm/issues/216< / a > .< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "kanidmd" > < a class = "header" href = "#kanidmd" > kanidmd< / a > < / h2 >
2022-05-25 23:52:53 +02:00
< p > kanidmd currently responds to HTTP GET requests at the < code > /status< / code > endpoint with a JSON object of
either " true" or " false" . < code > true< / code > indicates that the platform is responding to requests.< / p >
2022-05-01 06:11:32 +02:00
< table > < thead > < tr > < th > URL< / th > < th > < code > < hostname> /status< / code > < / th > < / tr > < / thead > < tbody >
< tr > < td > Example URL< / td > < td > < code > https://example.com/status< / code > < / td > < / tr >
< tr > < td > Expected response< / td > < td > One of either < code > true< / code > or < code > false< / code > (without quotes)< / td > < / tr >
< tr > < td > Additional Headers< / td > < td > x-kanidm-opid< / td > < / tr >
< tr > < td > Content Type< / td > < td > application/json< / td > < / tr >
< tr > < td > Cookies< / td > < td > kanidm-session< / td > < / tr >
< / tbody > < / table >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "password-quality-and-badlisting" > < a class = "header" href = "#password-quality-and-badlisting" > Password Quality and Badlisting< / a > < / h1 >
2022-05-25 23:52:53 +02:00
< p > Kanidm embeds a set of tools to help your users use and create strong passwords.
This is important as not all user types will require multi-factor authentication (MFA)
for their roles, but compromised accounts still pose a risk. There may also be deployment
or other barriers to a site rolling out sitewide MFA.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "quality-checking" > < a class = "header" href = "#quality-checking" > Quality Checking< / a > < / h2 >
2022-05-25 23:52:53 +02:00
< p > Kanidm enforces that all passwords are checked by the library " < a href = "https://github.com/dropbox/zxcvbn" > zxcvbn< / a > " .
This has a large number of checks for password quality. It also provides constructive feedback to users on how
to improve their passwords if they are rejected.< / p >
< p > Some things that zxcvbn looks for is use of the account name or email in the password, common passwords,
low entropy passwords, dates, reverse words and more.< / p >
2022-05-01 06:11:32 +02:00
< p > This library can not be disabled - all passwords in Kanidm must pass this check.< / p >
< h2 id = "password-badlisting" > < a class = "header" href = "#password-badlisting" > Password Badlisting< / a > < / h2 >
2022-05-25 23:52:53 +02:00
< p > This is the process of configuring a list of passwords to exclude from being able to be used.
This is especially useful if a specific business has been notified of a compromised account, allowing
you to maintain a list of customised excluded passwords.< / p >
< p > The other value to this feature is being able to badlist common passwords that zxcvbn does not detect, or
from other large scale password compromises.< / p >
< p > By default we ship with a preconfigured badlist that is updated over time as new password breach lists are
made available.< / p >
< h2 id = "updating-your-own-badlist" > < a class = "header" href = "#updating-your-own-badlist" > Updating your own Badlist< / a > < / h2 >
< p > You can update your own badlist by using the provided < code > kanidm_badlist_preprocess< / code > tool which helps to automate this process.< / p >
< p > Given a list of passwords in a text file, it will generate a modification set which can be applied.
The tool also provides the command you need to run to apply this:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm_badlist_preprocess -m -o /tmp/modlist.json < password file> [< password file> < password file> ...]
< / code > < / pre >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "posix-accounts-and-groups" > < a class = "header" href = "#posix-accounts-and-groups" > POSIX Accounts and Groups< / a > < / h1 >
< p > Kanidm has features that enable its accounts and groups to be consumed on
POSIX-like machines, such as Linux, FreeBSD, or others.< / p >
< h2 id = "notes-on-posix-features" > < a class = "header" href = "#notes-on-posix-features" > Notes on POSIX Features< / a > < / h2 >
< p > Many design decisions have been made in the POSIX features
2022-05-25 23:52:53 +02:00
of Kanidm that are intended to make distributed systems easier to manage and
2022-05-01 06:11:32 +02:00
client systems more secure.< / p >
2022-05-25 23:52:53 +02:00
< h3 id = "uid-and-gid-numbers" > < a class = "header" href = "#uid-and-gid-numbers" > UID and GID Numbers< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > In Kanidm there is no difference between a UID and a GID number. On most UNIX systems
a user will create all files with a primary user and group. The primary group is
effectively equivalent to the permissions of the user. It is very easy to see scenarios
where someone may change the account to have a shared primary group (ie < code > allusers< / code > ),
but without changing the umask on all client systems. This can cause users' data to be
compromised by any member of the same shared group.< / p >
< p > To prevent this, many systems create a " user private group" , or UPG. This group has the
2022-05-25 23:52:53 +02:00
GID number matching the UID of the user, and the user sets their primary
group ID to the GID number of the UPG.< / p >
2022-05-01 06:11:32 +02:00
< p > As there is now an equivalence between the UID and GID number of the user and the UPG,
2022-05-25 23:52:53 +02:00
there is no benefit in separating these values. As a result Kanidm accounts < em > only< / em >
have a GID number, which is also considered to be its UID number as well. This has the benefit
of preventing the accidental creation of a separate group that has an overlapping GID number
2022-05-01 06:11:32 +02:00
(the < code > uniqueness< / code > attribute of the schema will block the creation).< / p >
2022-05-25 23:52:53 +02:00
< h3 id = "upg-generation" > < a class = "header" href = "#upg-generation" > UPG Generation< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > Due to the requirement that a user have a UPG for security, many systems create these as
2022-05-25 23:52:53 +02:00
two independent items. For example in /etc/passwd and /etc/group:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > # passwd
william:x:654401105:654401105::/home/william:/bin/zsh
# group
william:x:654401105:
< / code > < / pre >
< p > Other systems like FreeIPA use a plugin that generates a UPG as a database record on
creation of the account.< / p >
2022-05-25 23:52:53 +02:00
< p > Kanidm does neither of these. As the GID number of the user must be unique, and a user
2022-05-01 06:11:32 +02:00
implies the UPG must exist, we can generate UPG's on-demand from the account.
This has a single side effect - that you are unable to add any members to a
UPG - given the nature of a user private group, this is the point.< / p >
2022-05-25 23:52:53 +02:00
< h3 id = "gid-number-generation" > < a class = "header" href = "#gid-number-generation" > GID Number Generation< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > In the future, Kanidm plans to have asynchronous replication as a feature between writable
database servers. In this case, we need to be able to allocate stable and reliable
2022-05-25 23:52:53 +02:00
GID numbers to accounts on replicas that may not be in continual communication.< / p >
< p > To do this, we use the last 32 bits of the account or group's UUID to
generate the GID number.< / p >
2022-05-01 06:11:32 +02:00
< p > A valid concern is the possibility of duplication in the lower 32 bits. Given the
birthday problem, if you have 77,000 groups and accounts, you have a 50% chance
of duplication. With 50,000 you have a 20% chance, 9,300 you have a 1% chance and
with 2900 you have a 0.1% chance.< / p >
< p > We advise that if you have a site with > 10,000 users you should use an external system
2022-05-25 23:52:53 +02:00
to allocate GID numbers serially or consistently to avoid potential duplication events.< / p >
2022-05-01 06:11:32 +02:00
< p > This design decision is made as most small sites will benefit greatly from the
2022-05-25 23:52:53 +02:00
auto-allocation policy and the simplicity of its design, while larger enterprises
will already have IDM or business process applications for HR/People that are
2022-05-01 06:11:32 +02:00
capable of supplying this kind of data in batch jobs.< / p >
2022-05-25 23:52:53 +02:00
< h2 id = "enabling-posix-attributes" > < a class = "header" href = "#enabling-posix-attributes" > Enabling POSIX Attributes< / a > < / h2 >
< h3 id = "enabling-posix-attributes-on-accounts" > < a class = "header" href = "#enabling-posix-attributes-on-accounts" > Enabling POSIX Attributes on Accounts< / a > < / h3 >
< p > To enable POSIX account features and IDs on an account, you require the permission
< code > idm_account_unix_extend_priv< / code > . This is provided to < code > idm_admins< / code > in the default database.< / p >
< p > You can then use the following command to enable POSIX extensions.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account posix set --name idm_admin < account_id> [--shell SHELL --gidnumber GID]
kanidm account posix set --name idm_admin demo_user
kanidm account posix set --name idm_admin demo_user --shell /bin/zsh
kanidm account posix set --name idm_admin demo_user --gidnumber 2001
< / code > < / pre >
2022-05-25 23:52:53 +02:00
< p > You can view the accounts POSIX token details with:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account posix show --name anonymous demo_user
< / code > < / pre >
2022-05-25 23:52:53 +02:00
< h3 id = "enabling-posix-attributes-on-groups" > < a class = "header" href = "#enabling-posix-attributes-on-groups" > Enabling POSIX Attributes on Groups< / a > < / h3 >
< p > To enable POSIX group features and IDs on an account, you require the permission < code > idm_group_unix_extend_priv< / code > .
2022-05-01 06:11:32 +02:00
This is provided to < code > idm_admins< / code > in the default database.< / p >
2022-05-25 23:52:53 +02:00
< p > You can then use the following command to enable POSIX extensions:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm group posix set --name idm_admin < group_id> [--gidnumber GID]
kanidm group posix set --name idm_admin demo_group
kanidm group posix set --name idm_admin demo_group --gidnumber 2001
< / code > < / pre >
2022-05-25 23:52:53 +02:00
< p > You can view the accounts POSIX token details with:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm group posix show --name anonymous demo_group
< / code > < / pre >
2022-05-25 23:52:53 +02:00
< p > POSIX-enabled groups will supply their members as POSIX members to clients. There is no
special or separate type of membership for POSIX members required.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "troubleshooting-common-issues" > < a class = "header" href = "#troubleshooting-common-issues" > Troubleshooting Common Issues< / a > < / h2 >
2022-05-25 23:52:53 +02:00
< h3 id = "subuid-conflicts-with-podman" > < a class = "header" href = "#subuid-conflicts-with-podman" > subuid conflicts with Podman< / a > < / h3 >
< p > Due to the way that Podman operates, in some cases using the Kanidm client inside non-root containers
with Kanidm accounts may fail with an error such as:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > ERRO[0000] cannot find UID/GID for user NAME: No subuid ranges found for user " NAME" in /etc/subuid
< / code > < / pre >
2022-05-25 23:52:53 +02:00
< p > This is a fault in Podman and how it attempts to provide non-root containers, when UID/GIDs
are greater than 65535. In this case you may manually allocate your users GID number to be
between 1000 - 65535, which may not trigger the fault.< / p >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "ssh-key-distribution" > < a class = "header" href = "#ssh-key-distribution" > SSH Key Distribution< / a > < / h1 >
2022-05-27 01:20:56 +02:00
< p > To support SSH authentication securely to a large set of hosts running SSH, we support
distribution of SSH public keys via the Kanidm server.< / p >
< h2 id = "configuring-accounts" > < a class = "header" href = "#configuring-accounts" > Configuring Accounts< / a > < / h2 >
< p > To view the current SSH public keys on accounts, you can use:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account ssh list_publickeys --name < login user> < account to view>
kanidm account ssh list_publickeys --name idm_admin william
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > All users by default can self-manage their SSH public keys. To upload a key, a command like this
2022-05-01 06:11:32 +02:00
is the best way to do so:< / p >
< pre > < code > kanidm account ssh add_publickey --name william william 'test-key' " `cat ~/.ssh/id_rsa.pub`"
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > To remove (revoke) an SSH public key, delete them by the tag name:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account ssh delete_publickey --name william william 'test-key'
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< h2 id = "security-notes" > < a class = "header" href = "#security-notes" > Security Notes< / a > < / h2 >
< p > As a security feature, Kanidm validates < em > all< / em > public keys to ensure they are valid SSH public keys.
2022-05-01 06:11:32 +02:00
Uploading a private key or other data will be rejected. For example:< / p >
< pre > < code > kanidm account ssh add_publickey --name william william 'test-key' " invalid"
Enter password:
2022-05-27 01:20:56 +02:00
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value:
Http(400, Some(SchemaViolation(InvalidAttributeSyntax)))', src/libcore/result.rs:1084:5
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< h2 id = "server-configuration" > < a class = "header" href = "#server-configuration" > Server Configuration< / a > < / h2 >
2022-05-27 01:20:56 +02:00
< h3 id = "public-key-caching-configuration" > < a class = "header" href = "#public-key-caching-configuration" > Public Key Caching Configuration< / a > < / h3 >
< p > If you have kanidm_unixd running, you can use it to locally cache SSH public keys. This means you
can still SSH into your machines, even if your network is down, you move away from Kanidm, or
2022-05-01 06:11:32 +02:00
some other interruption occurs.< / p >
< p > The kanidm_ssh_authorizedkeys command is part of the kanidm-unix-clients package, so should be installed
on the servers. It communicates to kanidm_unixd, so you should have a configured PAM/nsswitch
setup as well.< / p >
< p > You can test this is configured correctly by running:< / p >
< pre > < code > kanidm_ssh_authorizedkeys < account name>
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > If the account has SSH public keys you should see them listed, one per line.< / p >
2022-05-01 06:11:32 +02:00
< p > To configure servers to accept these keys, you must change their /etc/ssh/sshd_config to
contain the lines:< / p >
< pre > < code > PubkeyAuthentication yes
UsePAM yes
AuthorizedKeysCommand /usr/bin/kanidm_ssh_authorizedkeys %u
AuthorizedKeysCommandUser nobody
< / code > < / pre >
< p > Restart sshd, and then attempt to authenticate with the keys.< / p >
< p > It's highly recommended you keep your client configuration and sshd_configuration in a configuration
management tool such as salt or ansible.< / p >
< blockquote >
< p > < strong > NOTICE:< / strong >
With a working SSH key setup, you should also consider adding the following
sshd_config options as hardening.< / p >
< / blockquote >
< pre > < code > PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
GSSAPIAuthentication no
KerberosAuthentication no
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< h3 id = "direct-communication-configuration" > < a class = "header" href = "#direct-communication-configuration" > Direct Communication Configuration< / a > < / h3 >
< p > In this mode, the authorised keys commands will contact Kanidm directly.< / p >
2022-05-01 06:11:32 +02:00
< blockquote >
< p > < strong > NOTICE:< / strong >
2022-05-27 01:20:56 +02:00
As Kanidm is contacted directly there is no SSH public key cache. Any network
2022-05-01 06:11:32 +02:00
outage or communication loss may prevent you accessing your systems. You should
only use this version if you have a requirement for it.< / p >
< / blockquote >
< p > The kanidm_ssh_authorizedkeys_direct command is part of the kanidm-clients package, so should be installed
on the servers.< / p >
< p > To configure the tool, you should edit /etc/kanidm/config, as documented in < a href = "./client_tools.html" > clients< / a > < / p >
< p > You can test this is configured correctly by running:< / p >
< pre > < code > kanidm_ssh_authorizedkeys_direct -D anonymous < account name>
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > If the account has SSH public keys you should see them listed, one per line.< / p >
2022-05-01 06:11:32 +02:00
< p > To configure servers to accept these keys, you must change their /etc/ssh/sshd_config to
contain the lines:< / p >
< pre > < code > PubkeyAuthentication yes
UsePAM yes
AuthorizedKeysCommand /usr/bin/kanidm_ssh_authorizedkeys_direct -D anonymous %u
AuthorizedKeysCommandUser nobody
< / code > < / pre >
< p > Restart sshd, and then attempt to authenticate with the keys.< / p >
< p > It's highly recommended you keep your client configuration and sshd_configuration in a configuration
management tool such as salt or ansible.< / p >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "recycle-bin" > < a class = "header" href = "#recycle-bin" > Recycle Bin< / a > < / h1 >
< p > The recycle bin is a storage of deleted entries from the server. This allows
recovery from mistakes for a period of time.< / p >
< blockquote >
< p > < strong > WARNING:< / strong > The recycle bin is a best effort - when recovering in some cases
not everything can be " put back" the way it was. Be sure to check your entries
are valid once they have been revived.< / p >
< / blockquote >
< h2 id = "where-is-the-recycle-bin" > < a class = "header" href = "#where-is-the-recycle-bin" > Where is the Recycle Bin?< / a > < / h2 >
< p > The recycle bin is stored as part of your main database - it is included in all
backups and restores, just like any other data. It is also replicated between
all servers.< / p >
2022-05-27 01:20:56 +02:00
< h2 id = "how-do-things-get-into-the-recycle-bin" > < a class = "header" href = "#how-do-things-get-into-the-recycle-bin" > How do Things Get Into the Recycle Bin?< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > Any delete operation of an entry will cause it to be sent to the recycle bin. No
configuration or specification is required.< / p >
2022-05-27 01:20:56 +02:00
< h2 id = "how-long-do-items-stay-in-the-recycle-bin" > < a class = "header" href = "#how-long-do-items-stay-in-the-recycle-bin" > How Long Do Items Stay in the Recycle Bin?< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > Currently they stay up to 1 week before they are removed.< / p >
< h2 id = "managing-the-recycle-bin" > < a class = "header" href = "#managing-the-recycle-bin" > Managing the Recycle Bin< / a > < / h2 >
< p > You can display all items in the Recycle Bin with:< / p >
< pre > < code > kanidm recycle_bin list --name admin
< / code > < / pre >
< p > You can show a single items with:< / p >
< pre > < code > kanidm recycle_bin get --name admin < id>
< / code > < / pre >
< p > An entry can be revived with:< / p >
< pre > < code > kanidm recycle_bin revive --name admin < id>
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< h2 id = "edge-cases" > < a class = "header" href = "#edge-cases" > Edge Cases< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > The recycle bin is a best effort to restore your data - there are some cases where
the revived entries may not be the same as their were when they were deleted. This
generally revolves around reference types such as group membership, or when the reference
type includes supplemental map data such as the oauth2 scope map type.< / p >
< p > An example of this data loss is the following steps:< / p >
< pre > < code > add user1
add group1
add user1 as member of group1
delete user1
delete group1
revive user1
revive group1
< / code > < / pre >
< p > In this series of steps, due to the way that referential integrity is implemented, the
membership of user1 in group1 would be lost in this process. To explain why:< / p >
< pre > < code > add user1
add group1
add user1 as member of group1 // refint between the two established, and memberof added
delete user1 // group1 removes member user1 from refint
delete group1 // user1 now removes memberof group1 from refint
revive user1 // re-add groups based on directmemberof (empty set)
revive group1 // no members
< / code > < / pre >
< p > These issues could be looked at again in the future, but for now we think that deletes of
groups is rare - we expect recycle bin to save you in " opps" moments, and in a majority
of cases you may delete a group or a user and then restore them. To handle this series
of steps requires extra code complexity in how we flag operations. For more,
see < a href = "https://github.com/kanidm/kanidm/issues/177" > This issue on github< / a > .< / p >
2022-06-05 07:20:33 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "why-tls" > < a class = "header" href = "#why-tls" > Why TLS?< / a > < / h1 >
< p > You may have noticed that Kanidm requires you to configure TLS in
your container - or that you provide something < em > with< / em > TLS in front, like haproxy.< / p >
< p > This is due to a single setting on the server - < code > secure_cookies< / code > < / p >
< h2 id = "what-are-secure-cookies" > < a class = "header" href = "#what-are-secure-cookies" > What are Secure Cookies?< / a > < / h2 >
< p > < code > secure-cookies< / code > is a flag set in cookies that asks a client to transmit them
back to the origin site if and only if HTTPS is present in the URL.< / p >
< p > Certificate authority (CA) verification is < em > not< / em > checked - you can use invalid,
out of date certificates, or even certificates where the < code > subjectAltName< / code > does
not match, but the client must see https:// as the destination else it < em > will not< / em >
send the cookies.< / p >
< h2 id = "how-does-that-affect-kanidm" > < a class = "header" href = "#how-does-that-affect-kanidm" > How Does That Affect Kanidm?< / a > < / h2 >
< p > 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.< / p >
< p > 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.< / p >
< p > Simply put, we are trying to use settings like secure_cookies to add constraints
to the server so that you < em > must< / em > perform and adhere to best practices - such
as having TLS present on your communication channels.< / p >
< div style = "break-before: page; page-break-before: always;" > < / div > < h2 id = "getting-started-for-developers" > < a class = "header" href = "#getting-started-for-developers" > Getting Started (for Developers)< / a > < / h2 >
< h3 id = "designs" > < a class = "header" href = "#designs" > Designs< / a > < / h3 >
< p > See the < a href = "https://github.com/kanidm/kanidm/tree/master/designs" > designs< / a > folder, and compile the private documentation locally:< / p >
< pre > < code > cargo doc --document-private-items --open --no-deps
< / code > < / pre >
< h3 id = "rust-documentation" > < a class = "header" href = "#rust-documentation" > Rust Documentation< / a > < / h3 >
< p > A list of links to the library documentation is at
< a href = "https://kanidm.com/documentation/" > kanidm.com/documentation< / a > .< / p >
< h3 id = "minimum-supported-rust-version" > < a class = "header" href = "#minimum-supported-rust-version" > Minimum Supported Rust Version< / a > < / h3 >
< p > The MSRV is specified in the package < code > Cargo.toml< / code > files.< / p >
< h3 id = "dependencies" > < a class = "header" href = "#dependencies" > Dependencies< / a > < / h3 >
< h4 id = "macos" > < a class = "header" href = "#macos" > MacOS< / a > < / h4 >
< p > You will need < a href = "https://rustup.rs/" > rustup< / a > to install a Rust toolchain.< / p >
< h4 id = "suse" > < a class = "header" href = "#suse" > SUSE< / a > < / h4 >
< p > You will need < a href = "https://rustup.rs/" > rustup< / a > to install a Rust toolchain. If
you're
using the Tumbleweed release, it's packaged in < code > zypper< / code > .< / p >
< p > You will also need some system libraries to build this:< / p >
< pre > < code > libudev-devel sqlite3-devel libopenssl-devel npm-default
< / code > < / pre >
< h4 id = "fedora" > < a class = "header" href = "#fedora" > Fedora< / a > < / h4 >
< p > You need to install the Rust toolchain packages:< / p >
< pre > < code > rust cargo
< / code > < / pre >
< p > You will also need some system libraries to build this:< / p >
< pre > < code > systemd-devel sqlite-devel openssl-devel pam-devel
< / code > < / pre >
< p > Building the Web UI requires additional packages:< / p >
< pre > < code > perl-FindBin perl-File-Compare rust-std-static-wasm32-unknown-unknown
< / code > < / pre >
< h4 id = "ubuntu" > < a class = "header" href = "#ubuntu" > Ubuntu< / a > < / h4 >
< p > You need < a href = "https://rustup.rs/" > rustup< / a > to install a Rust toolchain.< / p >
< p > You will also need some system libraries to build this, which can be installed by running:< / p >
< pre > < code class = "language-shell" > sudo apt-get install libsqlite3-dev libudev-dev libssl-dev
< / code > < / pre >
< p > Tested with Ubuntu 20.04.< / p >
< h3 id = "get-involved" > < a class = "header" href = "#get-involved" > Get Involved< / a > < / h3 >
< p > To get started, you'll need to fork or branch, and we'll merge based on pull
requests.< / p >
< p > If you are a contributor to the project, simply clone:< / p >
< pre > < code class = "language-shell" > git clone git@github.com:kanidm/kanidm.git
< / code > < / pre >
< p > If you are forking, then fork in GitHub and clone with:< / p >
< pre > < code class = "language-shell" > git clone https://github.com/kanidm/kanidm.git
cd kanidm
git remote add myfork git@github.com:< YOUR USERNAME> /kanidm.git
< / code > < / pre >
< p > Select an issue (always feel free to reach out to us for advice!), and create a
branch to start working:< / p >
< pre > < code class = "language-shell" > git branch < feature-branch-name>
git checkout < feature-branch-name>
cargo test
< / code > < / pre >
< p > When you are ready for review (even if the feature isn't complete and you just
want some advice):< / p >
< ol >
< li > Run the test suite: < code > cargo test --workspace< / code > < / li >
< li > Ensure rust formatting standards are followed: < code > cargo fmt --check< / code > < / li >
< li > Try following the suggestions from clippy, after running < code > cargo clippy< / code > .
This is not a blocker on us accepting your code!< / li >
< li > Then commit your changes:< / li >
< / ol >
< pre > < code class = "language-shell" > git commit -m 'Commit message' change_file.rs ...
git push < myfork/origin> < feature-branch-name>
< / code > < / pre >
< p > If you receive advice or make further changes, just keep commiting to the branch,
and pushing to your branch. When we are happy with the code, we'll merge in GitHub,
meaning you can now clean up your branch.< / p >
< pre > < code > git checkout master
git pull
git branch -D < feature-branch-name>
< / code > < / pre >
< h4 id = "rebasing" > < a class = "header" href = "#rebasing" > Rebasing< / a > < / h4 >
< p > If you are asked to rebase your change, follow these steps:< / p >
< pre > < code > git checkout master
git pull
git checkout < feature-branch-name>
git rebase master
< / code > < / pre >
< p > Then be sure to fix any merge issues or other comments as they arise. If you
have issues, you can always stop and reset with:< / p >
< pre > < code > git rebase --abort
< / code > < / pre >
< h3 id = "development-server-quickstart-for-interactive-testing" > < a class = "header" href = "#development-server-quickstart-for-interactive-testing" > Development Server Quickstart for Interactive Testing< / a > < / h3 >
< p > After getting the code, you will need a rust environment. Please investigate
< a href = "https://rustup.rs" > rustup< / a > for your platform to establish this.< / p >
< p > Once you have the source code, you need encryption certificates to use with the server,
because without certificates, authentication will fail. < / p >
< p > We recommend using < a href = "https://letsencrypt.org" > Let's Encrypt< / a > , but if this is not
possible, please use our insecure certificate tool (< code > insecure_generate_tls.sh< / code > ). The
insecure certificate tool creates < code > /tmp/kanidm< / code > and puts some self-signed certificates there.< / p >
< p > You can now build and run the server with the commands below. It will use a database
in < code > /tmp/kanidm.db< / code > .< / p >
< p > Create the initial database and generate an < code > admin< / code > username:< / p >
< pre > < code > cargo run --bin kanidmd recover_account -c ./examples/insecure_server.toml -n admin
< snip>
Success - password reset to -> Et8QRJgQkMJu3v1AQxcbxRWW44qRUZPpr6BJ9fCGapAB9cT4
< / code > < / pre >
< p > Record the password above, then run the server start command:< / p >
< pre > < code > cd kanidmd/daemon
cargo run --bin kanidmd server -c ../../examples/insecure_server.toml
< / code > < / pre >
< p > (The server start command is also a script in < code > kanidmd/daemon/run_insecure_dev_server.sh< / code > )< / p >
< p > In a new terminal, you can now build and run the client tools with:< / p >
< pre > < code > cargo run --bin kanidm -- --help
cargo run --bin kanidm -- login -H https://localhost:8443 -D anonymous -C /tmp/kanidm/ca.pem
cargo run --bin kanidm -- self whoami -H https://localhost:8443 -D anonymous -C /tmp/kanidm/ca.pem
cargo run --bin kanidm -- login -H https://localhost:8443 -D admin -C /tmp/kanidm/ca.pem
cargo run --bin kanidm -- self whoami -H https://localhost:8443 -D admin -C /tmp/kanidm/ca.pem
< / code > < / pre >
< h3 id = "building-the-web-ui" > < a class = "header" href = "#building-the-web-ui" > Building the Web UI< / a > < / h3 >
< p > < strong > NOTE:< / strong > There is a pre-packaged version of the Web UI at < code > /kanidmd_web_ui/pkg/< / code > ,
which can be used directly. This means you don't need to build the Web UI yourself.< / p >
< p > The Web UI uses Rust WebAssembly rather than Javascript. To build this you need
to set up the environment:< / p >
< pre > < code > cargo install wasm-pack
npm install --global rollup
< / code > < / pre >
< p > Then you are able to build the UI:< / p >
< pre > < code > cd kanidmd_web_ui/
./build_wasm.sh
< / code > < / pre >
< p > The " developer" profile for kanidmd will automatically use the pkg output in this folder.< / p >
< p > Setting different developer profiles while building is done by setting the
environment
variable KANIDM_BUILD_PROFILE to one of the bare filename of the TOML files in
< code > /profiles< / code > . < / p >
< p > For example: < code > KANIDM_BUILD_PROFILE=release_suse_generic cargo build --release --bin kanidmd< / code > < / p >
< h3 id = "build-a-kanidm-container" > < a class = "header" href = "#build-a-kanidm-container" > Build a Kanidm Container< / a > < / h3 >
< p > Build a container with the current branch using:< / p >
< pre > < code > make < TARGET>
< / code > < / pre >
< p > Check < code > make help< / code > for a list of valid targets.< / p >
< p > The following environment variables control the build:< / p >
< table > < thead > < tr > < th > ENV variable< / th > < th > Definition< / th > < th > Default< / th > < / tr > < / thead > < tbody >
< tr > < td > < code > IMAGE_BASE< / code > < / td > < td > Base location of the container image.< / td > < td > < code > kanidm< / code > < / td > < / tr >
< tr > < td > < code > IMAGE_VERSION< / code > < / td > < td > Determines the container's tag.< / td > < td > None< / td > < / tr >
< tr > < td > < code > CONTAINER_TOOL_ARGS< / code > < / td > < td > Specify extra options for the container build tool.< / td > < td > None< / td > < / tr >
< tr > < td > < code > IMAGE_ARCH< / code > < / td > < td > Passed to < code > --platforms< / code > when the container is built.< / td > < td > < code > linux/amd64,linux/arm64< / code > < / td > < / tr >
< tr > < td > < code > CONTAINER_BUILD_ARGS< / code > < / td > < td > Override default ARG settings during the container build.< / td > < td > None< / td > < / tr >
< tr > < td > < code > CONTAINER_TOOL< / code > < / td > < td > Use an alternative container build tool.< / td > < td > < code > docker< / code > < / td > < / tr >
< tr > < td > < code > BOOK_VERSION< / code > < / td > < td > Sets version used when building the documentation book.< / td > < td > < code > master< / code > < / td > < / tr >
< / tbody > < / table >
< h4 id = "container-build-examples" > < a class = "header" href = "#container-build-examples" > Container Build Examples< / a > < / h4 >
< p > Build a < code > kanidm< / code > container using < code > podman< / code > :< / p >
< pre > < code > CONTAINER_TOOL=podman make build/kanidmd
< / code > < / pre >
< p > Build a < code > kanidm< / code > container and use a redis build cache:< / p >
< pre > < code > CONTAINER_BUILD_ARGS='--build-arg " SCCACHE_REDIS=redis://redis.dev.blackhats.net.au:6379" ' make build/kanidmd
< / code > < / pre >
< h4 id = "automatically-built-containers" > < a class = "header" href = "#automatically-built-containers" > Automatically Built Containers< / a > < / h4 >
< p > To speed up testing across platforms, we're leveraging GitHub actions to build
containers for test use.< / p >
< p > Whenever code is merged with the < code > master< / code > branch of Kanidm, containers are automatically
built for < code > kanidmd< / code > and < code > radius< / code > . Sometimes they fail to build, but we'll try to
keep them avilable.< / p >
< p > To find information on the packages,
< a href = "https://github.com/orgs/kanidm/packages?repo_name=kanidm" > visit the Kanidm packages page< / a > .< / p >
< p > An example command for pulling and running the radius container is below. You'll
need to
< a href = "https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry#authenticating-to-the-container-registry" > authenticate with the GitHub container registry first< / a > .< / p >
< pre > < code class = "language-shell" > docker pull ghcr.io/kanidm/radius:devel
docker run --rm -it \
-v $(pwd)/config.ini:/data/config.ini \
ghcr.io/kanidm/radius:devel
< / code > < / pre >
< p > This assumes you have a < code > config.ini< / code > file in the current working directory.< / p >
2022-05-27 01:20:56 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "oauth2" > < a class = "header" href = "#oauth2" > OAuth2< / a > < / h1 >
< p > OAuth is a web authorisation protocol that allows " single sign on" . It's key to note
OAuth is authorisation, not authentication, as the protocol in its default forms
2022-05-01 06:11:32 +02:00
do not provide identity or authentication information, only information that
an entity is authorised for the requested resources.< / p >
2022-05-27 01:20:56 +02:00
< p > OAuth can tie into extensions allowing an identity provider to reveal information
about authorised sessions. This extends OAuth from an authorisation only system
2022-05-01 06:11:32 +02:00
to a system capable of identity and authorisation. Two primary methods of this
2022-05-27 01:20:56 +02:00
exist today: RFC7662 token introspection, and OpenID connect.< / p >
< h2 id = "how-does-oauth2-work" > < a class = "header" href = "#how-does-oauth2-work" > How Does OAuth2 Work?< / a > < / h2 >
2022-05-01 06:11:32 +02:00
< p > A user wishes to access a service (resource, resource server). The resource
server does not have an active session for the client, so it redirects to the
authorisation server (Kanidm) to determine if the client should be allowed to proceed, and
has the appropriate permissions (scopes) for the requested resources.< / p >
< p > The authorisation server checks the current session of the user and may present
a login flow if required. Given the identity of the user known to the authorisation
sever, and the requested scopes, the authorisation server makes a decision if it
allows the authorisation to proceed. The user is then prompted to consent to the
authorisation from the authorisation server to the resource server as some identity
information may be revealed by granting this consent.< / p >
2022-05-27 01:20:56 +02:00
< p > If successful and consent given, the user is redirected back to the resource server with an
authorisation code. The resource server then contacts the authorisation server directly with this
code and exchanges it for a valid token that may be provided to the user's browser.< / p >
< p > The resource server may then optionally contact the token introspection endpoint of the
authorisation server about the provided OAuth token, which yields extra metadata about the identity
that holds the token from the authorisation. This metadata may include identity information,
2022-05-01 06:11:32 +02:00
but also may include extended metadata, sometimes refered to as " claims" . Claims are
information bound to a token based on properties of the session that may allow
the resource server to make extended authorisation decisions without the need
to contact the authorisation server to arbitrate.< / p >
2022-05-27 01:20:56 +02:00
< p > It's important to note that OAuth2 at its core is an authorisation system which has layered
identity-providing elements on top.< / p >
2022-05-01 06:11:32 +02:00
< h3 id = "resource-server" > < a class = "header" href = "#resource-server" > Resource Server< / a > < / h3 >
2022-05-27 01:20:56 +02:00
< p > This is the server that a user wants to access. Common examples could be Nextcloud, a wiki,
2022-05-01 06:11:32 +02:00
or something else. This is the system that " needs protecting" and wants to delegate authorisation
decisions to Kanidm.< / p >
2022-05-27 01:20:56 +02:00
< p > It's important for you to know < em > how< / em > your resource server supports OAuth2. For example, does it
support RFC 7662 token introspection or does it rely on OpenID connect for identity information?
2022-05-01 06:11:32 +02:00
Does the resource server support PKCE S256?< / p >
< p > In general Kanidm requires that your resource server supports:< / p >
< ul >
< li > HTTP basic authentication to the authorisation server< / li >
< li > PKCE S256 code verification to prevent certain token attack classes< / li >
< li > OIDC only - JWT ES256 for token signatures< / li >
< / ul >
2022-05-27 01:20:56 +02:00
< p > Kanidm will expose its OAuth2 APIs at the following URLs:< / p >
2022-05-01 06:11:32 +02:00
< ul >
< li > user auth url: https://idm.example.com/ui/oauth2< / li >
< li > api auth url: https://idm.example.com/oauth2/authorise< / li >
< li > token url: https://idm.example.com/oauth2/token< / li >
< li > token inspect url: https://idm.example.com/oauth2/inspect< / li >
< / ul >
2022-05-27 01:20:56 +02:00
< p > OpenID Connect discovery - you need to substitute your OAuth2 client id in the following
2022-05-01 06:11:32 +02:00
urls:< / p >
< ul >
2022-05-27 01:20:56 +02:00
< li > OpenID connect issuer uri: https://idm.example.com/oauth2/openid/:client_id:/< / li >
< li > OpenID connect discovery: https://idm.example.com/oauth2/openid/:client_id:/.well-known/openid-configuration< / li >
2022-05-01 06:11:32 +02:00
< / ul >
< p > For manual OpenID configuration:< / p >
< ul >
2022-05-27 01:20:56 +02:00
< li > OpenID connect userinfo: https://idm.example.com/oauth2/openid/:client_id:/userinfo< / li >
2022-05-01 06:11:32 +02:00
< li > token signing public key: https://idm.example.com/oauth2/openid/:client_id:/public_key.jwk< / li >
< / ul >
< h3 id = "scope-relationships" > < a class = "header" href = "#scope-relationships" > Scope Relationships< / a > < / h3 >
< p > For an authorisation to proceed, the resource server will request a list of scopes, which are
unique to that resource server. For example, when a user wishes to login to the admin panel
2022-05-27 01:20:56 +02:00
of the resource server, it may request the " admin" scope from Kanidm for authorisation. But when
a user wants to login, it may only request " access" as a scope from Kanidm.< / p >
< p > As each resource server may have its own scopes and understanding of these, Kanidm isolates
2022-05-01 06:11:32 +02:00
scopes to each resource server connected to Kanidm. Kanidm has two methods of granting scopes to accounts (users).< / p >
< p > The first are implicit scopes. These are scopes granted to all accounts that Kanidm holds.< / p >
< p > The second is scope mappings. These provide a set of scopes if a user is a member of a specific
group within Kanidm. This allows you to create a relationship between the scopes of a resource
server, and the groups/roles in Kanidm which can be specific to that resource server.< / p >
< p > For an authorisation to proceed, all scopes requested must be available in the final scope set
that is granted to the account. This final scope set can be built from implicit and mapped
scopes.< / p >
< p > This use of scopes is the primary means to control who can access what resources. For example, if
you have a resource server that will always request a scope of " read" , then you can limit the
" read" scope to a single group of users by a scope map so that only they may access that resource.< / p >
< h2 id = "configuration" > < a class = "header" href = "#configuration" > Configuration< / a > < / h2 >
< h3 id = "create-the-kanidm-configuration" > < a class = "header" href = "#create-the-kanidm-configuration" > Create the Kanidm Configuration< / a > < / h3 >
< p > After you have understood your resource server requirements you first need to configure Kanidm.
By default members of " system_admins" or " idm_hp_oauth2_manage_priv" are able to create or
2022-05-27 01:20:56 +02:00
manage OAuth2 resource server integrations.< / p >
2022-05-01 06:11:32 +02:00
< p > You can create a new resource server with:< / p >
< pre > < code > kanidm system oauth2 create < name> < displayname> < origin>
kanidm system oauth2 create nextcloud " Nextcloud Production" https://nextcloud.example.com
< / code > < / pre >
< p > If you wish to create implicit scopes you can set these with:< / p >
< pre > < code > kanidm system oauth2 set_implicit_scopes < name> [scopes]...
kanidm system oauth2 set_implicit_scopes nextcloud login read_user
< / code > < / pre >
< p > You can create a scope map with:< / p >
< pre > < code > kanidm system oauth2 create_scope_map < name> < kanidm_group_name> [scopes]...
kanidm system oauth2 create_scope_map nextcloud nextcloud_admins admin
< / code > < / pre >
< blockquote >
< p > < strong > WARNING< / strong >
2022-05-27 01:20:56 +02:00
If you are creating an OpenID Connect (OIDC) resource server you < em > MUST< / em > provide a
scope map OR implicit scope named 'openid'. Without this, OpenID clients < em > WILL NOT WORK< / em > < / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
< blockquote >
< p > < strong > HINT< / strong >
2022-05-27 01:20:56 +02:00
OpenID connect allows a number of scopes that affect the content of the resulting
authorisation token. If one of the following scopes are requested by the OpenID client,
2022-05-01 06:11:32 +02:00
then the associated claims may be added to the authorisation token. It is not guaranteed
that all of the associated claims will be added.< / p >
< ul >
< li > profile - (name, family_name, given_name, middle_name, nickname, preferred_username, profile, picture, website, gender, birthdate, zoneinfo, locale, and updated_at)< / li >
< li > email - (email, email_verified)< / li >
< li > address - (address)< / li >
< li > phone - (phone_number, phone_number_verified)< / li >
< / ul >
< / blockquote >
< p > Once created you can view the details of the resource server.< / p >
< pre > < code > kanidm system oauth2 get nextcloud
---
class: oauth2_resource_server
class: oauth2_resource_server_basic
class: object
displayname: Nextcloud Production
oauth2_rs_basic_secret: < secret>
oauth2_rs_name: nextcloud
oauth2_rs_origin: https://nextcloud.example.com
oauth2_rs_token_key: hidden
< / code > < / pre >
< h3 id = "configure-the-resource-server" > < a class = "header" href = "#configure-the-resource-server" > Configure the Resource Server< / a > < / h3 >
2022-05-27 01:20:56 +02:00
< p > On your resource server, you should configure the client ID as the " oauth2_rs_name" from
Kanidm, and the password to be the value shown in " oauth2_rs_basic_secret" . Ensure that
2022-05-01 06:11:32 +02:00
the code challenge/verification method is set to S256.< / p >
< p > You should now be able to test authorisation.< / p >
< h2 id = "resetting-resource-server-security-material" > < a class = "header" href = "#resetting-resource-server-security-material" > Resetting Resource Server Security Material< / a > < / h2 >
< p > In the case of disclosure of the basic secret, or some other security event where you may wish
to invalidate a resource servers active sessions/tokens, you can reset the secret material of
the server with:< / p >
< pre > < code > kanidm system oauth2 reset_secrets
< / code > < / pre >
< p > Each resource server has unique signing keys and access secrets, so this is limited to each
resource server.< / p >
< h2 id = "extended-options-for-legacy-clients" > < a class = "header" href = "#extended-options-for-legacy-clients" > Extended Options for Legacy Clients< / a > < / h2 >
< p > Not all resource servers support modern standards like PKCE or ECDSA. In these situations
it may be necessary to disable these on a per-resource server basis. Disabling these on
one resource server will not affect others.< / p >
< p > To disable PKCE for a resource server:< / p >
< pre > < code > kanidm system oauth2 warning_insecure_client_disable_pkce < resource server name>
< / code > < / pre >
< p > To enable legacy cryptograhy (RSA PKCS1-5 SHA256):< / p >
< pre > < code > kanidm system oauth2 warning_enable_legacy_crypto < resource server name>
< / code > < / pre >
< h2 id = "example-integrations" > < a class = "header" href = "#example-integrations" > Example Integrations< / a > < / h2 >
< h3 id = "apache-mod_auth_openidc" > < a class = "header" href = "#apache-mod_auth_openidc" > Apache mod_auth_openidc< / a > < / h3 >
< p > Add the following to a < code > mod_auth_openidc.conf< / code > . It should be included in a < code > mods_enabled< / code > folder
or with an appropriate include.< / p >
< pre > < code > OIDCRedirectURI /protected/redirect_uri
OIDCCryptoPassphrase < random password here>
OIDCProviderMetadataURL https://kanidm.example.com/oauth2/openid/< resource server name> /.well-known/openid-configuration
OIDCScope " openid"
OIDCUserInfoTokenMethod authz_header
OIDCClientID < resource server name>
OIDCClientSecret < resource server password>
OIDCPKCEMethod S256
OIDCCookieSameSite On
# Set the `REMOTE_USER` field to the `preferred_username` instead of the UUID.
# Remember that the username can change, but this can help with systems like Nagios which use this as a display name.
# OIDCRemoteUserClaim preferred_username
< / code > < / pre >
< p > Other scopes can be added as required to the < code > OIDCScope< / code > line, eg: < code > OIDCScope " openid scope2 scope3" < / code > < / p >
< p > In the virtual host, to protect a location:< / p >
< pre > < code > < Location />
AuthType openid-connect
Require valid-user
< /Location>
< / code > < / pre >
< h3 id = "nextcloud" > < a class = "header" href = "#nextcloud" > Nextcloud< / a > < / h3 >
< p > Install the module < a href = "https://apps.nextcloud.com/apps/user_oidc" > from the nextcloud market place< / a > -
it can also be found in the Apps section of your deployment as " OpenID Connect user backend" .< / p >
2022-05-27 01:20:56 +02:00
< p > In Nextcloud's config.php you need to allow connection to remote servers:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > 'allow_local_remote_servers' => true,
< / code > < / pre >
< p > You may optionally choose to add:< / p >
< pre > < code > 'allow_user_to_change_display_name' => false,
'lost_password_link' => 'disabled',
< / code > < / pre >
< p > If you forget this, you may see the following error in logs:< / p >
< pre > < code > Host 172.24.11.129 was not connected to because it violates local access rules
< / code > < / pre >
< p > This module does not support PKCE or ES256. You will need to run:< / p >
< pre > < code > kanidm system oauth2 warning_insecure_client_disable_pkce < resource server name>
kanidm system oauth2 warning_enable_legacy_crypto < resource server name>
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > In the settings menu, configure the discovery URL and client ID and secret.< / p >
2022-05-01 06:11:32 +02:00
< p > You can choose to disable other login methods with:< / p >
< pre > < code > php occ config:app:set --value=0 user_oidc allow_multiple_user_backends
< / code > < / pre >
2022-05-27 01:20:56 +02:00
< p > You can login directly by appending < code > ?direct=1< / code > to your login page. You can re-enable
2022-05-01 06:11:32 +02:00
other backends by setting the value to < code > 1< / code > < / p >
< h3 id = "velociraptor" > < a class = "header" href = "#velociraptor" > Velociraptor< / a > < / h3 >
< p > Velociraptor supports OIDC. To configure it select " Authenticate with SSO" then " OIDC" during
the interactive configuration generator. Alternately, you can set the following keys in server.config.yaml:< / p >
< pre > < code > GUI:
authenticator:
type: OIDC
oidc_issuer: https://idm.example.com/oauth2/openid/:client\_id:/
oauth_client_id: < resource server name/>
oauth_client_secret: < resource server secret>
< / code > < / pre >
< p > Velociraptor does not support PKCE. You will need to run the following:< / p >
< pre > < code > kanidm system oauth2 warning_insecure_client_disable_pkce < resource server name>
< / code > < / pre >
< p > Initial users are mapped via their email in the Velociraptor server.config.yaml config:< / p >
< pre > < code > GUI:
initial_users:
- name: < email address>
< / code > < / pre >
< p > Accounts require the < code > openid< / code > and < code > email< / code > scopes to be authenticated. It is recommended you limit
these to a group with a scope map due to Velociraptors high impact.< / p >
< pre > < code > # kanidm group create velociraptor_users
# kanidm group add_members velociraptor_users ...
2022-05-27 01:20:56 +02:00
kanidm system oauth2 create_scope_map < resource server name> velociraptor_users openid email< / code > < / pre >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "pam-and-nsswitch" > < a class = "header" href = "#pam-and-nsswitch" > PAM and nsswitch< / a > < / h1 >
2022-06-02 03:20:33 +02:00
< p > < a href = "http://linux-pam.org" > PAM< / a > and < a href = "https://en.wikipedia.org/wiki/Name_Service_Switch" > nsswitch< / a >
are the core mechanisms used by Linux and BSD clients to resolve identities from an IDM service
like Kanidm into accounts that can be used on the machine for various interactive tasks.< / p >
< h2 id = "the-unix-daemon" > < a class = "header" href = "#the-unix-daemon" > The UNIX Daemon< / a > < / h2 >
< p > Kanidm provides a UNIX daemon that runs on any client that wants to use PAM and nsswitch integration.
The daemon can cache the accounts for users who have unreliable networks, or who leave
the site where Kanidm is hosted. The daemon is also able to cache missing-entry responses to reduce network
traffic and main server load.< / p >
< p > Additionally, running the daemon means that the PAM and nsswitch integration libraries can be small,
helping to reduce the attack surface of the machine. Similarly, a tasks daemon is available that can
create home directories on first login and supports several features related to aliases and links to
these home directories.< / p >
< p > We recommend you install the client daemon from your system package manager:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > # OpenSUSE
zypper in kanidm-unixd-clients
# Fedora
dnf install kanidm-unixd-clients
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > You can check the daemon is running on your Linux system with:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > systemctl status kanidm-unixd
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > You can check the privileged tasks daemon is running with:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > systemctl status kanidm-unixd-tasks
< / code > < / pre >
< blockquote >
< p > < strong > NOTE< / strong > The < code > kanidm_unixd_tasks< / code > daemon is not required for PAM and nsswitch functionality.
2022-06-02 03:20:33 +02:00
If disabled, your system will function as usual. It is, however, recommended due to the features
2022-05-01 06:11:32 +02:00
it provides supporting Kanidm's capabilities.< / p >
< / blockquote >
< p > Both unixd daemons use the connection configuration from /etc/kanidm/config. This is the covered in
2022-06-05 07:20:33 +02:00
< a href = "integrations/./client_tools.html#kanidm-configuration" > client_tools< / a > .< / p >
2022-06-02 03:20:33 +02:00
< p > You can also configure some unixd-specific options with the file /etc/kanidm/unixd:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > pam_allowed_login_groups = [" posix_group" ]
default_shell = " /bin/sh"
home_prefix = " /home/"
home_attr = " uuid"
home_alias = " spn"
uid_attr_map = " spn"
gid_attr_map = " spn"
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > < code > pam_allowed_login_groups< / code > defines a set of POSIX groups where membership of any of these
groups will be allowed to login via PAM. All POSIX users and groups can be resolved by nss
regardless of PAM login status. This may be a group name, spn, or uuid.< / p >
< p > < code > default_shell< / code > is the default shell for users. Defaults to < code > /bin/sh< / code > .< / p >
2022-05-01 06:11:32 +02:00
< p > < code > home_prefix< / code > is the prepended path to where home directories are stored. Must end with
a trailing < code > /< / code > . Defaults to < code > /home/< / code > .< / p >
< p > < code > home_attr< / code > is the default token attribute used for the home directory path. Valid
choices are < code > uuid< / code > , < code > name< / code > , < code > spn< / code > . Defaults to < code > uuid< / code > .< / p >
2022-06-02 03:20:33 +02:00
< p > < code > home_alias< / code > is the default token attribute used for generating symlinks
pointing to the user's
2022-05-01 06:11:32 +02:00
home directory. If set, this will become the value of the home path
to nss calls. It is recommended you choose a " human friendly" attribute here.
Valid choices are < code > none< / code > , < code > uuid< / code > , < code > name< / code > , < code > spn< / code > . Defaults to < code > spn< / code > .< / p >
< blockquote >
< p > < strong > NOTICE:< / strong >
All users in Kanidm can change their name (and their spn) at any time. If you change
< code > home_attr< / code > from < code > uuid< / code > you < em > must< / em > have a plan on how to manage these directory renames
2022-06-02 03:20:33 +02:00
in your system. We recommend that you have a stable ID (like the UUID), and symlinks
from the name to the UUID folder. Automatic support is provided for this via the unixd
2022-05-01 06:11:32 +02:00
tasks daemon, as documented here.< / p >
< / blockquote >
< p > < code > uid_attr_map< / code > chooses which attribute is used for domain local users in presentation. Defaults
to < code > spn< / code > . Users from a trust will always use spn.< / p >
< p > < code > gid_attr_map< / code > chooses which attribute is used for domain local groups in presentation. Defaults
to < code > spn< / code > . Groups from a trust will always use spn.< / p >
2022-06-02 03:20:33 +02:00
< p > You can then check the communication status of the daemon:< / p >
< pre > < code > kanidm_unixd_status
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< p > If the daemon is working, you should see:< / p >
< pre > < code > [2020-02-14T05:58:37Z INFO kanidm_unixd_status] working!
< / code > < / pre >
< p > If it is not working, you will see an error message:< / p >
2022-06-02 03:20:33 +02:00
< pre > < code > [2020-02-14T05:58:10Z ERROR kanidm_unixd_status] Error ->
Os { code: 111, kind: ConnectionRefused, message: " Connection refused" }
2022-05-01 06:11:32 +02:00
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > For more information, see the
2022-06-05 07:20:33 +02:00
< a href = "integrations/./pam_and_nsswitch.html#troubleshooting" > Troubleshooting< / a > section.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "nsswitch" > < a class = "header" href = "#nsswitch" > nsswitch< / a > < / h2 >
< p > When the daemon is running you can add the nsswitch libraries to /etc/nsswitch.conf< / p >
< pre > < code > passwd: compat kanidm
group: compat kanidm
< / code > < / pre >
2022-06-05 07:20:33 +02:00
< p > You can < a href = "integrations/./accounts_and_groups.html#creating-accounts" > create a user< / a > then
< a href = "integrations/./posix_accounts.html#enabling-posix-attributes-on-accounts" > enable POSIX feature on the user< / a > .< / p >
2022-06-02 03:20:33 +02:00
< p > You can then test that the POSIX extended user is able to be resolved with:< / p >
< pre > < code > getent passwd < account name>
getent passwd testunix
2022-05-01 06:11:32 +02:00
testunix:x:3524161420:3524161420:testunix:/home/testunix:/bin/sh
< / code > < / pre >
< p > You can also do the same for groups.< / p >
2022-06-02 03:20:33 +02:00
< pre > < code > getent group < group name>
getent group testgroup
2022-05-01 06:11:32 +02:00
testgroup:x:2439676479:testunix
< / code > < / pre >
< blockquote >
2022-06-02 03:20:33 +02:00
< p > < strong > HINT< / strong > Remember to also create a UNIX password with something like
2022-05-01 06:11:32 +02:00
< code > kanidm account posix set_password --name idm_admin demo_user< / code > .
Otherwise there will be no credential for the account to authenticate. < / p >
< / blockquote >
< h2 id = "pam" > < a class = "header" href = "#pam" > PAM< / a > < / h2 >
< blockquote >
< p > < strong > WARNING:< / strong > Modifications to PAM configuration < em > may< / em > leave your system in a state
where you are unable to login or authenticate. You should always have a recovery
2022-06-02 03:20:33 +02:00
shell open while making changes (for example, root), or have access to single-user mode
2022-05-01 06:11:32 +02:00
at the machine's console.< / p >
< / blockquote >
2022-06-02 03:20:33 +02:00
< p > Pluggable Authentication Modules (PAM) is the mechanism a UNIX-like system
that authenticates users, and to control access to some resources. This is
configured through a stack of modules
that are executed in order to evaluate the request, and then each module may
request or reuse authentication token information.< / p >
< h3 id = "before-you-start" > < a class = "header" href = "#before-you-start" > Before You Start< / a > < / h3 >
< p > You < em > should< / em > backup your /etc/pam.d directory from its original state as you
< em > may< / em > change the PAM configuration in a way that will not allow you
to authenticate to your machine.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > cp -a /etc/pam.d /root/pam.d.backup
< / code > < / pre >
< h3 id = "suse--opensuse" > < a class = "header" href = "#suse--opensuse" > SUSE / OpenSUSE< / a > < / h3 >
2022-06-02 03:20:33 +02:00
< p > To configure PAM on suse you must modify four files, which control the
various stages of authentication:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > /etc/pam.d/common-account
/etc/pam.d/common-auth
/etc/pam.d/common-password
/etc/pam.d/common-session
< / code > < / pre >
< blockquote >
< p > < strong > IMPORTANT< / strong > By default these files are symlinks to their corresponding < code > -pc< / code > file, for example
< code > common-account -> common-account-pc< / code > . If you directly edit these you are updating the inner
content of the < code > -pc< / code > file and it WILL be reset on a future upgrade. To prevent this you must
first copy the < code > -pc< / code > files. You can then edit the files safely.< / p >
< / blockquote >
< pre > < code > cp /etc/pam.d/common-account-pc /etc/pam.d/common-account
cp /etc/pam.d/common-auth-pc /etc/pam.d/common-auth
cp /etc/pam.d/common-password-pc /etc/pam.d/common-password
cp /etc/pam.d/common-session-pc /etc/pam.d/common-session
< / code > < / pre >
< p > The content should look like:< / p >
< pre > < code > # /etc/pam.d/common-auth-pc
# Controls authentication to this system (verification of credentials)
auth required pam_env.so
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid > = 1000 quiet_success
auth sufficient pam_kanidm.so ignore_unknown_user
auth required pam_deny.so
# /etc/pam.d/common-account-pc
# Controls authorisation to this system (who may login)
account [default=1 ignore=ignore success=ok] pam_localuser.so
2022-05-24 06:01:51 +02:00
account sufficient pam_unix.so
2022-05-01 06:11:32 +02:00
account [default=1 ignore=ignore success=ok] pam_succeed_if.so uid > = 1000 quiet_success quiet_fail
account sufficient pam_kanidm.so ignore_unknown_user
2022-05-24 06:01:51 +02:00
account required pam_deny.so
2022-05-01 06:11:32 +02:00
# /etc/pam.d/common-password-pc
# Controls flow of what happens when a user invokes the passwd command. Currently does NOT
# interact with kanidm.
password [default=1 ignore=ignore success=ok] pam_localuser.so
password required pam_unix.so use_authtok nullok shadow try_first_pass
password [default=1 ignore=ignore success=ok] pam_succeed_if.so uid > = 1000 quiet_success quiet_fail
password required pam_kanidm.so
# /etc/pam.d/common-session-pc
# Controls setup of the user session once a successful authentication and authorisation has
# occured.
session optional pam_systemd.so
session required pam_limits.so
session optional pam_unix.so try_first_pass
session optional pam_umask.so
session [default=1 ignore=ignore success=ok] pam_succeed_if.so uid > = 1000 quiet_success quiet_fail
session optional pam_kanidm.so
session optional pam_env.so
< / code > < / pre >
< blockquote >
< p > < strong > WARNING:< / strong > Ensure that < code > pam_mkhomedir< / code > or < code > pam_oddjobd< / code > are < em > not< / em > present in any stage of your
2022-06-02 03:20:33 +02:00
PAM configuration, as they interfere with the correct operation of the
Kanidm tasks daemon.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
< h3 id = "fedora--centos" > < a class = "header" href = "#fedora--centos" > Fedora / CentOS< / a > < / h3 >
< blockquote >
< p > < strong > WARNING:< / strong > Kanidm currently has no support for SELinux policy - this may mean you need to
run the daemon with permissive mode for the unconfined_service_t daemon type. To do this run:
< code > semanage permissive -a unconfined_service_t< / code > . To undo this run < code > semanage permissive -d unconfined_service_t< / code > .< / p >
2022-06-02 03:20:33 +02:00
< p > You may also need to run < code > audit2allow< / code > for sshd and other types to be able to access the UNIX daemon sockets.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
2022-06-02 03:20:33 +02:00
< p > These files are managed by authselect as symlinks. You can either work with
authselect, or remove the symlinks first.< / p >
2022-05-10 03:03:16 +02:00
< h4 id = "without-authselect" > < a class = "header" href = "#without-authselect" > Without authselect< / a > < / h4 >
2022-06-02 03:20:33 +02:00
< p > If you just remove the symlinks:< / p >
< p > Edit the content.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > # /etc/pam.d/password-auth
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
2022-05-10 03:03:16 +02:00
auth sufficient pam_kanidm.so ignore_unknown_user
2022-05-01 06:11:32 +02:00
auth required pam_deny.so
account sufficient pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_usertype.so issystem
2022-05-10 03:03:16 +02:00
account sufficient pam_kanidm.so ignore_unknown_user
2022-05-01 06:11:32 +02:00
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
2022-05-10 03:03:16 +02:00
password sufficient pam_kanidm.so
2022-05-01 06:11:32 +02:00
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
2022-05-10 03:03:16 +02:00
session optional pam_kanidm.so
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< ul >
< li > < / li >
< / ul >
< pre > < code > # /etc/pam.d/system-auth
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_fprintd.so
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth [default=1 ignore=ignore success=ok] pam_usertype.so isregular
2022-05-10 03:03:16 +02:00
auth sufficient pam_kanidm.so ignore_unknown_user
2022-05-01 06:11:32 +02:00
auth required pam_deny.so
account sufficient pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_usertype.so issystem
2022-05-10 03:03:16 +02:00
account sufficient pam_kanidm.so ignore_unknown_user
2022-05-01 06:11:32 +02:00
account required pam_permit.so
password requisite pam_pwquality.so try_first_pass local_users_only
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
2022-05-10 03:03:16 +02:00
password sufficient pam_kanidm.so
2022-05-01 06:11:32 +02:00
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
-session optional pam_systemd.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
2022-05-10 03:03:16 +02:00
session optional pam_kanidm.so
< / code > < / pre >
< h4 id = "with-authselect" > < a class = "header" href = "#with-authselect" > With authselect< / a > < / h4 >
2022-06-02 03:20:33 +02:00
< p > To work with authselect:< / p >
< p > You will need to
< a href = "https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/configuring-user-authentication-using-authselect_configuring-authentication-and-authorization-in-rhel#creating-and-deploying-your-own-authselect-profile_configuring-user-authentication-using-authselect" > create a new profile< / a > .< / p >
<!-- TODO this URL is too short -->
< p > First run the following command:< / p >
2022-05-10 03:03:16 +02:00
< pre > < code > authselect create-profile kanidm -b sssd
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > A new folder, /etc/authselect/custom/kanidm, should be created. Inside that folder, create or
overwrite the following three files: nsswitch.conf, password-auth, system-auth.
password-auth and system-auth should be the same as above. nsswitch should be
modified for your use case. A working example looks like this:< / p >
2022-05-10 03:03:16 +02:00
< pre > < code > passwd: compat kanidm sss files systemd
group: compat kanidm sss files systemd
shadow: files
hosts: files dns myhostname
services: sss files
netgroup: sss files
automount: sss files
aliases: files
ethers: files
gshadow: files
networks: files dns
protocols: files
publickey: files
rpc: files
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Then run:< / p >
2022-05-10 03:03:16 +02:00
< pre > < code > authselect select custom/kanidm
< / code > < / pre >
< p > to update your profile.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "troubleshooting" > < a class = "header" href = "#troubleshooting" > Troubleshooting< / a > < / h2 >
2022-06-02 03:20:33 +02:00
< h3 id = "check-posix-status-of-group-and-configuration" > < a class = "header" href = "#check-posix-status-of-group-and-configuration" > Check POSIX-status of Group and Configuration< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > If authentication is failing via PAM, make sure that a list of groups is configured in < code > /etc/kanidm/unixd< / code > :< / p >
< pre > < code > pam_allowed_login_groups = [" example_group" ]
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Check the status of the group with < code > kanidm group posix show example_group< / code > .
If you get something similar to the following example:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code class = "language-shell" > > kanidm group posix show example_group
Using cached token for name idm_admin
2022-06-02 03:20:33 +02:00
Error -> Http(500, Some(InvalidAccountState(" Missing class: account & & posixaccount OR group & & posixgroup" )),
" b71f137e-39f3-4368-9e58-21d26671ae24" )
2022-05-01 06:11:32 +02:00
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > POSIX-enable the group with < code > kanidm group posix set example_group< / code > . You should get a result similar
to this when you search for your group name:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code class = "language-shell" > > kanidm group posix show example_group
[ spn: example_group@kanidm.example.com, gidnumber: 3443347205 name: example_group, uuid: b71f137e-39f3-4368-9e58-21d26671ae24 ]
< / code > < / pre >
< p > Also, ensure the target user is in the group by running:< / p >
< pre > < code > > kanidm group list_members example_group
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< h3 id = "increase-logging" > < a class = "header" href = "#increase-logging" > Increase Logging< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > For the unixd daemon, you can increase the logging with:< / p >
< pre > < code > systemctl edit kanidm-unixd.service
< / code > < / pre >
< p > And add the lines:< / p >
< pre > < code > [Service]
Environment=" RUST_LOG=kanidm=debug"
< / code > < / pre >
< p > Then restart the kanidm-unixd.service.< / p >
< p > The same pattern is true for the kanidm-unixd-tasks.service daemon.< / p >
< p > To debug the pam module interactions add < code > debug< / code > to the module arguments such as:< / p >
< pre > < code > auth sufficient pam_kanidm.so debug
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< h3 id = "check-the-socket-permissions" > < a class = "header" href = "#check-the-socket-permissions" > Check the Socket Permissions< / a > < / h3 >
< p > Check that the < code > /var/run/kanidm-unixd/sock< / code > has permissions mode 777, and that non-root readers can see it with
2022-05-01 06:11:32 +02:00
ls or other tools.< / p >
2022-06-02 03:20:33 +02:00
< p > Ensure that < code > /var/run/kanidm-unixd/task_sock< / code > has permissions mode 700, and
that it is owned by the kanidm unixd process user.< / p >
< h3 id = "verify-that-you-can-access-the-kanidm-server" > < a class = "header" href = "#verify-that-you-can-access-the-kanidm-server" > Verify that You Can Access the Kanidm Server< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > You can check this with the client tools:< / p >
< pre > < code > kanidm self whoami --name anonymous
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< h3 id = "ensure-the-libraries-are-correct" > < a class = "header" href = "#ensure-the-libraries-are-correct" > Ensure the Libraries are Correct< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > You should have:< / p >
< pre > < code > /usr/lib64/libnss_kanidm.so.2
/usr/lib64/security/pam_kanidm.so
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > The exact path < em > may< / em > change depending on your distribution, < code > pam_unixd.so< / code > should be co-located
with pam_kanidm.so. Look for it with the find command:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > find /usr/ -name 'pam_unix.so'
< / code > < / pre >
< p > For example, on a Debian machine, it's located in < code > /usr/lib/x86_64-linux-gnu/security/< / code > .< / p >
2022-06-02 03:20:33 +02:00
< h3 id = "increase-connection-timeout" > < a class = "header" href = "#increase-connection-timeout" > Increase Connection Timeout< / a > < / h3 >
< p > In some high-latency environments, you may need to increase the connection timeout. We set
2022-05-01 06:11:32 +02:00
this low to improve response on LANs, but over the internet this may need to be increased.
2022-06-02 03:20:33 +02:00
By increasing the conn_timeout, you will be able to operate on higher latency
links, but some operations may take longer to complete causing a degree of
latency. < / p >
< p > By increasing the cache_timeout, you will need to refresh less often, but it may result in an
account lockout or group change until cache_timeout takes effect. Note that this has security
implications:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > # /etc/kanidm/unixd
# Seconds
conn_timeout = 8
# Cache timeout
cache_timeout = 60
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< h3 id = "invalidate-or-clear-the-cache" > < a class = "header" href = "#invalidate-or-clear-the-cache" > Invalidate or Clear the Cache< / a > < / h3 >
2022-05-01 06:11:32 +02:00
< p > You can invalidate the kanidm_unixd cache with:< / p >
2022-06-02 03:20:33 +02:00
< pre > < code > kanidm_cache_invalidate
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< p > You can clear (wipe) the cache with:< / p >
2022-06-02 03:20:33 +02:00
< pre > < code > kanidm_cache_clear
2022-05-01 06:11:32 +02:00
< / code > < / pre >
< p > There is an important distinction between these two - invalidated cache items may still
be yielded to a client request if the communication to the main Kanidm server is not
possible. For example, you may have your laptop in a park without wifi.< / p >
< p > Clearing the cache, however, completely wipes all local data about all accounts and groups.
2022-06-02 03:20:33 +02:00
If you are relying on this cached (but invalid) data, you may lose access to your accounts until
2022-05-01 06:11:32 +02:00
other communication issues have been resolved.< / p >
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "radius" > < a class = "header" href = "#radius" > RADIUS< / a > < / h1 >
2022-06-02 03:20:33 +02:00
< p > Remote Authentication Dial In User Service (RADIUS) is a network protocol
that is commonly used to authenticate Wi-Fi devices or Virtual Private
Networks (VPNs). While it should not be a sole point of trust/authentication
to an identity, it's still an important control for protecting network resources.< / p >
2022-05-01 06:11:32 +02:00
< p > Kanidm has a philosophy that each account can have multiple credentials which
2022-06-02 03:20:33 +02:00
are related to their devices, and limited to specific resources. RADIUS is
2022-05-01 06:11:32 +02:00
no exception and has a separate credential for each account to use for
RADIUS access.< / p >
< h2 id = "disclaimer" > < a class = "header" href = "#disclaimer" > Disclaimer< / a > < / h2 >
2022-06-02 03:20:33 +02:00
< p > It's worth noting some disclaimers about Kanidm's RADIUS integration.< / p >
2022-05-01 06:11:32 +02:00
< h3 id = "one-credential---one-account" > < a class = "header" href = "#one-credential---one-account" > One Credential - One Account< / a > < / h3 >
2022-06-02 03:20:33 +02:00
< p > Kanidm normally attempts to have credentials for each < em > device< / em > and
< em > application< / em > rather than the legacy model of one to one.< / p >
< p > The RADIUS protocol is only able to attest a < em > single< / em > credential in an
authentication attempt, which limits us to storing a single RADIUS credential
per account. However, despite this limitation, it still greatly improves the
situation by isolating the RADIUS credential from the primary or application
credentials of the account. This solves many common security concerns around
credential loss or disclosure, and prevents rogue devices from locking out
accounts as they attempt to authenticate to Wi-Fi with expired credentials.< / p >
2022-05-01 06:11:32 +02:00
< h3 id = "cleartext-credential-storage" > < a class = "header" href = "#cleartext-credential-storage" > Cleartext Credential Storage< / a > < / h3 >
< p > RADIUS offers many different types of tunnels and authentication mechanisms.
2022-06-02 03:20:33 +02:00
However, most client devices " out of the box" only attempt a single type when
a WPA2-Enterprise network is selected: MSCHAPv2 with PEAP. This is a
challenge-response protocol that requires clear text or Windows NT LAN
Manager (NTLM) credentials.< / p >
< p > As MSCHAPv2 with PEAP is the only practical, universal RADIUS-type supported
on all devices with minimal configuration, we consider it imperative
2022-05-01 06:11:32 +02:00
that it MUST be supported as the default. Esoteric RADIUS types can be used
as well, but this is up to administrators to test and configure.< / p >
2022-06-02 03:20:33 +02:00
< p > Due to this requirement, we must store the RADIUS material as clear text or
NTLM hashes. It would be silly to think that NTLM is secure as it relies on
the obsolete and deprecated MD4 cryptographic hash, providing only an
illusion of security.< / p >
< p > This means Kanidm stores RADIUS credentials in the database as clear text.< / p >
< p > We believe this is a reasonable decision and is a low risk to security because:< / p >
2022-05-01 06:11:32 +02:00
< ul >
2022-06-02 03:20:33 +02:00
< li > The access controls around RADIUS secrets by default are strong, limited
2022-05-01 06:11:32 +02:00
to only self-account read and RADIUS-server read.< / li >
2022-06-02 03:20:33 +02:00
< li > As RADIUS credentials are separate from the primary account credentials and
have no other rights, their disclosure is not going to lead to a full
account compromise.< / li >
< li > Having the credentials in clear text allows a better user experience as< br / >
clients can view the credentials at any time to enroll further devices.< / li >
2022-05-01 06:11:32 +02:00
< / ul >
< h2 id = "account-credential-configuration" > < a class = "header" href = "#account-credential-configuration" > Account Credential Configuration< / a > < / h2 >
2022-06-02 03:20:33 +02:00
< p > For an account to use RADIUS they must first generate a RADIUS secret unique
to that account. By default, all accounts can self-create this secret.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account radius generate_secret --name william william
kanidm account radius show_secret --name william william
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< h2 id = "account-group-configuration" > < a class = "header" href = "#account-group-configuration" > Account Group Configuration< / a > < / h2 >
< p > In Kanidm, accounts which can authenticate to RADIUS must be a member
2022-05-01 06:11:32 +02:00
of an allowed group. This allows you to define which users or groups may use
2022-06-02 03:20:33 +02:00
a Wi-Fi or VPN infrastructure, and provides a path for revoking access to the
resources through group management. The key point of this is that service
accounts should not be part of this group:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm group create --name idm_admin radius_access_allowed
kanidm group add_members --name idm_admin radius_access_allowed william
< / code > < / pre >
< h2 id = "radius-server-service-account" > < a class = "header" href = "#radius-server-service-account" > RADIUS Server Service Account< / a > < / h2 >
< p > To read these secrets, the RADIUS server requires an account with the
correct privileges. This can be created and assigned through the group
2022-06-02 03:20:33 +02:00
" idm_radius_servers" , which is provided by default.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > kanidm account create --name admin radius_service_account " Radius Service Account"
kanidm group add_members --name admin idm_radius_servers radius_service_account
kanidm account credential reset_credential --name admin radius_service_account
< / code > < / pre >
< h2 id = "deploying-a-radius-container" > < a class = "header" href = "#deploying-a-radius-container" > Deploying a RADIUS Container< / a > < / h2 >
< p > We provide a RADIUS container that has all the needed integrations.
This container requires some cryptographic material, laid out in a volume like so:< / p >
< pre > < code > data
data/ca.pem # This is the kanidm ca.pem
data/config.ini # This is the kanidm-radius configuration.
data/certs
data/certs/dh # openssl dhparam -out ./dh 2048
data/certs/key.pem # These are the radius ca/cert/key
data/certs/cert.pem
data/certs/ca.pem
< / code > < / pre >
< p > The config.ini has the following template:< / p >
< pre > < code > [kanidm_client]
url = # URL to the kanidm server
strict = false # Strict CA verification
ca = /data/ca.pem # Path to the kanidm ca
user = # Username of the RADIUS service account
secret = # Generated secret for the service account
; default VLANs for groups that don't specify one.
[DEFAULT]
vlan = 1
; [group.test] # group.< name> will have these options applied
; vlan =
[radiusd]
ca = # Path to the radius server's CA
key = # Path to the radius servers key
cert = # Path to the radius servers cert
dh = # Path to the radius servers dh params
required_group = # Name of a kanidm group which you must be
# A member of to use radius.
cache_path = # A path to an area where cached user records can be stored.
# If in doubt, use /dev/shm/kanidmradiusd
; [client.localhost] # client.< nas name> configures wifi/vpn consumers
; ipaddr = # ipv4 or ipv6 address of the NAS
; secret = # Shared secret
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > A fully configured example:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > [kanidm_client]
; be sure to check the listening port is correct, it's the docker internal port
; not the external one if these containers are on the same host.
url = https://< kanidmd container name or ip> :8443
strict = true # Adjust this if you have CA validation issues
ca = /data/ca.crt
user = radius_service_account
secret = # The generated password from above
; default vlans for groups that don't specify one.
[DEFAULT]
vlan = 1
[group.network_admins]
vlan = 10
[radiusd]
ca = /data/certs/ca.pem
key = /data/certs/key.pem
cert = /data/certs/cert.pem
dh = /data/certs/dh
required_group = radius_access_allowed
cache_path = /dev/shm/kanidmradiusd
[client.localhost]
ipaddr = 127.0.0.1
secret = testing123
[client.docker]
ipaddr = 172.17.0.0/16
secret = testing123
< / code > < / pre >
< p > You can then run the container with:< / p >
< pre > < code > docker run --name radiusd -v ...:/data kanidm/radius:latest
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Authentication can be tested through the client.localhost Network Access Server (NAS) configuration with:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > docker exec -i -t radiusd radtest < username> badpassword 127.0.0.1 10 testing123
docker exec -i -t radiusd radtest < username> < radius show_secret value here> 127.0.0.1 10 testing123
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Finally, to expose this to a Wi-Fi infrastructure, add your NAS in < code > config.ini< / code > :< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > [client.access_point]
ipaddr = < some ipadd>
secret = < random value>
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Then re-create/run your docker instance with < code > -p 1812:1812 -p 1812:1812/udp< / code > ...< / p >
< p > If you have any issues, check the logs from the RADIUS output, as they tend
to indicate the cause of the problem. To increase the logging level you can
re-run your environment with debug enabled:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > docker rm radiusd
docker run --name radiusd -e DEBUG=True -i -t -v ...:/data kanidm/radius:latest
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Note the RADIUS container < em > is< / em > configured to provide Tunnel-Private-Group-ID,
so if you wish to use Wi-Fi-assigned VLANs on your infrastructure, you can
assign these by groups in the config.ini as shown in the above examples.< / p >
2022-05-01 06:11:32 +02:00
< div style = "break-before: page; page-break-before: always;" > < / div > < h1 id = "ldap" > < a class = "header" href = "#ldap" > LDAP< / a > < / h1 >
2022-06-02 03:20:33 +02:00
< p > While many applications can support systems like Security Assertion Markup
Language (SAML), or Open Authorization (OAuth), many do not.
Lightweight Directory Access Protocol (LDAP) has been the " lingua franca" of
authentication for many years, with almost every application in the world being
able to search and bind to LDAP. As many organization still rely on LDAP, Kanidm
can host a read-only LDAP interface.< / p >
2022-05-01 06:11:32 +02:00
< blockquote >
< p > < strong > WARNING< / strong > The LDAP server in Kanidm is not RFC compliant. This
2022-06-02 03:20:33 +02:00
is intentional, as Kanidm wants to cover the common use case,
simple bind and search.< / p >
2022-05-01 06:11:32 +02:00
< / blockquote >
< h2 id = "what-is-ldap" > < a class = "header" href = "#what-is-ldap" > What is LDAP< / a > < / h2 >
< p > LDAP is a protocol to read data from a directory of information. It is not
a server, but a way to communicate to a server. There are many famous LDAP
implementations such as Active Directory, 389 Directory Server, DSEE,
2022-06-02 03:20:33 +02:00
FreeIPA, and many others. Because it is a standard, applications can use
2022-05-01 06:11:32 +02:00
an LDAP client library to authenticate users to LDAP, given " one account" for
many applications - an IDM just like Kanidm!< / p >
< h2 id = "data-mapping" > < a class = "header" href = "#data-mapping" > Data Mapping< / a > < / h2 >
2022-06-02 03:20:33 +02:00
< p > Kanidm cannot be mapped 100% to LDAP's objects. This is because LDAP
2022-05-01 06:11:32 +02:00
types are simple key-values on objects which are all UTF8 strings (or subsets
thereof) based on validation (matching) rules. Kanidm internally implements complex
2022-06-02 03:20:33 +02:00
data types such as tagging on SSH keys, or multi-value credentials. These can not
2022-05-01 06:11:32 +02:00
be represented in LDAP.< / p >
2022-06-02 03:20:33 +02:00
< p > Many of the structures in Kanidm do not correlate closely to LDAP. For example
Kanidm only has a GID number, where LDAP's schemas define both a UID number and a
GID number.< / p >
2022-05-01 06:11:32 +02:00
< p > Entries in the database also have a specific name in LDAP, related to their path
in the directory tree. Kanidm is a flat model, so we have to emulate some tree-like
elements, and ignore others.< / p >
< p > For this reason, when you search the LDAP interface, Kanidm will make some mapping decisions.< / p >
< ul >
< li > The domain_info object becomes the suffix root.< / li >
2022-06-02 03:20:33 +02:00
< li > All other entries are direct subordinates of the domain_info for DN purposes.< / li >
< li > Distinguished Names (DNs) are generated from the attributes naming attributes.< / li >
< li > Bind DNs can be remapped and rewritten, and may not even be a DN during bind.< / li >
< li > The Kanidm domain name is used to generate the base DN.< / li >
2022-05-01 06:11:32 +02:00
< li > The '*' and '+' operators can not be used in conjuction with attribute lists in searches.< / li >
< / ul >
< p > These decisions were made to make the path as simple and effective as possible,
relying more on the Kanidm query and filter system than attempting to generate a tree-like
representation of data. As almost all clients can use filters for entry selection
2022-06-02 03:20:33 +02:00
we don't believe this is a limitation for the consuming applications.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "security" > < a class = "header" href = "#security" > Security< / a > < / h2 >
< h3 id = "tls-1" > < a class = "header" href = "#tls-1" > TLS< / a > < / h3 >
< p > StartTLS is not supported due to security risks. LDAPS is the only secure method
2022-06-02 03:20:33 +02:00
of communicating to any LDAP server. Kanidm, if configured with certificates, will
2022-05-01 06:11:32 +02:00
use them for LDAPS (and will not listen on a plaintext LDAP port). If no certificates exist
Kanidm will listen on a plaintext LDAP port, and you MUST TLS terminate in front
of the Kanidm system to secure data and authentication.< / p >
< h3 id = "access-controls" > < a class = "header" href = "#access-controls" > Access Controls< / a > < / h3 >
2022-06-02 03:20:33 +02:00
< p > LDAP only supports password authentication. As LDAP is used heavily in POSIX environments
2022-05-01 06:11:32 +02:00
the LDAP bind for any DN will use its configured posix password.< / p >
2022-06-02 03:20:33 +02:00
< p > As the POSIX password is not equivalent in strength to the primary credentials of Kanidm
(which may be multi-factor authentication, MFA), the LDAP bind does not grant
rights to elevated read permissions. All binds have the permissions of " Anonymous"
even if the anonymous account is locked.< / p >
2022-05-01 06:11:32 +02:00
< h2 id = "server-configuration-1" > < a class = "header" href = "#server-configuration-1" > Server Configuration< / a > < / h2 >
2022-06-02 03:20:33 +02:00
< p > To configure Kanidm to provide LDAP, add the argument to the < code > server.toml< / code > configuration:< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > ldapbindaddress = " 127.0.0.1:3636"
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > You should configure TLS certificates and keys as usual - LDAP will re-use the Web
server TLS material.< / p >
< h2 id = "showing-ldap-entries-and-attribute-maps" > < a class = "header" href = "#showing-ldap-entries-and-attribute-maps" > Showing LDAP Entries and Attribute Maps< / a > < / h2 >
< p > By default Kanidm is limited in what attributes are generated or remapped into
LDAP entries. However, the server internally contains a map of extended attribute
mappings for application specific requests that must be satisfied.< / p >
2022-05-01 06:11:32 +02:00
< p > An example is that some applications expect and require a 'CN' value, even though Kanidm does not
provide it. If the application is unable to be configured to accept " name" it may be necessary
2022-06-02 03:20:33 +02:00
to use Kanidm's mapping feature. Currently these are compiled into the server, so you may need to open
2022-05-01 06:11:32 +02:00
an issue with your requirements.< / p >
< p > To show what attribute maps exists for an entry you can use the attribute search term '+'.< / p >
< pre > < code > # To show Kanidm attributes
ldapsearch ... -x '(name=admin)' '*'
# To show all attribute maps
ldapsearch ... -x '(name=admin)' '+'
< / code > < / pre >
2022-06-02 03:20:33 +02:00
< p > Attributes that are in the map can be requested explicitly, and this can be combined with requesting
Kanidm native attributes.< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > ldapsearch ... -x '(name=admin)' cn objectClass displayname memberof
< / code > < / pre >
< h2 id = "example" > < a class = "header" href = "#example" > Example< / a > < / h2 >
< p > Given a default install with domain " example.com" the configured LDAP DN will be " dc=example,dc=com" .
This can be queried with:< / p >
< pre > < code > cargo run -- server -D kanidm.db -C ca.pem -c cert.pem -k key.pem -b 127.0.0.1:8443 -l 127.0.0.1:3636
> LDAPTLS_CACERT=ca.pem ldapsearch -H ldaps://127.0.0.1:3636 -b 'dc=example,dc=com' -x '(name=test1)'
# test1@example.com, example.com
dn: spn=test1@example.com,dc=example,dc=com
objectclass: account
objectclass: memberof
objectclass: object
objectclass: person
displayname: Test User
memberof: spn=group240@example.com,dc=example,dc=com
name: test1
spn: test1@example.com
entryuuid: 22a65b6c-80c8-4e1a-9b76-3f3afdff8400
< / code > < / pre >
< p > It is recommended that client applications filter accounts that can login with '(class=account)'
2022-06-02 03:20:33 +02:00
and groups with '(class=group)'. If possible, group membership is defined in RFC2307bis or
2022-05-01 06:11:32 +02:00
Active Directory style. This means groups are determined from the " memberof" attribute which contains
a DN to a group.< / p >
2022-06-02 03:20:33 +02:00
< p > LDAP binds can use any unique identifier of the account. The following are all valid bind DNs for
the object listed above (if it was a POSIX account, that is).< / p >
2022-05-01 06:11:32 +02:00
< pre > < code > ldapwhoami ... -x -D 'name=test1'
ldapwhoami ... -x -D 'spn=test1@example.com'
ldapwhoami ... -x -D 'test1@example.com'
ldapwhoami ... -x -D 'test1'
ldapwhoami ... -x -D '22a65b6c-80c8-4e1a-9b76-3f3afdff8400'
ldapwhoami ... -x -D 'spn=test1@example.com,dc=example,dc=com'
ldapwhoami ... -x -D 'name=test1,dc=example,dc=com'
< / code > < / pre >
< p > Most LDAP clients are very picky about TLS, and can be very hard to debug or display errors. For example
these commands:< / p >
< pre > < code > ldapsearch -H ldaps://127.0.0.1:3636 -b 'dc=example,dc=com' -x '(name=test1)'
ldapsearch -H ldap://127.0.0.1:3636 -b 'dc=example,dc=com' -x '(name=test1)'
ldapsearch -H ldap://127.0.0.1:3389 -b 'dc=example,dc=com' -x '(name=test1)'
< / code > < / pre >
< p > All give the same error:< / p >
< pre > < code > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
< / code > < / pre >
< p > This is despite the fact:< / p >
< ul >
2022-06-02 03:20:33 +02:00
< li > The first command is a certificate validation error.< / li >
< li > The second is a missing LDAPS on a TLS port.< / li >
< li > The third is an incorrect port.< / li >
2022-05-01 06:11:32 +02:00
< / ul >
< p > To diagnose errors like this, you may need to add " -d 1" to your LDAP commands or client.< / p >
< / main >
< nav class = "nav-wrapper" aria-label = "Page navigation" >
<!-- Mobile navigation buttons -->
< div style = "clear: both" > < / div >
< / nav >
< / div >
< / div >
< nav class = "nav-wide-wrapper" aria-label = "Page navigation" >
< / nav >
< / div >
< script type = "text/javascript" >
window.playground_copyable = true;
< / script >
< script src = "elasticlunr.min.js" type = "text/javascript" charset = "utf-8" > < / script >
< script src = "mark.min.js" type = "text/javascript" charset = "utf-8" > < / script >
< script src = "searcher.js" type = "text/javascript" charset = "utf-8" > < / script >
< script src = "clipboard.min.js" type = "text/javascript" charset = "utf-8" > < / script >
< script src = "highlight.js" type = "text/javascript" charset = "utf-8" > < / script >
< script src = "book.js" type = "text/javascript" charset = "utf-8" > < / script >
<!-- Custom JS scripts -->
< script type = "text/javascript" >
window.addEventListener('load', function() {
window.setTimeout(window.print, 100);
});
< / script >
< / body >
< / html >
