Backports previously approved corrections. (#15121)24.3.0

* Backports previously approved corrections.

* Deleted a blank line in inventories line 100

5 files changed, 13 insertions, 8 deletions

diff --git a/docs/docsite/rst/administration/ent_auth.rst b/docs/docsite/rst/administration/ent_auth.rst
index e09ac9cc9f..17c95edcdc 100644
--- a/docs/docsite/rst/administration/ent_auth.rst
+++ b/docs/docsite/rst/administration/ent_auth.rst
@@ -17,7 +17,7 @@ This section describes setting up authentication for the following enterprise sy
 
    For LDAP authentication, see :ref:`ag_auth_ldap`.
 
-SAML, RADIUS, and TACACS+ users are categorized as 'Enterprise' users. The following rules apply to Enterprise users:
+Azure, RADIUS, SAML, and TACACS+ users are categorized as 'Enterprise' users. The following rules apply to Enterprise users:
 
 - Enterprise users can only be created via the first successful login attempt from remote authentication backend.
 - Enterprise users cannot be created/authenticated if non-enterprise users with the same name has already been created in AWX.
diff --git a/docs/docsite/rst/administration/ldap_auth.rst b/docs/docsite/rst/administration/ldap_auth.rst
index b13a44c869..62372d949b 100644
--- a/docs/docsite/rst/administration/ldap_auth.rst
+++ b/docs/docsite/rst/administration/ldap_auth.rst
@@ -17,7 +17,9 @@ Administrators use LDAP as a source for account authentication information for A
 
 When so configured, a user who logs in with an LDAP username and password automatically gets an AWX account created for them and they can be automatically placed into organizations as either regular users or organization administrators.
 
-Users created via an LDAP login cannot change their username, first name, last name, or set a local password for themselves. This is also tunable to restrict editing of other field names.
+Users created locally in the user interface, take precedence over those logging into controller for their first time with an alternative authentication solution. You must delete the local user if you want to re-use it with another authentication method, such as LDAP.
+
+Users created through an LDAP login cannot change their username, given name, surname, or set a local password for themselves. You can also configure this to restrict editing of other field names.
 
 To configure LDAP integration for AWX:
 
@@ -84,7 +86,7 @@ Here ``CN=josie,CN=users,DC=website,DC=com`` is the Distinguished Name of the co
   .. _`django-auth-ldap library`: https://django-auth-ldap.readthedocs.io/en/latest/groups.html#types-of-groups
 
 
-7. The **LDAP Start TLS** is disabled by default. To enable TLS when the LDAP connection is not using SSL, click the toggle to **ON**. 
+7. The **LDAP Start TLS** is disabled by default. To enable TLS when the LDAP connection is not using SSL/TLS, click the toggle to **ON**. 
 
 .. image:: ../common/images/configure-awx-auth-ldap-start-tls.png
 
diff --git a/docs/docsite/rst/administration/social_auth.rst b/docs/docsite/rst/administration/social_auth.rst
index 4138b03ec9..b9c33cde2c 100644
--- a/docs/docsite/rst/administration/social_auth.rst
+++ b/docs/docsite/rst/administration/social_auth.rst
@@ -11,13 +11,14 @@ Authentication methods help simplify logins for end users--offering single sign-
 
 Account authentication can be configured in the AWX User Interface and saved to the PostgreSQL database. For instructions, refer to the :ref:`ag_configure_awx` section. 
 
-Account authentication in AWX can be configured to centrally use OAuth2, while enterprise-level account authentication can be configured for SAML, RADIUS, or even LDAP as a source for authentication information. See :ref:`ag_ent_auth`.
+Account authentication in AWX can be configured to centrally use OAuth2, while enterprise-level account authentication can be configured for :ref:`Azure <ag_auth_azure>`, :ref:`RADIUS <ag_auth_radius>`, :ref:`SAML <ag_auth_saml>`, or even :ref:`LDAP <ag_auth_ldap>` as a source for authentication information. See :ref:`ag_ent_auth` for more detail.
 
 For websites, such as Microsoft Azure, Google or GitHub, that provide account information, account information is often implemented using the OAuth standard. OAuth is a secure authorization protocol which is commonly used in conjunction with account authentication to grant 3rd party applications a "session token" allowing them to make API calls to providers on the user’s behalf.
 
-SAML (Security Assertion Markup Language) is an XML-based, open-standard data format for exchanging account authentication and authorization data between  an identity provider and a service provider. 
+Security Assertion Markup Language (:ref:`SAML <ag_auth_saml>`) is an XML-based, open-standard data format for exchanging account authentication and authorization data between  an identity provider and a service provider. 
+
+The :ref:`RADIUS <ag_auth_radius>` distributed client/server system allows you to secure networks against unauthorized access and can be implemented in network environments requiring high levels of security while maintaining network access for remote users.
 
-The RADIUS distributed client/server system allows you to secure networks against unauthorized access and can be implemented in network environments requiring high levels of security while maintaining network access for remote users.
 
 .. _ag_auth_github:
 
diff --git a/docs/docsite/rst/userguide/inventories.rst b/docs/docsite/rst/userguide/inventories.rst
index 2807177d3f..9a2cfb1a78 100644
--- a/docs/docsite/rst/userguide/inventories.rst
+++ b/docs/docsite/rst/userguide/inventories.rst
@@ -94,10 +94,10 @@ In some situations, you can modify the following:
 
 - A new Host manually created on Inventory w/ inventory sources
 - In Groups that were created as a result of inventory source syncs
-- Variables on Host and Group are changeable
 
 Hosts associated with the Smart Inventory are manifested at view time. If the results of a Smart Inventory contains more than one host with identical hostnames, only one of the matching hosts will be included as part of the Smart Inventory, ordered by Host ID.
 
+Variables on Host and Group are not changeable even as the local system admin user.
 
 .. _ug_host_filters:
 
diff --git a/docs/docsite/rst/userguide/job_templates.rst b/docs/docsite/rst/userguide/job_templates.rst
index fbd5c99660..3980e10b26 100644
--- a/docs/docsite/rst/userguide/job_templates.rst
+++ b/docs/docsite/rst/userguide/job_templates.rst
@@ -961,6 +961,8 @@ Extra Variables
 
 When you pass survey variables, they are passed as extra variables (``extra_vars``) within AWX. This can be tricky, as passing extra variables to a job template (as you would do with a survey) can override other variables being passed from the inventory and project.
 
+By default, ``extra_vars`` are marked as ``!unsafe`` unless you specify them on the job template’s Extra Variables section. These are trusted, because they can only be added by users with enough privileges to add or edit a Job Template. For example, nested variables do not expand when entered as a prompt, as the Jinja brackets are treated as a string. For more information about unsafe variables, see `unsafe or raw strings <https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_advanced_syntax.html#unsafe-or-raw-strings>`_.
+
 For example, say that you have a defined variable for an inventory for ``debug = true``. It is entirely possible that this variable, ``debug = true``, can be overridden in a job template survey.
 
 To ensure that the variables you need to pass are not overridden, ensure they are included by redefining them in the survey. Keep in mind that extra variables can be defined at the inventory, group, and host levels. 
@@ -979,7 +981,7 @@ If specifying the ``ALLOW_JINJA_IN_EXTRA_VARS`` parameter, refer to the :ref:`AW
   The Job Template extra variables dictionary is merged with the Survey variables. 
 
 
-Here are some simplified examples of extra_vars in YAML and JSON formats:
+Here are some simplified examples of ``extra_vars`` in YAML and JSON formats:
 
 The configuration in YAML format: