[7.0][DOCS] Copies security source files from stack-docs

x-pack/docs/en/security/auditing/auditing-search-queries.asciidoc

@@ -1,5 +1,4 @@
 [role="xpack"]
-[testenv="gold+"]
 [[auditing-search-queries]]
 === Auditing search queries
 

x-pack/docs/en/security/authentication/active-directory-realm.asciidoc

@@ -0,0 +1,80 @@
+[role="xpack"]
+[[active-directory-realm]]
+=== Active Directory user authentication
+
+You can configure {stack} {security-features} to communicate with Active
+Directory to authenticate users. To integrate with Active Directory, you
+configure an `active_directory` realm and map Active Directory users and groups
+to roles in the <<mapping-roles, role mapping file>>.
+
+See {ref}/configuring-ad-realm.html[Configuring an active directory realm].
+
+The {security-features} use LDAP to communicate with Active Directory, so
+`active_directory` realms are similar to <<ldap-realm, `ldap` realms>>. Like
+LDAP directories, Active Directory stores users and groups hierarchically. The
+directory's hierarchy is built from containers such as the _organizational unit_
+(`ou`), _organization_ (`o`), and _domain controller_ (`dc`).
+
+The path to an entry is a _Distinguished Name_ (DN) that uniquely identifies a
+user or group. User and group names typically have attributes such as a
+_common name_ (`cn`) or _unique ID_ (`uid`). A DN is specified as a string, for
+example `"cn=admin,dc=example,dc=com"` (white spaces are ignored).
+
+The {security-features} supports only Active Directory security groups. You
+cannot map distribution groups to roles.
+
+NOTE: When you use Active Directory for authentication, the username entered by
+      the user is expected to match the `sAMAccountName` or `userPrincipalName`,
+      not the common name.
+
+The Active Directory realm authenticates users using an LDAP bind request. After
+authenticating the user, the realm then searches to find the user's entry in
+Active Directory. Once the user has been found, the Active Directory realm then
+retrieves the user's group memberships from the `tokenGroups` attribute on the
+user's entry in Active Directory.
+
+[[ad-load-balancing]]
+==== Load balancing and failover
+The `load_balance.type` setting can be used at the realm level to configure how
+the {security-features} should interact with multiple Active Directory servers.
+Two modes of operation are supported: failover and load balancing.
+
+See
+{ref}/security-settings.html#load-balancing[Load balancing and failover settings].
+
+[[ad-settings]]
+==== Active Directory realm settings
+
+See
+{ref}/security-settings.html#ref-ad-settings[Active Directory realm settings].
+
+[[mapping-roles-ad]]
+==== Mapping Active Directory users and groups to roles
+
+See {ref}/configuring-ad-realm.html[Configuring an Active Directory realm]. 
+
+[[ad-user-metadata]]
+==== User metadata in Active Directory realms
+When a user is authenticated via an Active Directory realm, the following
+properties are populated in the user's _metadata_:
+
+|=======================
+| Field               | Description
+| `ldap_dn`           | The distinguished name of the user.
+| `ldap_groups`       | The distinguished name of each of the groups that were
+                        resolved for the user (regardless of whether those
+                        groups were mapped to a role).
+|=======================
+
+This metadata is returned in the 
+{ref}/security-api-authenticate.html[authenticate API] and can be used with
+<<templating-role-query, templated queries>> in roles.
+
+Additional metadata can be extracted from the Active Directory server by configuring
+the `metadata` setting on the Active Directory realm.
+
+[[active-directory-ssl]]
+==== Setting up SSL between Elasticsearch and Active Directory
+
+See 
+{ref}/configuring-tls.html#tls-active-directory[Encrypting communications between {es} and Active Directory].

x-pack/docs/en/security/authentication/built-in-users.asciidoc

