[7.5] [DOCS] Fixes broken links (#51634) (#51773)

docs/api/role-management/put.asciidoc

@@ -26,7 +26,9 @@ To use the create or update role API, you must have the `manage_security` cluste
   (Optional, object) In the `metadata` object, keys that begin with `_` are reserved for system usage.
 
 `elasticsearch`:: 
-  (Optional, object) {es} cluster and index privileges. Valid keys include `cluster`, `indices`, and `run_as`. For more information, see {xpack-ref}/defining-roles.html[Defining Roles].
+  (Optional, object) {es} cluster and index privileges. Valid keys include 
+  `cluster`, `indices`, and `run_as`. For more information, see
+  {ref}/defining-roles.html[Defining roles].
 
 `kibana`:: 
   (list) Objects that specify the <<kibana-privileges, Kibana privileges>> for the role:

docs/developer/security/rbac.asciidoc

@@ -1,7 +1,14 @@
 [[development-security-rbac]]
 === Role-based access control
 
-Role-based access control (RBAC) in {kib} relies upon the {xpack-ref}/security-privileges.html#application-privileges[application privileges] that Elasticsearch exposes. This allows {kib} to define the privileges that {kib} wishes to grant to users, assign them to the relevant users using roles, and then authorize the user to perform a specific action. This is handled within a secured instance of the `SavedObjectsClient` and available transparently to consumers when using `request.getSavedObjectsClient()` or `savedObjects.getScopedSavedObjectsClient()`.
+Role-based access control (RBAC) in {kib} relies upon the
+{ref}/security-privileges.html#application-privileges[application privileges]
+that Elasticsearch exposes. This allows {kib} to define the privileges that
+{kib} wishes to grant to users, assign them to the relevant users using roles,
+and then authorize the user to perform a specific action. This is handled within
+a secured instance of the `SavedObjectsClient` and available transparently to
+consumers when using `request.getSavedObjectsClient()` or 
+`savedObjects.getScopedSavedObjectsClient()`.
 
 [[development-rbac-privileges]]
 ==== {kib} Privileges

docs/getting-started/tutorial-full-experience.asciidoc

@@ -91,7 +91,7 @@ and whether it's _tokenized_, or broken up into separate words.
 
 NOTE: If security is enabled, you must have the `all` Kibana privilege to run this tutorial.
 You must also have the `create`, `manage` `read`, `write,` and `delete` 
-index privileges. See {xpack-ref}/security-privileges.html[Security Privileges] 
+index privileges. See {ref}/security-privileges.html[Security privileges] 
 for more information.
 
 In Kibana *Dev Tools > Console*, set up a mapping for the Shakespeare data set:

docs/getting-started/tutorial-sample-data.asciidoc

@@ -12,8 +12,8 @@ with Kibana sample data and learn to:
 
 
 NOTE: If security is enabled, you must have `read`, `write`, and `manage` privileges
-on the `kibana_sample_data_*` indices. See {xpack-ref}/security-privileges.html[Security Privileges] 
-for more information.
+on the `kibana_sample_data_*` indices. See
+{ref}/security-privileges.html[Security privileges] for more information.
 
 
 [float]

docs/limitations.asciidoc

@@ -11,9 +11,9 @@
 
 These {stack} features also have limitations that affect {kib}:
 
-* {stack-ov}/watcher-limitations.html[Alerting]
+* {ref}/watcher-limitations.html[Alerting]
 * {stack-ov}/ml-limitations.html[Machine learning]
-* {stack-ov}/security-limitations.html[Security]
+* {ref}/security-limitations.html[Security]
 
 --
 

docs/management/managing-indices.asciidoc

@@ -22,7 +22,7 @@ If security is enabled,
 you must have the `monitor` cluster privilege and the `view_index_metadata` 
 and `manage` index privileges to view the data.  
 For index templates, you must have the `manage_index_templates` cluster privilege.
-See {xpack-ref}/security-privileges.html[Security Privileges] for more
+See {ref}/security-privileges.html[Security privileges] for more
 information.
 
 Before using this feature, you should be familiar with index management 

docs/management/managing-licenses.asciidoc

@@ -25,4 +25,4 @@ license, extend the trial, or purchase a subscription.
 
 TIP: If {security-features} are enabled, before you revert to a Basic license or install 
 a Gold or Platinum license, you must configure Transport Layer Security (TLS) in {es}. 
-See {stack-ov}/encrypting-communications.html[Encrypting communications].
+See {ref}/encrypting-communications.html[Encrypting communications].

docs/management/managing-remote-clusters.asciidoc

@@ -10,7 +10,7 @@ Before using these features, you should be familiar with the following concepts:
 
 * {ref}/xpack-ccr.html[{ccr-cap}]
 * {ref}/modules-cross-cluster-search.html[{ccs-cap}]
-* {stack-ov}/cross-cluster-configuring.html[Cross-cluster security requirements]
+* {ref}/cross-cluster-configuring.html[Cross-cluster security requirements]
 
 [float]
 [[managing-remote-clusters]]

docs/management/watcher-ui/index.asciidoc

@@ -31,7 +31,7 @@ watch—input, schedule, condition, and actions.
 === Watcher security
 
 If the {es} {security-features} are enabled, you must have the
-{stack-ov}/security-privileges.html[`manage_watcher` or `monitor_watcher`]
+{ref}/security-privileges.html[`manage_watcher` or `monitor_watcher`]
 cluster privileges to use Watcher in {kib}.
 
 Alternately, you can have the built-in `kibana_user` role

docs/redirects.asciidoc

@@ -39,7 +39,7 @@ This page has moved. Please see <<xpack-logs-configuring>>.
 == Creating {transforms}
 
 This page is deleted. Please see
-{stack-ov}/ecommerce-dataframes.html[Transforming the eCommerce sample data].
+{ref}/ecommerce-transforms.html[Transforming the eCommerce sample data].
 
 [role="exclude",id="ml-jobs"]
 == Creating {anomaly-jobs}

docs/settings/monitoring-settings.asciidoc

@@ -25,7 +25,7 @@ from Logstash, you configure
 in `logstash.yml`.
 
 For more information, see
-{stack-ov}/xpack-monitoring.html[Monitoring the Elastic Stack].
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster].
 
 [float]
 [[monitoring-general-settings]]

