Remove square brackets and fix orphaned links

doc/administration/auth/ldap-ee.md

@@ -43,7 +43,13 @@ The process will execute the following access checks:
 - Ensure the user is still present in LDAP.
 - If the LDAP server is Active Directory, ensure the user is active (not
   blocked/disabled state). This will only be checked if
-  `active_directory: true` is set in the LDAP configuration. [^1]
+  `active_directory: true` is set in the LDAP configuration.
+
+NOTE: **Note:**
+In Active Directory, a user is marked as disabled/blocked if the user
+account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
+has bit 2 set. See <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
+for more information.
 
 The user will be set to `ldap_blocked` state in GitLab if the above conditions
 fail. This means the user will not be able to login or push/pull code.
@@ -93,7 +99,7 @@ following.
    EOS
    ```
 
-1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
+1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
 **Source configuration**
 
@@ -108,7 +114,7 @@ following.
            group_base: ou=groups,dc=example,dc=com
    ```
 
-1. [Restart GitLab][restart] for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 To take advantage of group sync, group owners or maintainers will need to [create one
 or more LDAP group links](#adding-group-links).
@@ -183,7 +189,7 @@ group, as opposed to the full DN.
    EOS
    ```
 
-1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
+1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
 **Source configuration**
 
@@ -199,7 +205,7 @@ group, as opposed to the full DN.
            admin_group: my_admin_group
    ```
 
-1. [Restart GitLab][restart] for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Global group memberships lock
 
@@ -318,7 +324,7 @@ task.
    EOS
    ```
 
-1. [Reconfigure GitLab][reconfigure] for the changes to take effect.
+1. [Apply your changes to GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
 
 **Source configuration**
 
@@ -333,7 +339,7 @@ task.
            external_groups: ['interns', 'contractors']
    ```
 
-1. [Restart GitLab][restart] for the changes to take effect.
+1. [Restart GitLab](../restart_gitlab.md#installations-from-source) for the changes to take effect.
 
 ## Group sync technical details
 

doc/administration/auth/ldap-troubleshooting.md

@@ -84,7 +84,7 @@ following is most likely true:
 
 - The `bind_dn` user doesn't have enough permissions to traverse the user tree.
 - The user(s) don't fall under the [configured `base`](ldap.md#configuration).
-- The [configured `user_filter`][user-filter] blocks access to the user(s).
+- The [configured `user_filter`](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server) blocks access to the user(s).
 
 In this case, you con confirm which of the above is true using
 [ldapsearch](#ldapsearch) with the existing LDAP configuration in your
@@ -97,7 +97,7 @@ here are some questions to ask yourself:
 
 - Does the user fall under the [configured `base`](ldap.md#configuration) in
   LDAP? The user must fall under this `base` to login.
-- Does the user pass through the [configured `user_filter`][user-filter]?
+- Does the user pass through the [configured `user_filter`](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server)?
   If one is not configured, this question can be ignored. If it is, then the
   user must also pass through this filter to be allowed to login.
   - Refer to our docs on [debugging the `user_filter`](#debug-ldap-user-filter).
@@ -132,7 +132,7 @@ are true for the user in question:
 #### Email has already been taken
 
 A user tries to login with the correct LDAP credentials, is denied access,
-and the [production.log][production-log] shows an error that looks like this:
+and the [production.log](../logs.md#productionlog) shows an error that looks like this:
 
 ```plaintext
 (LDAP) Error saving user <USER DN> (email@example.com): ["Email has already been taken"]
@@ -168,7 +168,7 @@ profile](../../user/profile/index.md#user-profile) or an admin can do it.
 #### Debug LDAP user filter
 
 [`ldapsearch`](#ldapsearch) allows you to test your configured
-[user filter][user-filter]
+[user filter](ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server)
 to confirm that it returns the users you expect it to return.
 
 ```shell
@@ -184,7 +184,7 @@ ldapsearch -H ldaps://$host:$port -D "$bind_dn" -y bind_dn_password.txt  -b "$ba
 
 #### Sync all users **(STARTER ONLY)**
 
-The output from a manual [user sync][user-sync] can show you what happens when
+The output from a manual [user sync](ldap-ee.md#user-sync) can show you what happens when
 GitLab tries to sync its users against LDAP. Enter the [rails console](#rails-console)
 and then run:
 
@@ -297,9 +297,9 @@ LDAP group sync, but for some reason it's not happening. There are several
 things to check to debug the situation.
 
 - Ensure LDAP configuration has a `group_base` specified.
-  [This configuration][group-sync] is required for group sync to work properly.
+  [This configuration](ldap-ee.md#group-sync) is required for group sync to work properly.
 - Ensure the correct [LDAP group link is added to the GitLab
-  group][group-links].
+  group](ldap-ee.md#adding-group-links).
 - Check that the user has an LDAP identity:
   1. Sign in to GitLab as an administrator user.
   1. Navigate to **Admin area -> Users**.
@@ -312,7 +312,7 @@ things to check to debug the situation.
   interval](ldap-ee.md#adjusting-ldap-group-sync-schedule) for the group to
   sync. To speed up the process, either go to the GitLab group **Settings ->
   Members** and press **Sync now** (sync one group) or [run the group sync Rake
-  task][group-sync-rake] (sync all groups).
+  task](../raketasks/ldap.md#run-a-group-sync) (sync all groups).
 
 If all of the above looks good, jump in to a little more advanced debugging in
 the rails console.
@@ -352,9 +352,9 @@ GitLab syncs the `admin_group`.
 
 NOTE: **NOTE:**
 To sync all groups manually when debugging is unnecessary, [use the Rake
-task][group-sync-rake] instead.
+task](../raketasks/ldap.md#run-a-group-sync) instead.
 
-The output from a manual [group sync][group-sync] can show you what happens
+The output from a manual [group sync](ldap-ee.md#group-sync) can show you what happens
 when GitLab syncs its LDAP group memberships against LDAP.
 
 ```ruby
@@ -449,7 +449,7 @@ this line will indicate the sync is finished:
 Finished syncing admin users for 'ldapmain' provider
 ```
 
-If [admin sync][admin-sync] is not configured, you'll see a message
+If [admin sync](ldap-ee.md#administrator-sync) is not configured, you'll see a message
 stating as such:
 
 ```shell
@@ -541,7 +541,7 @@ for each of these users.
 
 ### LDAP check
 
-The [Rake task to check LDAP][ldap-check] is a valuable tool
+The [Rake task to check LDAP](../raketasks/ldap.md#check) is a valuable tool
 to help determine whether GitLab can successfully establish a connection to
 LDAP and can get so far as to even read users.
 
@@ -561,11 +561,11 @@ users, [see what to do when no users are found](#no-users-are-found).
 ### GitLab logs
 
 If a user account is blocked or unblocked due to the LDAP configuration, a
-message will be [logged to `application.log`][application-log].
+message will be [logged to `application.log`](../logs.md#applicationlog).
 
 If there is an unexpected error during an LDAP lookup (configuration error,
 timeout), the login is rejected and a message will be [logged to
-`production.log`][production-log].
+`production.log`](../logs.md#productionlog).
 
 ### ldapsearch
 
@@ -649,24 +649,3 @@ console](#rails-console) and run:
 ```ruby
 Rails.logger.level = Logger::DEBUG
 ```
-
-<!-- LINK REFERENCES -->
-
-[tail-logs]: https://docs.gitlab.com/omnibus/settings/logs.html#tail-logs-in-a-console-on-the-server
-[production-log]: ../logs.md#productionlog
-[application-log]: ../logs.md#applicationlog
-[reconfigure]: ../restart_gitlab.md#omnibus-gitlab-reconfigure
-[restart]: ../restart_gitlab.md#installations-from-source
-[ldap-check]: ../raketasks/ldap.md#check
-[group-sync-rake]: ../raketasks/ldap.md#run-a-group-sync
-[user-filter]: ldap.md#using-an-ldap-filter-to-limit-access-to-your-gitlab-server
-[user-sync]: ldap-ee.md#user-sync
-[group-sync]: ldap-ee.md#group-sync
-[admin-sync]: ldap-ee.md#administrator-sync
-[config]: ldap.md#configuration
-[group-links]: ldap-ee.md#adding-group-links
-
-[^1]: In Active Directory, a user is marked as disabled/blocked if the user
-      account control attribute (`userAccountControl:1.2.840.113556.1.4.803`)
-      has bit 2 set. See <https://ctogonewild.com/2009/09/03/bitmask-searches-in-ldap/>
-      for more information.

doc/user/application_security/container_scanning/index.md

@@ -38,9 +38,9 @@ Having an extra job in your pipeline that checks for those vulnerabilities,
 and the fact that they are displayed inside a merge request, makes it very easy
 to perform audits for your Docker-based apps.
 
-[//]: # "NOTE: The container scanning tool references the following heading in the code, so if you"
-[//]: # "      make a change to this heading, make sure to update the documentation URLs used in the"
-[//]: # "      container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar)"
+<!-- NOTE: The container scanning tool references the following heading in the code, so if you
+           make a change to this heading, make sure to update the documentation URLs used in the
+           container scanning tool (https://gitlab.com/gitlab-org/security-products/analyzers/klar) -->
 
 ## Requirements