@@ -0,0 +1,204 @@
+[role="xpack"]
+[[built-in-users]]
+=== Built-in users
+
+The {stack-security-features} provide built-in user credentials to help you get
+up and running. These users have a fixed set of privileges and cannot be
+authenticated until their passwords have been set. The `elastic` user can be
+used to <<set-built-in-user-passwords,set all of the built-in user passwords>>.
+
+`elastic`:: A built-in _superuser_. See <<built-in-roles>>.
+`kibana`:: The user Kibana uses to connect and communicate with Elasticsearch.
+`logstash_system`:: The user Logstash uses when storing monitoring information in Elasticsearch.
+`beats_system`:: The user the Beats use when storing monitoring information in Elasticsearch.
+`apm_system`:: The user the APM server uses when storing monitoring information in {es}.
+`remote_monitoring_user`:: The user {metricbeat} uses when collecting and 
+storing monitoring information in {es}. It has the `remote_monitoring_agent` and 
+`remote_monitoring_collector` built-in roles. 
+
+
+[float]
+[[built-in-user-explanation]]
+==== How the built-in users work
+These built-in users are stored in a special `.security` index, which is managed
+by {es}. If a built-in user is disabled or its password
+changes, the change is automatically reflected on each node in the cluster. If
+your `.security` index is deleted or restored from a snapshot, however, any
+changes you have applied are lost.
+
+Although they share the same API, the built-in users are separate and distinct
+from users managed by the <<native-realm, native realm>>. Disabling the native
+realm will not have any effect on the built-in users. The built-in users can
+be disabled individually, using the
+{ref}/security-api-disable-user.html[disable users API].
+
+[float]
+[[bootstrap-elastic-passwords]]
+==== The Elastic bootstrap password
+
+When you install {es}, if the `elastic` user does not already have a password,
+it uses a default bootstrap password. The bootstrap password is a transient
+password that enables you to run the tools that set all the built-in user passwords.
+
+By default, the bootstrap password is derived from a randomized `keystore.seed`
+setting, which is added to the keystore during installation. You do not need
+to know or change this bootstrap password. If you have defined a
+`bootstrap.password` setting in the keystore, however, that value is used instead.
+For more information about interacting with the keystore, see
+{ref}/secure-settings.html[Secure Settings].
+
+NOTE: After you <<set-built-in-user-passwords,set passwords for the built-in users>>,
+in particular for the `elastic` user, there is no further use for the bootstrap
+password.
+
+[float]
+[[set-built-in-user-passwords]]
+==== Setting built-in user passwords
+
+You must set the passwords for all built-in users.
+
+The +elasticsearch-setup-passwords+ tool is the simplest method to set the
+built-in users' passwords for the first time. It uses the `elastic` user's
+bootstrap password to run user management API requests. For example, you can run
+the command in an "interactive" mode, which prompts you to enter new passwords
+for the `elastic`, `kibana`, `logstash_system`, `beats_system`, `apm_system`, 
+and `remote_monitoring_user` users:
+
+[source,shell]
+--------------------------------------------------
+bin/elasticsearch-setup-passwords interactive
+--------------------------------------------------
+
+For more information about the command options, see
+{ref}/setup-passwords.html[elasticsearch-setup-passwords].
+
+IMPORTANT: After you set a password for the `elastic` user, the bootstrap
+password is no longer valid; you cannot run the `elasticsearch-setup-passwords`
+command a second time.
+
+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
+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
+new bootstrap password:
+
+[source,shell]
+----------------------------------------------------
+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
+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.
+
+[[add-built-in-user-passwords]]
+
+[float]
+[[add-built-in-user-kibana]]
+==== Adding built-in user passwords to {kib}
+
+After the `kibana` user password is set, you need to update the {kib} server
+with the new password by setting `elasticsearch.password` in the `kibana.yml`
+configuration file:
+
+[source,yaml]
+-----------------------------------------------
+elasticsearch.password: kibanapassword
+-----------------------------------------------
+
+See {kibana-ref}/using-kibana-with-security.html[Configuring security in {kib}].
+
+[float]
+[[add-built-in-user-logstash]]
+==== Adding built-in user passwords to {ls} 
+
+The `logstash_system` user is used internally within Logstash when
+monitoring is enabled for Logstash.
+
+To enable this feature in Logstash, you need to update the Logstash
+configuration with the new password by setting `xpack.monitoring.elasticsearch.password` in
+the `logstash.yml` configuration file:
+
+[source,yaml]
+----------------------------------------------------------
+xpack.monitoring.elasticsearch.password: logstashpassword
+----------------------------------------------------------
+
+If you have upgraded from an older version of Elasticsearch,
+the `logstash_system` user may have defaulted to _disabled_ for security reasons.
+Once the password has been changed, you can enable the user via the following API call:
+
+[source,js]
+---------------------------------------------------------------------
+PUT _security/user/logstash_system/_enable
+---------------------------------------------------------------------
+// CONSOLE
+
+See {logstash-ref}/ls-security.html#ls-monitoring-user[Configuring credentials for {ls} monitoring]. 
+
+[float]
+[[add-built-in-user-beats]]
+==== Adding built-in user passwords to Beats
+
+The `beats_system` user is used internally within Beats when monitoring is
+enabled for Beats.
+
+To enable this feature in Beats, you need to update the configuration for each
+of your beats to reference the correct username and password. For example:
+
+[source,yaml]
+----------------------------------------------------------
+xpack.monitoring.elasticsearch.username: beats_system
+xpack.monitoring.elasticsearch.password: beatspassword
+----------------------------------------------------------
+
+For example, see {metricbeat-ref}/monitoring.html[Monitoring {metricbeat}]. 
+
+The `remote_monitoring_user` is used when {metricbeat} collects and stores 
+monitoring data for the {stack}. See <<monitoring-production>>. 
+
+If you have upgraded from an older version of {es}, then you may not have set a
+password for the `beats_system` or `remote_monitoring_user` users. If this is 
+the case, then you should use the *Management > Users* page in {kib} or the
+{ref}/security-api-change-password.html[Change Password API] to set a password
+for these users.
+
+[float]
+[[add-built-in-user-apm]]
+==== Adding built-in user passwords to APM
+
+The `apm_system` user is used internally within APM when monitoring is enabled.
+
+To enable this feature in APM, you need to update the 
+{apm-server-ref}/configuring-howto-apm-server.html[APM configuration file] to 
+reference the correct username and password. For example:
+
+[source,yaml]
+----------------------------------------------------------
+xpack.monitoring.elasticsearch.username: apm_system
+xpack.monitoring.elasticsearch.password: apmserverpassword
+----------------------------------------------------------
+
+See {apm-server-ref}/monitoring.html[Monitoring APM Server]. 
+
+If you have upgraded from an older version of {es}, then you may not have set a
+password for the `apm_system` user. If this is the case, 
+then you should use the *Management > Users* page in {kib} or the
+{ref}/security-api-change-password.html[Change Password API] to set a password
+for these users.
+
+[float]
+[[disabling-default-password]]
+==== Disabling default password functionality
+[IMPORTANT]
+=============================================================================
+This setting is deprecated. The elastic user no longer has a default password.
+The password must be set before the user can be used.
+See <<bootstrap-elastic-passwords>>.
+=============================================================================