docs/settings/ssl-settings.asciidoc

@@ -2,7 +2,7 @@
 === {component} TLS/SSL settings
 You can configure the following TLS/SSL settings. If the settings are not
 configured, the default values are used. See
-{stack-ov}/security-settings.html[Default TLS/SSL Settings].
+{ref}/security-settings.html[Default TLS/SSL settings].
 
 ifdef::server[]
 +{ssl-prefix}.ssl.enabled+::
@@ -45,7 +45,7 @@ Java Cryptography Architecture documentation]. Defaults to the value of
 The following settings are used to specify a private key, certificate, and the
 trusted certificates that should be used when communicating over an SSL/TLS connection.
 If none of the settings below are specified, the default values are used.
-See {stack-ov}/security-settings.html[Default TLS/SSL settings].
+See {ref}/security-settings.html[Default TLS/SSL settings].
 
 ifdef::server[]
 A private key and certificate must be configured.
@@ -55,7 +55,7 @@ A private key and certificate are optional and would be used if the server requi
 authentication.
 endif::server[]
 If none of the settings below are specified, the defaults values are used.
-See {stack-ov}/security-settings.html[Default TLS/SSL settings]. 
+See {ref}/security-settings.html[Default TLS/SSL settings]. 
 
 [float]
 ===== PEM encoded files

docs/setup/install.asciidoc

@@ -54,8 +54,8 @@ Formulae are available from the Elastic Homebrew tap for installing {kib} on mac
 <<brew>>
 
 IMPORTANT: If your Elasticsearch installation is protected by
-{xpack-ref}/elasticsearch-security.html[{security}] see
-{kibana-ref}/using-kibana-with-security.html[Configuring Security in Kibana] for
+{ref}/elasticsearch-security.html[{security}] see
+{kibana-ref}/using-kibana-with-security.html[Configuring security in Kibana] for
 additional setup instructions.
 
 include::install/targz.asciidoc[]

docs/setup/production.asciidoc

@@ -23,7 +23,7 @@ and an Elasticsearch client node on the same machine. For more information, see
 [[configuring-kibana-shield]]
 === Using {stack} {security-features}
 
-You can use {stack-ov}/elasticsearch-security.html[{stack} {security-features}] 
+You can use {ref}/elasticsearch-security.html[{stack} {security-features}] 
 to control what {es} data users can access through Kibana.
 
 When {security-features} are enabled, Kibana users have to log in. They need to

