diff --git a/docs/reference/high-availability/backup-and-restore-security-config.asciidoc b/docs/reference/high-availability/backup-and-restore-security-config.asciidoc index 47fa196d2cba7..525604a77271b 100644 --- a/docs/reference/high-availability/backup-and-restore-security-config.asciidoc +++ b/docs/reference/high-availability/backup-and-restore-security-config.asciidoc @@ -198,7 +198,7 @@ GET /_snapshot/my_backup/snapshot_1 -------------------------------------------------- // TEST[continued] -Then log into one of the node hosts, navigate to {es} installation directory, +Then log in to one of the node hosts, navigate to {es} installation directory, and follow these steps: . Add a new user with the `superuser` built-in role to the diff --git a/docs/reference/indices/flush.asciidoc b/docs/reference/indices/flush.asciidoc index b6190a27e2052..a5b20aa251a3c 100644 --- a/docs/reference/indices/flush.asciidoc +++ b/docs/reference/indices/flush.asciidoc @@ -37,7 +37,7 @@ stream, index, or index alias. Flushing a data stream or index is the process of making sure that any data that is currently only stored in the <> is also permanently stored in the Lucene index. When restarting, {es} replays any -unflushed operations from the transaction log into the Lucene index to bring it +unflushed operations from the transaction log in to the Lucene index to bring it back into the state that it was in before the restart. {es} automatically triggers flushes as needed, using heuristics that trade off the size of the unflushed transaction log against the cost of performing each flush. diff --git a/docs/reference/upgrade/reindex_upgrade.asciidoc b/docs/reference/upgrade/reindex_upgrade.asciidoc index 303b0142db207..702812a8adc10 100644 --- a/docs/reference/upgrade/reindex_upgrade.asciidoc +++ b/docs/reference/upgrade/reindex_upgrade.asciidoc @@ -82,7 +82,7 @@ bin/elasticsearch-users useradd \ -- . Use these credentials when you reindex the `.security*` index. That is to say, -use them to log into {kib} and run the Upgrade Assistant or to call the +use them to log in to {kib} and run the Upgrade Assistant or to call the reindex API. You can use your regular administration credentials to reindex the other internal indices. diff --git a/x-pack/docs/en/security/authentication/built-in-users.asciidoc b/x-pack/docs/en/security/authentication/built-in-users.asciidoc index a2fd384b6ae83..3df3338bae03f 100644 --- a/x-pack/docs/en/security/authentication/built-in-users.asciidoc +++ b/x-pack/docs/en/security/authentication/built-in-users.asciidoc @@ -84,7 +84,7 @@ Alternatively, you can set the initial passwords for the built-in users by using the *Management > Users* page in {kib} or the {ref}/security-api-change-password.html[Change Password API]. These methods are more complex. You must supply the `elastic` user and its bootstrap password to -log into {kib} or run the API. This requirement means that you cannot use the +log in to {kib} or run the API. This requirement means that you cannot use the default bootstrap password that is derived from the `keystore.seed` setting. Instead, you must explicitly set a `bootstrap.password` setting in the keystore before you start {es}. For example, the following command prompts you to enter a @@ -96,7 +96,7 @@ bin/elasticsearch-keystore add "bootstrap.password" ---------------------------------------------------- You can then start {es} and {kib} and use the `elastic` user and bootstrap -password to log into {kib} and change the passwords. Alternatively, you can +password to log in to {kib} and change the passwords. Alternatively, you can submit Change Password API requests for each built-in user. These methods are better suited for changing your passwords after the initial setup is complete, since at that point the bootstrap password is no longer required. diff --git a/x-pack/docs/en/security/authentication/saml-guide.asciidoc b/x-pack/docs/en/security/authentication/saml-guide.asciidoc index 4c0e9edc9b962..ca219d5dd1c53 100644 --- a/x-pack/docs/en/security/authentication/saml-guide.asciidoc +++ b/x-pack/docs/en/security/authentication/saml-guide.asciidoc @@ -458,7 +458,7 @@ The possible solutions to this problem are: - Advise your users to close their browser after logging out of {kib} - Enable the `force_authn` setting on your SAML realm. This setting causes the Elastic Stack to request fresh authentication from the IdP every time a user - attempts to log into {kib}. + attempts to log in to {kib}. This setting defaults to `false` because it can be a more cumbersome user experience, but it can also be an effective protection to stop users piggy-backing on existing IdP sessions. diff --git a/x-pack/docs/en/security/securing-communications/tutorial-tls-addnodes.asciidoc b/x-pack/docs/en/security/securing-communications/tutorial-tls-addnodes.asciidoc index e7c93374aa195..6604a86e96261 100644 --- a/x-pack/docs/en/security/securing-communications/tutorial-tls-addnodes.asciidoc +++ b/x-pack/docs/en/security/securing-communications/tutorial-tls-addnodes.asciidoc @@ -149,7 +149,7 @@ If you encounter errors, you can see some common problems and solutions in . Verify that your cluster now contains three nodes. + -- -For example, log into {kib} with the `elastic` built-in user. Go to +For example, log in to {kib} with the `elastic` built-in user. Go to *Dev Tools > Console* and run the {ref}/cluster-health.html[cluster health API]: [source,console]