x-pack/docs/en/security/authentication/file-realm.asciidoc

@@ -0,0 +1,27 @@
+[role="xpack"]
+[[file-realm]]
+=== File-based user authentication
+
+You can manage and authenticate users with the built-in `file` realm.
+With the `file` realm, users are defined in local files on each node in the cluster.
+
+IMPORTANT:  As the administrator of the cluster, it is your responsibility to
+ensure the same users are defined on every node in the cluster. The {stack}
+{security-features} do not deliver any mechanism to guarantee this.
+
+The `file` realm is primarily supported to serve as a fallback/recovery realm. It
+is mostly useful in situations where all users locked themselves out of the system
+(no one remembers their username/password). In this type of scenarios, the `file`
+realm is your only way out - you can define a new `admin` user in the `file` realm
+and use it to log in and reset the credentials of all other users.
+
+IMPORTANT: When you configure realms in `elasticsearch.yml`, only the realms you
+specify are used for authentication. To use the `file` realm as a fallback, you
+must include it in the realm chain.
+
+To define users, the {security-features} provide the
+{ref}/users-command.html[users] command-line tool. This tool enables you to add
+and remove users, assign user roles, and manage user passwords.
+
+For more information, see 
+{ref}/configuring-file-realm.html[Configuring a file realm].

x-pack/docs/en/security/authentication/index.asciidoc

@@ -0,0 +1,22 @@
+
+include::overview.asciidoc[]
+include::built-in-users.asciidoc[]
+include::internal-users.asciidoc[]
+include::token-authentication-services.asciidoc[]
+include::realms.asciidoc[]
+include::realm-chains.asciidoc[]
+include::active-directory-realm.asciidoc[]
+include::file-realm.asciidoc[]
+include::ldap-realm.asciidoc[]
+include::native-realm.asciidoc[]
+include::pki-realm.asciidoc[]
+include::saml-realm.asciidoc[]
+include::kerberos-realm.asciidoc[]
+
+include::{xes-repo-dir}/security/authentication/custom-realm.asciidoc[]
+
+include::{xes-repo-dir}/security/authentication/anonymous-access.asciidoc[]
+
+include::{xes-repo-dir}/security/authentication/user-cache.asciidoc[]
+
+include::{xes-repo-dir}/security/authentication/saml-guide.asciidoc[]

x-pack/docs/en/security/authentication/internal-users.asciidoc

@@ -0,0 +1,14 @@
+[role="xpack"]
+[[internal-users]]
+=== Internal users
+
+The {stack-security-features} use three _internal_ users (`_system`, `_xpack`,
+and `_xpack_security`), which are responsible for the operations that take place
+inside an {es} cluster.
+
+These users are only used by requests that originate from within the cluster.
+For this reason, they cannot be used to authenticate against the API and there
+is no password to manage or reset.
+
+From time-to-time you may find a reference to one of these users inside your
+logs, including <<auditing, audit logs>>.