data directory is locked что делать
Выявляем источник блокировки учетной записи пользователя в Active Directory
В этой статье описано, как отслеживать события блокировки учетных записей пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы выполняется постоянная блокировка. Рассмотрим использование для поиска источника блокировки журнала безопасности Windows и скриптов PowerShell.
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory в случае n-кратного неправильного набора пароля пользователем. Обычно учетная запись блокируется контроллером домена после нескольких попыток ввести неправильный пароль на несколько минут (5-30), в течении которых вход пользователя в систему невозможен. Через определение время, заданное политиками безопасности, учетная запись домена автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) учетных записей пользователей AD.
В том случае, если учётная запись пользователя в домене заблокирована, при попытке авторизации в Windows появляется предупреждение:
Политики блокировки учетных записей в домене
Довольно полезную информацию о времени блокировки, задания пароля, количестве попыток набора пароля и прочее можно получить в свойствах учетной записи в консоль ADSIEdit или на дополнительной вкладке Additional Account Info в свойствах пользователя (проще).
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться «клянется», что ничего особого не делал, не разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Для того, чтобы решить проблему пользователя администратору нужно разобраться с какого компьютера и какой программой была заблокирована учетная запись пользователя в Active Directory.
Поиск компьютера, с которого была заблокирована учетная запись
В первую очередь администратору нужно разобраться с какого компьютера / сервера происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
При этом в журнале обоих контроллеров домена фиксируются события 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Логично, что в первую очередь необходимо проверить журналы безопасности на PDC контроллере. Найти PDC в домене можно так:
Событие блокировки учетной записи домена можно найти в журнале Security на контролере домена. Отфильтруйте журнал безопасности по событию с Event ID 4740. Должен появится список последних событий блокировок учетных записей на контроллере домена. Начиная с самого верхнего переберите все события и найдите событие, в котором указано что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:
Выявляем программу, причину блокировки учетной записи в AD
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь хотелось бы понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля своей доменной учетной записи. Это наталкивает на мысль, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространение места, в которых пользователь мог использовать свой старый пароль:
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие активированных групповых политик аудита.
В том случае, если вы так и не смогли выяснить причину блокировки учетной записи на конкретном компьютере, чтобы избежать постоянной блокировки учетки, стоит попробовать переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя.
Выявляем источник блокировки учетной записи пользователя в Active Directory
В этой статье мы покажем, как отслеживать события блокировки учеток пользователей на котроллерах домена Active Directory, определять с какого компьютера и из какой конкретно программы постоянно блокируется учетная запись пользователя. Для поиска источника блокировки аккаунтов пользователей можно использовать журнал безопасности Windows, скрипты PowerShell или утилиту Account Lockout and Management Tools (Lockoutstatus.exe).
Учетная запись пользователя заблокирована и не может быть использована для входа в сеть
Политика безопасности учетных записей в большинстве организаций требует обязательного блокирования учетной записи пользователя в домене Active Directory, если он несколько раз подряд ввел неправильный пароль. Обычно учетная запись блокируется контроллером домена на несколько минут (5-30), в течении которых вход пользователя в домен невозможен. Через определение время (задается в политике безопасности домена), учетная запись пользователя автоматически разблокируется. Временная блокировка учетной записи позволяет снизить риск подбора пароля (простым брутфорсом) к учетным записям пользователей AD.
Если учётная запись пользователя в домене заблокирована, то при попытке входа в Windows появляется предупреждение:
Как проверить, что аккаунт пользователя AD заблокирован?
Вы можете проверить, что аккаунт заблокирован в графический консоли ADUC или с помощью комнадлета Get-ADUser из модуля Active Directory для PowerShell:
Учетная запись сейчас заблокирована и не может быть использована для авторизации в домене (Lockedout = True).
Можно вывести сразу все заблокированные аккаунты в домене с помощью Search-ADAccount:
Вы можете вручную снять блокировку учетной записи с помощью консоли ADUC, не дожидаясь автоматической разблокировки. Для этого в свойствах учетной записи пользователя на вкладке Account, включите опцию Unlock account. This account is currently locked out on this Active Directory Domain Controller (Разблокируйте учетную запись. Учетная запись на этом контроллере домена Active Directory на данный момент заблокирована) и сохраните изменения.
Также можно немедленно разблокировать учетную запись с помощью следующей команды PowerShell:
Политики блокировки учетных записей в домене
Ситуации, когда пользователь забыл свой пароль и сам вызвал блокировку своей учетки случаются довольно часто. Но в некоторых случаях блокировка учеток происходит неожиданно, без каких-либо видимых причин. Т.е. пользоваться “клянется”, что ничего особого не делал, ни разу не ошибался при вводе пароля, но его учетная запись почему-то заблокировалась. Администратор по просьбе пользователя может вручную снять блокировку, но через некоторое время ситуация повторяется.
Чтобы решить проблему самопроизвольной блокировки учетной записи пользователя, администратору нужно разобраться с какого компьютера и какой программой была заблокирован аккаунт пользователя Active Directory.
Политики аудита входа на DC
Проще всего включить эту политику через консоль gpmc.msc, отредактировав политику Default Domain Controller Policy, либо на уровне всего домена с помощью Default Domain Policy.
EventID 4740: событие блокировки учетной записи
В первую очередь администратору нужно разобраться с какого компьютера/сервера домена происходят попытки ввода неверных паролей и идет дальнейшая блокировка учетной записи.
Если пользователь ввел неверный пароль, то ближайший к пользователю контроллер домена перенаправляет запрос аутентификации на DC с FSMO ролью эмулятора PDC (именно он отвечает за обработку блокировок учетных записей). Если проверка подлинности не выполнилась и на PDC, он отвечает первому DC о невозможности аутентификации. Если количество неуспешных аутентификаций превысило значение, заданное для домена в политике Account lockout threshold, учетная запись пользователя временно блокируется.
При этом в журнале обоих контроллеров домена фиксируются событие с EventID 4740 с указанием DNS имени (IP адреса) компьютера, с которого пришел первоначальный запрос на авторизацию пользователя. Чтобы не анализировать журналы на всех DC, проще всего искать это события в журнале безопасности на PDC контроллере. Найти PDC в домене можно так:
Событие блокировки учетной записи домена можно найти в журнале Security (Event Viewer > Windows Logs) на контролере домена. Отфильтруйте журнал безопасности (Filter Current Log) по событию с Event ID 4740. Должен появиться список последних событий блокировок учетных записей контроллером домена. Переберите все события, начиная с самого верхнего и найдите событие, в котором указано, что учетная запись нужного пользователя (имя учетной записи указано в строке Account Name) заблокирована (A user account was locked out).
Откройте данное событие. Имя компьютера (или сервера), с которого была произведена блокировка указано в поле Caller Computer Name. В данном случае имя компьютера – TS01.
Поиск компьютера/сервера, с которого блокируется пользователь с помощью PowerShell
Можно воспользоваться следующим PowerShell скриптом для поиска источника блокировки конкретного пользователя на PDC. Данный скрипт вернет дату блокировки и компьютер, с которого она произошла:
Утилита Microsoft Account Lockout and Management Tools
Для поиска источника блокировки пользователя можно использовать графическую утилиту Microsoft Account Lockout and Management Tools — Lockoutstatus.exe (скачать ее можно тут). Данная утилита проверяет статус блокировки учетной записи на всех контроллерах домена.
Запустите утилиту Lockoutstatus.exe, укажите имя заблокированной учетной записи (Target User Name) и имя домена (Target Domain Name).
В появившемся списке будет содержаться список DC и состояние учетной записи (Locked или Non Locked). Дополнительно отображается время блокировки и компьютер, с которого заблокирована данная учетная запись (Orig Lock).
Прямо из утилиты Lockoutstatus можно разблокировать пользователя, или сменить его пароль.
Основной недостаток утилиты LockoutStatus – она довольно долго опрашивает все контроллеры домена (некоторые из них могут быть недоступны).
Как определить программу, из которой блокируется учетной запись пользователя?
Итак, мы определили с какого компьютера или устройства была заблокирована учетная запись. Теперь нужно понять, какая программа или процесс выполняет неудачные попытки входа и является источником блокировки.
Часто пользователи начинают жаловаться на блокировку своей учетной записи в домене после плановой смены пароля. Чаще всего это значит, что старый (неверный) пароль сохранен в некой программе, скрипте или службе, которая периодически пытается авторизоваться в домене с устаревшим паролем. Рассмотрим самые распространенные места, в которых пользователь мог сохранить свой старый пароль:
Для более детального аудита блокировок на найденном компьютере необходимо включить ряд локальных политик аудита Windows. Для этого на локальном компьютере, на котором нужно отследить источник блокировки, откройте редактор групповых политик gpedit.msc и в разделе Compute Configurations -> Windows Settings -> Security Settings -> Local Policies -> Audit Policy включите политики:
Дождитесь очередной блокировки учетной записи и найдите в журнале безопасности (Security) события с Event ID 4625. В нашем случае это событие выглядит так:
Из описания события видно, что источник блокировки учетной записи – процесс mssdmn.exe (является компонентом Sharepoint). Осталось сообщить пользователю о том, что ему необходимо обновить свой пароль на веб-портале Sharepoint.
После окончания анализа, выявления и наказания виновника не забудьте отключить действие включенных групповых политик аудита.
Если вы так и не смогли найти причину блокировки учетной записи на конкретном компьютере, попробуйте просто переименовать имя учетной записи пользователя в Active Directory. Это как правило самый действенный метод защиты от внезапных блокировок определенного пользователя, если вы не смогли установить источник блокировки.
Data directory is locked что делать
Добрый день! Уважаемые читатели и гости, крупного IT блога Pyatilistnik.org. В прошлый раз мы с вами рассматривали границы применения групп Active Directory, и надеюсь вы разобрались, где и какие следует использовать. Сегодня я хочу рассмотреть, очень частую и жизненную ситуацию, которая есть в любой доменной среде, а именно блокировка учетной записи Windows в Active Directory. Данную проблему вы легко встретите на предприятиях, где есть свои политики PSO и политики смены паролей. Так, что давайте прокачаем свои знания и научимся разбираться в данной ситуации.
Причина блокировки пользователя Active Directory
Давайте разбираться, какие существуют причины блокирования учетных записей пользователей в Active Directory. Как я и говорил выше, данная ситуация существует в компаниях, где есть политики паролей, которые подразумевают блокировку учетной записи при вводе определенного количества не правильных паролей, это правильно с точки зрения безопасности и выявления таких случаев, когда кто-то пытается скомпрометировать ваши ресурсы.
Вот так вот выглядит сообщение о блокировке:
Как видите в моем примере, пользователь по имени Барбоскин Геннадий Викторович не может начать работать, так как залочен.
Ставим галку и разблокируем учетную запись. После этого нужно выявлять причины.
Из основных причин блокировки я могу выделить:
Где настраивается политика блокировки учетных записей в домене
По рекомендациям компании Microsoft, политику блокировки учетной записи Windows настраивают на уровне домена, и чаще всего используют для этого уже имеющуюся политику «Default Domain Policy». Открываем редактор групповой политики и щелкаем правым кликом мыши по политике «Default Domain Policy», из контекстного меню выберите пункт «Изменить».
Тут в политике будет три пункта:
Как выяснить причину блокировки учетной записи
Выше я вас рассказал, из-за чего может все лочиться, теперь нужно выяснить с какого компьютера или устройств, это происходит. Ко мне на работе за неделю попадает 5-7 заявок с подобным вопросом, пользователь сменил пароль и у него началась веселая игра под названием угадайка, где я оставил свои старые данные, по которым меня банит контроллер домена. Чтобы однозначно ответить на этот вопрос вам как системному администратору необходимо настроить специальную политику аудита, призванную следить за соответствующими событиями по которым вы сможете дать однозначный ответ по причинам блокировок. По умолчанию данный вид аудита не настроен.
Про аудит Active Directory я подробно рассказывал, можете посмотреть по ссылке, тут я приведу легкую его выдержку, для полноты статьи. Нам нужно включить политику аудита входа, на уровне домена. (Так же вы можете подробно почитать про расширенный аудит, дающий более тонкие настройки https://technet.microsoft.com/ru-ru/library/mt431761%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396)
Включение политики аудита входа
Открываем редактор групповой политики и находим в нем дефолтную политику «Default Domain Policy», открываем ее и переходим по такому пути.
Тут будут такие политики:
Нас будет интересовать включение аудита входа в систему, именно данный вид будет генерировать события 4771 и 4624. Открываем ее и ставим галки «Успех и отказ»
Так же советую задать политику аудита событий входа в систему, так же установите «Успех и отказ»
Ну и настроим еще таким же способом «Аудит управления учетными записями«, чтобы мы видели события с кодом 4740.
Когда политика настроена, то вы можете ее принудительно обновить или дождаться автоматического обновления в течении 90-120 минут.
Какие события отслеживать в журнале безопасность
Чтобы отследить устройство вызывающее блокировки учетной записи, нужно понять алгоритм работы данного механизма. Когда кто-то пытается вводить учетные данные в Active Directory, то он идет на ближайший к нему контроллер домена (Кстати выяснить какой контроллер домена вас аутентифицировал можно очень просто, я об этом рассказывал, если интересно, то посмотрите). Данный контроллер домена видит, что пользователь предоставляет некорректные учетные данные и отсылает этот запрос аутентификации на контроллер, который обладает ролью PDC и FSMO. Так как данная роль PDC-эмулятор и отвечает в доменной среде за обработку блокировок учетных записей. Если PDC-эмулятор видит не корректные данные, то он возвращает ответ контроллеру домена, который ему это прислал, что аутентификация не возможна, и в следствии этого генерируется событие 4740, на обоих контроллерах
Как удобно отслеживать события блокировки
Я приведу примеры, как это делаю я и как это можно автоматизировать и оповещать вас заранее, чем это сделает представитель технической поддержки. Самый правильный вариант, это использование систем мониторинга, таких как SCOM или Zabbix, но если их нет, то можно упростить себе жизнь вот такими утилитами. Могу точно сказать, что у вас в компании, как минимум не один контроллер домена, в противном случае у вас проблемы. Бегать по каждому из контроллеров домена, это не лучший вариант, правильнее будет либо перенаправлять все события на централизованный коллектор или же воспользоваться двумя волшебными утилитами, которые вам упростят жизнь.
В поле «Target User Name» вы указываете логин пользователя, кто подвергся блокировке в Active Directory.
На выходе вы получите отчет по всем контроллерам в домене, о статусе вашей учетной записи. Как видите, мой Барбоскин Геннадий Викторович заблокирован и имеет статус «Locked», видно количество попыток неправильного ввода пароля (Bad Pwd Count) и на каких контроллерах домена, на них мы и будем искать нужные нам события, о которых я говорил выше.
Открываем просмотр событий на нужном контроллере домена. Переходим в журнал «Безопасность (Security)» именно в нем кроется причина блокировки учетной записи Барбоскина Геннадия. Так как событий огромное количество, то нам нужно отфильтровать наш журнал событий. Для этого есть кнопка «Filter Current Log (Фильтр текущего журнала)», она позволит нам выбрать только те события, которые нам нужны.
В поле «Logged (Дата)» указываем за какой срок нужны данные, я укажу 12 часов, и в поле все события, укажем номер ID 4740 и нажимаем «Ок»
Видим нашлось 50 событий, но может быть и больше и чтобы ускорить поиск нужного события, мы воспользуемся поисков, для этого нажмите кнопку «Find (Поиск)»
В поисковом поле указываем нужный вам логин учетной записи Windows и нажимаем поиск, если сообщений много, то он может слегка подвисать, не переживайте по этому поводу.
В итоге у меня нашлось событие с кодом 4740, из которого видна причина блокировки учетной записи. В данном случае это рабочая станция с именем SVTTSETMAIN01, это тестовая виртуальная машина, как видите тут статус «A user account was locked out», можно переходить на эту машину и смотреть в чем там дело.
В событиях 4740 вы можете встреть еще вот такие причины блокировки учетной записи Active Directory, так например у меня имя сервера, где происходит блокирование EXchange, означает, что проблема в Outlook или его календарем. Я вам рассказывал, где кэшируются его данные доступа, в заметка Outlook постоянно запрашивает пароль.
В моей компании используются сервисы Google, такие как G-Sute и общие файловые диски, и вот при смене пароля пользователем, в данных утилитах могут остаться старые данные, в результате чего вы будите видеть в логах в компьютере блокировки имя WORKSTATION. Думаю с событием 4740 все понятно, но оно не всегда показывает подробный источник блокировки, поэтому нужно смотреть событие 4771.
Вот пример блокировки из-за WiFI подключения, об это мне говорит имя компьютера CISCO точки доступа. Как видите причин может быть очень много.
Более подробную причину блокировки учетной записи Windows на покажет событие 4771. Сделаем так же фильтрацию и по нему. Основное сообщение тут «Kerberos pre-authentication failed», обратите внимание тут есть IP-адрес, что уже хорошо, это дополнительная информация, показывающая территориальный источник. В ошибка есть код отказа Kerberos, таблица была представлена выше.
Еще может быть полезным событие с кодом 4776, тут то же будет показано с какой рабочей станции была попытка ввода учетных данных.
Кстати получив IP-адрес вы можете посмотреть его mac адрес на DHCP сервере или же на сетевом оборудовании, например, Cisco, я показывал как там узнать mac-адрес.
Далее с помощью специальных сервисов можно определить, что за производитель у данного mac-адреса, сайтов в интернете полно, которые вам помогу, например, https://2ip.ua/ru/services/information-service/mac-find. Будет полезно с мобильными устройствами.
Еще полезным будет изучение события 4625, там вы можете обнаружить процесс из-за которого происходит блокировка учетных записей.
Как видите утилита от компании Mirosoft отлично работает, но можно посмотреть, что-то более удобное, мне нравится утилита Account Lockout Examiner от Netwrix, она бесплатная и позволяет создавать портал для технической поддержки, где они могут видеть кто заблокирован и разблокировать его, а так же причину и она умеет посылать оповещения по электронной почте.
Утилита Account Lockout Examiner проста в установке и потребует от вас две вещи:
Через некоторое время вы получите табличку со всем пользователями у кого наблюдаются проблемы с блокировкой учеток. Тут вы увидите столбец «Workstation» в котом вы увидите адрес устройства блокировки, есть поле Bad Pwd Count показывающее количество попыток неправильно введенного пароля и дата последнего ввода. В самом конце вы увидите статусы пользователей Not locked или Locked.
Тут же вы можете через правый клик разблокировать пользователя.
В настройках Account Lockout Examine вы можете указать адрес электронной почты и сервер, для уведомлений, о событиях блокировки пользователей.
Если развернете IIS на данном сервер, где установлена утилита, то сможете создать портал для технической поддержки, где можно делегировать права на разблокировку пользователей.
Поиск компьютера блокирующего пользователя через PowerShell
PowerShell, очень мощное средство позволяющее сделать очень многое, вот пример поиска устройства из-за которого блокируется учетная запись. Открываем PowerShell ISE и вводим код:
Аналогичным образом можно опросить из PowerShell все контроллеры домена в Active Directory:
Надеюсь, что мой скромный опыт слегка вам поможет в поиске причин, по которым у вас в домене блокируются учетные записи Active Directory.
Блокировка учетной записи не в домене Active Directory
В случае с Active Directory все понятно, а как быть если учетная запись заблокировалась на вашем локальном, домашнем компьютере. Тут две ситуации, если у вас есть заблокировалась одна из нескольких учетных записей и у других записей есть права администратора, то вы можете все разблокировать, и вторая ситуация, если у вас одна учетная запись и она залочилась, тут будет повеселее, но так же все поправимо. Я опущу причины блокировки, вероятнее всего у вас стоит политика блокировки и вы ее можете поправить через локальную, для этого в окне выполнить напишите gpedit.msc и отключите пункты, о которых я писал в самом начале, либо же с вами кто-то подшутил таким образом выставив вам эту политику, но не суть.
Как разблокировать учетную запись в Windows 10 имея вторую учетку
Если у вас блокировка учетной записи windows 10 уже свершилась, и есть в наличии вторая учетная запись, например у папы своя у мамы своя, то сделайте следующее. Чтобы снять блокировку активируйте учетную запись, откройте окно выполнить, через сочетание клавиш WIN и R и введите название оснастки lusrmgr.msc
Открываем контейнер «Пользователи» и находим нужного нам, переходим в его свойства
Снимаем у нее галку «Заблокировать учётную запись» и нажимаем применить, все учетная запись теперь будет в рабочем состоянии.
Как разблокировать свою учётную запись Windows, если нет административного доступа
Чтобы обойти блокировку учетной записи, можно пойти двумя путями, легким и посложнее. Самый простой способ разблокировать учетную запись не имя административных прав, это воспользоваться загрузочным диском SonyaPE. Когда вы сделаете из него загрузочную флешку и загрузитесь с нее, то получите рабочий стол Windows 7. Там есть утилита Active@ Password Changer Professional 3.8, которая позволит вам включить и сбросить пароль от встроенной учетной записи Администратор, которая есть в любой операционной системе Windows, далее зайдя под ней вы разблокируете нужную нам учетную запись, как я описывал выше.
Как видите этот метод позволяет обойти блокировку учетной записи, но он не единственный, допустим у вас под рукой нет такого диска, как SonyaPE, что делать. Можно воспользоваться встроенными средствами восстановления Windows или же ими, но на любом установочном диске с Windows вашей редакции. В заметке «Как вернуть предыдущую версию виндоус 10» я показал метод попадания в дополнительные инструменты Windows 10.
Либо вы можете попасть в эти утилиты, через инструменты восстановления системы, о которых шла речь в заметке про восстановление загрузчика Windows 10.
В том и в другом случае, вам необходимо открыть командную строку.
Выбираем раздел HKEY_LOCAL_MACHINE, после чего в меню «Файл» выберите пункт «Загрузить куст».
У вас откроется проводник Windows. В моем компьютере, перейдите по пути Windows\System32\Config. В этой папке лежит файл локальной базы данных пользователей, по имени SAM. Выбираем его и открываем.
Задаем имя новому кусту, для примера это будет 777.
Выбираем теперь куст 00003f8. В правой панели реестра ищем параметр «F» и двойным кликом раскрываем его.
В окошке параметра нам нужна строка 0038. Её первые два значения (у нас это 10 и 00) заменяем.
Двойным кликом щёлкаем по очереди на каждом из двух значений, и когда те выделятся синим, вписываем другие значения. А эти другие значения должны быть 10 и 02 соответственно.
Теперь в окне реестра кликаем на загруженный и отредактированный куст, у нас это 777. И выгружаем его: жмём «Файл», далее «Выгрузить куст». Все необходимые изменения внесены.