docs/user/monitoring/configuring-monitoring.asciidoc

@@ -15,7 +15,7 @@ You can also use {kib} to
 <<monitoring-data,visualize monitoring data from across the {stack}>>.
 
 To learn about monitoring in general, see 
-{stack-ov}/xpack-monitoring.html[Monitoring the {stack}]. 
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster]. 
 
 include::monitoring-kibana.asciidoc[]
 include::monitoring-metricbeat.asciidoc[]

docs/user/monitoring/elasticsearch-details.asciidoc

@@ -27,7 +27,7 @@ highlighted in yellow or red.
 TIP: Conditions that require your attention are listed at the top of the
 Clusters page. You can also set up watches to alert you when the status
 of your cluster changes. To learn how, see
-{stack-ov}/watch-cluster-status.html[Watch Your Cluster Health].
+{ref}/watch-cluster-status.html[Watch your cluster health].
 
 The panel at the top shows the current cluster statistics, the charts show the
 search and indexing performance over time, and the table at the bottom shows
@@ -145,7 +145,7 @@ You can also see advanced information, which contains the results from the
 [role="screenshot"] 
 image::user/monitoring/images/monitoring-ccr-shard.png["Cross-cluster replication shard details",link="images/monitoring-ccr-shard.png"]
 
-For more information, see {stack-ov}/xpack-ccr.html[Cross-cluster replication].
+For more information, see {ref}/xpack-ccr.html[Cross-cluster replication].
 
 [float]
 [[logs-monitor-page]]

docs/user/monitoring/index.asciidoc

@@ -21,7 +21,7 @@ NOTE: Watcher must be enabled to view cluster alerts. If you have a Basic
 license, Top Cluster Alerts are not displayed.
 
 For more information, see <<configuring-monitoring>> and 
-{stack-ov}/xpack-monitoring.html[Monitoring the {stack}].  
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster].  
 
 --
 

docs/user/monitoring/monitoring-kibana.asciidoc

@@ -13,7 +13,7 @@ which ultimately routes them to the monitoring cluster. For an alternative
 method, see <<monitoring-metricbeat>>. 
 
 To learn about monitoring in general, see 
-{stack-ov}/xpack-monitoring.html[Monitoring the {stack}]. 
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster]. 
 
 . Set the `xpack.monitoring.collection.enabled` setting to `true` on each
 node in the production cluster. By default, it is is disabled (`false`). 

docs/user/monitoring/monitoring-metricbeat.asciidoc

@@ -13,7 +13,7 @@ production cluster as described in <<monitoring-kibana>>.
 image::user/monitoring/images/metricbeat.png[Example monitoring architecture]
 
 To learn about monitoring in general, see 
-{stack-ov}/xpack-monitoring.html[Monitoring the {stack}]. 
+{ref}/monitor-elasticsearch-cluster.html[Monitor a cluster]. 
 
 //NOTE: The tagged regions are re-used in the Stack Overview.
 
@@ -134,9 +134,9 @@ If the Elastic {security-features} are enabled, you must also provide a user
 ID and password so that {metricbeat} can collect metrics successfully: 
 
 .. Create a user on the production cluster that has the 
-`remote_monitoring_collector` {stack-ov}/built-in-roles.html[built-in role]. 
+`remote_monitoring_collector` {ref}/built-in-roles.html[built-in role]. 
 Alternatively, use the `remote_monitoring_user` 
-{stack-ov}/built-in-users.html[built-in user].
+{ref}/built-in-users.html[built-in user].
 
 .. Add the `username` and `password` settings to the {kib} module configuration 
 file.
@@ -197,9 +197,9 @@ must provide a valid user ID and password so that {metricbeat} can send metrics
 successfully: 
 
 .. Create a user on the monitoring cluster that has the 
-`remote_monitoring_agent` {stack-ov}/built-in-roles.html[built-in role]. 
+`remote_monitoring_agent` {ref}/built-in-roles.html[built-in role]. 
 Alternatively, use the `remote_monitoring_user` 
-{stack-ov}/built-in-users.html[built-in user].
+{ref}/built-in-users.html[built-in user].
 
 .. Add the `username` and `password` settings to the {es} output information in 
 the {metricbeat} configuration file.

docs/user/monitoring/viewing-metrics.asciidoc

@@ -41,7 +41,7 @@ default value, in the `kibana.yml` file. For more information, see
 must provide a user ID and password so {kib} can retrieve the data. 
 
 .. Create a user that has the `monitoring_user` 
