Настройте почтовый сервер с postfixadmin

Защита SMTP с помощью SSL

The certificates for use with postfix should be stored in /etc/ssl/postfix/ or if using the same certificates as with courier-imap they should be stored in /etc/ssl/postfix/. If using CACert.org, then its root certificate needs to be used. Gentoo pre-installs the CACert.org root certificate and should be used.

Файл Настройка сертификата для SMTP

# SSL Authentication
smtpd_tls_security_level = may
smtpd_tls_auth_only = no
smtpd_tls_loglevel = 3
smtpd_tls_key_file = /etc/ssl/postfix/foo.example.com_privatekey.pem
smtpd_tls_cert_file = /etc/ssl/postfix/foo.example.com_crt.pem
smtpd_tls_CAfile = /etc/ssl/certs/cacert.org_root.pem
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

ЗаметкаFor debugging purposes has been increased to 3. Also means users (and webmail) can still log in insecurely. Putting this option to yes forces all clients to use only authenticated connections.

ЗаметкаThe CaCert file is renamed in /etc/ssl/certs/cacert.org_root.pem, it used to be named as /etc/ssl/certs/cacert.org.pem.

Now STARTTLS can be used to use an authenticated connection over port 25. SSL/TLS support on port 465 (smtps) however should be enabled as well. Courier-imap did this automatically, postfix needs a change to master.cf:

Файл Включение поддержки smtps

smtps     inet  n       -       n       -       -       smtpd
  -o smtpd_tls_wrappermode=yes

Перезапустите postfix, чтобы запустить демонов в защищенном SSL-режиме:

Maintaining security

Configuring and maintaining a secure Postfix SMTP server only requires a basic understanding of the components, but simple mistakes in the setup can render the security settings ineffective, therefore most important part is to make sure the server does not become an open relay. Conveniently MX Toolbox, an online network testing utility, provides an SMTP diagnostics tool with which you can easily test your configuration by just entering your mail server domain name such as mail.example.com. With the setup used in this guide, everything should show green in their tests, granted that the DNS rules have propagated.

While a configuration helps to keep your SMTP server secure, strong user passwords are also very important. In such a case that a third party was to gain unauthorised access to one of the user account, they would be able to send spam messages unhindered using your infrastructure and tarnish your network reputation. A common way to reduce the chance of someone guessing your user’s passwords is to impose limitations to failed logging attempts with Fail2ban. You can read more about install Fail2ban on Ubuntu in its own article to further improve the server security.

General good usage practices can also bring your server security a long way. In addition to the aforementioned security methods, Linux systems offer documentation ways to minimise vulnerabilities and harden your cloud server against abuse. Take a look at our introductory guide on how to secure your Linux cloud server if you wish to learn more.

Без шифрования

Устанавливаем dovecot.

а) если используем CentOS / Red Hat:

yum install dovecot

б) если используем Ubuntu / Debian:

apt-get install dovecot-imapd dovecot-pop3d

Открываем конфигурационный файл Postfix:

vi /etc/postfix/main.cf

И добавляем:

smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = dovecot
smtpd_relay_restrictions = permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination

* где smtpd_sasl_path — путь до плагина аутентификации по механизму SASL; smtpd_sasl_auth_enable — разрешает или запрещает аутентификацию по механизму SASL; smtpd_sasl_type — тип плагина, который используется для SASL-аутентификации; smtpd_relay_restrictions — правила разрешения и запрета использования MTA при пересылке.

Открываем настройки аутентификации в dovecot:

vi /etc/dovecot/conf.d/10-master.conf

и приводим опцию service auth к следующему виду:

service auth {
  …
  unix_listener /var/spool/postfix/private/auth {
    mode = 0660
    user = postfix
    group = postfix
  }
  …
}

* если соответствующей секции unix_listener нет, то ее нужно создать.

Отключаем требование ssl для аутентификации:

vi /etc/dovecot/conf.d/10-ssl.conf

ssl = no

Настройки аутентификации приводим к следующему виду:

vi /etc/dovecot/conf.d/10-auth.conf

auth_mechanisms = plain login

В этом же файле проверяем, что снят комментарий со следующей строки:

!include auth-system.conf.ext

Перезапускаем сервис Postfix:

systemctl restart postfix

Запускаем Dovecot:

systemctl enable dovecot

