Правила apparmor

Причина

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

Подключение ссылки на сайт включено в сети, которая не поддерживает физическое подключение к сети между двумя контроллерами домена на разных сайтах, подключенных ссылкой KCC.
Один или несколько сайтов не содержатся в ссылках на сайт.
Ссылки на сайты содержат все сайты, но ссылки на них не связаны между собой. Это условие называется несоединяемой ссылкой на сайт.
Один или несколько контроллеров домена находятся в автономном режиме.
Контроллеры домена Bridgehead находятся в сети, но ошибки возникают, когда они пытаются реплицировать необходимый контекст именования между сайтами Active Directory.
Предпочтительные мостики, определенные администратором, находятся в сети, но не являются требуемой контекстами именования.
Предпочтительные мостики правильно определяются администратором, но в настоящее время они находятся в автономном режиме.
Сервер верхнего плана перегружен либо из-за негабаритного размера сервера, слишком многие сайты филиалов пытаются реплицировать изменения из одного контроллера домена концентратора, либо слишком часто расписания ссылок на сайт.
KCC выстроил другой путь вокруг сбоя подключения сайта к сайту, но каждые 15 минут он будет повторно отходить от подключения, так как он находится в режиме сохраняемого подключения.

Общие причины сообщений event ID 1311 подпадают под две категории: неправильная логическая конфигурация и сбой инфраструктуры. Сообщения event ID 1311 регистрируются при неправильной логической конфигурации или ошибке репликации.

Неправильная логическая конфигурация

Логическая конфигурация неправильно настроена, если сведения в контексте имен конфигурации (NC) (видимые в оснастке Сайтов и служб) не соответствуют физической топологии сети, в котором размещен лес Active Directory. Например, может быть неправильно определен сайт, могут быть включены сайты, отсутствующие из ссылок на сайт, ссылки на сайты не могут быть связаны между собой, или администратор может выбрать неправильные мостики.
Сбой инфраструктуры

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

Дополнительные сетевые проверки

В некоторых случаях причиной ошибок с доступностью RPC выступает сбой на сетевых адаптерах. Помогает сброс сетевых настроек и перезагрузка. В сети с Active Directory, старайтесь, чтобы на всех ваших сетевых адаптерах в свойствах были выставлены обе галки IPV4 и IPV6, особенно это актуально для контроллеров домена, где вы легко можете получать ошибку . Еще может помочь отключение протокола Teredo у IPv6. В командной строке выполните:

netsh interface teredo set state disabled

Для включения обратно введите:

netsh interface teredo set state disabled

Еще на сайте Майкрософт пишут, что необходимо на сервере RPC иметь включенную службу «Удаленный реестр». На этом у меня все, с вами был Иван Сёмин, автор и создатель IP портала Pyatilistnik.org.

AppArmor проще потому, что он ориентирован ТОЛЬКО на процессы.

Защита AppArmor основана на профилях (profiles). Профиль приложения — обычный конфигурационный файл со своим синтаксисом. Используя профиль, AppArmor ограничивает процесс и предоставляют ему только минимально необходимые для работы возможности и привилегии. И если в SELinux могут использоваться еще и пользователи, роли, типы, уровни и категории, то в AppArmor — один только профиль. Контроль пользователей оставили на откуп традиционному DAC — решили, что этого будет достаточно.

Вместо маркирования всех субъектов и объектов системы, в профилях AppArmor применен pathname-based подход. Его сущность заключается в том, что в профиле приложения определяются записи путей и записи разрешений. Записи путей (path entries) определяют, к каким объектам файловой системы приложение может получить доступ. Записи разрешений (capability entries POSIX.1e) устанавливают, какие разрешения ограничиваемый процесс может получить.

Кстати! Поначалу для SELinux приоритетной являлась «Stict Policy». Но эта политика была настолько строгой, что для большинства обычных пользователей понятия «нормальная работа» и «SELinux» стали несовместимы. Как это все отразилось на репутации SELinux’а и на психическом состоянии Дэна Уолша – все мы прекрасно знаем. Что сделали разработчики? Быстренько выбрали приоритетной «Targerted Policy», которая характеризуется тем, что ограничивает только выбранные приложения и при этом практически не использует ни пользователей, ни ролей. Вы не находите такое поведение схожим с моделью, на которую сделали ставку разработчики AppArmor?