-{stack-ov}/built-in-roles.html[built-in role] on the monitoring cluster.
+{ref}/built-in-roles.html[built-in role] on the monitoring cluster.
 
 .. Add the `xpack.monitoring.elasticsearch.username` and 
 `xpack.monitoring.elasticsearch.password` settings in the `kibana.yml` file.
@@ -64,7 +64,7 @@ remote monitoring cluster, you must use credentials that are valid on both the
 --
 
 .. Create users that have the `monitoring_user` and `kibana_user` 
-{stack-ov}/built-in-roles.html[built-in roles].
+{ref}/built-in-roles.html[built-in roles].
 
 . Open {kib} in your web browser. 
 +

docs/user/reporting/gs-index.asciidoc

@@ -16,7 +16,7 @@ The following Reporting button appears in the {kib} toolbar:
 
 image:images/reporting.jpg["Reporting",link="reporting.jpg"]
 
-You can also {stack-ov}/automating-report-generation.html[generate reports automatically].
+You can also <<automating-report-generation,generate reports automatically>>.
 
 IMPORTANT: Reports are stored in the `.reporting-*` indices. Any user with
 access to these indices has access to every report generated by all users.

docs/user/reporting/watch-example.asciidoc

@@ -44,7 +44,7 @@ PUT _watcher/watch/error_report
 ---------------------------------------------------------
 // CONSOLE
 
-<1> You must configure at least one email account to enable Watcher to send email.
+<1> You must configure at least one email account to enable {watcher} to send email.
 For more information, see
 {ref}/actions-email.html#configuring-email[Configuring email accounts].
 <2> This is an example POST URL. You can copy and paste the URL for any
@@ -56,7 +56,7 @@ report from the Kibana UI.
 //For more information, see <<secure-reporting>>.
 //<<reporting-app-users, Setting up a Reporting Role>>.
 
-NOTE: Reporting is integrated with Watcher only as an email attachment type.
+NOTE: Reporting is integrated with {watcher} only as an email attachment type.
 
 For more information about configuring watches, see
-{stack-ov}/how-watcher-works.html[How Watcher Works].
+{ref}/how-watcher-works.html[How {watcher} works].

docs/user/security/audit-logging.asciidoc

@@ -12,7 +12,7 @@ audit logging to get a holistic view of all security related events.
 {kib} defers to {es}'s security model for authentication, data
 index authorization, and features that are driven by cluster-wide privileges.
 For more information on enabling audit logging in {es}, see
-{stack-ov}/auditing.html[Auditing Security Events].
+{ref}/enable-audit-logging.html[Enabling audit logging].
 
 [IMPORTANT]
 ============================================================================

docs/user/security/authentication/index.asciidoc

@@ -14,16 +14,17 @@
 - <<oidc>>
 
 [[basic-authentication]]
-==== Basic Authentication
+==== Basic authentication
 
 Basic authentication requires a username and password to successfully log in to {kib}. It is enabled by default and based on the Native security realm provided by {es}. The basic authentication provider uses a Kibana provided login form, and supports authentication using the `Authorization` request header's `Basic` scheme.
 
 The session cookies that are issued by the basic authentication provider are stateless. Therefore, logging out of Kibana when using the basic authentication provider clears the session cookies from the browser but does not invalidate the session cookie for reuse.
 
-For more information about basic authentication and built-in users, see {xpack-ref}/setting-up-authentication.html[Setting Up User Authentication].
+For more information about basic authentication and built-in users, see
+{ref}/setting-up-authentication.html[User authentication].
 
 [[token-authentication]]
-==== Token Authentication
+==== Token authentication
 
 Token authentication allows users to login using the same Kibana provided login form as basic authentication. The token authentication provider is built on {es}'s token APIs. The bearer tokens returned by {es}'s {ref}/security-api-get-token.html[get token API] can be used directly with Kibana using the `Authorization` request header with the `Bearer` scheme.
 
@@ -46,7 +47,7 @@ xpack.security.authc.providers: [token, basic]
 --------------------------------------------------------------------------------
 
 [[pki-authentication]]
-==== Public Key Infrastructure (PKI) Authentication
+==== Public key infrastructure (PKI) authentication
 
 [IMPORTANT]
 ============================================================================
