Fix Vale warnings in the Reference section

Skip warnings in auto-generated pages, which we can handle in a separate
change.

docs/pages/reference/access-controls/access-lists.mdx

@@ -4,7 +4,7 @@ description: An explanation and overview of Access Lists in Teleport.
 ---
 
 Access Lists allow Teleport users to be granted long term access to resources
-managed within Teleport. With Access Lists, administrators and access list
+managed within Teleport. With Access Lists, administrators and Access List
 owners can regularly audit and control membership to specific roles and
 traits, which then tie easily back into Teleport's existing RBAC system.
 
@@ -31,7 +31,7 @@ to live on the order of hours or days.
 
 Access List owners are Teleport users or nested Access Lists who are granted special privileges over
 an Access List. These owners are defined explicitly as part of the Access List, and
-must be added by a Teleport user who has RBAC access to access lists, which the preset `editor`
+must be added by a Teleport user who has RBAC access to Access Lists, which the preset `editor`
 role has. Owners must meet requirements in order for their ownership to be effective.
 
 Provided owners meet requirements, owners are able to do the following:
@@ -178,7 +178,7 @@ Roles intended to reduce privileges should be assigned directly to users.
 ## Managing Access Lists from the CLI
 
 In addition to using the web UI, Access Lists can be created and managed from the CLI