Pathname-based проще в реализации, так как не требует маркирования всех объектов ОС и не зависит от файловой системы. С другой стороны, это менее секьюрно. AppArmor работает с абстракцией вида /full/path/to/file, в то время как SELinux использует индексные дескрипторы (inodes) и расширенные атрибуты файловой системы. Как известно, объекты ФС могут иметь несколько pathnames и, следовательно, один и тот же объект может управляться различными профилями по-разному.

Лирическое отступление. Также как и в случае с Type Enforcement, возникает вопрос, можно ли считать такой вот pathbased-подход настоящим Mandatory Access Control про который пишут в «Оранжевой книге»? Зануда внутри меня уверенно отвечает: «Нет!» Но мы снова позволим себе маленькую слабость и будем считать AppArmor «одной из форм» MAC. Но имейте ввиду: ребята в погонах такой MAC точно не оценят!

Доступ

Важно понимать, что доменные имена something.com и mail.something.com являются абсолютно разными. Если главным доменом вашего Сервера CommuniGate Pro является mycompany.dom и вы пытаетесь соединиться с ним, набрав в вашем браузере http://mail.mycompany.com:8100, вы получите страницу с уведомлением, что Сервер CommuniGate Pro не предоставляет доступ к домену mail.mycompany.com

В большинстве случаев доменные имена mail.mycompany.com, webmail.mycompany.com и т.п. должны просто быть другими именами (псевдонимами) домена mycompany.com в CommuniGate Pro. Для того, чтобы выполнить эти настройки, откройте страницу Установки Домена mycompany.com и найдите поле Доменные псевдонимы. В пустом поле введите имя mail.mycompany.com и нажмите кнопку Модифицировать. Теперь Сервер CommuniGate Pro будет знать, что домен mail.mycompany.com — это просто другое имя для обслуживаемого им домена mycompany.com. Запросы на соединения с доменом mail.mycompany.com приведут к установке соединения с доменом mycompany.com, и сообщения, отправленные на адрес username@mail.mycompany.com будут доставляться пользователю username в домене mycompany.com.

Обратите внимание: Если имя, указанное в URL браузера, не является одним из имен Доменов в CommuniGate Pro, то будет открыт Веб Интерфейс Администратора Сервера. Поэтому соединения через порт Веб Интерфейса Администратора (8010) будут работать, хотя соединения через порт Веб Интерфейса Пользователя (8100) вернут «розовую страницу»

Сессия работы через Веб Интерфейс Пользователя прекращается почти сразу же после входа

Когда пользователь работает через «распределённый HTTP прокси-сервер» (используемый обычно крупными интернет-провайдерами, такими как AOL), TCP соединения приходят на CommuniGate Pro с нескольких разных IP адресов этих прокси-серверов. Если в Веб Интерфейсе Пользователя включена опция Защита по Фиксированному Адресу в настройках Пользователя, то соединение через браузер пользователя может быть отвергнуто. Отключите опцию Защита по Фиксированному Адресу для тех пользователей, которые соединяются через «распределённый HTTP прокси». Если большинство ваших пользователей соединяется через такие прокси-сервера, вы можете отключить эту настройку в Умолчаниях для Пользователя Домена или в Общесерверных Умолчаниях для Пользователя.

Что означает ошибка «unassigned local network address» («не задан локальный адрес сети»)?

Компьютер, на котором установлен ваш сервер CommuniGate Pro, имеет один или несколько IP (сетевых) адресов. Эти адреса могут быть назначены Доменам, обслуживаемым CommuniGate Pro. Страница Домены, доступная через Веб Интерфейс Администратора, показывает все домены с IP адресами, закрепленными за ними.

Обычно настройка Присвоенные Сетевые Адреса установлена в значение «Все незанятые», так что все IP адреса, не назначенные дополнительным доменам, автоматически назначаются Главному Домену. Если ни один из ваших Доменов не имеет настройки Присвоенные Сетевые Адреса в значении «Все незанятые», тогда некоторые из IP адресов вашего Сервера могут быть вообще не назначены Доменам.

Когда пользователь соединяется с сервером через POP или IMAP клиент и указывает там только имя пользователя без имени домена или при установлении безопасного соединения (SSL/TLS) Сервер CommuniGate Pro использует локальный IP адрес, на который установлено соединение и пытается найти Домен, которому этот адрес назначен. Если этот IP адрес не назначен ни для какого Домена в CommuniGate Pro, то тогда возникает ошибка «unassigned local network address» («не задан локальный адрес сети»).

