Skip to content

G
gitlab-ce
Commit 1c1047ed authored by Craig Norris's avatar Craig Norris
Browse files
Options

Merge branch 'docs-login-signin-vale' into 'master' 

Fix login and signin grammar errors

See merge request gitlab-org/gitlab!47145
parents e08dddfb 3a6d4bd5
Hide whitespace changes
Inline Side-by-side
Showing with 239 additions and 192 deletions
doc/.vale/gitlab/Substitutions.yml
View file @ 1c1047ed
......@@ -25,5 +25,13 @@ swap:
self hosted: self-managed
self-hosted: self-managed
styleguide: style guide
to login: to log in
can login: can log in
to log-in: to log in
can log-in: can log in
to signin: to sign in
can signin: can sign in
to sign-in: to sign in
can sign-in: can sign in
x509: X.509
yaml: YAML
doc/administration/auth/crowd.md
View file @ 1c1047ed
......@@ -82,6 +82,8 @@ If you see an error message like the one below when you sign in after Crowd auth
could not authorize you from Crowd because invalid credentials
```
Please make sure the Crowd users who need to login to GitLab are authorized to [the application](#configure-a-new-crowd-application) in the step of **Authorisation**. This could be verified by try "Authentication test" for Crowd as of 2.11.
Ensure the Crowd users who need to sign in to GitLab are authorized to the
[application](#configure-a-new-crowd-application) in the **Authorisation** step.
This could be verified by trying "Authentication test" for Crowd (as of 2.11).
![Example Crowd application authorisation configuration](img/crowd_application_authorisation.png)
doc/administration/auth/ldap/index.md
View file @ 1c1047ed
......@@ -97,7 +97,8 @@ library. `start_tls` corresponds to StartTLS, not to be confused with regular TL
Normally, if you specify `simple_tls` it will be on port 636, while `start_tls` (StartTLS)
would be on port 389. `plain` also operates on port 389. Removed values: `tls` was replaced with `start_tls` and `ssl` was replaced with `simple_tls`.
LDAP users must have an email address set, regardless of whether it is used to sign-in.
LDAP users must have a set email address, regardless of whether or not it's used
to sign in.
### Example Configurations **(CORE ONLY)**
......@@ -444,10 +445,10 @@ account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
has bit 2 set.
For more information, see <https://ctovswild.com/2009/09/03/bitmask-searches-in-ldap/>
The user will be set to `ldap_blocked` state in GitLab if the above conditions
fail. This means the user will not be able to sign-in or push/pull code.
The user is set to an `ldap_blocked` state in GitLab if the previous conditions
fail. This means the user won't be able to sign in or push/pull code.
The process will also update the following user information:
The process also updates the following user information:
- Email address.
- If `sync_ssh_keys` is set, SSH public keys.
......
doc/administration/auth/ldap/ldap-troubleshooting.md
View file @ 1c1047ed
......@@ -103,16 +103,16 @@ A user can have trouble signing in for any number of reasons. To get started,
here are some questions to ask yourself:
- Does the user fall under the [configured `base`](index.md#configuration) in
LDAP? The user must fall under this `base` to sign-in.
LDAP? The user must fall under this `base` to sign in.
- Does the user pass through the [configured `user_filter`](index.md#set-up-ldap-user-filter)?
If one is not configured, this question can be ignored. If it is, then the
user must also pass through this filter to be allowed to sign-in.
user must also pass through this filter to be allowed to sign in.
- Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
If the above are both okay, the next place to look for the problem is
the logs themselves while reproducing the issue.
- Ask the user to sign-in and let it fail.
- Ask the user to sign in and let it fail.
- [Look through the output](#gitlab-logs) for any errors or other
messages about the sign-in. You may see one of the other error messages on
this page, in which case that section can help resolve the issue.
......@@ -159,7 +159,7 @@ The user should now be able to sign in.
#### Email has already been taken
A user tries to sign-in with the correct LDAP credentials, is denied access,
A user tries to sign in with the correct LDAP credentials, is denied access,
and the [production.log](../../logs.md#productionlog) shows an error that looks like this:
```plaintext
......
doc/administration/geo/replication/configuration.md
View file @ 1c1047ed
......@@ -229,8 +229,8 @@ replicating missing data from the **primary** node in a process known as **backf
Meanwhile, the **primary** node will start to notify each **secondary** node of any changes, so
that the **secondary** node can act on those notifications immediately.
Make sure the **secondary** node is running and accessible.
You can login to the **secondary** node with the same credentials as used for the **primary** node.
Be sure the _secondary_ node is running and accessible. You can sign in to the
_secondary_ node with the same credentials as were used with the _primary_ node.
### Step 4. Enabling Hashed Storage
......@@ -262,10 +262,10 @@ method to be enabled. Navigate to **Admin Area > Settings**
Your **secondary** node is now configured!
You can login to the **secondary** node with the same credentials you used for the
**primary** node. Visit the **secondary** node's **Admin Area > Geo**
(`/admin/geo/nodes`) in your browser to check if it's correctly identified as a
**secondary** Geo node and if Geo is enabled.
You can sign in to the _secondary_ node with the same credentials you used with
the _primary_ node. Visit the _secondary_ node's **Admin Area > Geo**
(`/admin/geo/nodes`) in your browser to determine if it's correctly identified
as a _secondary_ Geo node, and if Geo is enabled.
The initial replication, or 'backfill', will probably still be in progress. You
can monitor the synchronization process on each Geo node from the **primary**
......
doc/administration/operations/fast_ssh_key_lookup.md
View file @ 1c1047ed
......@@ -196,7 +196,8 @@ the database. The following instructions can be used to build OpenSSH 7.5:
yes | cp pam-ssh-conf-$timestamp /etc/pam.d/sshd
```
1. Verify the installed version. In another window, attempt to login to the server:
1. Verify the installed version. In another window, attempt to sign in to the
server:
```shell
ssh -v <your-centos-machine>
......@@ -204,7 +205,7 @@ the database. The following instructions can be used to build OpenSSH 7.5:
You should see a line that reads: "debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5"
If not, you may need to restart `sshd` (e.g. `systemctl restart sshd.service`).
If not, you may need to restart `sshd` (for example, `systemctl restart sshd.service`).
1. *IMPORTANT!* Open a new SSH session to your server before exiting to make
sure everything is working! If you need to downgrade, simple install the
......
doc/administration/packages/container_registry.md
View file @ 1c1047ed
......@@ -170,7 +170,7 @@ If your certificate provider provides the CA Bundle certificates, append them to
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
Users should now be able to login to the Container Registry with their GitLab
Users should now be able to sign in to the Container Registry with their GitLab
credentials using:
```shell
......@@ -234,7 +234,7 @@ registry_nginx['ssl_certificate_key'] = "/etc/gitlab/ssl/certificate.key"
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
1. Make the relevant changes in NGINX as well (domain, port, TLS certificates path).
Users should now be able to login to the Container Registry using their GitLab
Users should now be able to sign in to the Container Registry using their GitLab
credentials:
```shell
......@@ -1234,8 +1234,8 @@ This will launch the Docker daemon and proxy all connections through mitmproxy.
#### Running the Docker client
Now that we have mitmproxy and Docker running, we can attempt to login and push
a container image. You may need to run as root to do this. For example:
Now that we have mitmproxy and Docker running, we can attempt to sign in and
push a container image. You may need to run as root to do this. For example:
```shell
docker login s3-testing.myregistry.com:5050
......
doc/administration/postgresql/replication_and_failover.md
View file @ 1c1047ed
......@@ -579,18 +579,19 @@ in the Troubleshooting section before proceeding.
### Ensure GitLab is running
At this point, your GitLab instance should be up and running. Verify you are
able to login, and create issues and merge requests. If you have troubles check
At this point, your GitLab instance should be up and running. Verify you're able
to sign in, and create issues and merge requests. If you encounter issues, see
the [Troubleshooting section](#troubleshooting).
## Example configuration
Here we'll show you some fully expanded example configurations.
This section describes several fully expanded example configurations.
### Example recommended setup
This example uses 3 Consul servers, 3 PgBouncer servers (with associated internal load balancer),
3 PostgreSQL servers, and 1 application node.
This example uses three Consul servers, three PgBouncer servers (with an
associated internal load balancer), three PostgreSQL servers, and one
application node.
We start with all servers on the same 10.6.0.0/16 private network range, they
can connect to each freely other on those addresses.
......
doc/ci/docker/using_docker_images.md
View file @ 1c1047ed
......@@ -561,10 +561,11 @@ See below for examples of each.
#### Determining your `DOCKER_AUTH_CONFIG` data
As an example, let's assume that you want to use the `registry.example.com:5000/private/image:latest`
image which is private and requires you to login into a private container registry.
As an example, let's assume you want to use the `registry.example.com:5000/private/image:latest`
image, which is private and requires you to sign in to a private container
registry.
Let's also assume that these are the login credentials:
Let's also assume that these are the sign-in credentials:
| Key | Value |
|:---------|:----------------------------|
......@@ -572,9 +573,9 @@ Let's also assume that these are the login credentials:
| username | `my_username` |
| password | `my_password` |
There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
Use one of the following methods to determine the value of `DOCKER_AUTH_CONFIG`:
- **First way -** Do a `docker login` on your local machine:
- Do a `docker login` on your local machine:
```shell
docker login registry.example.com:5000 --username my_username --password my_password
......@@ -589,12 +590,11 @@ There are two ways to determine the value of `DOCKER_AUTH_CONFIG`:
docker logout registry.example.com:5000
```
- **Second way -** In some setups, it's possible that Docker client
uses the available system key store to store the result of `docker
login`. In that case, it's impossible to read `~/.docker/config.json`,
so you need to prepare the required base64-encoded version of
`${username}:${password}` and create the Docker configuration JSON manually.
Open a terminal and execute the following command:
- In some setups, it's possible that Docker client uses the available system key
store to store the result of `docker login`. In that case, it's impossible to
read `~/.docker/config.json`, so you need to prepare the required
base64-encoded version of `${username}:${password}` and create the Docker
configuration JSON manually. Open a terminal and execute the following command:
```shell
# The use of "-n" - prevents encoding a newline in the password.
......
doc/ci/examples/deploy_spring_boot_to_cloud_foundry/index.md
View file @ 1c1047ed
......@@ -103,27 +103,27 @@ Hub](https://hub.docker.com/). We've also added the [`only`
clause](../../yaml/README.md#onlyexcept-basic)
to ensure our deployments only happen when we push to the master branch.
Now, since the steps defined in `.gitlab-ci.yml` require credentials to login
to CF, you'll need to add your CF credentials as [environment
variables](../../variables/README.md#predefined-environment-variables)
on GitLab CI/CD. To set the environment variables, navigate to your project's
**Settings > CI/CD** and expand **Variables**. Name the variables
Because the steps defined in `.gitlab-ci.yml` require credentials to sign in to
CF, you'll need to add your CF credentials as
[environment variables](../../variables/README.md#predefined-environment-variables)
in GitLab CI/CD. To set the environment variables, navigate to your project's
**Settings > CI/CD**, and then expand **Variables**. Name the variables
`CF_USERNAME` and `CF_PASSWORD` and set them to the correct values.
![Variable Settings in GitLab](img/cloud_foundry_variables.png)
Once set up, GitLab CI/CD will deploy your app to CF at every push to your
repository's default branch. To see the build logs or watch your builds running
live, navigate to **CI/CD > Pipelines**.
After set up, GitLab CI/CD deploys your app to CF at every push to your
repository's default branch. To review the build logs or watch your builds
running live, navigate to **CI/CD > Pipelines**.
CAUTION: **Caution:**
It is considered best practice for security to create a separate deploy
user for your application and add its credentials to GitLab instead of using
a developer's credentials.
It's considered best practice for security to create a separate deploy user for
your application and add its credentials to GitLab instead of using a
developer's credentials.
To start a manual deployment in GitLab go to **CI/CD > Pipelines** then click
on **Run Pipeline**. After the app is finished deploying it will display the URL
of your application in the logs for the `production` job like:
on **Run Pipeline**. After the app is finished deploying, it will display the
URL of your application in the logs for the `production` job like:
```shell
requested state: started
......
doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
View file @ 1c1047ed
......@@ -238,7 +238,11 @@ run: ./services/tunnel_gitlab: (pid 2650) 10875s, normally down; run: log: (pid
run: ./services/tunnel_registry: (pid 2651) 10875s, normally down; run: log: (pid 65155) 177993s
```
Also, restarting Docker and then, on the Terminal, issue the command `docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use the GDK credentials to login. Note that the Registry port and GDK port are not the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command outputs the port of the Registry:
Also, restarting Docker and then, on the Terminal, issue the command
`docker login https://[YOUR-REGISTRY-PORT].qa-tunnel.gitlab.info:443` and use
the GDK credentials to sign in. Note that the Registry port and GDK port aren't
the same. When configuring Auto DevOps in GDK, the `gdk reconfigure` command
outputs the port of the Registry:
```shell
*********************************************
......
doc/install/azure/index.md
View file @ 1c1047ed
......@@ -347,8 +347,8 @@ connect to it using SSH ([Secure Shell](https://en.wikipedia.org/wiki/Secure_She
If you're running Windows, you'll need to connect using [PuTTY](https://www.putty.org) or an equivalent Windows SSH client.
If you're running Linux or macOS, then you already have an SSH client installed.
Remember that you will need to login with the username and password you specified
[when you created](#basics) your Azure VM.
Remember to sign in with the username and password you specified when you
[created your Azure VM](#basics).
If you need to reset your VM password, read
[how to reset SSH credentials for a user on an Azure VM](https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/troubleshoot-ssh-connection).
......@@ -375,20 +375,20 @@ read on [using PuTTY in Windows](https://mediatemple.net/community/products/dv/2
### Updating GitLab
Once you've logged in via SSH, enter the following command to update GitLab to the latest
version:
After signing in by using SSH, enter the following command to update GitLab to
the latest version:
```shell
sudo apt-get update && sudo apt-get install gitlab-ce
```
This command will update GitLab and its associated components to the latest versions, so it will
take a little time to complete. You'll see various update tasks being completed in your SSH
terminal window:
This command updates GitLab and its associated components to the latest versions,
so it will take a little time to complete. You'll see various update tasks being
completed in your SSH terminal window:
![GitLab updating](img/gitlab-ssh-update-in-progress.png)
Once the update process has completed, you'll see a message like this:
After the update process is complete, you'll see a message like this:
```plaintext
Upgrade complete! If your GitLab server is misbehaving try running
......
doc/install/openshift_and_gitlab/index.md
View file @ 1c1047ed
......@@ -183,9 +183,9 @@ Using the all-in-one VM gives you the ability to test OpenShift whenever you
want. That means you get to play with it, shutdown the VM, and pick up where
you left off.
Sometimes though, you may encounter some issues, like OpenShift not running
when booting up the VM. The web UI may not responding or you may see issues
when trying to login with `oc`, like:
Occasionally, you may encounter issues, like OpenShift not running when booting
up the VM. The web UI may not respond, or you may see issues when trying to sign
in with `oc`, like:
```plaintext
The connection to the server 10.2.2.2:8443 was refused - did you specify the right host or port?
......@@ -213,8 +213,7 @@ In that case, the OpenShift service might not be running, so in order to fix it:
systemctl status openshift -l
```
Now you will be able to login using `oc` (like we did before) and visit the web
console.
You can now sign in by using `oc` (like we did before) and visit the web console.
## Deploy GitLab
......@@ -497,14 +496,13 @@ oc adm policy add-scc-to-user anyuid system:serviceaccount:gitlab:gitlab-ce-user
## Conclusion
By now, you should have an understanding of the basic OpenShift Origin concepts
and a sense of how things work using the web console or the CLI.
You should now have an understanding of the basic OpenShift Origin concepts, and
a sense of how things work using the web console or the CLI.
GitLab was hard to install in previous versions of OpenShift,
but now that belongs to the past. Upload a template, create a project, add an
application and you are done. You are ready to login to your new GitLab instance.
Upload a template, create a project, add an application, and you're done. You're
ready to sign in to your new GitLab instance.
And remember that in this tutorial we just scratched the surface of what Origin
is capable of. As always, you can refer to the detailed
[documentation](https://docs.okd.io) to learn more about deploying your own OpenShift
PaaS and managing your applications with the ease of containers.
Remember that this tutorial doesn't address all that Origin is capable of. As
always, refer to the detailed [documentation](https://docs.okd.io) to learn more
about deploying your own OpenShift PaaS and managing your applications with
containers.
doc/integration/github.md
View file @ 1c1047ed
......@@ -6,7 +6,9 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Integrate your GitLab instance with GitHub
You can integrate your GitLab instance with GitHub.com as well as GitHub Enterprise to enable users to import projects from GitHub and/or to login to your GitLab instance with your GitHub account.
You can integrate your GitLab instance with GitHub.com and GitHub Enterprise to
enable users to import projects from GitHub or sign in to your GitLab instance
with your GitHub account.
## Enabling GitHub OAuth
......@@ -24,11 +26,11 @@ See [Initial OmniAuth Configuration](omniauth.md#initial-omniauth-configuration)
Once you have configured the GitHub provider, you'll need the following information, which you'll need to substitute in the GitLab configuration file, in the steps shown next.
| Setting from GitHub | Substitute in the GitLab configuration file | Description |
|:---------------------|:-----------------------------------------------|:------------|
| Client ID | `YOUR_APP_ID` | OAuth 2 Client ID |
| Client Secret | `YOUR_APP_SECRET` | OAuth 2 Client Secret |
| URL | `https://github.example.com/` | GitHub Deployment URL |
| Setting from GitHub | Substitute in the GitLab configuration file | Description |
|:---------------------|:---------------------------------------------|:------------|
| Client ID | `YOUR_APP_ID` | OAuth 2 Client ID |
| Client Secret | `YOUR_APP_SECRET` | OAuth 2 Client Secret |
| URL | `https://github.example.com/` | GitHub Deployment URL |
Follow these steps to incorporate the GitHub OAuth 2 app in your GitLab server:
......
doc/integration/kerberos.md
View file @ 1c1047ed
......@@ -96,18 +96,17 @@ to authenticate with Kerberos tokens.
The Administrative user can navigate to **Admin > Users > Example User > Identities**
and attach a Kerberos account. Existing GitLab users can go to **Profile > Account**
and attach a Kerberos account. If you want to allow users without a GitLab
account to login, you should enable the option `allow_single_sign_on` as
described in the [Configure GitLab](#configure-gitlab) section. Then, the first
time a user signs in with Kerberos credentials, GitLab will create a new GitLab
user associated with the email, which is built from the Kerberos username and
realm. User accounts will be created automatically when authentication was
successful.
account to sign in, enable the `allow_single_sign_on` option, as described in the
[Configure GitLab](#configure-gitlab) section. The first time a user signs in
with Kerberos credentials, GitLab will create a new GitLab user associated with
the email, which is built from the Kerberos username and realm. User accounts are
created after successful authentications.
## Linking Kerberos and LDAP accounts together
If your users log in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
enabled, then your users will be automatically linked to their LDAP accounts on
first login. For this to work, some prerequisites must be met:
If your users sign in with Kerberos, but you also have [LDAP integration](../administration/auth/ldap/index.md)
enabled, your users will be linked to their LDAP accounts on their first sign-in.
For this to work, some prerequisites must be met:
The Kerberos username must match the LDAP user's UID. You can choose which LDAP
attribute is used as the UID in GitLab's [LDAP configuration](../administration/auth/ldap/index.md#configuration)
......@@ -125,10 +124,10 @@ LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/9962) in GitLab 13.5.
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 will be ignored and an LDAP identity will not be linked.
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 will be
ignored and an LDAP identity won't be linked.
**For Omnibus installations**
......
doc/integration/omniauth.md
View file @ 1c1047ed
......@@ -88,8 +88,8 @@ To change these settings:
```ruby
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# This allows users to sign in without having a user account first. Define the allowed providers
# using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml', 'twitter']
gitlab_rails['omniauth_auto_link_ldap_user'] = true
......@@ -111,13 +111,13 @@ To change these settings:
```yaml
## OmniAuth settings
omniauth:
# Allow login via Twitter, Google, etc. using OmniAuth providers
# Allow sign-in by using Twitter, Google, etc. using OmniAuth providers
# Versions prior to 11.4 require this to be set to true
# enabled: true
# CAUTION!
# This allows users to login without having a user account first. Define the allowed providers
# using an array, e.g. ["saml", "twitter"], or as true/false to allow all providers or none.
# This allows users to sign in without having a user account first. Define the allowed providers
# using an array, for example, ["saml", "twitter"], or as true/false to allow all providers or none.
# User accounts will be created automatically when authentication was successful.
allow_single_sign_on: ["saml", "twitter"]
......@@ -177,9 +177,9 @@ like `google_oauth2` for Google. Refer to the examples for the full names of the
supported providers.
NOTE: **Note:**
If you decide to remove an OmniAuth provider from the external providers list
you will need to manually update the users that use this method to login, if you
want their accounts to be upgraded to full internal accounts.
If you decide to remove an OmniAuth provider from the external providers list,
you must manually update the users that use this method to sign in if you want
their accounts to be upgraded to full internal accounts.
**For Omnibus installations**
......@@ -302,13 +302,13 @@ omniauth:
## Bypassing two factor authentication
Starting with GitLab 12.3, this allows users to login with the specified
providers without two factor authentication.
In GitLab 12.3 or later, users can sign in with specified providers _without_
using two factor authentication.
Define the allowed providers using an array, e.g. `["twitter", 'google_oauth2']`, or as
`true`/`false` to allow all providers or none. This option should only be configured
for providers which already have two factor authentication (default: false).
This configuration dose not apply to SAML.
Define the allowed providers using an array (for example, `["twitter", 'google_oauth2']`),
or as `true` or `false` to allow all providers (or none). This option should be
configured only for providers which already have two factor authentication
(default: false). This configuration doesn't apply to SAML.
```ruby
gitlab_rails['omniauth_allow_bypass_two_factor'] = ['twitter', 'google_oauth2']
......@@ -323,13 +323,12 @@ omniauth:
## Automatically sign in with provider
You can add the `auto_sign_in_with_provider` setting to your
GitLab configuration to automatically redirect login requests
to your OmniAuth provider for authentication, thus removing the need to click a button
before actually signing in.
You can add the `auto_sign_in_with_provider` setting to your GitLab
configuration to redirect login requests to your OmniAuth provider for
authentication, removing the need to click a button before actually signing in.
For example, when using the Azure integration, you would set the following
to enable auto sign in.
For example, when using the Azure integration, set the following to enable auto
sign-in:
For Omnibus package:
......@@ -344,13 +343,15 @@ omniauth:
auto_sign_in_with_provider: azure_oauth2
```
Please keep in mind that every sign in attempt will be redirected to the OmniAuth provider,
so you will not be able to sign in using local credentials. Make sure that at least one
of the OmniAuth users has admin permissions.
Keep in mind that every sign-in attempt will be redirected to the OmniAuth
provider; you won't be able to sign in using local credentials. Ensure at least
one of the OmniAuth users has admin permissions.
You may also bypass the auto signin feature by browsing to
You may also bypass the auto sign in feature by browsing to
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
## Passwords for users created via OmniAuth
The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md) guide provides an overview of how GitLab generates and sets passwords for users created via OmniAuth.
The [Generated passwords for users created through integrated authentication](../security/passwords_for_integrated_authentication_methods.md)
guide provides an overview about how GitLab generates and sets passwords for
users created with OmniAuth.
doc/integration/saml.md
View file @ 1c1047ed
......@@ -369,18 +369,18 @@ omniauth:
auto_sign_in_with_provider: saml
```
Please keep in mind that every sign in attempt will be redirected to the SAML server,
so you will not be able to sign in using local credentials. Make sure that at least one
of the SAML users has admin permissions.
Keep in mind that every sign in attempt will be redirected to the SAML server;
you won't be able to sign in using local credentials. Ensure at least one of the
SAML users has admin permissions.
You may also bypass the auto signin feature by browsing to
You may also bypass the auto sign-in feature by browsing to
`https://gitlab.example.com/users/sign_in?auto_sign_in=false`.
### `attribute_statements`
NOTE: **Note:**
This setting should only be used to map attributes that are part of the
OmniAuth `info` hash schema.
This setting should be used only to map attributes that are part of the OmniAuth
`info` hash schema.
`attribute_statements` is used to map Attribute Names in a SAMLResponse to entries
in the OmniAuth [`info` hash](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema#schema-10-and-later).
......@@ -541,9 +541,14 @@ This integration uses the `certificate` and `private_key` settings for both asse
## Request signing (optional)
Another optional configuration is to sign SAML authentication requests. GitLab SAML Requests uses the SAML redirect binding so this is not necessary, unlike the SAML POST binding where signing is required to prevent intermediaries tampering with the requests.
Another optional configuration is to sign SAML authentication requests. GitLab
SAML Requests use the SAML redirect binding, so this isn't necessary (unlike the
SAML POST binding, where signing is required to prevent intermediaries from
tampering with the requests).
In order to sign, you need to create a private key and public certificate pair for your GitLab instance to use for SAML. The settings related to signing can be set in the `security` section of the configuration.
To sign, you need to create a private key and public certificate pair for your
GitLab instance to use for SAML. The settings for signing can be set in the
`security` section of the configuration.
For example:
......@@ -648,13 +653,14 @@ If you only need a SAML provider for testing, a [quick start guide to start a Do
### 500 error after login
If you see a "500 error" in GitLab when you are redirected back from the SAML sign in page,
this likely indicates that GitLab could not get the email address for the SAML user.
If you see a "500 error" in GitLab when you are redirected back from the SAML
sign-in page, this likely indicates that GitLab couldn't get the email address
for the SAML user.
Make sure the IdP provides a claim containing the user's email address, using claim name
`email` or `mail`.
Ensure the IdP provides a claim containing the user's email address, using the
claim name `email` or `mail`.
### Redirect back to login screen with no evident error
### Redirect back to the login screen with no evident error
If after signing in into your SAML server you are redirected back to the sign in page and
no error is displayed, check your `production.log` file. It will most likely contain the
......
doc/integration/vault.md
View file @ 1c1047ed
......@@ -106,13 +106,17 @@ The following assumes you already have Vault installed and running.
vault login -method=oidc port=8250 role=demo
```
Here is a short explanation of what this command does:
Here's a short explanation of what this command does:
1. In the **Write the OIDC Role Config** (step 4), we created a role called `demo`. We set `role=demo` so Vault knows which configuration we'd like to login in with.
1. In the **Write the OIDC Role Config** (step 4), we created a role called
`demo`. We set `role=demo` so Vault knows which configuration we'd like to
sign in with.
1. To set Vault to use the `OIDC` sign-in method, we set `-method=oidc`.
1. To set the port that GitLab should redirect to, we set `port=8250` or another port number that matches the port given to GitLab when listing [Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
1. To set the port that GitLab should redirect to, we set `port=8250` or
another port number that matches the port given to GitLab when listing
[Redirect URIs](https://www.vaultproject.io/docs/auth/jwt#redirect-uris).
Once you run the command above, it will present a link in the terminal.
After running the command, it will present a link in the terminal.
Click the link in the terminal and a tab will open in the browser confirming you're signed into Vault via OIDC:
![Signed into Vault via OIDC](img/signed_into_vault_via_oidc_v12_6.png)
......
doc/security/reset_user_password.md
View file @ 1c1047ed
......@@ -56,14 +56,15 @@ Don't forget to save the changes.
user.save!
```
Exit the console and try to login with your new password.
Exit the console, and then try to sign in with your new password.
NOTE: **Note:**
Passwords can also be reset via the [Users API](../api/users.md#user-modification)
You can also reset passwords by using the [Users API](../api/users.md#user-modification).
### Reset your root password
The steps described above can also be used to reset the root password. But first, identify the root user, with an `id` of `1`. To do so, run the following command:
The previously described steps can also be used to reset the root password. First,
identify the root user, with an `id` of `1`. To do so, run the following command:
```shell
user = User.where(id: 1).first
......
doc/security/two_factor_authentication.md
View file @ 1c1047ed
......@@ -8,22 +8,22 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Enforce Two-factor Authentication (2FA)
Two-factor Authentication (2FA) provides an additional level of security to your
users' GitLab account. Once enabled, in addition to supplying their username and
password to login, they'll be prompted for a code generated by an application on
their phone.
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
application on their phone.
You can read more about it here:
[Two-factor Authentication (2FA)](../user/profile/account/two_factor_authentication.md)
## Enforcing 2FA for all users
Users on GitLab, can enable it without any admin's intervention. If you want to
enforce everyone to set up 2FA, you can choose from two different ways:
Users on GitLab can enable it without any administrator's intervention. If you
want to enforce everyone to set up 2FA, you can choose from two different ways:
- Enforce on next login.
- Suggest on next login, but allow a grace period before enforcing.
After the configured grace period has elapsed, users will be able to log in but
After the configured grace period has elapsed, users will be able to sign in but
won't be able to leave the 2FA configuration area at `/profile/two_factor_auth`.
To enable 2FA for all users:
......@@ -32,15 +32,17 @@ To enable 2FA for all users:
(`/admin/application_settings/general`).
1. Expand the **Sign-in restrictions** section, where you can configure both.
If you want 2FA enforcement to take effect on next login, change the grace
period to `0`.
If you want 2FA enforcement to take effect during the next sign-in attempt,
change the grace period to `0`.
## Enforcing 2FA for all users in a group
If you want to enforce 2FA only for certain groups, you can:
1. Enable it in the group's **Settings > General** page. Navigate to **Permissions, LFS, 2FA > Two-factor authentication**.
You can then check the **Require all users in this group to setup Two-factor authentication** option.
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.
To change this setting, you need to be administrator or owner of the group.
......
doc/system_hooks/system_hooks.md
View file @ 1c1047ed
......@@ -31,11 +31,18 @@ Your GitLab instance can perform HTTP POST requests on the following events:
- `user_update_for_group`
- `user_update_for_team`
The triggers for most of these are self-explanatory, but `project_update` and `project_rename` deserve some clarification: `project_update` is fired any time an attribute of a project is changed (name, description, tags, etc.) *unless* the `path` attribute is also changed. In that case, a `project_rename` is triggered instead (so that, for instance, if all you care about is the repository URL, you can just listen for `project_rename`).
`user_failed_login` is sent whenever a **blocked** user attempts to login and denied access.
System hooks can be used, e.g. for logging or changing information in a LDAP server.
The triggers for most of these are self-explanatory, but `project_update` and
`project_rename` deserve some clarification: `project_update` is fired any time
an attribute of a project is changed (including name, description, and tags)
_unless_ the `path` attribute is also changed. In that case, a `project_rename`
is triggered instead (so that, for instance, if all you care about is the
repository URL, you can just listen for `project_rename`).
`user_failed_login` is sent whenever a _blocked_ user attempts to sign in and is
denied access.
System hooks can be used, for example, for logging or changing information in an
LDAP server.
NOTE: **Note:**
We follow the same structure and deprecations as [Webhooks](../user/project/integrations/webhooks.md)
......
doc/user/admin_area/settings/index.md
View file @ 1c1047ed
......@@ -23,7 +23,7 @@ Access the default page for admin area settings by navigating to **Admin Area >
| [Account and limit](account_and_limit_settings.md) **(STARTER)** | Set projects and maximum size limits, session duration, user options, and check feature availability for namespace plan. |
| [Diff limits](../diff_limits.md) | Diff content limits. |
| [Sign-up restrictions](sign_up_restrictions.md) | Configure the way a user creates a new account. |
| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign-in. Enable mandatory two-factor authentication. |
| [Sign in restrictions](sign_in_restrictions.md) | Set requirements for a user to sign in. Enable mandatory two-factor authentication. |
| [Terms of Service and Privacy Policy](terms.md) | Include a Terms of Service agreement and Privacy Policy that all users must accept. |
| [External Authentication](external_authorization.md#configuration) | External Classification Policy Authorization |
| [Web terminal](../../../administration/integration/terminal.md#limiting-websocket-connection-time) | Set max session time for web terminal. |
......
doc/user/profile/account/two_factor_authentication.md
View file @ 1c1047ed
......@@ -8,12 +8,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
# Two-factor authentication
Two-factor authentication (2FA) provides an additional level of security to your
GitLab account. Once enabled, in addition to supplying your username and
password to login, you'll be prompted for a code generated by your one time password
authenticator. For example, a password manager on one of your devices.
GitLab account. After being enabled, in addition to supplying your username and
password to sign in, you'll be prompted for a code generated by your one-time
password authenticator (for example, a password manager on one of your devices).
By enabling 2FA, the only way someone other than you can log into your account
is to know your username and password *and* have access to your one time password secret.
By enabling 2FA, the only way someone other than you can sign in to your account
is to know your username and password _and_ have access to your one-time
password secret.
## Overview
......@@ -41,10 +42,10 @@ or a U2F / WebAuthn device.
To enable 2FA:
1. **In GitLab:**
1. Log in to your GitLab account.
1. Sign in to your GitLab account.
1. Go to your [**Profile settings**](../index.md#profile-settings).
1. Go to **Account**.
1. Click **Enable Two-factor Authentication**.
1. Select **Enable Two-factor Authentication**.
1. **On your device (usually your phone):**
1. Install a compatible application, like:
- [Authenticator](https://mattrubin.me/authenticator/): open source app for iOS devices.
......@@ -59,11 +60,11 @@ To enable 2FA:
1. **In GitLab:**
1. Enter the six-digit pin number from the entry on your device into the **Pin
code** field.
1. Click **Submit**.
1. Select **Submit**.
If the pin you entered was correct, you'll see a message indicating that
two-factor authentication has been enabled, and you'll be presented with a list
of [recovery codes](#recovery-codes). Make sure you download them and keep them
of [recovery codes](#recovery-codes). Be sure to download them and keep them
in a safe place.
### One-time password via FortiAuthenticator
......
doc/user/project/deploy_tokens/index.md
View file @ 1c1047ed
......@@ -13,57 +13,61 @@ type: howto
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29280) from **Settings > CI / CD** in GitLab 12.10.1.
> - [Added package registry scopes](https://gitlab.com/gitlab-org/gitlab/-/issues/213566) in GitLab 13.0.
Deploy tokens allow you to download (`git clone`) or push and pull packages and container registry images of a project without having a user and a password.
Deploy tokens allow you to download (`git clone`) or push and pull packages and
container registry images of a project without having a user and a password.
Deploy tokens can be managed by [maintainers only](../../permissions.md).
If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys) instead.
If you have a key pair, you might want to use [deploy keys](../../../ssh/README.md#deploy-keys)
instead.
## Creating a Deploy Token
You can create as many deploy tokens as you like from the settings of your project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
You can create as many deploy tokens as you need from the settings of your
project. Alternatively, you can also create [group-scoped deploy tokens](#group-deploy-token).
1. Log in to your GitLab account.
1. Sign in to your GitLab account.
1. Go to the project (or group) you want to create Deploy Tokens for.
1. Go to **Settings > Repository**.
1. Click on "Expand" on **Deploy Tokens** section.
1. Choose a name, expiry date (optional), and username (optional) for the token.
1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
1. Click on **Create deploy token**.
1. Save the deploy token somewhere safe. Once you leave or refresh
1. Select **Create deploy token**.
1. Save the deploy token somewhere safe. After you leave or refresh
the page, **you won't be able to access it again**.
![Personal access tokens page](img/deploy_tokens.png)
## Deploy token expiration
Deploy tokens expire on the date you define, at midnight UTC.
Deploy tokens expire at midnight UTC on the date you define.
## Revoking a deploy token
At any time, you can revoke any deploy token by just clicking the
respective **Revoke** button under the 'Active deploy tokens' area.
At any time, you can revoke any deploy token by just clicking the respective
**Revoke** button under the 'Active deploy tokens' area.
## Limiting scopes of a deploy token
Deploy tokens can be created with different scopes that allow various
actions that a given token can perform. The available scopes are depicted in
the following table along with GitLab version it was introduced in.
Deploy tokens can be created with different scopes that allow various actions
that a given token can perform. The available scopes are depicted in the
following table along with GitLab version it was introduced in:
| Scope | Description | Introduced in GitLab Version |
| ----- | ----------- | ------ |
| `read_repository` | Allows read-access to the repository through `git clone` | 10.7 |
| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
| `read_package_registry` | Allows read access to the package registry. | 13.0 |
| Scope | Description | Introduced in GitLab Version |
|--------------------------|-------------|------------------------------|
| `read_repository` | Allows read-access to the repository through `git clone` | 10.7 |
| `read_registry` | Allows read-access to [container registry](../../packages/container_registry/index.md) images if a project is private and authorization is required. | 10.7 |
| `write_registry` | Allows write-access (push) to [container registry](../../packages/container_registry/index.md). | 12.10 |
| `read_package_registry` | Allows read access to the package registry. | 13.0 |
| `write_package_registry` | Allows write access to the package registry. | 13.0 |
## Deploy token custom username
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/29639) in GitLab 12.1.
The default username format is `gitlab+deploy-token-#{n}`. Some tools or platforms may not support this format,
in such case you can specify custom username to be used when creating the deploy token.
The default username format is `gitlab+deploy-token-#{n}`. Some tools or
platforms may not support this format; in this case you can specify a custom
username to be used when creating the deploy token.
## Usage
......@@ -87,13 +91,13 @@ To read the container registry images, you'll need to:
1. Create a Deploy Token with `read_registry` as a scope.
1. Take note of your `username` and `token`.
1. Log in to GitLab’s Container Registry using the deploy token:
1. Sign in to GitLab’s Container Registry using the deploy token:
```shell
docker login -u <username> -p <deploy_token> registry.example.com
```
Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
Replace `<username>` and `<deploy_token>` with the proper values. You can now
pull images from your Container Registry.
### Push Container Registry images
......@@ -104,13 +108,13 @@ To push the container registry images, you'll need to:
1. Create a Deploy Token with `write_registry` as a scope.
1. Take note of your `username` and `token`.
1. Log in to GitLab’s Container Registry using the deploy token:
1. Sign in to GitLab’s Container Registry using the deploy token:
```shell
docker login -u <username> -p <deploy_token> registry.example.com
```
Just replace `<username>` and `<deploy_token>` with the proper values. Then you can simply
Replace `<username>` and `<deploy_token>` with the proper values. You can now
push images to your Container Registry.
### Read or pull packages
......@@ -121,7 +125,8 @@ To pull packages in the GitLab package registry, you'll need to:
1. Create a Deploy Token with `read_package_registry` as a scope.
1. Take note of your `username` and `token`.
1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
1. For the [package type of your choice](../../packages/index.md), follow the
authentication instructions for deploy tokens.
### Push or upload packages
......@@ -131,7 +136,8 @@ To upload packages in the GitLab package registry, you'll need to:
1. Create a Deploy Token with `write_package_registry` as a scope.
1. Take note of your `username` and `token`.
1. For the [package type of your choice](../../packages/index.md), follow the authentication instructions for deploy tokens.
1. For the [package type of your choice](../../packages/index.md), follow the
authentication instructions for deploy tokens.
### Group Deploy Token
......@@ -158,10 +164,10 @@ apply consistently when cloning the repository of related projects.
There's a special case when it comes to Deploy Tokens. If a user creates one
named `gitlab-deploy-token`, the username and token of the Deploy Token will be
automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER` and
`CI_DEPLOY_PASSWORD`, respectively.
automatically exposed to the CI/CD jobs as environment variables: `CI_DEPLOY_USER`
and `CI_DEPLOY_PASSWORD`, respectively.
After you create the token, you can login to the Container Registry using
After you create the token, you can sign in to the Container Registry by using
those variables:
```shell
......@@ -169,4 +175,7 @@ docker login -u $CI_DEPLOY_USER -p $CI_DEPLOY_PASSWORD $CI_REGISTRY
```
NOTE: **Note:**
The special handling for the `gitlab-deploy-token` deploy token is not currently implemented for group deploy tokens. For the deploy token to be available for CI/CD jobs, it must be created at the project level. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014) for details.
The special handling for the `gitlab-deploy-token` deploy token is not currently
implemented for group deploy tokens. For the deploy token to be available for
CI/CD jobs, it must be created at the project level. For details, see
[this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214014).
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