Я пытаюсь настроить свой Debian-сервер в качестве контроллера домена Active Directory с помощью Samba 4.5. После прохождения предоставления домена samba-tool --use-rfc2307 --interactive
служба Samba не запускается и выдача systemctl start samba
сообщает, что служба samba замаскирована и systemctl unmask samba
ничего не делает, служба по-прежнему замаскирована.
Согласно https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837679 тогда маскировка службы Samba задумано, но, насколько я понимаю, после подготовки сервера в качестве AD DC эта служба должна быть демаскирована, но у меня этого не происходит, и мне интересно, почему? Насколько я понимаю, эта служба должна быть запущена для запуска всех других служб, которые необходимы, чтобы мои клиенты могли найти сервер в качестве контроллера домена и подключиться к домену, чего они сейчас не делают.
Вот мой кого-л. но все иностранные пользователи не могли доверять подключение своего Outlook или браузера к веб-приложению OWA. Я купил подстановочный сертификат для ...
До сих пор я использовал сертификат, подписанный локальным ЦС для моего Exchange, но все иностранные пользователи не могли доверять соединение своего Outlook или браузера с веб-приложением OWA.
Я купил подстановочный знак сертификат для моего общедоступного домена mydomain.com (который отличается от моего локального доменного имени mydomain.local), и я хочу использовать его для служб Exchange.
Я узнал, что не могу использовать разные сертификаты для внутреннего / внешнего соединения, поэтому я решил позволить локальному пользователю использовать внешний адрес и создать зону для пересылки в локальном DNS. Итак, все используют одно имя для доступа к серверу Exchange: mbox.mydomain.com
Я изменил свой OutlookProvider со старого CertPrincipalName msstd: mbox.mydomain. com на новое имя с подстановочными знаками:
Set-OutlookProvider -Identity EXPR -CertPrincipalName msstd:*.mydomain.com
Set-OutlookProvider -Identity EXCH -CertPrincipalName msstd:*.mydomain.com
Затем я активировал службу IIS в новом сертификате с подстановочными знаками, загруженном через веб-интерфейс ECP Exchange.
Я немного подождал обновления Outlookprovier (TTL = 1 час)
А теперь ....
Внешнее соединение работает, но у меня есть ошибка прокси для всех моих локальных клиентов Outlook:
Где целевой сайт - это ЛОКАЛЬНЫЙ путь к серверу.
Что я пропустил?
Вы можете использовать разные сертификаты для внешних и внутренних подключений. Один из возможных вариантов - задействовать балансировщик нагрузки. Вы также можете использовать прокси-сервер веб-приложения (см. здесь ).
И затем вы можете использовать один сертификат (внешний) на LoadBalancer / прокси-сервере веб-приложения. И перенастройте среду Exchange для использования внутренних и внешних URL-адресов.