Откройте в Веб Интерфейсе Администратора страницу Установки->Общее для того, чтобы увидеть все Сетевые Адреса Сервера. Возможно, потребуется нажать кнопку Обновить для того, чтобы увидеть все адреса. Неназначенные адреса будет отмечены красным цветом.

Disable AppArmor framework

Systems should not generally need to have AppArmor disabled entirely. It is highly recommended that users leave AppArmor enabled and put the problematic profile into complain mode (see above), then file a bug using the procedures found in https://wiki.ubuntu.com/DebuggingApparmor. If AppArmor must be disabled (eg to use SELinux instead), users can:

sudo systemctl stop apparmor
sudo systemctl disable apparmor

On Ubuntu systems prior to Ubuntu 16.04 LTS:

sudo invoke-rc.d apparmor stop
sudo update-rc.d -f apparmor remove

To disable AppArmor in the kernel to either:

adjust your kernel boot command line (see /etc/default/grub) to include either
* ‘apparmor=0’
* ‘security=XXX’ where XXX can be «» to disable AppArmor or an alternative LSM name, eg. ‘security=»selinux»‘
remove the apparmor package with your package manager. Do not ‘purge’ apparmor if you think you might want to reenable AppArmor at a later date

Терминология и понятия

Сервер Bridgehead. Любой контроллер домена на сайте Active Directory, который реплицирует раздел Active Directory (например, схему, конфигурацию, домен, раздел приложения или глобальный каталог) на контроллер домена на другом сайте Active Directory.

Для каждого уникального раздела каталога, домена или раздела приложений на сайте Active Directory выбирается мостовая часть, поэтому сайт, на котором размещены три различных домена, имеет три сервера на месте.

Контроллеры домена реплицирует все контексты именования, которые находятся в общем с их прямыми партнерами репликации, поэтому контроллер домена в домене «corp.com» реплицирует CN=SCHEMA и CN=CONFIGURATION в дополнение к контексту именования домена «corp.com» со своим межобъектным партнером по мостовику.
Генератор топологии между сайтами (ISTG): Для каждого сайта Active Directory для создания топологии репликации между сайтами назначается один сервер, известный как ISTG.
Открытый сайт. Сайт Active Directory, определенный в оснастке Sites and Services, который в настоящее время не содержит Windows 2000 контроллеров домена. Открытый сайт может ждать прибытия контроллера домена с сайта-постановщика. Кроме того, сайт может быть определен как открытый, чтобы предоставить предпочтение сайта для клиентских операций.

Отправка по SMTP

Мой Сервер не может отправлять почту на некоторый хост с использованием SSL/TLS

Когда SMTP модуль CommuniGate Pro соединяется с почтовым хостом/ретранслятором и пытается установить безопасное (SSL/TLS) соединение, он получает от хоста Сертификат и проверяет в нём имя. Это имя должно совпадать либо с именем домена, на который должна быть отправлена почта, либо с именем MX-записи в DNS для этого домена.

Когда удалённый сервер обслуживает несколько доменов на одном IP адресе, он всегда отправляет только один сертификат, так как сервер не может заранее знать, для какого именно домена будут предназначены входящие сообщения. Следовательно, сервер не может представить Сертификат, соответствующий этому домену. В результате ваш (отправляющий почту) сервер может отказаться продолжать работу.

Если сервер mainhost.com обслуживает домены client1.com и client2.com, а MX-записи для всех трёх доменов указывают на одно имя и один IP адрес на сервере, то сервер всегда будет предоставлять только один Сертификат — как правило, Сертификат с именем mainhost.com.

Для того, чтобы сервер CommuniGate Pro отправлял почту через безопасное соединение в домены client1.com и client2.com, вы должны создать в Маршрутизаторе две записи уровня домена: client1.com = [email protected] client2.com = [email protected]

Эти записи направят всю почту для доменов client1.com и client2.com в SMTP очередь для mailhost.com. Вы должны поместить имя mailhost.com в список Посылать Зашифрованным (SSL/TLS) в SMTP модуле; тогда сервер будет соединяться с сервером mailhost.com, проверять его сертификат (в котором должно содержаться или имя mailhost.com или имя релея, с которым соединился SMTP модуль), затем SMTP модуль установит безопасное (SSL/TLS) соединение с этим сервером и отправит всю почту получателям в доменах client1.com и client2.com через безопасное соединение.

Nginx пример профиля

В данном примере вы создаете пользовательский профиль AppArmor для Nginx.Ниже приведен пользовательский профиль.



profile docker-nginx flags=(attach_disconnected,mediate_deleted) {
  

  network inet tcp,
  network inet udp,
  network inet icmp,

  deny network raw,

  deny network packet,

  file,
  umount,

  deny /bin/** wl,
  deny /boot/** wl,
  deny /dev/** wl,
  deny /etc/** wl,
  deny /home/** wl,
  deny /lib/** wl,
  deny /lib64/** wl,
  deny /media/** wl,
  deny /mnt/** wl,
  deny /opt/** wl,
  deny /proc/** wl,
  deny /root/** wl,
  deny /sbin/** wl,
  deny /srv/** wl,
  deny /tmp/** wl,
  deny /sys/** wl,
  deny /usr/** wl,

  audit /** w,

  /var/run/nginx.pid w,

  /usr/sbin/nginx ix,

  deny /bin/dash mrwklx,
  deny /bin/sh mrwklx,
  deny /usr/bin/top mrwklx,


  capability chown,
  capability dac_override,
  capability setuid,
  capability setgid,
  capability net_bind_service,

  deny @{PROC}/* w,   
  
  deny @{PROC}/{,,,*}/** w,
  deny @{PROC}/sys/** w,  
  deny @{PROC}/sys/kernel/{?,??,**} w,  
  deny @{PROC}/sysrq-trigger rwklx,
  deny @{PROC}/mem rwklx,
  deny @{PROC}/kmem rwklx,
  deny @{PROC}/kcore rwklx,

  deny mount,

  deny /sys/*/** wklx,
  deny /sys/f*/** wklx,
  deny /sys/fs/*/** wklx,
  deny /sys/fs/c*/** wklx,
  deny /sys/fs/cg*/** wklx,
  deny /sys/firmware/** rwklx,
  deny /sys/kernel/security/** rwklx,
}

Сохраните пользовательский профиль на диск в файле .

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

Загрузите профиль.

$ sudo apparmor_parser -r -W /etc/apparmor.d/containers/docker-nginx

Запустите контейнер с профилем.

Для запуска nginx в автономном режиме:
```
$ docker run 
     -p 80:80 -d 
```
Выполнить в бегущий контейнер.
```
$ docker container exec -it apparmor-nginx bash
```

Попробуйте несколько операций,чтобы проверить профиль.

root@6da5a2a930b9:~# ping 8.8.8.8
ping: Lacking privilege for raw socket.

root@6da5a2a930b9:/# top
bash: /usr/bin/top: Permission denied

root@6da5a2a930b9:~# touch ~/thing
touch: cannot touch 'thing': Permission denied

root@6da5a2a930b9:/# sh
bash: /bin/sh: Permission denied

root@6da5a2a930b9:/# dash
bash: /bin/dash: Permission denied

Поздравляю! Вы только что установили контейнер,защищенный пользовательским профилем аппармера!

Немного теории

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

Профили могут работать в двух режимах:

Enforce — ядро гарантирует соблюдение правил, указанных в файле профиля, все нарушения блокируются, а также записываются в файл журнала, где могут быть очень легко просмотрены.
Complain — режим обучения, программа будет только регистрировать нарушения ничего не блокируя.

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

Причина

RPC — промежуточный уровень между сетевым транспортом и протоколом приложений. Сам RPC не имеет специального сведения о сбоях, но пытается сопоставить сбои протокола нижнего уровня в ошибку на уровне RPC.

Ошибка RPC 1722 / 0x6ba/RPC_S_SERVER_UNAVAILABLE регистрируется, когда протокол нижнего слоя сообщает о сбое подключения. Распространенным случаем является сбой абстрактной операции TCP CONNECT. В контексте репликации AD клиент RPC в пункте назначения DC не смог успешно подключиться к серверу RPC на источнике DC. Распространенными причинами для этого являются:

Ссылка локального сбоя
Отказ DHCP
Сбой DNS
Сбой WINS
Сбой маршрутной маршрутики (включая заблокированные порты на брандмауэрах)
Сбои в проверке подлинности IPSec /Network
Ограничения ресурсов
Протокол более высокого уровня, не запущенный
Протокол более высокого уровня возвращает эту ошибку

Design a test plan

Try to think about how the application should be exercised. The test plan should be divided into small test cases. Each test case should have a small description and list the steps to follow.

Some standard test cases are :

starting the program
stopping the program
reloading the program
testing all the command supported by the init script

In the case of graphical programs, your test cases should also include anything you normally do. Downloading and opening files, saving files, uploading files, using plugins, saving configurations changes, and launching other programs are all possibilities.

AppArmor не может похвастаться такой же богатой историей, как SELinux, однако на качестве конечного продукта это никак не отразилось. Просто он получился немного проще.

Неизвестно, о ком больше думали Криспин Коуэн (Crispin Cowan) и команда его разработчиков – о котятах, пользователях или бизнесах, когда в конце девяностых годов прошлого века приступили к реализации проекта «Grand». Задачи, в общем-то, были те же, что и у NSA – разработать инструменты, которые способны дополнить традиционный DAC и предоставить гибкий механизм разграничения прав доступа. И, как не странно, у ребят кое-что получилось – на свет появились StackGuard (защита от атак переполнения буфера (buffer overflow)), FormatGuard (защита от атак на функции форматирования строк(format string attack)) и SubDomain (механизм, ограничивающий приложения). Для успешного продвижения всех этих фич в 1998 году Криспин Коуэн основывает компанию WireX. Главным продуктом компании стал коммерческий rhel-based дистрибутив Immunix, в котором и были реализованы все вышеперечисленные разработки. Однако успешного продвижения новоиспеченной ОС не получилось — дистрибутив как-то не пошел, а там еще и NSA бесплатно (sic!) стало предлагать свой SELinux. Поэтому в 2004 году все работы по разработке собственного защищенного дистрибутива сворачиваются, компанию переименовывают в Immunix Inc., а SubDomain переписывают под LSM и включают его поддержку в SUSELinux.

В 2005 году IT-гигант Novell покупает Immunix Inc, переименовывает SubDomain в AppArmor и публикует исходники под лицензией GNU GPL. Специалисты компании начинают вычищать и частично переписывать код для его включения в mainstream-ветку Linux kernel. В период с 2005 по 2007 годы AppArmor активно развивается, специалисты Novell выпускают несколько версий.

Интересное событие произошло в октябре 2007 года — Novell увольняет большую часть команды разработчиков AppArmor. Доподлинно неизвестно, что послужило поводом, но можно предположить, что руководство компании просто-напросто засомневалось в способности AppArmor составить достойную конкуренцию SELinux. Косвенно эту версию подтверждает тот факт, что в 2008 году в OpenSUSE появляется поддержка Security Enhanced Linux. Такое событие не оставили без внимания и разработчики конкурирующей технологии. Так Рассел Кокер (Russell Coker), подлил масла в огонь, заявив, что появление поддержки SELinux в OpenSUSE фактически означает смерть AppArmor.

После увольнения сотрудников Nowell выпустит еще одну версию AppArmor, однако на этом мутуализм Novell и AppArmor закончится.

В 2009 году, видимо посчитав, что недостаток конкуренции — это плохо для рынка, а единообразие — плохо для безопасности, Canonical «подбирает», брошенный Nowell’ом AppArmor. Под их началом полуживой инструмент вновь начинает совершенствоваться и развиваться. И всего лишь через год, в 2010 году, AppArmor вошел в состав Linux kernel 2.6.36.

Под теплым крылышком Canonical AppArmor развивается и по сей день.

Прежде чем приступить к дальнейшему знакомству с AppArmor, очень советую не полениться и ознакомиться со статьей «Знакомимся с SELINUX и пытаемся понять, почему Дэн Уолш плачет».

Создание профиля в AppArmor

Создать профиль для AppArmor не так сложно как кажется на первый взгляд. Для этого в системе существует несколько утилит. Но для начала давайте рассмотрим синтаксис файла, чтобы было понятно с чем мы имеем дело. Возьмем опять же файл от man:

Основу профиля составляют адреса файлов, к которым программа может иметь доступ, а также разрешения для этих файлов. Синтаксис такой:

/адрес/файла права

Доступны такие права:

r — разрешить чтение
w — разрешить запись
a — разрешить запись в конец файла
px — разрешить запуск новых процессов если для них есть профиль
Px — разрешить запуск новых процессов, если для них есть профиль и стереть переменные окружения
ix — разрешить запуск нового процесса под профилем текущего
m — разрешить загружать исполняемые файлы в память и запускать
l — разрешить создавать символические ссылки на исполняемые файлы
k — разрешить блокировать файлы
ux — не контролировать новые процессы
Ux — не контролировать новые процессы и очистить переменные окружения.

Этих полномочий вполне достаточно, для управления правами, но кроме списка файлов и их полномочий, файл профиля содержит еще директивы include и capability.

include позволяет включать другие файлы с разрешениями, они находятся в папке /etc/apparmor.d/abstractions/. Это такие же части профиля, со списком файлов и правами доступа. Они облегчают создание новых профилей.

С capability все немного сложнее. Программа может обращаться к ядру с помощью системных вызовов, эти вызовы Apparmor тоже контролирует. Посмотреть все доступные вызовы вы можете командой man capabilities. В нашем случае мы разрешаем процессу задать свой uid и gid, то есть сменить пользователя и группу, от которого он запущен.

Есть еще папка /etc/apparrmor.d/thunables с переменными, которые могут использоваться в каждом профиле. Но с ними разберемся по ходу. Теперь вы готовы к тому, чтобы создать профиль apparmor. Для примера будем создавать новый профиль для утилиты free. Напомню, что эта утилита показывает доступную оперативную память.

Сначала выполните такую команду, чтобы инициализировать шаблон профиля:

Шаблон профиля создан, можете его посмотреть, теперь нужно выполнить профилирование программы, чтобы посмотреть какие ей файлы нужны и добавить их в профиль:

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

Готово, теперь нажимаем F, чтобы завершить работу утилиты. Дальше включаем принудительный режим:

И проверяем работоспособность утилиты:

Если вы меняли профиль вручную, то его необходимо перезагрузить, чтобы изменения вступили в силу, для этого используйте команду:

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

Вот и все, настройка apparmor в Ubuntu 16.04 завершена.

Симптомы

В этой статье описываются симптомы, причины и решения для устранения сбоя репликации Active Directory с ошибкой Win32 1722. Сервер RPC недоступен.

DCPROMO Promotion реплики DC не удается создать объект NTDS Параметры на помощнике DC с ошибкой 1722。

Текст заголовка диалогового диалога: Мастер установки служб доменных служб Active Directory

Текст диалогового сообщения:
DCDIAG сообщает, что с ошибкой 1722 не удалось проверить репликации Active Directory. Сервер RPC недоступен.
REPADMIN.EXE сообщает, что попытка репликации не удалась со статусом 1722 (0x6ba).

Команды REPADMIN, которые обычно ссылаются на состояние -1722 (0x6ba), включают, но не ограничиваются:

Пример вывода и изображение недоступен ошибки сервера RPC ниже:

Пример вывода изображения сервера RPC недоступен, показан ниже:
Команда репликации в Active Directory Sites and Services возвращает, что сервер RPC недоступен.

Щелкнув правой кнопкой мыши по объекту подключения из источника постоянного тока и выбрав репликацию, теперь не удается с сервером RPC недоступен. Сообщение об ошибке на экране отображается ниже:

Текст заголовка диалогового диалога: Репликация теперь

Текст сообщения диалогового сообщения:

Проверка согласованности знаний NTDS (KCC), NTDS General или события Microsoft-Windows-ActiveDirectory_DomainService с состоянием 1722 регистрируются в журнале событий службы каталогов.

События Active Directory, которые обычно ссылаются на состояние 1722, включают, но не ограничиваются:

Источник события	Идентификатор события	Строка события
Microsoft-Windows-ActiveDirectory_DomainService	1125	Мастер установки доменных служб Active Directory (Dcpromo) не смог установить подключение к следующему контроллеру домена.
NTDS KCC	1311	Проверка согласованности знаний (KCC) обнаружила проблемы со следующим разделом каталога.
NTDS KCC	1865	Проверка согласованности знаний (KCC) не смогла сформировать полную топологию сети деревьев. В результате с локального сайта невозможно получить следующий список сайтов.
NTDS KCC	1925	Попытка установить ссылку на репликацию для следующего раздела каталога writable не удалась.
Репликация NTDS	1960	Внутреннее событие. Следующий контроллер домена получил исключение из подключения удаленного вызова процедуры (RPC). Возможно, операция не удалась.