Skip to content

G
gitlab-ce
Commit b8f13d85 authored by Evan Read's avatar Evan Read Committed by Nick Gaskill
Browse files
Options

Update Access and Compliance documentation for new Menu structure

parent d9b99c31
Hide whitespace changes
Inline Side-by-side
Showing with 225 additions and 152 deletions
doc/administration/audit_events.md
View file @ b8f13d85
......@@ -6,7 +6,8 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Audit Events **(PREMIUM)**
GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan](https://about.gitlab.com/pricing/).
GitLab offers a way to view the changes made within the GitLab server for owners and administrators
on a [paid plan](https://about.gitlab.com/pricing/).
GitLab system administrators can also take advantage of the logs located on the
file system. See [the logs system documentation](logs.md#audit_jsonlog) for more details.
......@@ -56,7 +57,11 @@ A user with:
Group events do not include project audit events.
To view a group's audit events, navigate to **Group > Security & Compliance > Audit Events**.
To view a group's audit events:
1. Go to the group.
1. On the left sidebar, select **Security & Compliance > Audit Events**.
From there, you can see the following actions:
- Group name or path changed.
......@@ -86,7 +91,11 @@ Group events can also be accessed via the [Group Audit Events API](../api/audit_
A user with a Maintainer role (or above) can retrieve project audit events of all users.
A user with a Developer role is limited to project audit events based on their individual actions.
To view a project's audit events, navigate to **Project > Security & Compliance > Audit Events**.
To view a project's audit events:
1. Go to the project.
1. On the left sidebar, select **Security & Compliance > Audit Events**.
From there, you can see the following actions:
- Added or removed deploy keys
......@@ -126,7 +135,10 @@ changed what and when for audit purposes.
Instance events do not include group or project audit events.
To view the server-wide administrator log, visit **Admin Area > Monitoring > Audit Events**.
To view the server-wide audit events:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Monitoring > Audit Events**.
The following user actions are recorded:
......@@ -187,7 +199,7 @@ It may make the user interface for your project or audit events very busy, and t
`audit_events` PostgreSQL table may increase considerably. It's disabled by default
to prevent performance degradations on GitLab instances with very high Git write traffic.
In an upcoming release, Audit Events for Git push events will be enabled
In an upcoming release, Audit Events for Git push events are planned to be enabled
by default. Follow our [Partitioning strategy for Audit Events epic](https://gitlab.com/groups/gitlab-org/-/epics/3206) for updates.
If you still wish to enable **Repository push** events in your instance, follow
......@@ -229,11 +241,12 @@ Export to CSV allows customers to export the current filter view of your audit e
CSV file, which stores tabular data in plain text. The data provides a comprehensive view with respect to
audit events.
To export the Audit Events to CSV, navigate to
**{monitor}** **Admin Area > Monitoring > Audit Events**
To export the Audit Events to CSV:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Monitoring > Audit Events**.
1. Select the available search [filters](#search).
1. Click **Export as CSV**.
1. Select **Export as CSV**.
### Sort
......
doc/administration/auth/ldap/index.md
View file @ b8f13d85
......@@ -367,7 +367,7 @@ Instead of having the LDAP integration credentials stored in plaintext in the co
use an encrypted file for the LDAP credentials. To use this feature, you first need to enable
[GitLab encrypted configuration](../../encrypted_configuration.md).
The encrypted configuration for LDAP exists in an encrypted YAML file. By default the file will be created at
The encrypted configuration for LDAP exists in an encrypted YAML file. By default the file is created at
`shared/encrypted_configuration/ldap.yaml.enc`. This location is configurable in the GitLab configuration.
The unencrypted contents of the file should be a subset of the secret settings from your `servers` block in the LDAP
......@@ -646,7 +646,7 @@ For information on adding group links by using CNs and filters, refer to the
As an extension of group sync, you can automatically manage your global GitLab
administrators. Specify a group CN for `admin_group` and all members of the
LDAP group will be given administrator privileges. The configuration looks
LDAP group are given administrator privileges. The configuration looks
like the following.
NOTE:
......@@ -704,7 +704,9 @@ When enabled, the following applies:
To enable it you need to:
1. [Enable LDAP](#configuration)
1. Go to the Admin Area (**{admin}**) and select **Settings > Visibility and access controls**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Visibility and access controls** section.
1. Ensure the **Lock memberships to LDAP synchronization** checkbox is selected.
### Adjusting LDAP group sync schedule **(PREMIUM SELF)**
......@@ -748,7 +750,7 @@ sync to run once every two hours at the top of the hour.
### External groups **(PREMIUM SELF)**
Using the `external_groups` setting will allow you to mark all users belonging
Using the `external_groups` setting allows you to mark all users belonging
to these groups as [external users](../../../user/permissions.md#external-users).
Group membership is checked periodically through the `LdapGroupSync` background
task.
......
doc/administration/auth/ldap/ldap-troubleshooting.md
View file @ b8f13d85
......@@ -20,7 +20,7 @@ or `encryption: 'simple_tls'` and `port: 636`.
#### Connection times out
If GitLab cannot reach your LDAP endpoint, you will see a message like this:
If GitLab cannot reach your LDAP endpoint, you see a message like this:
```plaintext
Could not authenticate you from Ldapmain because "Connection timed out - user specified timeout".
......@@ -145,7 +145,8 @@ may see the following message: `Access denied for your LDAP account`.
We have a workaround, based on toggling the access level of affected users:
1. As an administrator, go to **Admin Area > Overview > Users**.
1. As an administrator, on the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the name of the affected user.
1. In the user's administrative page, press **Edit** on the top right of the page.
1. Change the user's access level from `Regular` to `Admin` (or vice versa),
......@@ -202,9 +203,11 @@ field contains no data:
To resolve this:
1. Go to both of the following in the Admin Area (**{admin}**):
- **Settings > General > Account and limit**
- **Settings > General > Sign-up restrictions**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, go to **Settings > General**.
1. Expand both of the following:
- **Account and limit**.
- **Sign-up restrictions**.
1. Check, for example, the **Default projects limit** or **Allowed domains for sign-ups**
fields and ensure that a relevant value is configured.
......@@ -345,8 +348,9 @@ things to check to debug the situation.
group](index.md#adding-group-links).
- Check that the user has an LDAP identity:
1. Sign in to GitLab as an administrator user.
1. Go to **Admin area > Users**.
1. Search for the user
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Search for the user.
1. Open the user by clicking their name. Do not click **Edit**.
1. Select the **Identities** tab. There should be an LDAP identity with
an LDAP DN as the 'Identifier'. If not, this user hasn't signed in with
......@@ -383,7 +387,7 @@ the following are true:
- The configured `admin_group` in the `gitlab.rb` is a CN, rather than a DN or an array.
- This CN falls under the scope of the configured `group_base`.
- The members of the `admin_group` have already signed into GitLab with their LDAP
credentials. GitLab will only grant this administrator access to the users whose
credentials. GitLab only grants this administrator access to the users whose
accounts are already connected to LDAP.
If all the above are true and the users are still not getting access, [run a manual
......@@ -412,7 +416,7 @@ output](#example-console-output-after-a-group-sync).
##### Example console output after a group sync **(PREMIUM SELF)**
Like the output from the user sync, the output from the [manual group
sync](#sync-all-groups) will also be very verbose. However, it contains lots
sync](#sync-all-groups) is also very verbose. However, it contains lots
of helpful information.
Indicates the point where syncing actually begins:
......@@ -423,7 +427,7 @@ Started syncing 'ldapmain' provider for 'my_group' group
The following entry shows an array of all user DNs GitLab sees in the LDAP server.
Note that these are the users for a single LDAP group, not a GitLab group. If
you have multiple LDAP groups linked to this GitLab group, you will see multiple
you have multiple LDAP groups linked to this GitLab group, you see multiple
log entries like this - one for each LDAP group. If you don't see an LDAP user
DN in this log entry, LDAP is not returning the user when we do the lookup.
Verify the user is actually in the LDAP group.
......@@ -437,7 +441,7 @@ Members in 'ldap_group_1' LDAP group: ["uid=john0,ou=people,dc=example,dc=com",
"uid=mary4,ou=people,dc=example,dc=com"]
```
Shortly after each of the above entries, you will see a hash of resolved member
Shortly after each of the above entries, you see a hash of resolved member
access levels. This hash represents all user DNs GitLab thinks should have
access to this group, and at which access level (role). This hash is additive,
and more DNs may be added, or existing entries modified, based on additional
......@@ -478,21 +482,21 @@ Finally, the following entry says syncing has finished for this group:
Finished syncing all providers for 'my_group' group
```
Once all the configured group links have been synchronized, GitLab will look
Once all the configured group links have been synchronized, GitLab looks
for any Administrators or External users to sync:
```shell
Syncing admin users for 'ldapmain' provider
```
The output will look similar to what happens with a single group, and then
this line will indicate the sync is finished:
The output looks similar to what happens with a single group, and then
this line indicates the sync is finished:
```shell
Finished syncing admin users for 'ldapmain' provider
```
If [administrator sync](index.md#administrator-sync) is not configured, you'll see a message
If [administrator sync](index.md#administrator-sync) is not configured, you see a message
stating as such:
```shell
......@@ -518,8 +522,8 @@ group = Group.find_by(name: 'my_gitlab_group')
EE::Gitlab::Auth::Ldap::Sync::Group.execute_all_providers(group)
```
The output will be similar to
[that you'd get from syncing all groups](#example-console-output-after-a-group-sync).
The output is similar to
[that you get from syncing all groups](#example-console-output-after-a-group-sync).
#### Query a group in LDAP **(PREMIUM SELF)**
......@@ -540,24 +544,25 @@ ldap_group.member_uids
When an LDAP user is created in GitLab, their LDAP DN is stored for later reference.
If GitLab cannot find a user by their DN, it will fall back
to finding the user by their email. If the lookup is successful, GitLab will
update the stored DN to the new value so both values will now match what's in
If GitLab cannot find a user by their DN, it falls back
to finding the user by their email. If the lookup is successful, GitLab
updates the stored DN to the new value so both values now match what's in
LDAP.
If the email has changed and the DN has not, GitLab will find the user with
If the email has changed and the DN has not, GitLab finds the user with
the DN and update its own record of the user's email to match the one in LDAP.
However, if the primary email _and_ the DN change in LDAP, then GitLab will
have no way of identifying the correct LDAP record of the user and, as a
result, the user will be blocked. To rectify this, the user's existing
profile will have to be updated with at least one of the new values (primary
However, if the primary email _and_ the DN change in LDAP, then GitLab
has no way of identifying the correct LDAP record of the user and, as a
result, the user is blocked. To rectify this, the user's existing
profile must be updated with at least one of the new values (primary
email or DN) so the LDAP record can be found.
The following script will update the emails for all provided users so they
won't be blocked or unable to access their accounts.
The following script updates the emails for all provided users so they
aren't blocked or unable to access their accounts.
>**NOTE**: The following script will require that any new accounts with the new
NOTE:
The following script requires that any new accounts with the new
email address are removed first. This is because emails have to be unique in GitLab.
Go to the [rails console](#rails-console) and then run:
......@@ -604,23 +609,23 @@ users, [see what to do when no users are found](#no-users-are-found).
### GitLab logs
If a user account is blocked or unblocked due to the LDAP configuration, a
message will be [logged to `application.log`](../../logs.md#applicationlog).
message is [logged to `application.log`](../../logs.md#applicationlog).
If there is an unexpected error during an LDAP lookup (configuration error,
timeout), the sign-in is rejected and a message will be [logged to
timeout), the sign-in is rejected and a message is [logged to
`production.log`](../../logs.md#productionlog).
### ldapsearch
`ldapsearch` is a utility that will allow you to query your LDAP server. You can
`ldapsearch` is a utility that allows you to query your LDAP server. You can
use it to test your LDAP settings and ensure that the settings you're using
will get you the results you expect.
get you the results you expect.
When using `ldapsearch`, be sure to use the same settings you've already
specified in your `gitlab.rb` configuration so you can confirm what happens
when those exact settings are used.
Running this command on the GitLab host will also help confirm that there's no
Running this command on the GitLab host also helps confirm that there's no
obstruction between the GitLab host and LDAP.
For example, consider the following GitLab configuration:
......@@ -701,9 +706,9 @@ For instructions about how to use the rails console, refer to this
#### Enable debug output
This will provide debug output that will be useful to see
what GitLab is doing and with what. This value is not persisted, and will only
be enabled for this session in the rails console.
This provides debug output that is useful to see
what GitLab is doing and with what. This value is not persisted, and is only
enabled for this session in the rails console.
To enable debug output in the rails console, [enter the rails
console](#rails-console) and run:
......
doc/integration/kerberos.md
View file @ b8f13d85
......@@ -25,7 +25,7 @@ mythology; Kerberos was a three-headed dog who guarded the gates of Hades.
For GitLab to offer Kerberos token-based authentication, perform the
following prerequisites. You still need to configure your system for
Kerberos usage, such as specifying realms. GitLab will make use of the
Kerberos usage, such as specifying realms. GitLab makes use of the
system's Kerberos settings.
### GitLab keytab
......@@ -34,7 +34,7 @@ system's Kerberos settings.
If your GitLab server is `gitlab.example.com` and your Kerberos realm
`EXAMPLE.COM`, create a Service Principal `HTTP/gitlab.example.com@EXAMPLE.COM`
in your Kerberos database.
1. Create a keytab on the GitLab server for the above Service Principal, e.g.
1. Create a keytab on the GitLab server for the above Service Principal. For example,
`/etc/http.keytab`.
The keytab is a sensitive file and must be readable by the GitLab user. Set
......@@ -107,8 +107,9 @@ set up GitLab to create a new account when a Kerberos user tries to sign in.
If you're an administrator, you can link a Kerberos account to an
existing GitLab account. To do so:
1. Navigate to **Admin Area > Overview > Users > Example User**.
1. Select the Identities tab.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select a user, then select the **Identities** tab.
1. Select 'Kerberos SPNEGO' in the 'Provider' dropdown box.
1. Make sure the **Identifier** corresponds to the Kerberos username.
1. Select **Save changes**.
......@@ -145,8 +146,9 @@ With that information at hand:
administrator if you think this is an error.
```
1. As an administrator, you can confirm the new, blocked account.
Select **Admin Area > Overview > Users** and review the Blocked tab.
1. As an administrator, you can confirm the new, blocked account:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users** and review the **Blocked** tab.
1. You can enable the user.
1. If `block_auto_created_users` is false, the Kerberos user is
authenticated and is signed in to GitLab.
......@@ -181,7 +183,7 @@ LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
You can configure custom allowed realms when the user's Kerberos realm doesn't
match the domain from the user's LDAP DN. The configuration value must specify
all domains that users may be expected to have. Any other domains are
ignored and an LDAP identity won't be linked.
ignored and an LDAP identity is not linked.
**For Omnibus installations**
......@@ -214,12 +216,12 @@ A linked Kerberos account enables you to `git pull` and `git push` using your
Kerberos account, as well as your standard GitLab credentials.
GitLab users with a linked Kerberos account can also `git pull` and `git push`
using Kerberos tokens, i.e., without having to send their password with each
using Kerberos tokens. That is, without having to send their password with each
operation.
WARNING:
There is a [known issue](https://github.com/curl/curl/issues/1261) with `libcurl`
older than version 7.64.1 wherein it won't reuse connections when negotiating.
older than version 7.64.1 wherein it doesn't reuse connections when negotiating.
This leads to authorization issues when push is larger than `http.postBuffer`
configuration. Ensure that Git is using at least `libcurl` 7.64.1 to avoid this. To
know the `libcurl` version installed, run `curl-config --version`.
......@@ -236,13 +238,13 @@ authentication fails.
For GitLab users to be able to use either `basic` or `negotiate` authentication
with older Git versions, it is possible to offer Kerberos ticket-based
authentication on a different port (e.g. 8443) while the standard port offers
only `basic` authentication.
authentication on a different port (for example, `8443`) while the standard port
offers only `basic` authentication.
**For source installations with HTTPS**
1. Edit the NGINX configuration file for GitLab
(e.g., `/etc/nginx/sites-available/gitlab-ssl`) and configure NGINX to
(for example, `/etc/nginx/sites-available/gitlab-ssl`) and configure NGINX to
listen to port `8443` in addition to the standard HTTPS port:
```conf
......
doc/integration/oauth_provider.md
View file @ b8f13d85
......@@ -27,8 +27,8 @@ of the resource owner or the end-user.
OAuth 2 can be used:
- To allow users to sign in to your application with their GitLab.com account.
- To set up GitLab.com for authentication to your GitLab instance.
(see [GitLab OmniAuth](gitlab.md)).
- To set up GitLab.com for authentication to your GitLab instance. See
[GitLab OmniAuth](gitlab.md).
The 'GitLab Importer' feature also uses OAuth 2 to give access
to repositories without sharing user credentials to your GitLab.com account.
......@@ -63,7 +63,7 @@ To add a new application for your user:
To add a new application for a group:
1. Navigate to the desired group.
1. In the left sidebar, select **Settings > Applications**.
1. On the left sidebar, select **Settings > Applications**.
1. Enter a **Name**, **Redirect URI** and OAuth 2 scopes as defined in [Authorized Applications](#authorized-applications).
The **Redirect URI** is the URL where users are sent after they authorize with GitLab.
1. Select **Save application**. GitLab displays:
......@@ -73,10 +73,13 @@ To add a new application for a group:
## Instance-wide applications
To create an application for your GitLab instance, select
**Admin Area > Applications > New application**.
To create an application for your GitLab instance:
When creating an **Admin Area** application, you can mark it as _trusted_.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Applications**.
1. Select **New application**.
When creating application in the **Admin Area** , you can mark it as _trusted_.
The user authorization step is automatically skipped for this application.
## Authorized applications
......
doc/security/password_length_limits.md
View file @ b8f13d85
......@@ -14,8 +14,9 @@ By default, GitLab supports passwords with the following lengths:
GitLab administrators can modify password lengths:
- Using the GitLab UI. **[From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab 12.6 this is the only available option.**
- Using configuration file. **Up to GitLab 12.5**.
- Using the GitLab UI. [From](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20661) GitLab
12.6, this is the only available option.
- Using configuration file. Up to GitLab 12.5.
Changing the minimum or maximum length does not affect existing user passwords. Existing users are
not asked to reset their password to adhere to the new limits. The new limit restriction applies
......@@ -29,7 +30,8 @@ The user password length is set to a minimum of 8 characters by default.
To change the minimum password length using GitLab UI:
1. Go to the Admin Area (**{admin}**) and select **Settings > Sign-up restrictions**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General** and expand **Sign-up restrictions**.
![Minimum password length settings](../user/admin_area/img/minimum_password_length_settings_v12_6.png)
......
doc/security/ssh_keys_restrictions.md
View file @ b8f13d85
......@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
`ssh-keygen` allows users to create RSA keys with as few as 768 bits, which
falls well below recommendations from certain standards groups (such as the US
NIST). Some organizations deploying GitLab will need to enforce minimum key
NIST). Some organizations deploying GitLab need to enforce minimum key
strength, either to satisfy internal security policy or for regulatory
compliance.
......@@ -18,14 +18,17 @@ the older DSA, and administrators may need to limit the allowed SSH key
algorithms.
GitLab allows you to restrict the allowed SSH key technology as well as specify
the minimum key length for each technology.
the minimum key length for each technology:
In **Admin Area > Settings** (`/admin/application_settings/general`), expand the
**Visibility and access controls** section:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
1. Expand the **Visibility and access controls** section:
![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
![SSH keys restriction admin settings](img/ssh_keys_restrictions_settings.png)
If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to pull or push code using them.
If a restriction is imposed on any key type, users cannot upload new SSH keys that don't meet the
requirement. Any existing keys that don't meet it are disabled but not removed and users cannot to
pull or push code using them.
An icon is visible to the user of a restricted key in the SSH keys section of their profile:
......
doc/security/two_factor_authentication.md
View file @ b8f13d85
......@@ -9,7 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
Two-factor Authentication (2FA) provides an additional level of security to your
users' GitLab account. After being enabled, in addition to supplying their
username and password to sign in, they'll be prompted for a code generated by an
username and password to sign in, they are prompted for a code generated by an
application on their phone.
You can read more about it here:
......@@ -28,8 +28,8 @@ cannot leave the 2FA configuration area at `/-/profile/two_factor_auth`.
To enable 2FA for all users:
1. Navigate to **Admin Area > Settings > General**
(`/admin/application_settings/general`).
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
1. Expand the **Sign-in restrictions** section, where you can configure both.
If you want 2FA enforcement to take effect during the next sign-in attempt,
......@@ -39,13 +39,13 @@ change the grace period to `0`.
> [Introduced in](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24965) GitLab 12.0, 2FA settings for a group are also applied to subgroups.
If you want to enforce 2FA only for certain groups, you can:
If you want to enforce 2FA only for certain groups:
1. Enable it in the group's **Settings > General** page. Navigate to
**Permissions, LFS, 2FA > Two-factor authentication**. You can then select
the **Require all users in this group to setup Two-factor authentication**
option.
1. You can also specify a grace period in the **Time before enforced** option.
1. Go to the group's **Settings > General** page.
1. Expand the **Permissions, LFS, 2FA** section.
1. Select the **Require all users in this group to setup two-factor authentication** option.
You can also specify a grace period in the **Time before enforced** option.
To change this setting, you need to be administrator or owner of the group.
......@@ -67,8 +67,12 @@ The following are important notes about 2FA:
2FA enabled, 2FA is **not** required for those individually added members.
- If there are multiple 2FA requirements (for example, group + all users, or multiple
groups) the shortest grace period is used.
- It is possible to disallow subgroups from setting up their own 2FA requirements.
Navigate to the top-level group's **Settings > General > Permissions, LFS, 2FA > Two-factor authentication** and uncheck the **Allow subgroups to set up their own two-factor authentication rule** field. This action causes all subgroups with 2FA requirements to stop requiring that from their members.
- It is possible to disallow subgroups from setting up their own 2FA requirements:
1. Go to the top-level group's **Settings > General**.
1. Expand the **Permissions, LFS, 2FA** section.
1. Uncheck the **Allow subgroups to set up their own two-factor authentication rule** field.
This action causes all subgroups with 2FA requirements to stop requiring that from their members.
## Disabling 2FA for everyone
......@@ -93,18 +97,6 @@ WARNING:
This is a permanent and irreversible action. Users have to
reactivate 2FA from scratch if they want to use it again.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
## Two-factor Authentication (2FA) for Git over SSH operations **(PREMIUM)**
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/270554) in GitLab 13.7.
......@@ -157,3 +149,15 @@ The feature flag affects these features:
- [Two-factor Authentication (2FA) for Git over SSH operations](#two-factor-authentication-2fa-for-git-over-ssh-operations).
- [Customize session duration for Git Operations when 2FA is enabled](../user/admin_area/settings/account_and_limit_settings.md#customize-session-duration-for-git-operations-when-2fa-is-enabled).
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
one might have when setting this up, or when something is changed, or on upgrading, it's
important to describe those, too. Think of things that may go wrong and include them here.
This is important to minimize requests for support, and to avoid doc comments with
questions that you know someone might ask.
Each scenario can be a third-level heading, e.g. `### Getting error message X`.
If you have none to add when creating a doc, leave this section in place
but commented out to help encourage others to add to it in the future. -->
doc/security/user_email_confirmation.md
View file @ b8f13d85
......@@ -11,8 +11,9 @@ GitLab can be configured to require confirmation of a user's email address when
the user signs up. When this setting is enabled, the user is unable to sign in until
they confirm their email address.
In **Admin Area > Settings** (`/admin/application_settings/general`), go to the section
**Sign-up Restrictions** and look for the **Send confirmation email on sign-up** option.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General** (`/admin/application_settings/general`).
1. Expand the **Sign-up restrictions** section and look for the **Send confirmation email on sign-up** option.
## Confirmation token expiry
......
doc/user/admin_area/approving_users.md
View file @ b8f13d85
......@@ -34,7 +34,8 @@ sign in.
To view user sign ups pending approval:
1. Go to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
## Approve or reject a user sign up
......@@ -43,9 +44,10 @@ A user sign up pending approval can be approved or rejected from the Admin Area.
To approve or reject a user sign up:
1. Go to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Pending approval** tab.
1. In the user's row select settings (**{settings}**).
1. In the user's row, select settings (**{settings}**).
1. Select **Approve** or **Reject**.
Approving a user:
......
doc/user/admin_area/credentials_inventory.md
View file @ b8f13d85
......@@ -9,7 +9,9 @@ type: howto
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/20912) in GitLab 12.6.
GitLab administrators are responsible for the overall security of their instance. To assist, GitLab provides a Credentials inventory to keep track of all the credentials that can be used to access their self-managed instance.
GitLab administrators are responsible for the overall security of their instance. To assist, GitLab
provides a Credentials inventory to keep track of all the credentials that can be used to access
their self-managed instance.
Using Credentials inventory, you can see all the personal access tokens (PAT), SSH keys, and GPG keys
that exist in your GitLab instance. In addition, you can [revoke](#revoke-a-users-personal-access-token)
......@@ -21,7 +23,10 @@ and [delete](#delete-a-users-ssh-key) and see:
- When they expire. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2.
- When they were revoked. [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/214809) in GitLab 13.2.
To access the Credentials inventory, navigate to **Admin Area > Credentials**.
To access the Credentials inventory:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Credentials**.
The following is an example of the Credentials inventory page:
......
doc/user/admin_area/moderate_users.md
View file @ b8f13d85
......@@ -21,9 +21,10 @@ administrators can choose to block the user.
Users can be blocked [via an abuse report](review_abuse_reports.md#blocking-users),
or directly from the Admin Area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select a user.
1. Under the **Account** tab, click **Block user**.
1. Under the **Account** tab, select **Block user**.
A blocked user:
......@@ -43,10 +44,11 @@ A blocked user does not consume a [seat](../../subscriptions/self_managed/index.
A blocked user can be unblocked from the Admin Area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Click on the **Blocked** tab.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select on the **Blocked** tab.
1. Select a user.
1. Under the **Account** tab, click **Unblock user**.
1. Under the **Account** tab, select **Unblock user**.
Users can also be unblocked using the [GitLab API](../../api/users.md#unblock-user).
......@@ -74,16 +76,17 @@ with the following differences:
A deactivated user:
- Cannot access Git repositories or the API.
- Will not receive any notifications from GitLab.
- Will not be able to use [slash commands](../../integration/slash_commands.md).
- Does not receive any notifications from GitLab.
- Does not be able to use [slash commands](../../integration/slash_commands.md).
Personal projects, and group and user history of the deactivated user are left intact.
A user can be deactivated from the Admin Area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select a user.
1. Under the **Account** tab, click **Deactivate user**.
1. Under the **Account** tab, select **Deactivate user**.
Please note that for the deactivation option to be visible to an admin, the user:
......@@ -99,11 +102,14 @@ A deactivated user does not consume a [seat](../../subscriptions/self_managed/in
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/320875) in GitLab 14.0.
Administrators can enable automatic deactivation of users who have not signed in, or have no activity in the last 90 days. To do this:
Administrators can enable automatic deactivation of users who have not signed in, or have no activity
in the last 90 days. To do this:
1. Navigate to **Admin Area > Settings > General > Account and Limit**.
1. Under the **Dormant users** tab, check **Deactivate dormant users after 90 days of inactivity**.
1. Click **Save changes**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Account and limit** section.
1. Under **Dormant users**, check **Deactivate dormant users after 90 days of inactivity**.
1. Select **Save changes**.
When this feature is enabled, GitLab runs a job once a day to deactivate the dormant users.
......@@ -117,10 +123,11 @@ A deactivated user can be activated from the Admin Area.
To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Click on the **Deactivated** tab.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Deactivated** tab.
1. Select a user.
1. Under the **Account** tab, click **Activate user**.
1. Under the **Account** tab, select **Activate user**.
Users can also be activated using the [GitLab API](../../api/users.md#activate-user).
......@@ -148,23 +155,25 @@ To completely block a user, administrators can choose to ban the user.
Users can be banned using the Admin Area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select a user.
1. Under the **Account** tab, click **Ban user**.
1. Under the **Account** tab, select **Ban user**.
NOTE:
This feature is a work in progress. Currently, banning a user
only blocks them and does not hide their comments or issues.
This functionality will be implemented in follow up issues.
This functionality is planned to be implemented in follow up issues.
### Unban a user
A banned user can be unbanned using the Admin Area. To do this:
1. Navigate to **Admin Area > Overview > Users**.
1. Click on the **Banned** tab.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select the **Banned** tab.
1. Select a user.
1. Under the **Account** tab, click **Unban user**.
1. Under the **Account** tab, select **Unban user**.
NOTE:
Unbanning a user changes the user's state to active and consumes a
......
doc/user/admin_area/review_abuse_reports.md
View file @ b8f13d85
......@@ -16,7 +16,8 @@ reports in the Admin Area.
To receive notifications of new abuse reports by e-mail, follow these steps:
1. Select **Admin Area > Settings > Reporting**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > Reporting**.
1. Expand the **Abuse reports** section.
1. Provide an email address.
......@@ -30,7 +31,10 @@ documentation](../report_abuse.md).
## Resolving abuse reports
To access abuse reports, go to **Admin Area > Abuse Reports**.
To access abuse reports:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Abuse Reports**.
There are 3 ways to resolve an abuse report, with a button for each method:
......
doc/user/group/subgroups/index.md
View file @ b8f13d85
......@@ -67,8 +67,6 @@ Another example of GitLab as a company would be the following:
- (project) Chef cookbooks
- Category Subgroup - Executive team
---
When performing actions such as transferring or importing a project between
subgroups, the behavior is the same as when performing these actions at the
`group/project` level.
......@@ -85,13 +83,20 @@ By default, groups created in:
The setting can be changed for any group by:
- A group owner. Select the group, and navigate to **Settings > General > Permissions, LFS, 2FA**.
- An administrator. Navigate to **Admin Area > Overview > Groups**, select the group, and choose **Edit**.
- A group owner:
1. Select the group.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Permissions, LFS, 2FA** section.
- An administrator:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Groups**.
1. Select the group, and select **Edit**.
For:
For more information check the
[permissions table](../../permissions.md#group-members-permissions). For a list
of words that are not allowed to be used as group names see the
[reserved names](../../reserved_names.md).
- More information, check the [permissions table](../../permissions.md#group-members-permissions).
- A list of words that are not allowed to be used as group names, see the
[reserved names](../../reserved_names.md).
Users can always create subgroups if they are explicitly added as an Owner (or
Maintainer, if that setting is enabled) to an immediate parent group, even if group
......
doc/user/permissions.md
View file @ b8f13d85
......@@ -359,10 +359,11 @@ External users still count towards a license seat.
An administrator can flag a user as external by either of the following methods:
- Either [through the API](../api/users.md#user-modification).
- Or by navigating to the **Admin Area > Overview > Users** to create a new user
or edit an existing one. There, you can find the option to flag the user as
external.
- [Through the API](../api/users.md#user-modification).
- Using the GitLab UI:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users** to create a new user or edit an existing one.
There, you can find the option to flag the user as external.
Additionally users can be set as external users using [SAML groups](../integration/saml.md#external-groups)
and [LDAP groups](../administration/auth/ldap/index.md#external-groups).
......@@ -370,7 +371,11 @@ and [LDAP groups](../administration/auth/ldap/index.md#external-groups).
### Setting new users to external
By default, new users are not set as external users. This behavior can be changed
by an administrator on the **Admin Area > Settings > General** page, under **Account and limit**.
by an administrator:
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Settings > General**.
1. Expand the **Account and limit** section.
If you change the default behavior of creating new users as external, you
have the option to narrow it down by defining a set of internal users.
......
doc/user/profile/account/create_accounts.md
View file @ b8f13d85
......@@ -14,16 +14,21 @@ You can create users:
## Create users on sign in page
If you have [sign-up enabled](../../admin_area/settings/sign_up_restrictions.md), users can create their own accounts by selecting "Register now" on the sign-in page, or navigate to `https://gitlab.example.com/users/sign_up`.
If you have [sign-up enabled](../../admin_area/settings/sign_up_restrictions.md), users can create
their own accounts by either:
- Selecting the **Register now** link on the sign-in page.
- Navigating to `https://gitlab.example.com/users/sign_up`.
![Register Tab](img/register_v13_6.png)
## Create users in Admin Area
As an admin user, you can manually create users by:
As an Admin user, you can manually create users:
1. Navigating to **Admin Area > Overview > Users** (`/admin/users` page).
1. Selecting the **New User** button.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users** (`/admin/users`).
1. Select **New user**.
You can also [create users through the API](../../../api/users.md) as an admin.
......@@ -33,9 +38,11 @@ You can also [create users through the API](../../../api/users.md) as an admin.
## Create users through authentication integrations
Users will be:
Users are:
- Automatically created upon first sign in with the [LDAP integration](../../../administration/auth/ldap/index.md).
- Created when first signing in via an [OmniAuth provider](../../../integration/omniauth.md) if the `allow_single_sign_on` setting is present.
- Created when first signing with [Group SAML](../../group/saml_sso/index.md)
- Automatically created by [SCIM](../../group/saml_sso/scim_setup.md) when the user is created in the identity provider.
- Created when first signing in using an [OmniAuth provider](../../../integration/omniauth.md) if
the `allow_single_sign_on` setting is present.
- Created when first signing with [Group SAML](../../group/saml_sso/index.md).
- Automatically created by [SCIM](../../group/saml_sso/scim_setup.md) when the user is created in
the identity provider.
doc/user/profile/account/delete_account.md
View file @ b8f13d85
......@@ -13,7 +13,7 @@ Users can be deleted from a GitLab instance, either by:
- An administrator.
NOTE:
Deleting a user will delete all projects in that user namespace.
Deleting a user deletes all projects in that user namespace.
## As a user
......@@ -28,7 +28,8 @@ As a user, to delete your own account:
As an administrator, to delete a user account:
1. Go to **Admin Area > Overview > Users**.
1. On the top bar, select **Menu >** **{admin}** **Admin**.
1. On the left sidebar, select **Overview > Users**.
1. Select a user.
1. Under the **Account** tab, select:
- **Delete user** to delete only the user but maintain their
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7