@@ -76,9 +77,9 @@ xpack.security.authc.providers: [pki, basic]
 Note that with `server.ssl.clientAuthentication` set to `required`, users are asked to provide a valid client certificate, even if they want to authenticate with username and password. Depending on the security policies, it may or may not be desired. If not, `server.ssl.clientAuthentication` can be set to `optional`. In this case, {kib} still requests a client certificate, but the client won't be required to present one. The `optional` client authentication mode might also be needed in other cases, for example, when PKI authentication is used in conjunction with Reporting.
 
 [[saml]]
-==== SAML Single Sign-On
+==== SAML single sign-on
 
-SAML authentication allows users to log in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting it up in {kib}. See {xpack-ref}/saml-guide.html[Configuring SAML Single-Sign-On on the Elastic Stack].
+SAML authentication allows users to log in to {kib} with an external Identity Provider, such as Okta or Auth0. Make sure that SAML is enabled and configured in {es} before setting it up in {kib}. See {ref}/saml-guide.html[Configuring SAML single sign-on on the Elastic Stack].
 
 Set the configuration values in `kibana.yml` as follows:
 
@@ -106,7 +107,7 @@ server.xsrf.whitelist: [/api/security/saml/callback]
 Users will be able to log in to {kib} via SAML Single Sign-On by navigating directly to the {kib} URL. Users who aren't authenticated are redirected to the Identity Provider for login. Most Identity Providers maintain a long-lived session—users who logged in to a different application using the same Identity Provider in the same browser are automatically authenticated. An exception is if {es} or the Identity Provider is configured to force user to re-authenticate. This login scenario is called _Service Provider initiated login_.
 
 [float]
-===== SAML and Basic Authentication
+===== SAML and basic authentication
 
 SAML support in {kib} is designed to be the primary (or sole) authentication method for users of that {kib} instance. However, you can configure both SAML and Basic authentication for the same {kib} instance:
 
@@ -135,7 +136,7 @@ xpack.security.authc.saml.maxRedirectURLSize: 1kb
 --------------------------------------------------------------------------------
 
 [[oidc]]
-==== OpenID Connect Single Sign-On
+==== OpenID Connect single sign-on
 
 Similar to SAML, authentication with OpenID Connect allows users to log in to {kib} using an OpenID Connect Provider such as Google, or Okta. OpenID Connect
 should also be configured in {es}. For more details, see {ref}/oidc-guide.html[Configuring single sign-on to the {stack} using OpenID Connect].
@@ -166,7 +167,7 @@ server.xsrf.whitelist: [/api/security/v1/oidc]
 --------------------------------------------------------------------------------
 
 [float]
-===== OpenID Connect and Basic Authentication
+===== OpenID Connect and basic authentication
 
 Similar to SAML, OpenID Connect support in {kib} is designed to be the primary (or sole) authentication method for users
 of that {kib} instance. However, you can configure both OpenID Connect and Basic authentication for the same {kib} instance:
@@ -179,12 +180,12 @@ xpack.security.authc.providers: [oidc, basic]
 Users will be able to access the login page and use Basic authentication by navigating to the `/login` URL.
 
 [float]
-==== Single Sign-On provider details
+==== Single sign-on provider details
 
 The following sections apply both to <<saml>> and <<oidc>> 
 
 [float]
-===== Access and Refresh Tokens
+===== Access and refresh tokens
 
 Once the user logs in to {kib} Single Sign-On, either using SAML or OpenID Connect, {es} issues access and refresh tokens
 that {kib} encrypts and stores them in its own session cookie. This way, the user isn't redirected to the Identity Provider
@@ -201,7 +202,7 @@ If {kib} can't redirect the user to the external authentication provider (for ex
 indicates that both access and refresh tokens are expired. Reloading the current {kib} page fixes the error.
 
 [float]
-===== Local and Global Logout
+===== Local and global logout
 
 During logout, both the {kib} session cookie and access/refresh token pair are invalidated. Even if the cookie has been
 leaked, it can't be re-used after logout. This is known as "local" logout.

docs/user/security/authorization/index.asciidoc

@@ -2,7 +2,7 @@
 [[xpack-security-authorization]]
 
 === Granting access to {kib}
