Merge branch 'doc_new_admin_area' into 'master'

Move admin application settings to own path

Move existing documentation to its own `user/admin_area/settings` path.

See merge request !5420

5 files changed, 62 insertions, 0 deletions

diff --git a/doc/user/admin_area/settings/img/access_restrictions.png b/doc/user/admin_area/settings/img/access_restrictions.png
new file mode 100644
index 00000000000..8eea84320d7
--- /dev/null
+++ b/doc/user/admin_area/settings/img/access_restrictions.png
diff --git a/doc/user/admin_area/settings/img/domain_blacklist.png b/doc/user/admin_area/settings/img/domain_blacklist.png
new file mode 100644
index 00000000000..bd87b73cf9e
--- /dev/null
+++ b/doc/user/admin_area/settings/img/domain_blacklist.png
diff --git a/doc/user/admin_area/settings/img/restricted_url.png b/doc/user/admin_area/settings/img/restricted_url.png
new file mode 100644
index 00000000000..8b00a18320b
--- /dev/null
+++ b/doc/user/admin_area/settings/img/restricted_url.png
diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md
new file mode 100644
index 00000000000..4b540473a6e
--- /dev/null
+++ b/doc/user/admin_area/settings/sign_up_restrictions.md
@@ -0,0 +1,22 @@
+# Sign-up restrictions
+
+## Blacklist email domains
+
+> [Introduced][ce-5259] in GitLab 8.10.
+
+With this feature enabled, you can block email addresses of a specific domain
+from creating an account on your GitLab server. This is particularly useful to
+prevent spam. Disposable email addresses are usually used by malicious users to
+create dummy accounts and spam issues.
+
+This feature can be activated via the **Application Settings** in the Admin area,
+and you have the option of entering the list manually, or uploading a file with
+the list.
+
+The blacklist accepts wildcards, so you can use `*.test.com` to block every
+`test.com` subdomain, or `*.io` to block all domains ending in `.io`. Domains
+should be separated by a whitespace, semicolon, comma, or a new line.
+
+![Domain Blacklist](img/domain_blacklist.png)
+
+[ce-5259]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/5259
diff --git a/doc/user/admin_area/settings/visibility_and_access_controls.md b/doc/user/admin_area/settings/visibility_and_access_controls.md
new file mode 100644
index 00000000000..633f16a617c
--- /dev/null
+++ b/doc/user/admin_area/settings/visibility_and_access_controls.md
@@ -0,0 +1,40 @@
+# Visibility and access controls
+
+## Enabled Git access protocols
+
+> [Introduced][ce-4696] in GitLab 8.10.
+
+With GitLab's Access restrictions you can choose which Git access protocols you
+want your users to use to communicate with GitLab. This feature can be enabled
+via the `Application Settings` in the Admin interface.
+
+The setting is called `Enabled Git access protocols`, and it gives you the option
+to choose between:
+
+- Both SSH and HTTP(S)
+- Only SSH
+- Only HTTP(s)
+
+![Settings Overview](img/access_restrictions.png)
+
+When both SSH and HTTP(S) are enabled, GitLab will behave as usual, it will give
+your users the option to choose which protocol they would like to use.
+
+When you choose to allow only one of the protocols, a couple of things will happen:
+
+- The project page will only show the allowed protocol's URL, with no option to
+  change it.
+- A tooltip will be shown when you hover over the URL's protocol, if an action
+  on the user's part is required, e.g. adding an SSH key, or setting a password.
+
+![Project URL with SSH only access](img/restricted_url.png)
+
+On top of these UI restrictions, GitLab will deny all Git actions on the protocol
+not selected.
+
+> **Note:** Please keep in mind that disabling an access protocol does not actually
+  block access to the server itself. The ports used for the protocol, be it SSH or
+  HTTP, will still be accessible. What GitLab does is restrict access on the
+  application level.
+
+[ce-4696]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/4696