Commit 3a92ea01 authored by Suzanne Selhorn's avatar Suzanne Selhorn

Merge branch 'wtd-writing-day-2021' into 'master'

Fix future tense issues

See merge request gitlab-org/gitlab!60218
parents 9676ee18 f961eb82
......@@ -27,7 +27,7 @@ GitLab Rails application (Puma) as well as the other components, like:
### Omnibus GitLab restart
There may be times in the documentation where you will be asked to _restart_
There may be times in the documentation where you are asked to _restart_
GitLab. In that case, you need to run the following command:
```shell
......@@ -73,7 +73,7 @@ As a last resort, you can try to
### Omnibus GitLab reconfigure
There may be times in the documentation where you will be asked to _reconfigure_
There may be times in the documentation where you are asked to _reconfigure_
GitLab. Remember that this method applies only for the Omnibus packages.
Reconfigure Omnibus GitLab with:
......@@ -86,15 +86,15 @@ Reconfiguring GitLab should occur in the event that something in its
configuration (`/etc/gitlab/gitlab.rb`) has changed.
When you run this command, [Chef](https://www.chef.io/products/chef-infra/), the underlying configuration management
application that powers Omnibus GitLab, will make sure that all things like directories,
application that powers Omnibus GitLab, makes sure that all things like directories,
permissions, and services are in place and in the same shape that they were
initially shipped.
It will also restart GitLab components where needed, if any of their
It also restarts GitLab components where needed, if any of their
configuration files have changed.
If you manually edit any files in `/var/opt/gitlab` that are managed by Chef,
running reconfigure will revert the changes AND restart the services that
running reconfigure reverts the changes AND restarts the services that
depend on those files.
## Installations from source
......
......@@ -87,7 +87,7 @@ For source installations, make sure the `kerberos` gem group
1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
GitLab will now offer the `negotiate` authentication method for signing in and
GitLab now offers the `negotiate` authentication method for signing in and
HTTP Git access, enabling Git clients that support this authentication protocol
to authenticate with Kerberos tokens.
......@@ -159,7 +159,7 @@ knowledge can be a security risk.
## Link Kerberos and LDAP accounts together
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.
enabled, your users are 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
......@@ -170,7 +170,7 @@ The Kerberos realm must match the domain part of the LDAP user's Distinguished
Name. For instance, if the Kerberos realm is `AD.EXAMPLE.COM`, then the LDAP
user's Distinguished Name should end in `dc=ad,dc=example,dc=com`.
Taken together, these rules mean that linking will only work if your users'
Taken together, these rules mean that linking only works if your users'
Kerberos usernames are of the form `foo@AD.EXAMPLE.COM` and their
LDAP Distinguished Names look like `sAMAccountName=foo,dc=ad,dc=example,dc=com`.
......@@ -180,7 +180,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 will be
all domains that users may be expected to have. Any other domains are
ignored and an LDAP identity won't be linked.
**For Omnibus installations**
......@@ -236,8 +236,8 @@ 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 will
keep offering only `basic` authentication.
authentication on a different port (e.g. 8443) while the standard port offers
only `basic` authentication.
**For source installations with HTTPS**
......@@ -280,14 +280,14 @@ keep offering only `basic` authentication.
1. [Reconfigure GitLab](../administration/restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
After this change, all Git remote URLs will have to be updated to
After this change, Git remote URLs have to be updated to
`https://gitlab.example.com:8443/mygroup/myproject.git` in order to use
Kerberos ticket-based authentication.
## Upgrading from password-based to ticket-based Kerberos sign-ins
Prior to GitLab 8.10 Enterprise Edition, users had to submit their
Kerberos username and password to GitLab when signing in. We will
Kerberos username and password to GitLab when signing in. We plan to
remove support for password-based Kerberos sign-ins in a future
release, so we recommend that you upgrade to ticket-based sign-ins.
......@@ -343,14 +343,14 @@ to a larger value in [the NGINX configuration](http://nginx.org/en/docs/http/ngx
With Kerberos SPNEGO authentication, the browser is expected to send a list of
mechanisms it supports to GitLab. If it doesn't support any of the mechanisms
GitLab supports, authentication will fail with a message like this in the log:
GitLab supports, authentication fails with a message like this in the log:
```plaintext
OmniauthKerberosSpnegoController: failed to process Negotiate/Kerberos authentication: gss_accept_sec_context did not return GSS_S_COMPLETE: An unsupported mechanism was requested Unknown error
```
This is usually seen when the browser is unable to contact the Kerberos server
directly. It will fall back to an unsupported mechanism known as
directly. It falls back to an unsupported mechanism known as
[`IAKERB`](https://k5wiki.kerberos.org/wiki/Projects/IAKERB), which tries to use
the GitLab server as an intermediary to the Kerberos server.
......@@ -359,10 +359,10 @@ client machine and the Kerberos server - this is a prerequisite! Traffic may be
blocked by a firewall, or the DNS records may be incorrect.
Another failure mode occurs when the forward and reverse DNS records for the
GitLab server do not match. Often, Windows clients will work in this case, while
Linux clients will fail. They use reverse DNS while detecting the Kerberos
realm. If they get the wrong realm, then ordinary Kerberos mechanisms will fail,
so the client will fall back to attempting to negotiate `IAKERB`, leading to the
GitLab server do not match. Often, Windows clients work in this case while
Linux clients fail. They use reverse DNS while detecting the Kerberos
realm. If they get the wrong realm then ordinary Kerberos mechanisms fail,
so the client falls back to attempting to negotiate `IAKERB`, leading to the
above error message.
To fix this, ensure that the forward and reverse DNS for your GitLab server
......
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