-The Elastic Stack comes with the `kibana_user` {stack-ov}/built-in-roles.html[built-in role], which you can use to grant access to all Kibana features in all spaces. To grant users access to a subset of spaces or features, you can create a custom role that grants the desired Kibana privileges. 
+The Elastic Stack comes with the `kibana_user` {ref}/built-in-roles.html[built-in role], which you can use to grant access to all Kibana features in all spaces. To grant users access to a subset of spaces or features, you can create a custom role that grants the desired Kibana privileges. 
 
 When you assign a user multiple roles, the user receives a union of the roles’ privileges. Therefore, assigning the `kibana_user` role in addition to a custom role that grants Kibana privileges is ineffective because `kibana_user` has access to all the features in all spaces.
 

docs/user/security/index.asciidoc

@@ -7,7 +7,7 @@ security, you can
 password-protect your data as well as implement more advanced security measures
 such as encrypting communications, role-based access control, IP filtering, and
 auditing. For more information, see
-{stack-ov}/elasticsearch-security.html[Securing {es} and {kib}] and
+{ref}/elasticsearch-security.html[Security overview] and
 <<using-kibana-with-security,Configuring Security in {kib}>>.
 
 [float]
@@ -16,7 +16,7 @@ auditing. For more information, see
 You can create and manage users on the *Management -> Security -> Users* page.
 You can also change their passwords and roles. For more information about
 authentication and built-in users, see
-{stack-ov}/setting-up-authentication.html[Setting up user authentication].
+{ref}/setting-up-authentication.html[User authentication].
 
 [float]
 === Roles
@@ -25,7 +25,7 @@ You can manage roles on the *Management -> Security -> Roles* page, or use
 the <<role-management-api>>. For more information on configuring roles for {kib}, see <<xpack-security-authorization, Granting access to {kib}>>.
 
 For a more holistic overview of configuring roles for the entire stack,
-see {stack-ov}/authorization.html[Configuring role-based access control].
+see {ref}/authorization.html[User authorization].
 
 [NOTE]
 ============================================================================

docs/user/security/reporting.asciidoc

@@ -8,7 +8,7 @@ user actions in {kib}.
 To use {reporting} with {security} enabled, you need to
 <<using-kibana-with-security,set up {kib} to work with {security}>>.
 If you are automatically generating reports with
-{xpack-ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
+{ref}/xpack-alerting.html[{watcher}], you also need to configure {watcher}
 to trust the {kib} server's certificate. For more information, see
 <<securing-reporting>>.
 
@@ -35,7 +35,7 @@ POST /_security/user/reporter
 * If you are using an LDAP or Active Directory realm, you can either assign
 roles on a per user basis, or assign roles to groups of users. By default, role
 mappings are configured in
-{xpack-ref}/mapping-roles.html[`config/shield/role_mapping.yml`].
+{ref}/mapping-roles.html[`config/shield/role_mapping.yml`].
 For example, the following snippet assigns the user named Bill Murray the
 `kibana_user` and `reporting_user` roles:
 +
@@ -55,7 +55,7 @@ In a production environment, you should restrict access to
 the {reporting} endpoints to authorized users. This requires that you:
 
 . Enable {security} on your {es} cluster. For more information,
-see {xpack-ref}/security-getting-started.html[Getting Started with Security].
+see {ref}/security-getting-started.html[Getting Started with Security].
 . Configure an SSL certificate for Kibana. For more information, see
 <<using-kibana-with-security>>.
 . Configure {watcher} to trust the Kibana server's certificate by adding it to
@@ -83,4 +83,4 @@ includes a watch that submits requests as the built-in `elastic` user:
 <<automating-report-generation>>.
 
 For more information about configuring watches, see
-{xpack-ref}/how-watcher-works.html[How Watcher Works].
+{ref}/how-watcher-works.html[How Watcher works].

docs/user/security/securing-kibana.asciidoc

@@ -40,7 +40,7 @@ APIs and the `.kibana` index. The server does _not_ need access to user indices.
 
 The password for the built-in `kibana` user is typically set as part of the
 {security} configuration process on {es}. For more information, see
-{stack-ov}/built-in-users.html[Built-in users].
+{ref}/built-in-users.html[Built-in users].
 --
 
 . Set the `xpack.security.encryptionKey` property in the `kibana.yml`
@@ -106,7 +106,7 @@ TIP: You can define as many different roles for your {kib} users as you need.
 
 For example, create roles that have `read` and `view_index_metadata` privileges
 on specific index patterns. For more information, see
-{xpack-ref}/authorization.html[Configuring Role-based Access Control].
+{ref}/authorization.html[User authorization].
 
 --