systemctl start dovecot

Готово. В качестве логина и пароля необходимо использовать системную учетную запись.

Как настроить отсылку уведомлений на внешний почтовый сервер с помощью msmtp в Debian 10 (Buster)

Не смотря на то, что в документе указано то, что Exim поставляется в Debian Linux по умолчанию, как это было в предыдущих версиях Debain, свежеустановленный Debian Buster не имеет никакого ПО для отправки электронной почты за пределы сервера.

Предположим, у нас в организации уже имеется почтовый сервер и нам нужно сделать так, чтобы письма, сформированные всевозможными локальными службами и приложениями на нашей Linux-системе, пересылались на этот почтовый сервер (relayhost/smarthost).

Для решения этой задачи мы можем установить в систему простой и легковесный почтовый клиент, умеющий выполнять такую пересылку — msmtp:

# apt install msmtp

Конфигурационные файлы для работы msmtp могут быть, как глобальные на уровне системы, так и на уровне отдельно взятого пользователя системы.

Глобальный файл может располагаться в .

Файл настроек пользователя может размещаться в профиле в .

Получить информацию о настройке конфигурации msmtp можно в man msmtp.

Примеры конфиг.файлов для системы и пользователя лежат здесь:

# locate msmtprc

Скопируем примерный конфиг.файл уровня системы и откроем его на редактирование:

# cp /usr/share/doc/msmtp/examples/msmtprc-system.example /etc/msmtprc
# nano /etc/msmtprc

Задаём в файле адрес внешнего почтового сервера в опциях / , а также при необходимости добавляем поле , в котором указывается имя отправителя почты на тот случай, если в внутренний почтовый сервер использует проверку имён отправителя.

Пример заполненного файла:

msmtprc
# Example for a system wide configuration file
 
# A system wide configuration file is optional.
# If it exists, it usually defines a default account.
# This allows msmtp to be used like /usr/sbin/sendmail.
account default
 
# The SMTP smarthost
host kom-smtp.holding.com
port 25
 
# Use TLS on port 465
#port 465
#tls on
#tls_starttls off
 
# Construct envelope-from addresses of the form "user@oursite.example"
#auto_from on
#maildomain oursite.example
 
from KOM-DL20@holding.com
 
# Syslog logging with facility LOG_MAIL instead of the default LOG_USER
syslog LOG_MAIL

Сохраняем конфигурационный файл и тестируем отправку с помощью msmtp:

# echo -e "Subject: mSMTP Test" | msmtp DST-Monitoring@holding.com

Должно прийти письмо с адреса, указанного в опции в конфиг.файле .

Если письмо не приходит, то можно проанализировать лог отправки:

# cat /var/log/mail.log

Клиент msmtp это sendmail-совместимое приложение, поэтому для любых служб и приложений сервера, использующих вызов sendmail мы сделаем перенаправление на msmtp.

Для начала убедимся в том, что в системе нет действующих ссылок на :

# ls -la /usr/sbin/sendmail

Слинкуем sendmail с клиентом msmtp:

# ln -s /usr/bin/msmtp /usr/sbin/sendmail
# ls -la /usr/sbin/sendmail

Теперь можно протестировать приложения, использующие отправку почты.

Например, если в системе сконфигурированы программные RAID-массивы mdraid и настроена и сконфигурирована служба оповещений mdmonitor (опции и в ), то можем инициировать разовый тест состояния RAID-устройств с отправкой оповещения:

# mdadm --monitor --scan --test --oneshot

В результате по каждому из устройств mdraid мы должны получить по отдельному письму. Если это произошло, значит настроенный нами механизм оповещений через msmtp работает успешно.

Дополнительные источники информации:

Автор первичной редакции:Алексей Максимов
Время публикации: 21.08.2020 18:22

Связь, электричество, бэкапы

Дома, в отличие от датацентра возможны перебои электричества, поэтому нужен ИБП с батареей на несколько часов работы сервера и роутера. От этого же электричества зависит работа оборудования внутридомового провайдера, поэтому ИБП для домашнего сервера не решает проблему отключения провайдерского оборудования и интернета вместе с электричеством. Получается, что на домашний роутер должно быть заведено два провайдера: основной (например, по витой паре или оптике) и резервный (через LTE модем). В разных роутерах процесс настройки выглядит по разному, но суть не меняется. Для резервного интернет-канала я взял LTE модем Huawei E3372-320. Свисток хорош тем, что есть в свободной продаже в разлоченном виде и он оснащен разъемами для внешних антенн, что в некоторых ситуациях может сильно улучшить качество связи.