-as well. To create an access list from the CLI, create an Access List YAML file (as described
+as well. To create an Access List from the CLI, create an Access List YAML file (as described
 above) and run `tctl create <filename>`. Access Lists can be updated by using `tctl create -f <filename>`.
 
 `tctl` also supports a subset of Access List focused commands under the `tctl acl` subcommand.

docs/pages/reference/access-controls/authentication.mdx

@@ -17,10 +17,10 @@ possible values (types) of MFA:
 - `otp` is the default. It implements the [TOTP](https://en.wikipedia.org/wiki/Time-based_One-time_Password_Algorithm)
   standard. You can use [Google Authenticator](https://en.wikipedia.org/wiki/Google_Authenticator), [Authy](https://www.authy.com/) or any other TOTP client.
 - `webauthn` implements the [Web Authentication standard](https://webauthn.guide) for utilizing
-  second factor authenticators and hardware devices.
+  multi-factor authenticators and hardware devices.
   You can use [YubiKeys](https://www.yubico.com/), [SoloKeys](https://solokeys.com/) or any other authenticator that
   implements FIDO2 or FIDO U2F standards.
-  See our [Second Factor - WebAuthn](../../admin-guides/access-controls/guides/webauthn.mdx) guide for detailed
+  See our [Harden your Cluster Against IdP Compromises](../../admin-guides/access-controls/guides/webauthn.mdx) guide for detailed
   instructions on setting up WebAuthn for Teleport.
 - `on` enables both TOTP and WebAuthn, and all local users are required to have at least one MFA device registered.
 - `optional` enables both TOTP and WebAuthn but makes it optional for users. Local users that register a MFA device will

docs/pages/reference/access-controls/roles.mdx

@@ -574,7 +574,7 @@ You can specify an external trait in dot syntax if it begins with a letter and
 contains only letters, numbers, and underscores. Otherwise, you must use bracket
 syntax to specify a trait.
 
-When using Azure AD or ADFS as your IdP, you must use bracket notation, as these
+When using Microsoft Entra ID or ADFS as your IdP, you must use bracket notation, as these
 IdPs assign attribute keys to URLs such as the following:
 
 ```text

docs/pages/reference/agent-services/desktop-access-reference/configuration.mdx

@@ -21,10 +21,10 @@ The Windows Desktop Service can be deployed in two modes.
 ### Direct mode
 
 In *direct* mode, Windows Desktop Services registers directly with the Teleport
-Auth Server, and listens for desktop connections from the Teleport Proxy. To
+Auth Service, and listens for desktop connections from the Teleport Proxy. To
 enable direct mode, set `windows_desktop_service.listen_addr` in
 `teleport.yaml`, and ensure that `teleport.auth_server` points directly at the
-Auth Server.
+Auth Service.
 
 Direct mode requires network connectivity both:
 
@@ -38,7 +38,7 @@ self-hosted Teleport clusters.
 
 In *IoT mode*, Windows Desktop Service only needs to be able to make an outbound
 connection to a Teleport Proxy. The Windows Desktop Service establishes a
-reverse tunnel to the proxy, and both registration with the Auth Server and
+reverse tunnel to the proxy, and both registration with the Auth Service and
 desktop sessions are performed over this tunnel. To enable this mode, ensure
 that `windows_desktop_service.listen_addr` is *unset*, and point
 `teleport.proxy_server` at a Teleport Proxy.
@@ -65,4 +65,4 @@ spec:
   screen_size:
     width: 1024
     height: 768
-```
+```

docs/pages/reference/agent-services/kubernetes-application-discovery.mdx

@@ -8,7 +8,7 @@ Teleport Application Service, and annotations on Kubernetes services. This guide
 shows you how to configure each of these to manage Kubernetes Application
 Discovery in your Kubernetes cluster.
 
-## Configuring Teleport agent Helm chart
+## Configuring Teleport Agent Helm chart
 
 You can configure scope of services discovery by setting value `kubernetesDiscovery` of the chart. For more information
 please see [helm chart documentation](../helm-reference/teleport-kube-agent.mdx).

docs/pages/reference/architecture/agent-update-management.mdx

@@ -54,16 +54,16 @@ The agent version is subject to the following constraints:
 - the agent must always be no more than one major version below the Proxy or Auth
   Service version.
 
-The best practice is to always align the agent version with the Proxy and Auth
-ones. To upgrade Auth and Proxy, follow [the Teleport Cluster upgrade guide
-](../../upgrading/upgrading.mdx).
+The best practice is to always align the agent version with the version of the
+Proxy Service and Auth Service. To upgrade the Auth Service and Proxy Service,
+follow [the Teleport Cluster upgrade guide](../../upgrading/upgrading.mdx).
 
 For this reason, all updaters must subscribe to a release channel targeting
 versions that are compatible with their Teleport cluster. Teleport Cloud users
 must use the Teleport Cloud version server with the `stable/cloud` release
 channel. Self-hosted Teleport users must host their own version server and
-either update their release channel each time they update their Auth and Proxy
-instances, or use the `stable/rolling` channel.
+either update their release channel each time they update their Auth Service and
+Proxy Service instances, or use the `stable/rolling` channel.
 
 ### Teleport Cloud
 

docs/pages/reference/architecture/agents.mdx

@@ -180,13 +180,13 @@ Teleport cluster:
 - [OpenSSH servers](../../enroll-resources/server-access/openssh/openssh.mdx)
 - [Windows desktops](../../enroll-resources/desktop-access/getting-started.mdx)
 
-## Clients to agents
+## Clients to Agents
 
-Client tools authenticate to Teleport agent by presenting certificates signed by
-a Teleport certificate authority, forwarding traffic to the agent through an SSH
-reverse tunnel established between the Teleport Proxy Service and the agent.
+Client tools authenticate to Teleport Agents by presenting certificates signed by
+a Teleport certificate authority, forwarding traffic to the Agent through an SSH
+reverse tunnel established between the Teleport Proxy Service and the Agent.
 Clients need to retrieve a certificate, then connect to an infrastructure
-resource through the agent.
+resource through the Agent.
 
 ### Credentials for Teleport clients
 
@@ -275,5 +275,5 @@ Reference](../monitoring/audit.mdx).
 
 ## Further reading
 
-- For instructions on deploying agents, see the [Teleport agent
+- For instructions on deploying agents, see the [Teleport Agent
   guides](../../enroll-resources/agents/introduction.mdx).

docs/pages/reference/architecture/api-architecture.mdx

@@ -12,12 +12,12 @@ Started](../../admin-guides/api/getting-started.mdx).
 ## Authentication
 
 The Auth API uses mTLS to authenticate a client-server connection. Therefore, the client must provide
-TLS certificates signed by the Auth server to access the API. These are easy to create and provide using
+TLS certificates signed by the Auth Service to access the API. These are easy to create and provide using
 [Credential loaders](#credentials).
 
 ## Authorization
 
-The client certificates signed by the Auth server will be associated with a specific user. This user will
+The client certificates signed by the Auth Service will be associated with a specific user. This user will
 be used to authorize API requests made by the client.
 
 It is recommended to make a new user and role for each client. This makes it easier to track client actions,
@@ -77,7 +77,7 @@ benefits, here's a quick breakdown:
    underlying identity files.
  - Key pair credentials have a much simpler implementation than the other
    Credentials listed and may feel more familiar. These are good for
-   authenticating clients hosted directly on the auth server.
+   authenticating clients hosted directly on the Auth Service.
  - TLS credentials leave everything up to the client user. This is mostly used
    internally, but some advanced users may find it useful.
 
@@ -97,11 +97,12 @@ on pkg.go.dev for more information and examples for Credentials and Credential L
 
 ## Client connection
 
-The API client makes requests through an open connection to the Teleport Auth server.
+The API client makes requests through an open connection to the Teleport Auth
+Service.
 
-If the Auth server is isolated behind a
+If the Auth Service is isolated behind a
 [Proxy Server](../architecture/proxy.mdx), a reverse tunnel connection can be
-made using SSH certificates signed by the auth server. You can either provide
+made using SSH certificates signed by the Auth Service. You can either provide
 the server's reverse tunnel address directly or provide the web proxy address
 and have the client automatically retrieve the reverse tunnel address.
 

docs/pages/reference/architecture/authentication.mdx

@@ -57,8 +57,9 @@ identity to the public key with a certificate authority's signature.
 
 </Figure>
 
-Teleport uses x.509 certificates for Kubernetes, databases, web services and its own internal
-components - proxies, auth services to establish mutually authenticated TLS connections - mTLS.
+Teleport uses x.509 certificates for Kubernetes clusters, databases, web
+services and its own internal components, such as the Proxy Service and Auth
+Service, to establish mutually authenticated TLS connections (mTLS).
 
 ### OpenSSH certificates
 
@@ -154,8 +155,10 @@ Take a look at the [Certificate Rotation Guide](../../admin-guides/management/op
 learn how to do certificate rotation in practice.
 
 <Notice type="tip">
-To quickly lock out the node, proxy or auth service that may be compromised without rotating the entire
-cluster certificates, use node [session and identity locking](../../admin-guides/access-controls/guides/locking.mdx).
+To quickly lock out a potentially compromised Auth Service instance, Proxy
+Service instance, or Teleport Agent without rotating the entire cluster
+certificates, use [session and identity
+locking](../../admin-guides/access-controls/guides/locking.mdx).
 </Notice>
 
 ## More concepts

docs/pages/reference/architecture/authorization.mdx

@@ -252,8 +252,9 @@ Reference](../access-controls/roles.mdx).
 
 **How role templates are evaluated**
 
-Role templates are evaluated at the time of access to any resource either by proxy or node.
-Every Teleport component - proxy, auth server or node has up to date copy of all roles.
+Every Teleport component - whether a Proxy Service instance, Auth Service
+instance, or Agent -has up to date copy of all roles.  Teleport components
+evaluate role templates at the time of access to any resource. 
 
 Let's review a case with the following role template:
 

docs/pages/reference/architecture/kubernetes-applications-architecture.mdx

@@ -9,7 +9,7 @@ Kubernetes application auto-discovery consists of two parts:
 - Creating Teleport apps based on that list and proxying requests to them.
 
 <Admonition type="note">
-  This will only work when the Teleport agent runs inside the target Kubernetes cluster
+  This will only work when the Teleport Agent runs inside the target Kubernetes cluster
 </Admonition>
 
 ### Polling Kubernetes services

docs/pages/reference/architecture/machine-id-architecture.mdx

@@ -25,7 +25,7 @@ they comprise three linked resources. These are:
 - Token: for [onboarding](#joining-and-authentication), a token must exist that
   allows the Machine ID agent to initially authenticate as the bot user. If an
   existing token is not specified, then a single-use token will be created by
-  the Auth Server.
+  the Auth Service.
 - Bot instance: a single instance of a bot. As multiple `tbot` clients can join
   with a single Bot user or a single token, Bot Instances keep a running record
   of unique bot joins.

docs/pages/reference/architecture/proxy-peering.mdx

@@ -8,7 +8,7 @@ every Teleport Proxy Service. This allows Teleport Proxy instances to scale
 horizontally without increasing the number of connections created by agents.
 
 <Admonition title="Note" type="tip">
-  A Teleport agent is a Teleport instance that provides access to resources in your infrastructure, i.e., by running the SSH,
+  A Teleport Agent is a Teleport instance that provides access to resources in your infrastructure, i.e., by running the SSH,
   Kubernetes, Database, Application, or Desktop Services.
 </Admonition>
 

docs/pages/reference/backends.mdx

@@ -276,7 +276,7 @@ To configure Teleport to use PostgreSQL:
   `storage` section of `teleport.yaml` as shown below.
 - Deploy several Auth Service instances connected to the PostgreSQL storage backend.
 - Deploy several Proxy Service nodes.
-- Make sure that the Proxy Service instances and all Teleport agent services that
+- Make sure that the Proxy Service instances and all Teleport Agent services that
   connect directly to the Auth Service have the `auth_server` configuration
   setting populated with the address of a load balancer for Auth Service
   instances.
@@ -361,9 +361,10 @@ If the use of passwords is unavoidable, we recommend configuring them in [the
 `~/.pgpass` file](https://www.postgresql.org/docs/current/libpq-pgpass.html)
 rather than storing them in Teleport's configuration file.
 
-### Azure AD authentication
+### Microsoft Entra ID authentication
 
-If you are running Teleport on Azure, Teleport can make use of [Azure AD
+If you are running Teleport on Azure, Teleport can make use of [Microsoft Entra
+ID
 authentication](https://learn.microsoft.com/azure/postgresql/flexible-server/concepts-azure-ad-authentication)
 to connect to an Azure Database for PostgreSQL server without having to manage
 any secrets:
@@ -383,13 +384,13 @@ teleport:
 When `auth_mode` is set to `azure`, Teleport will automatically fetch
 short-lived tokens from the credentials available to it, to be used as database
 passwords. The database user must be [configured to allow connections using
-Azure
-AD](https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-configure-sign-in-azure-ad-authentication).
+Microsoft Entra ID](https://learn.microsoft.com/azure/postgresql/flexible-server/how-to-configure-sign-in-azure-ad-authentication).
 
-Teleport will make use of the Azure AD credentials specified by [environment
+Teleport will make use of the Microsoft Entra ID credentials specified by
+[environment
 variables](https://learn.microsoft.com/azure/developer/go/azure-sdk-authentication#2-authenticate-with-azure),
-[Azure AD Workload
-Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview)
+[Microsoft Entra Workload
+ID](https://learn.microsoft.com/azure/aks/workload-identity-overview)
 credentials, or [managed
 identity](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
 credentials.
@@ -1390,10 +1391,10 @@ to define a custom role for it.
 
 ### Authentication
 
-Teleport will make use of the Azure AD credentials specified by [environment
+Teleport will make use of the Microsoft Entra ID credentials specified by [environment
 variables](https://learn.microsoft.com/azure/developer/go/azure-sdk-authentication#2-authenticate-with-azure),
-[Azure AD Workload
-Identity](https://learn.microsoft.com/azure/aks/workload-identity-overview)
+[Microsoft Entra Workload
+ID](https://learn.microsoft.com/azure/aks/workload-identity-overview)
 credentials, or [managed
 identity](https://learn.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview)
 credentials.
@@ -1495,7 +1496,7 @@ To configure Teleport to use CockroachDB as a storage backend:
   `storage` section of `teleport.yaml` as shown below.
 - Deploy several Auth Service instances connected to the CockroachDB storage backend.
 - Deploy several Proxy Service instances.
-- Make sure that the Proxy Service instances and all Teleport agent services that
+- Make sure that the Proxy Service instances and all Teleport Agent services that
   connect directly to to the Auth Service have the `auth_server` configuration
   setting populated with the address of a load balancer for Auth Service
   instances.

docs/pages/reference/cli/tbot.mdx

@@ -154,7 +154,7 @@ $ tbot proxy --destination-dir=./tbot-user --proxy-server=proxy.example.com:3080
    - `3022` is the remote SSH port, which is `3022` for Nodes running the Teleport
      SSH service.
 
-**Example using Database Access**
+**Example using a Teleport-protected database**
 
 The following example opens a local proxy server to the given database. Your database client
 must still be configured with client TLS certificates:
@@ -192,7 +192,7 @@ using database proxies.
 | `-a/--auth-server`   | Address of the Teleport Auth Service. Prefer using --proxy-server where possible                |
 | `--proxy-server`     | Address of the Teleport Proxy Server.                                                          |
 | `--token`            | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. |
-| `--ca-pin`           | CA pin to validate the Teleport Auth Server; used on first connect.                            |
+| `--ca-pin`           | CA pin to validate the Teleport Auth Service; used on first connect.                            |
 | `--data-dir`         | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. |
 | `--destination-dir`  | Directory to write short-lived machine certificates.                                           |
 | `--certificate-ttl`  | TTL of short-lived machine certificates.                                                       |
@@ -305,7 +305,7 @@ another dedicated mode instead.
 | `-a/--auth-server`   | Address of the Teleport Auth Service. Prefer using --proxy-server where possible                |
 | `--proxy-server`     | Address of the Teleport Proxy Server.                                                          |
 | `--token`            | A bot join token, if attempting to onboard a new bot; used on first connect. Can also be an absolute path to a file containing the token. |
-| `--ca-pin`           | CA pin to validate the Teleport Auth Server; used on first connect.                            |
+| `--ca-pin`           | CA pin to validate the Teleport Auth Service; used on first connect.                            |
 | `--data-dir`         | Directory to store internal bot data. In production environments access to this directory should be limited only to an isolated linux user as an owner with `0600` permissions. |
 | `--destination-dir`  | Directory to write short-lived machine certificates.                                           |
 | `--certificate-ttl`  | TTL of short-lived machine certificates.                                                       |