mart-w/kanidm
1
0
Fork 0
mirror of https://github.com/kanidm/kanidm.git synced 2025-02-23 20:47:01 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

More small corrections: line breaks, capitalization, typos (#778)

Browse source
This commit is contained in:
Carla Schroder 2022-05-25 14:38:28 -07:00 committed by GitHub
parent b4094324d8
commit 70db0630ea
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 59 additions and 49 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

6
kanidm_book/src/monitoring.md
View file

@ -1,10 +1,12 @@
# Monitoring the platform
The monitoring design of Kanidm is still very much in its infancy - [take part in the dicussion here!](https://github.com/kanidm/kanidm/issues/216).
The monitoring design of Kanidm is still very much in its infancy -
[take part in the dicussion at github.com/kanidm/kanidm/issues/216](https://github.com/kanidm/kanidm/issues/216).
## kanidmd
kanidmd currently responds to HTTP GET requests at the `/status` endpoint with a JSON object of either "true" or "false". `true` indicates that the platform is responding to requests.
kanidmd currently responds to HTTP GET requests at the `/status` endpoint with a JSON object of
either "true" or "false". `true` indicates that the platform is responding to requests.
| URL | `<hostname>/status` |
| --- | --- |

31
kanidm_book/src/password_quality.md
View file

@ -1,29 +1,38 @@
# Password Quality and Badlisting
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 MFA for their roles, but compromised accounts still pose a risk. There may also be deployment or other barriers to a site rolling out site wide MFA.
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.
## Quality Checking
Kanidm enforces that all passwords are checked by the library "[zxcvbn](https://github.com/dropbox/zxcvbn)". This has a large number of checks for password quality. It also provides constructive feedback to users on how to improve their passwords if it was rejected.
Kanidm enforces that all passwords are checked by the library "[zxcvbn](https://github.com/dropbox/zxcvbn)".
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.
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.
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.
This library can not be disabled - all passwords in Kanidm must pass this check.
## Password Badlisting
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.
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.
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.
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.
By default we ship with a preconfigured badlist that is updated overtime as new password breach lists are made available.
By default we ship with a preconfigured badlist that is updated over time as new password breach lists are
made available.
## Updating your own badlist.
## Updating your own Badlist
You can update your own badlist by using the proided `kanidm_badlist_preprocess` tool which helps to automate this process.
You can update your own badlist by using the provided `kanidm_badlist_preprocess` tool which helps to automate this process.
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.
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:
kanidm_badlist_preprocess -m -o /tmp/modlist.json <password file> [<password file> <password file> ...]

71
kanidm_book/src/posix_accounts.md
View file

@ -6,10 +6,10 @@ POSIX-like machines, such as Linux, FreeBSD, or others.
## Notes on POSIX Features
Many design decisions have been made in the POSIX features
of kanidm that are intended to make distributed systems easier to manage and
of Kanidm that are intended to make distributed systems easier to manage and
client systems more secure.
### UID and GID numbers
### UID and GID Numbers
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
@ -19,19 +19,19 @@ but without changing the umask on all client systems. This can cause users' data
compromised by any member of the same shared group.
To prevent this, many systems create a "user private group", or UPG. This group has the
gidnumber matching the uidnumber of the user, and the user sets its primary
group id to the gidnumber of the UPG.
GID number matching the UID of the user, and the user sets their primary
group ID to the GID number of the UPG.
As there is now an equivalence between the UID and GID number of the user and the UPG,
there is no benefit to separating these values. As a result kanidm accounts *only*
have a gidnumber, which is also considered to be its uidnumber as well. This has the benefit
of preventing the accidental creation of a separate group that has an overlapping gidnumber
there is no benefit in separating these values. As a result Kanidm accounts *only*
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
(the `uniqueness` attribute of the schema will block the creation).
### UPG generation
### UPG Generation
Due to the requirement that a user have a UPG for security, many systems create these as
two independent items. For example in /etc/passwd and /etc/group
two independent items. For example in /etc/passwd and /etc/group:
# passwd
william:x:654401105:654401105::/home/william:/bin/zsh
@ -41,19 +41,19 @@ two independent items. For example in /etc/passwd and /etc/group
Other systems like FreeIPA use a plugin that generates a UPG as a database record on
creation of the account.
Kanidm does neither of these. As the gidnumber of the user must be unique, and a user
Kanidm does neither of these. As the GID number of the user must be unique, and a user
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.
### gidnumber generation
### GID Number Generation
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
gidnumbers to accounts on replicas that may not be in continual communication.
GID numbers to accounts on replicas that may not be in continual communication.
To do this, we use the last 32 bits of the account or group's UUID to generate the
gidnumber.
To do this, we use the last 32 bits of the account or group's UUID to
generate the GID number.
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
@ -61,59 +61,58 @@ of duplication. With 50,000 you have a 20% chance, 9,300 you have a 1% chance an
with 2900 you have a 0.1% chance.
We advise that if you have a site with >10,000 users you should use an external system
to allocate gidnumbers serially or consistently to avoid potential duplication events.
to allocate GID numbers serially or consistently to avoid potential duplication events.
This design decision is made as most small sites will benefit greatly from the
autoallocation policy and the simplicity of its design, while larger enterprises
will already have IDM or Business process applications for HR/People that are
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
capable of supplying this kind of data in batch jobs.
## Enabling Posix Attributes
## Enabling POSIX Attributes
### Enabling Posix Attributes on Accounts
### Enabling POSIX Attributes on Accounts
To enable posix account features and ids on an account, you require the permission `idm_account_unix_extend_priv`.
This is provided to `idm_admins` in the default database.
To enable POSIX account features and IDs on an account, you require the permission
`idm_account_unix_extend_priv`. This is provided to `idm_admins` in the default database.
You can then use the following command to enable posix extensions.
You can then use the following command to enable POSIX extensions.
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
You can view the accounts posix token details with:
You can view the accounts POSIX token details with:
kanidm account posix show --name anonymous demo_user
### Enabling Posix Attributes on Groups
### Enabling POSIX Attributes on Groups
To enable posix group features and ids on an account, you require the permission `idm_group_unix_extend_priv`.
To enable POSIX group features and IDs on an account, you require the permission `idm_group_unix_extend_priv`.
This is provided to `idm_admins` in the default database.
You can then use the following command to enable posix extensions.
You can then use the following command to enable POSIX extensions:
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
You can view the accounts posix token details with:
You can view the accounts POSIX token details with:
kanidm group posix show --name anonymous demo_group
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.
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.
## Troubleshooting Common Issues
### Subid conflicts with Podman
### subuid conflicts with Podman
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:
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:
ERRO[0000] cannot find UID/GID for user NAME: No subuid ranges found for user "NAME" in /etc/subuid
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 gidnumber to be
between 1000 - 65535 which may not have the fault.
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.