Однако, с двумя провайдерами у вас будет два разных серых IP адреса, а почтовому серверу нужно нормальное доменное имя и по хорошему белый IP. Выход из ситуации у меня такой: арендуется виртуальный сервер (VPS) за границей, на нем настраивается VPN-сервер, а на почтовом сервере настраивается туннель до VPS. Кроме того, туннель можно поднять прямо с домашнего роутера (если он умеет) и таким образом ликвидируется сразу два зайца: мы получаем статический белый IP не зависящий от локальных провайдеров, а после тюнинга маршрутизации на роутере ‒ централизованный обход блокировок Роскомпозора для всех устройств домашней сети. Схема получается примерно такая:

Будет не очень весело, если жесткий диск домашнего сервера неожиданно накроется вместе со всей почтой. Поэтому необходимость бэкапов сервера даже не обсуждается. О настройке бэкапов поговорим в конце статьи.

1 Защита веб-почты

Когда вы входите в свой почтовый ящик через веб-почту, устанавливается соединение между вашим браузером и веб-почтой, запущенной на веб-сервере. Чтобы защитить пересылаемые письма и учетные записи почты от взлома, по умолчанию выполняется защита веб-почты с помощью того же самозаверенного SSL/TLS-сертификата, что используется для защиты Plesk. Самозаверенный SSL/TLS-сертификат шифрует передаваемые данные, но каждый раз при входе в веб-почту вы видите предупреждение о том, что используется ненадежный SSL/TLS-сертификат. Чтобы это предупреждение больше не показывалось, защитите веб-почту с помощью действительного SSL/TLS-сертификата.

Чтобы защитить веб-почту с помощью SSL/TLS-сертификата:

  1. Получите подстановочный SSL/TLS-сертификат или сертификат SAN, который позволяет настроить имя в SAN. Для этого у вас есть несколько возможностей:

    Получить бесплатный подстановочный сертификат от Let’s Encrypt. Если вы выберете эту опцию, пропустите шаг 2.

    Примечание: Мы настоятельно рекомендуем вам использовать эту опцию, так как с помощью одного подстановочного сертификата вы можете защитить все необходимые почтовые соединения.

    • Загрузить сертификат, который у вас уже есть.
  2. Перейдите в раздел Почта > вкладка «Настройки почты», нажмите имя домена, выберите SSL/TLS-сертификат для веб-почты и нажмите OK.

Install an SSL Certificate on Postfix

After your CA validates your SSL request and sends the necessary SSL files to your inbox, you can begin the SSL installation. Please, perform the following:

Prepare your SSL files

Postfix supports SSL Certificates in X.509 format. A correct installation requires the following files:

  • Your private key file: you’ve generated the key file along with the CSR code on your server
  • Your primary SSL Certificate: it resides in the ZIP archived folder you’ve received from the CA. Check your email and download, then extract your SSL Certificate. For the purpose of this demonstration, we’ll name the primary SSL certificate file .crt
  • The intermediate CA: this is the CA bundle (.ca-bundle) file from the same ZIP folder as your SSL Certificate. In our case, we’ll name the file intca.crt

Note: you can place all three files in a single directory. For example, /etc/postfix.

To add the SSL Certificate to Postfix, follow the steps below:

Merge the SS Certificate and intermediate CA in a single file by running the following command:

For the email reception part (SMTP server):

smtpd_tls_cert_file = /path/to/your/server.crt
smtpd_tls_key_file = /path/to/your/privatekey.key
# TLS activation
smtpd_tls_security_level = may	
# recommanded for log details
smtpd_tls_loglevel = 1
# recommanded for tracing TLS headers
smtpd_tls_received_header = yes
smtpd_tls_exclude_ciphers = NULL, aNULL, RC4, 3DES, eNULL, DHE_EXPORT
smtpd_tls_mandatory_ciphers = high
smtpd_tls_ciphers = medium
smtpd_tls_protocols = !SSLv2, !SSLv3

For the email delivery part (SMTP client):

smtp_tls_security_level = may
# recommended for having log details
smtp_tls_loglevel = 1
smtp_tls_exclude_ciphers = NULL, aNULL, RC4, 3DES, eNULL, DHE_EXPORT
smtp_tls_mandatory_ciphers = high
smtp_tls_ciphers = medium
smtp_tls_protocols = !SSLv2, !SSLv3

Edit the master.cf file and ensure the follow instruction is uncommented

tlsmgr    unix  -       -       n       1000?   1       tlsmgr

Congratulations, you’ve successfully installed an SSL Certificate on Postfix.

Configuring Dovecot

Postfix supports two SASL implementations, that are used for authentication, Cyrus and Dovecot. Of these two, Dovecot is relatively simple to configure and was therefore selected for this guide. To enable Dovecot SASL you will need to install the dovecot-common package. You might also wish to install the Dovecot plugins for IMAP and POP3 to allow connections from mail clients such as Thunderbird or Outlook.

sudo apt install dovecot-common dovecot-imapd dovecot-pop3d

Once installed, you will need to make some changes to a few of the configuration files. Dovecot configuration is split between a number of files under /etc/dovecot/conf.d/. To enable the required security features, make the changes and indicated below to the next four .conf files.

Start by disabling the plaintext authentication at the top and enabling login authentication mechanism near the end of the auth.conf file.

sudo nano /etc/dovecot/conf.d/10-auth.conf
disable_plaintext_auth = yes
...
auth_mechanisms = plain login
sudo nano /etc/dovecot/conf.d/10-mail.conf
mail_location = maildir:~/Maildir
sudo nano /etc/dovecot/conf.d/10-master.conf
service imap-login {
   inet_listener imap {
      port = 143
   }
...
}
service pop3-login {
   inet_listener pop3 {
      port = 110
   }
   ...
}
...
service auth {
...
   # Postfix smtp-auth
   unix_listener /var/spool/postfix/private/auth {
      mode = 0660
      user = postfix
      group = postfix
}

You will also need to include your certificates in the Dovecot ssl.conf file, replace the <mail.example.com> with your server’s domain name. Select to require SSL and also disable the insecure SSLv2 and SSLv3 protocols.

sudo nano /etc/dovecot/conf.d/10-ssl.conf
# SSL/TLS support: yes, no, required. <doc/wiki/SSL.txt>
ssl = required
...
ssl_cert = </etc/letsencrypt/live/<mail.example.com>/fullchain.pem
ssl_key = </etc/letsencrypt/live/<mail.example.com>/privkey.pem
...
# SSL protocols to use
ssl_protocols = !SSLv2 !SSLv3

When you are done editing the files, you can check the Dovecot configuration with the following command.

dovecot -n

Once everything looks correct, restart Dovecot to apply the new settings.

sudo systemctl restart dovecot

Creating DNS records

For example, you could add a subdomain for your SMTP server such as mail.example.com and enable an MX record that points to that subdomain.

The records that you will need to configure:

  • DNS A record, that maps your domain name to the server’s public IP address.
    example.com   A    83.136.253.111
  • MX record, which will tell other mail servers where messages send to your domain should be delivered.
    example.com   MX   1   mail.example.com.
    @             MX   2   mail.example.com.
  • Reverse DNS record, that allows servers to check what domain your server’s IP address belongs to.

You can set the reverse DNS name per public IP address at your UpCloud control panel under Server settings and IP Addresses tab.

Команды

Проверка синтаксиса postfix -c ПУТЬ_К_ФАЙЛУ_НАСТРОЕК_main.cf check
Состояние очереди postqueue -c ПУТЬ_К_ФАЙЛУ_НАСТРОЕК_main.cf -p
Обработка очереди немедленно postqueue -c ПУТЬ_К_ФАЙЛУ_НАСТРОЕК_main.cf -f
Очистка очереди postsuper -c ПУТЬ_К_ФАЙЛУ_НАСТРОЕК_main.cf -d ALL
Тест адресации postmap -q address@domail.ru ldap:/etc/postfix/ldap-users.cf

Работа с несколькими экземплярами

При решении некоторых задач можно воспользоваться возможностью работы с несколькими экземплярами (instance) сервера.

Для работы нужно добавить такие строки:/etc/postfix/main.cf

multi_instance_enable = yes
multi_instance_wrapper = ${command_directory}/postmulti -p -g ИМЯ_ГРУППЫ reload
multi_instance_directories = /etc/postfix-mx /etc/postfix-1 /etc/postfix-n

1
2
3

multi_instance_enable=yes

multi_instance_wrapper=${command_directory}postmulti-p-gИМЯ_ГРУППЫreload

multi_instance_directories=etcpostfix-mxetcpostfix-1etcpostfix-n

в переменной 
multi_instance_directories указывается экземпляры программы, в примере использованы следующие:

  • etcpostfix-mx
  • etcpostfix-1
  • etcpostfix-n

Для того, чтобы при запуске/останове и перезапуске Postfix и по команде

service postfix …

1 service postfix…

нужно параметре 
multi_instance_wrapper нужно указать имя группы (
ИМЯ_ГРУППЫ) в куда входя нужные экземпляров программы.

Также для того, чтобы разрешить работу с несколькими экземплярами можно использовать команду

postmulti -e init

1 postmulti-einit

Для управления служит программа 
postmulti.

Примеры:

Создание postmulti -I ИМЯ_ЭКЗЕМПЛЯРА -G ИМЯ_ГРУППЫ -e create
Активация postmulti -i ИМЯ_ЭКЗЕМПЛЯРА -e enable
Управление экземпляром postmulti -i ИМЯ_ЭКЗЕМПЛЯРА -p КОМАНДА

Безопасность

mynetworks список подсетей с которых разрешена отправка через этот сервер
disable_vrfy_command=yes Клиент, подключившийся к серверу, может командой 
vrfy user@domain.ru определить, существует ли заданный адрес в системе
show_user_unknown_table_name=no При попытке клиента отправить письмо несуществующему пользователю по умолчанию сервер выдаст 
550(reject) с сообщением 
user unknown inlocal recipient table (или другой таблице). Отключаем, пусть сервер сообщает 
user unknown
smtpd_helo_required=yes Требуем от клиента приветствия (HELO/EHLO). Все, кто подключается, должны представляться
smtpd_helo_restrictions= permit_mynetworks, permit_sasl_authenticated, reject_invalid_hostname, reject_non_fqdn_hostname, reject_invalid_helo_hostname, reject_unknown_helo_hostname Ограничения для этапа 
HELOEHLO. Применяются к имени хоста, его IP-адресу и приветствию 
HELOEHLO:Разрешаем доверенные сетиРазрешаем тем, кто прошёл аутентификациюОтбрасываем неправильное (несуществующее) имя хостаОтбрасываем не полностью определённое доменное имя хостаОтбрасываем, если хост по HELO/EHLO не имеет А или МХ записи
smtpd_sender_restrictions= reject_non_fqdn_sender, reject_unknown_sender_domain, reject_unlisted_sender, permit_mynetworks, permit_sasl_authenticated Ограничения для этапа MAIL FROM. Применяется ко всему предыдущему + имя отправителя:Отбрасываем не полностью определённое имя отправителяОтбрасываем отправителя с несуществующего доменаОтбрасываем несуществующих отправителейПроверяем отправителя. Если с нашего домена, то проверим, находится ли он в доверенной сети или прошёл аутентификациюРазрешаем отправлять с доверенных сетейРазрешаем отправлять прошедшим аутентификацию
smtpd_recipient_restrictions= reject_non_fqdn_recipient, reject_unknown_recipient_domain, reject_unlisted_recipient, permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination reject_invalid_hostname Ограничения для этапа RCPT TO. Применяется к предыдущему + имя получателя:reject, если получатель отсутствует в списке нашего домена или списке пересылки. Чтобы сервер не стал открытым 
relay
smtpd_data_restrictions= reject_unauth_pipelining, reject_multi_recipient_bounce Ограничения для этапа DATA:Отвергаем запрос, когда клиент посылает команды SMTP раньше времениreject клиента с пустым именем отправителя, который отправляет сразу нескольким получателям
smtpd_etrn_restrictions= permit_mynetworks, permit_sasl_authenticated, reject Ограничиваем клиентов, которые могут запрашивать очистку очереди сообщений

SSL-сертификат, центр сертификации.

Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат. Технология шифрования не зависит от сертификатов, но они необходимы для того, чтобы гарантировать, что общаться друг с другом будут только те хосты, которые действительно намеревались это сделать. Если каждый из хостов может проверить сертификат другого, то они договариваются о шифровании сеанса. В противном случае они полностью отказываются от шифрования и формируют предупреждение, т.к. отсутствует Аутентичность.

Центр сертификации или Удостоверяющий центр (англ. Certification authority, CA) — это организация или подразделение организации, которая выпускает сертификаты ключей электронной цифровой подписи, это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится центрами сертификации в виде цифровых сертификатов, имеющих следующую структуру:

  • Серийный номер сертификата;
  • Объектный идентификатор алгоритма электронной подписи;
  • Имя удостоверяющего центра;
  • Срок годности;
  • Имя владельца сертификата (имя пользователя, которому принадлежит сертификат);
  • Открытые ключи владельца сертификата (ключей может быть несколько);

Сертификат также содержит полностью определенное имя домена (FQDN RFC 821) в строке Common Name. Одна из возможных атак — подмена DNS — будет обнаружена до отправки данных.

Виды SSL- сертификатов

Выделяют различные виды SSL- сертификатов в зависимости от типа проверки:

  • Сертификаты с проверкой домена – подтверждают подлинность доменного имени. Не содержат информации о компании.
  • Сертификаты с проверкой компании – содержат информацию не только о домене, но и о компании, которой выдан сертификат. Пользуются большим доверием у пользователей.
  • Сертификаты на домен и поддомены (Wildcard SSL) – обеспечивают защиту неограниченного количества субдоменов одним сертификатом. Сертификат выдается на определенное доменное имя и при этом защищает все поддомены. Данные сертификаты могут быть как с проверкой домена, так и с проверкой организации.
  • Сертификаты с расширенной проверкой организации (Extended Validation SSL (EV SSL)) – обеспечивают наивысшее доверие клиентов. Когда пользователь находится на сайте с EV SSL сертификатом, браузер подсвечивает адресную строку зеленым цветом.

Wildcard SSL — сертификаты — это сертификаты, защищающие не только основной домен(ваш_домен.ру), но и поддомены(www.ваш_домен.ру, ssl.ваш_домен.ру, secure.ваш_домен.ру и т.д.). Может использоваться на веб-сервере и почтовом сервере. При генерации запроса на Wildcard сертификат в качестве Common Name (CN) используйте «*.domain.com», где domain.com — это ваше доменное имя.

Скачайте и настройте Postfix Admin

На момент написания это последняя стабильная версия Postfix Admin.

Загрузите архив Postfix Admin, используя следующую команду wget :

После завершения загрузки извлеките архив :

Переместите исходные файлы Postfix Admin в каталог и создайте каталог (smarty cache):

И Nginx, и PHP-FPM работают с пользовательскими поэтому нам нужно изменить владельца на этого пользователя:

Postfix Admin будет использовать базу данных MySQL для хранения информации о пользователях, доменах и конфигурации приложения.

Войдите в оболочку MySQL :

Создайте нового пользователя MySQL и базу данных, используя следующие команды:

Не забудьте изменить пароль ( ) на более безопасный.

Вместо редактирования конфигурации администратора Postfix по умолчанию мы создадим новый файл с именем который перезапишет настройки приложения по умолчанию:

Откройте файл с вашим текстовым файлом:

Вставьте следующий код php:

/var/www/postfixadmin/config.local.php

Сохраните и закройте файл.

В приведенной выше конфигурации мы определяем тип базы данных и учетные данные для входа. Кроме того, мы указываем псевдонимы по умолчанию, отключаем и включаем квоту.

Затем выполните следующую команду, чтобы создать схему для базы данных Postfix Admin:

После того , как база данных заполнена, мы можем пойти дальше и создать наш первый пользователь PostfixAdmin SuperAdmin используя инструмент.

Этот пользователь будет иметь права администратора для изменения любого домена или настройки приложения.

Результат должен выглядеть примерно так:

Не забудьте изменить пароль ( ) для учетной записи на более безопасный.

Рейтинг
( Пока оценок нет )
Понравилась статья? Поделиться с друзьями:
Техноарена
Добавить комментарий

;-) :| :x :twisted: :smile: :shock: :sad: :roll: :razz: :oops: :o :mrgreen: :lol: :idea: :grin: :evil: :cry: :cool: :arrow: :???: :?: :!: