ГлавнаяРазноеВведен некорректный sid

Mark Russinovich по-русски Mark Russinovich по-русски. Введен некорректный sid


Изменение SID и имени базы данных

Этот выпуск посвящен некоторым аспектам проблемы переименования и клонирования базы данных. Начнем с простого - как узнать и изменить идентификатор службы (SID) и имя базы данных (DB_NAME). Последний раз Том Кайт вернулся к этому вопросу 20 августа 2002 года.

Что такое SID, как его узнать и как изменить

Том!

Тривиальный вопрос для тебя: что такое SID и для чего он используется? Повлияет ли его изменение на другие экземпляры базы данных? И, наконец, как мне узнать значение SID моей базы данных? Я не смог найти ответ на сайте technet.oracle.com.

Ответ Тома Кайта

SID - это идентификатор сайта. Его значение хешируется вместе со значеним параметра ORACLE_HOME в ОС Unix для получения уникального ключа для подключения к области SGA. Если значения Oracle_sid или Oracle_home установлены неправильно, будет получено сообщение "oracle not available", поскольку мы не можем подключиться к сегменту разделяемой памяти, который идентфицируется этим "волшебным" лючом. В NT мы не используем разделяемую память, но SID все равно важен. Можно создать несколько баз данных в одном начальном каталоге oracle, так что, надо же их как-то идентифицировать.

Изменить его сложнее, чем кажется. Я знаю, что вы работаете в ОС Unix, поэтому следующая последовательность шагов для изменения SID (или имени базы данных) в Unix - для вас. В NT последовательность шагов - немного другая.

Как найти sid -- с помощью оператора select instance from v$thread.

НАЗНАЧЕНИЕ

Здесь описано, как найти и изменить имя базы данных (db_name) или ORACLE_SID для экземпляра, не пересоздавая базу данных.

ДЛЯ КОГО ЭТА ЗАМЕТКА

Для АБД, которым надо найти или изменить db_name или ORACLE_SID.

Чтобы найти текущие значения DB_NAME и ORACLE_SID:

Выполните запросы к представлениям v$database и v$thread.

V$DATABASE дает DB_NAME V$THREAD дает ORACLE_SID

Если ORACLE_SID = DB_SID и db_name = DBNAME:

Чтобы найти текущее значение ORACLE_SID:

SVRMGR> select instance from v$thread; INSTANCE ---------------- DB_SID

Чтобы найти текущее значение DB_NAME:

SVRMGR> select name from v$database; NAME --------- DBNAME

Изменение базы данных для работы с новым ORACLE_SID:

  1. Остановите экземпляр
  2. Скопируйте все управляющие файлы, журналы повторного выполнения и файлы данных.
  3. Пройдите по файлам .profile, .cshrc, .login, oratab, tnsnames.ora и задайте переменной среды ORACLE_SID новое значение.

    Например, пройдите по всем каталогам и выполните grep ORACLE_SID *

  4. Перейдите в каталог dbs % cd $ORACLE_HOME/dbs и переименуйте следующие файлы:
    • init<sid>.ora (или используйте для задания файла параметров инициализации файл pfile.)
    • управляющий файл (файлы). Это не обязательно, если вы не переименовываете управляющие файлы и используете параметр control_files. Параметр control_files устанавливается в файле init<SID>.ora или в файле, на который ссылается в нем параметр ifile. Проверьте, что параметр control_files не указывает на старые имена управляющиъ файлов, если вы их переименовали.
    • crdb<sid>.sql и crdb2<sid>.sql, Это не обязательно, пеоскольку эти файлы используются только при создании базы данных.
  5. Перейдите в каталог rdbms/admin % cd $ORACLE_HOME/rdbms/admin и переименуйте файл:
    • startup<sid>.sql. Это не обязательно. На некоторых платформах этот файл может находиться в каталоге $ORACLE_HOME/rdbms/install. Проверьте, что содержимое этого файла не ссылается на старые файлы init<SID>.ora, которые вы переименовали. Этот файл упрощает процесс запуска с сервера базы данных в исключительном режиме (startup exclusive).
  6. Переименование файлов данных и файлов журнала повторного ввполнения описано в документе службы поддерожки <Note:9560.1>.
  7. Измените соответственно значение переменной среды ORACLE_SID.
  8. Проверьте в каталоге $ORACLE_HOME/dbs, включен ли файл паролей. Если да, в каталоге будет файл orapw<OLD_SID> и надо создать новый файл паролей для нового значения SID (переименование старого файла не поможет). Если файл orapw<OLD_SID> не существует, переходим на шаг 9. Для создания нового файла паролей выполните следующую команду от имени владельца ПО oracle: orapwd file=orapw<NEWSID> password=?? entries=<количество пользователей, которые смогут получить право запускать экземпляр>
  9. Запустите базу данных и проверьте, что она работает. После этого остановите базу данных и создайте завершающую резервную копию всех управляющих файлов, файлов журнала повторного выполнения и файлов данных.
  10. При запуске экземпляра в управляющем файле установится текущее значение ORACLE_SID.
Изменение имени (db_name) базы данных:
  1. Подключитесь как internal: % svrmgrl SVRMGR> connect internal
  2. Введите SVRMGR> alter system switch logfile; для принудительной обработки контрольной точки.
  3. Введите SVRMGR> alter database backup controlfile to trace resetlogs; В результате будет создан трассировочный файл, содержащий оператор CREATE CONTROLFILE для пересоздания управляющего файла в текущем виде.
  4. Отсновите базу данных и завершите сеанс SVRMGR> shutdown SVRMGR> exit База данных должна быть остановлена штатно, с помощью SHUTDOWN NORMAL или SHUTDOWN IMMEDIATE. Нельзя останавливать ее аварийно с помощью SHUTDOWN ABORT.
  5. Перейдите в каталог, в котором находятся трассировочные файлы. Они обычно записываются в каталог $ORACLE_HOME/rdbms/log. Если установлен параметр инициализации user_dump_dest, перейдите в каталог, указанный в качестве его значения. Трассировочные файлы имеют вид ora_NNNN.trc, где NNNN - число.
  6. Скопируйте оператор CREATE CONTROLFILE из трассировочного файла и поместите его в новый файл, например, ccf.sql.
  7. Отредактируйте созданный файл ccf.sql

    БЫЛО:

    CREATE CONTROLFILE REUSE DATABASE "старое_имя_базы" NORESETLOGS ...

    НАДО:

    CREATE CONTROLFILE set DATABASE "новое_имя_базы" RESETLOGS ...

    БЫЛО:

    # Recovery is required if any of the datafiles are restored backups, # or if the last shutdown was not normal or immediate. RECOVER DATABASE USING BACKUP CONTROLFILE

    НАДО:

    # Recovery is required if any of the datafiles are restored backups, # or if the last shutdown was not normal or immediate. # RECOVER DATABASE USING BACKUP CONTROLFILE
  8. Сохраните файл ccf.sql и завершите сеанс редактирования
  9. Переименуйте старые управляющие файлы в качестве резервной копии, и чтобы их не было при создании новых.
  10. Отредактируйте файл init<SID>.ora, задав db_name="новое_имя_базы".
  11. Подключитесь как internal: % svrmgrl SVRMGR> connect internal
  12. Выполните сценарий ccf.sql: SVRMGR> @ccf Он выполнит команду startup nomount и пересоздаст управляющий файл.

    Если в этот момент вы получаете сообщение об ошибке, утверждающее, что для файла необходимо восстановление носителя (media recovery), значит, база данных была остановлена аварийно на шаге 4. Можно попытаться восстановить базу данных, используя данные повторного выполнения в текущем файле журнала, с помощью команды:

    SVRMGRL> recover database using backup controlfile; Будет выдан запрос архивного файла журнала повторного выполнения. После применения текущего файла журнала базу данных, возможно, удастся открыть. Но, это НЕ ГАРАНТИРОВАНО. Если после применения текущего файла журнала повторного выполнения база данных не открывается, весьма вероятно, придется повторить все с начала, предварительно нормально остановив старую базу данных.

    Чтобы применить необходимые данные повторного выполнения, надо проверить активные журналы повторного выполнения и применить один, порядковый номер которого указан в сообщении. Обычно, это журнальный файл со status=CURRENT.

    Чтобы найти список активных журнальных файлов:

    SVRMGR> select group#, seq#, status from v$log; GROUP# SEQUENCE# STATUS ---------- --------- ---------------- 1 123 CURRENT <== надо применить этот журнал 2 124 INACTIVE 3 125 INACTIVE 4 126 INACTIVE 5 127 INACTIVE 6 128 INACTIVE 7 129 INACTIVE 7 rows selected. SVRMGR> select member from v$logfile where GROUP# = 1; Member ------------------------------------ /u02/oradata/V815/redoV81501.log Последней командой в файле ccf.sql должна быть: alter database open resetlogs;
  13. Может также потребоваться изменить глобальное имя базы данных: alter database rename global_name to . Подробнее об этом см. <Note:1018634.102>.
  14. Проверьте, что база данных работает.
  15. Остановите базы данных и создайте ее резервную копию.

Cколько АБД Oracle надо, чтобы поменять лампочку... Комментарий от 13 сентября 2001 года

Удивительно, сколько механической работы требуется в Oracle для простых вещей.

Смысл реляционной модели - нормализация; если проще - устранение избыточных данных. А что мы имеем - SID в десятке мест?

Ответ Тома Кайта

Ну, и что???

Чтобы было просто -- не меняйте SID.

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

НА САМОМ ДЕЛЕ, мы сталкиваемся с попыткой ИЗМЕНИТЬ ПЕРВИЧНЫЙ КЛЮЧ.

Это, на самом деле, ПРЕКРАСНАЯ демонстрация особенностей реляционной модели. Первичным ключом для базы данных является SID. Вы пытаетесь изменить первичный ключ (чего в реляционных базах данных делать КРАЙНЕ НЕ РЕКОМЕНДУЕТСЯ) и реализовать действие on update cascade.

Так что, даже при наличии ОДНОГО внешнего ключа, пробюлема будет аналогичной. Если вы когда-нибудь изменяли значение первичного ключа, вам приходилось делать то же самое (находить все внешние ключи и изменять их соответственно).

Почему вы считаете изменение SID "простой вещью" (мне этот процесс кажется весьма мутным -- мне ни разу не приходилось самому это делать за 15 лет)...

Комментарий от 1 марта 2001 года

Прекрасное описание процедуры изменения sid. Я постоянно это делала на прежней работе при создании тестовых экземпляров. Одна проблема, связанная с sid, меня всегда беспокоила - как узнать этот самый sid. Если вы не знаете sid, как вы подключитесь к экземпляру и спросите значение sid?

Ответ Тома Кайта

ps -<флаги, соответствующие версии ОС UNIX> | grep pmon например: $ ps -aux | grep pmon ora734 3662 0.0 0.518720 6896 ? S Jan 21 0:00 ora_pmon_ora734 tkyte 7446 0.0 0.1 944 784 pts/8 S 13:30:09 0:00 grep pmon ora716 12929 0.0 0.417472 5552 ? S Jan 22 0:00 ora_pmon_ora716 oracle9i 13112 0.0 13.6249688205872 ? S Jan 18 0:00 ora_pmon_ora9iUTF ora806 13901 0.0 1.03324014080 ? S Feb 26 0:00 ora_pmon_ora806 oracle9i 17941 0.0 24.6413528372528 ? S Feb 18 0:00 ora_pmon_ora9i ora817 25122 0.0 16.2279824245824 ? S Feb 01 0:00 ora_pmon_ora817dev ora815 25424 0.0 2.99008043712 ? S Jan 28 0:00 ora_pmon_ora815 получаем 7 значений sid, работающих сечас на моей тестовой машине -- ora_pmon_$ORACLE_SID

Если вы работате не на сервере, sid просто не имеет значения, - вам нужна запись tns в файле tnsnames.ora.

На NT посмотрите список служб Oracle в Панели управления.

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

Изменение SID на платформе Windows, кстати, описано вот здесь.

Copyright © 2003 Oracle Corporation

Перевод очередной статьи Джонатана Льюиса пока придется подождать. Статья большая... Пожалуй, продолжим тему клонирования БД "по мотивам" ответов Тома Кайта. Следите за новостями на сайте проекта Open Oracle.

С наилучшими пожеланиями,

  В.К.

mir-oracle.com.ua

Ошибки TLS при работе в Сбербанк Бизнес Онлайн

Ошибки TLS соединений в Сбербанк Бизнес Онлайн – проблема с которой приходится иногда сталкиваться пользователям системы. Последнее время дистанционное управление банковскими операциями приобрело большую популярность. Многие компании и частные предприятия оценили удобство сервиса: теперь нет необходимости тратить время на посещение банка, а управление счетами, заполнение платежных поручений можно проводить прямо в офисе за рабочим столом. Как и в любой системе, здесь не редки сбои в работе. Этого не избежать. Лучше заранее знать о возможных проблемах, чтобы легко справиться с ними.

Работа любого сервиса неизбежно связана с наличием единичных сложностей в подключении

Содержание статьи:

Ошибки соединения Сбербанк Бизнес Онлайн

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

  • Некорректный ввод логина и пароля. Такая надпись на мониторе свидетельствует о том, что действительно логин и пароль были введены неправильно. Решить проблему просто: перезагрузить страницу, снова войти, но при этом предельно внимательно указать идентификатор и пароль.
  • Ошибка 401. Она появляется во время входа в систему. Тут причиной может стать работа самого компьютера (устаревшая версия ОС или браузера, блокировка антивирусом или рядовой сбой). Выход следующий: обновить браузер, установить сервис банка Бизнес Онлайн в антивирусный перечень исключений или просто повторно войти.
  • Ошибка контроля. Возникает при формировании платежного документа, если допущены погрешности в заполнении. Система автоматически принимает документ как неактуальный. Для устранения этой неприятности стоит повторно перепроверить все внесенные данные в поля документа, исправить неточности, и снова установить проверку «платежки».
  • Внутренняя ошибка сервера. Здесь вообще не стоит беспокоиться и некоторое время переждать: всеми сбоями сервера занимаются специалисты банка. Достаточно сообщить об этом в службу техподдержки.
В этой статье собраны наиболее часто встречаемые проблемы в сервисе банка и пути их устранения

Проблема номер 0100

Ошибка TLS соединения 0100 Сбербанк Бизнес Онлайн предупреждает о проблемах с сертификатом. При входе в систему происходит процедура проверки и подтверждения его подлинности. Сервер банка осуществляет проверку подлинности сертификата, срок действия, сравнивает адрес URL с указанным адресом в сертификате.

Ошибка TLS соединения 0140

Причин возникновения этой проблемы может быть несколько. Конечно, это может быть элементарный сбой программы. Но чаще всего это связано с применением электронной цифровой подписи. Она является идентификатором пользователя и применяется при визировании различных документов. Скорее всего, мог истечь срок действия подписи, и поэтому она устарела и не является действительной. Для этого нужно обновить ее. Если же срок действия еще не истек, необходимо проверить корректность заполнение полей. Возможно, нужно установить Capicom для прикрепления цифровой подписи. В любом случае, надо быстро реагировать и обратиться за помощью в службу техподдержки банка, предварительно указав код и действия, предшествующие возникновению погрешности. Чтобы в дальнейшем не возникало подобных проблем, необходимо знать, когда истекает срок подписи.

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

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

Проблема номер 0160

Если на экране возникает сообщение «Ошибка TLS соединения 0160» в системе Сбербанка, это говорит о том, что сервису не удалось проверить подлинность сертификата клиента. Это может означать одно, что у пин-кода закончился срок действия. Решение простое – обратиться в банковское учреждение для получения нового токена и пин-кодов.

Заключение

Многие бизнес-структуры работают с программой Сбербанк Бизнес Онлайн, и не редки случаи возникновения ошибок TLS соединений. Поскольку денежный оборот у многих компаний существенен, то принимать решение об устранении неполадки следует сразу. Нельзя надеяться, что это обыкновенный сбой системы. Такое может быть, как и неполадки на сервере. Но чаще всего подобное возникает из-за несоответствия требований, предъявляемых техническому оснащению при подключении к программе. Следует серьезно подойти к ПО, чтобы в дальнейшем не возникало подобных проблем. В любом случае, чтобы ускорить решение данного вопроса стоит сразу обратиться в службу технической поддержки банковского учреждения.

14-11-2017

  • Поделиться
  • Нравится
  • Твитнуть
  • Класс!
  • Нравится

sbankami.ru

Как узнать sid пользователя windows в домене

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

Sid windows

Давайте для начала с вами выясним определение SID или Security Identifier > это идентификатор безопасности, который используется в семействе операционных систем Windows для идентификации объекта:

  • Группа безопасности
  • Пользователь
  • Компьютер
  • Организационная единица
  • Принтер

SID во время создания объекта, присваивается ему , в домене Active Directory за это отвечает мастер роль RID. В рамках домена, каждый SID должен быть уникален, в отличии от имени, так как Ивановых Иванов Ивановичей, может быть много, а вот отличаться они будут логином и SID. Для операционной системы Windows, важнее сиды объектов, она же их использует и для контроля прав доступа на различные корпоративные ресурсы:

  • Папки и файлы
  • Принтеры
  • Доступ к внешним ресурсам

Структура SID

Давайте разбираться из каких частей состоит Security IDentifier.

Впереди идет версия сида, далее Генеральная область Authority - это ссылка на систему источник, которая его выпустила. В операционных системах Windows версия  Security IDentifier сейчас одна и равна она 1, Генеральная область Authority имеет значения 1,3,5, для Microsoft Exchange она 9. Далее в сиде следует 1 или более идентификаторов Sub Authority, а за ними идет RID (Relative IDentificator) локальный для данного Sub Authority номер субъекта безопасности.

 

По мимо этого, в любой ос Windows существуют встроенные или BuiltIn группы и учетные записи, например администратор или гость, в каждой ос виндоус они имеют одинаковые SID значения. Посмотреть вы их можете в оснастке Управление компьютером.

Сделаны они для того, что если у вас нет Active Directory, то вы могли бы администрировать данные системы с помощью них. Все SID для данных учетных записей находятся в локальной базе данных Windows, под названием Security Account Manager или SAM. Все сиды пользователей домена лежат в базе Active Directory в файле NTDS.dit.

База Security Account Manager

Давайте посмотрим за, что отвечает Security Account Manager:

  • Сопоставление имен с SID и обратно, некий такой DNS для учетных записей
  • Проверяет пароли, авторизовывает (принимает участие в процессе входа пользователей в ОС)
  • Ведет статистику, кто последний входил, количество входов, кто сколько раз ввел не тот пароль, короче аудит
  • Контролирует политика паролей учетных записей, в случае чего может блокировать учетные записи.
  • Ведет учет, кто в какие группы входит
  • Производит защиты самого себя
  • Дает программный интерфейс для управления базой учетных записей

Хранится SAM (Security Account Manager) в реестре Windows. Как открыть реестр windows, я уже описывал не однократно, переходим в ветку.

HKEY_LOCAL_MACHINE\SAM\SAM

Если вы кликните правым кликом и из контекстного меню выберете Разрешения, то обнаружите, что права доступа есть только у системы, а вот у администраторов локальной станции их нет, но при желании можно их получить, это лишний механизм защиты, так как можно вытащить хэши учетных записей и попытаться их взломать.

SAM это библиотека samsrv.dll, которая работает в Windows в виде процесса lsass.exe, увидеть это можно в диспетчере задач.

1 способ узнать sid пользователя, команда WMIC

Для примера я все буду показывать на своей рабочей станции с установленной в ней Windows Server 2012 R2, станция принадлежит домену Active Directory. Первый метод, это использование старого, доброго WMIC инструментария (Windows Management Instrumentation). Все, что вам нужно, это знать имя пользователя, точнее его логин. Чтобы посмотреть список локальных пользователей введите команду

На выходе вы получите список локальных пользователей.

Чтобы выяснить все логины доменных пользователей вводим команду

Net user "пользователи домена" /domain

Я вам это уже рассказывал в заметке Как узнать имена учетных записей Администраторов домена. На выходе получите, что то такое

Далее зная логин все просто вводим

wmic useraccount where name="admdc" get sid

Как видите все работает.

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

wmic useraccount where sid="S-1-5-21-2071342971-2054724104-2057240633-1001" get name

Еще с помощью WMI вы можете реализовать вот, что укажите имя компьютера (для локального) или домена (для доменного пользователя). Ниже пример получения SID локальной рабочей станции

wmic useraccount where (name="Администратор" and domain="%computername%") get sid

Для доменной структуры

wmic useraccount where (name="Администратор" and domain="aetp") get sid

Получить логин по SID аналогично предыдущей команду.

wmic useraccount where (sid="S-1-5-21-613421863-3366779934-4260147692-500" and domain="aetp") get name

2 способ узнать sid пользователя, команда Whoami

Тоже довольно старенькая команда из cmd.exe. Вводим

Получаем полный сид текущего залогиненного пользователя.

Если ввести Whoami /logonid, то можно получить logonid, выглядит он вот так S-1-5-5-0-595920

Если ввести ключ /all, то вы увидите, все sid локальных (bultin) групп и пользователей

Так же вы увидите сведения о привилегиях.

На мой взгляд, данный метод, немного проще первого, так как требует ввода меньшего количества ключей.

3 способ узнать sid пользователя, ADUC и ADSIedit

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

После чего заходим в свойства учетной записи, вкладка Редактор атрибутов и находим там поле objectSid.

Так же SID можно посмотреть и во встроенной оснастке ADSIedit, подключаетесь там к контексту именования имен и заходите в свойства нужной учетной записи.

Да чуть не забыл в Windows Server 2012 R2 есть такое средство как Центр администрирования Active Directory, ищите там нужную учетную запись и в ней находите пункт SID.

4 способ узнать sid пользователя, утилита PsGetSid

Есть такая замечательная утилита от Microsoft од названием PsGetSid.

Скачать PsGetSid можно по ссылке https://technet.microsoft.com/en-us/sysinternals/bb897417.aspx

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

смысл у данной утилиты очень простой, она входит в состав Sysinternals и умеет получать SID пользователя по его имени и наоборот, умеет получать как локальных пользователей, так и доменных.

Вводим команду psgetsid имя компьютера\логин учетки

psgetsid adm999\admdc

и наоборот, выясним имя по SID:

psgetsid S-1-5-21-613421863-3366779934-4260147692-1312

5 способ узнать sid пользователя, PowerShell и System.Security.Principal.NTAccount

Пятым методом будет использование в powershell класса System.Security.Principal.NTAccount. Для домена Active Directory.

$objUser = New-Object System.Security.Principal.NTAccount("домен", "логин учетки")$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])$strSID.Value

Для локального пользователя команда будет такой.

$objUser = New-Object System.Security.Principal.NTAccount("логин")$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])$strSID.Value

Обратная ситуация получаем по SID имя пользователя

$objSID = New-Object System.Security.Principal.SecurityIdentifier ("S-1-5-21-613421863-3366779934-4260147692-1312")$objUser = $objSID.Translate( [System.Security.Principal.NTAccount])$objUser.Value

6 способ узнать sid пользователя, Get-ADUser

Снова воспользуемся командлетами powershell Get-ADUser. вводим команду для получения SID доменного пользователя.

Get-ADUser -Identity 'логин' | select SID

получить наоборот логин по sid

Get-ADUser -Identity S-1-5-21-247647651-3952524288-2944781117-23711116

pyatilistnik.org

Смена SID при клонировании и массовом развёртывании / Блог компании Acronis / Хабр

Привет, Хабр! Упомянутая в заголовке тема всё ещё порождает множественные дискуссии и недопонимание между системными администраторами. В своей статье я постараюсь ответить на следующие вопросы:
  1. Что такое SID и каких он бывает типов?
  2. Когда наличие двух и более машин с одинаковыми Machine SID будет порождать проблемы? Или, другими словами, когда всё-таки (не)нужно менять Machine SID?
  3. Что такое Sysprep и нужен ли Sysprep для клонирования/развёртывания?
Эти вопросы будут рассмотрены в первую очередь в контексте задачи развёртывания/клонирования множества рабочих станций/серверов из одного мастер-образа в пределах одной компании.

В основу рассуждений была взята популярная статья Марка Руссиновича (доступна также на русском языке), которую довольно часто неправильно интерпретируют (судя по комментариям и «статьям-ответам»), что приводит к неприятным последствиям. Добро пожаловать под кат.

TL;DR
  1. Менять SID машины само по себе бессмысленно и даже вредно для современных ОСей (пример последствий смены SID на Windows 10 ниже).
  2. Для подготовки машины к клонированию/развёртыванию образа стоит использовать sysprep.
  3. SID машины будет иметь значение, только если одну из склонированных машин промоутить до домен контроллера. Так делать не стоит.
  4. Не стоит клонировать/развёртывать образ машины, которая УЖЕ добавлена в домен; добавление в домен нужно делать после клонирования/развертывания.

Что такое SID, его типы и чем отличается Machine SID от Domain SID?

Ликбез

“SID (Security Identifier), или Идентификатор безопасности – Это структура данных переменной длины, которая идентифицирует учетную запись пользователя, группы, домена или компьютера (в Windows на базе технологии NT (NT4, 2000, XP, 2003,Vista,7,8)). SID ставится в соответствие с каждой учетной записью в момент её создания. Система оперирует с SID'ами учетных записей, а не их именами. В контроле доступа пользователей к защищаемым объектам (файлам, ключам реестра и т.п.) участвуют также только SID'ы.”

В первую очередь, важно различать SID компьютера (Machine SID) и SID домена (Domain SID), которые являются независимыми и используются в разных операциях.

Machine SID и Domain SID состоят из базового SID’а (base SID) и относительного SID’а (Relative SID = RID), который «приклеивается» в конец к базовому. Базовый SID можно рассматривать как сущность, в рамках которой можно определить группы и аккаунты. Машина (компьютер) является сущностью, в рамках которой определяются локальные группы и аккаунты. Каждой машине присваивается machine SID, и SID’ы всех локальных групп и аккаунтов включают в себя этот Machine SID с добавлением RID в конце. Для примера:

Machine SID для машины с именем DEMOSYSTEM S-1-5-21-3419697060-3810377854-678604692
DEMOSYSTEM\Administrator S-1-5-21-3419697060-3810377854-678604692-500
DEMOSYSTEM\Guest S-1-5-21-3419697060-3810377854-678604692-501
DEMOSYSTEM\CustomAccount1 S-1-5-21-3419697060-3810377854-678604692-1000
DEMOSYSTEM\CustomAccount2 S-1-5-21-3419697060-3810377854-678604692-1001
Именно SID’ы (а не имена) хранятся в токенах доступа (access tokens) и дескрипторах безопасности (security descriptors), и именно SID’ы используются при проверке возможности доступа к объектам системы Windows (в том числе, например, к файлам).

На машине вне домена используются локальные SID’ы, описанные выше. Соответственно, при соединении с машиной удалённо используется локальная аутентификация, поэтому даже имея 2 или более машин с одинаковым machine SID в одной сети вне домена, проблем с логином и работой внутри системы не будет, т.к. SID’ы в операциях удалённой аутентификации попросту не используются. Единственный случай, в котором возможны проблемы, это полное совпадение имени пользователя и пароля на двух машинах – тогда, например, RDP между ними может глючить.

Когда машина добавляется в домен, в игру вступает новый SID, который генерируется на этапе добавления. Machine SID никуда не девается, так же как и локальные группы, и пользователи. Этот новый SID используется для представления аккаунта машины в рамках домена. Для примера:

Domain SID для домена BIGDOMAIN S-1-5-21-124525095-708259637-1543119021
BIGDOMAIN\DEMOSYSTEM$ (аккаунт машины (computer account)) S-1-5-21-124525095-708259637-1543119021-937822
BIGDOMAIN\JOHNSMITH (аккаунт пользователя (user account)) S-1-5-21-124525095-708259637-1543119021-20937
Таким образом, машина DEMOSYSTEM теперь имеет два независимых SID’а:

• Machine SID, определяющая машину как сущность, в рамках которой заданы группы и аккаунты (первая строчка в первой таблице).

• SID аккаунта машины (computer account SID) в рамках домена BIGDOMAIN (вторая строчка во второй таблице).

Увидеть точное значение machine SID можно с помощью утилиты PsGetSid, запустив её без параметров. Второй SID, относящийся к домену, можно увидеть, запустив PsGetSid со следующими параметрами: psgetsid %COMPUTERNAME%$. Соответственно, для примера из таблиц это будет “psgetsid DEMOSYSTEM$".

Основная суть в том, что SID’ы должны быть уникальны в пределах окружения (authority), к которому они применимы. Другими словами, если машине DEMOSYSTEM присвоен machine SID S-1-5-21-3419697060-3810377854-678604692-1000, то неважно, что у другой машины в той же сети будет идентичный machine SID, т.к. этот SID используется только локально (в пределах машины DEMOSYSTEM). Но в пределах домена BIGDOMAIN computer SID у обоих машин должен быть уникальным для корректной работы в этом домене.

Смена SID при клонировании или развёртывании

В применении к продукту Acronis Snap Deploy 5 (основное предназначение — массовое развёртывание систем из мастер-образа), в котором функциональность смены SID-а присутствовала с самой первой версии, это означает, что мы, как и многие пользователи, ошибочно пошли на поводу у устоявшегося мнения, что менять SID нужно.

Однако исходя из вышесказанного, ничего страшного в развёртывании (или клонировании) машины без изменения Machine SID вовсе нет, в случае если это развёртывание происходит до добавления машины в домен. В противном случае — возникнут проблемы.

Из этого правила есть одно исключение: нельзя клонировать машину, если в дальнейшем роль этого клона планируется повышать (promote) до уровня домена контроллера. В этом случае Machine SID домен контроллера будет совпадать с computer SID в созданном домене, что вызовет проблемы при попытке добавления оригинальной машины (из которой производилось клонирование) в этот домен. Это, очевидно, относится только к серверному семейству Windows.

Проблемы, связанные со сменой SID

Пересмотреть точку зрения на функциональность смены SID нас подтолкнул выпуск новой версии Windows. При первом тестовом развёртывании образа Windows 10 со сменой SID на получившейся машине обнаружилось, что кнопка Start перестала нажиматься (и это оказалось только вершиной «айсберга»). Если же развёртывать тот же образ без смены SID, то такой проблемы не возникает.

Основная причина в том, что эта опция вносит изменения практически во всю файловую систему развёртываемой машины. Изменения вносятся в реестр Windows, в разрешения NTFS (NTFS permissions) для каждого файла, в SID'ы локальных пользователей (так как SID пользователя включает в себя в том числе и machine SID; подробнее тут) и т.д.

В случае с Windows 10 большая часть ключей реестра не могла быть модифицирована («Error code = C0000005. Access violation» и другие ошибки) и, как следствие, наша функция смены SID'а отрабатывала не до конца, что и приводило к трагической гибели практически нерабочей копии Windows 10.

Было принято решение убрать эту опцию в случае, если в мастер-образе мы находим Windows 10 (или Windows Server 2016). Решение было принято на основе теоретических выкладок описанных выше плюс, естественно, было подтверждено практикой при тестировании недавно вышедшего обновления Acronis Snap Deploy 5 во множестве комбинаций: с и без переименования машин после развёртывания, с добавлением в домен и рабочую группу, развёртывание из мастер-образов снятых от разных состояний мастер-машины (она была добавлена в домен или рабочую группу в разных тестах) и т.д.

Использование Sysprep

Начиная с Windows NT клонирование (развертывание) ОСи с использованием только NewSID никогда не рекомендовалось самим Microsoft. Вместо этого рекомендуется использовать родную утилиту Sysprep (см. KB314828), которая, помимо смены SID'а, также вносит большое число других изменений, и с каждой новой версией Windows их становится только больше. Вот небольшой (неполный) список основных вносимых изменений:

  • Удаляется имя машины
  • Машина выводится из домена: это нужно для последующего успешного добавления в домен с новым именем
  • Удаляются plug-and-play драйвера, что уменьшает риск возникновения проблем с совместимостью на новом «железе»
  • Опционально удаляются Windows Event Logs (параметр 'reseal')
  • Удаляются точки восстановления
  • Удаляется профиль локального администратора и этот аккаунт отключается
  • Обеспечивается загрузка целевой машины в режим аудита, позволяющий устанавливать дополнительные приложения и драйверы
  • Обеспечивается запуск mini-setup при первом запуске для смены имени машины и другой дополнительной конфигурации
  • Сбрасывается период активации Windows (сброс возможен до 3 раз)

Таким образом, клонирование/развертывание без использования Sysprep может повлиять (читай «скорее всего, сломает») на функциональность Windows Update, Network Load Balancing, MSDTC, Vista и выше Key Manager Activation (KMS), который завязан на CMID (не путать с Machine SID), также изменяемый Sysprep'ом, и т.д.

Итого

Повторяя TL;DR из начала статьи, основной вывод можно сделать такой: для подготовки образа машины к клонированию/развёртыванию следует использовать sysprep в подавляющем большинстве случаев.
Линки
— Как изменить SID в Windows 7 и Windows Server 2008 R2 с помощью sysprep — How to View Full Details of All User Accounts in Windows 10 — Миф о дублировании SID компьютера — Sysprep, Machine SIDs and Other Myths — The Machine SID Duplication Myth (and Why Sysprep Matters) — Yes you do need to worry about SIDs when you clone virtual machines – reasserting the ‘myth’ — Why Sysprep is a necessary Windows deployment tool

Спасибо за внимание!

habr.com

Так нужно ли менять SID и делать sysprep?

Думаю, многие администраторы слышали от коллег, что при переносе или клонировании системы на другие компьютеры необходимо изменять SID машины. Так ли это? Давайте разберемся.

Достаточно давно уже вышла статья Марка Руссиновича, в которой он сорвал покровы с этой темы, но, к сожалению, все еще встречаются администраторы, которые с ней не ознакомились. Если вкратце описывать ее содержание, то выходит примерно следующее: каждому объекту безопасности Windows присваивает идентификатор безопасности (SID), который сопоставляет с именем, видимым конечному пользователю. Общее правило — эти идентификаторы должны быть уникальными в пределах определенного домена (а именно, такого домена, в пределах которого возможна ситуация, когда две машины с одинаковыми SID могут передать их друг другу).

Выглядит так, как будто бы SID менять необходимо. Но на самом деле следует отметить еще два момента. Первый: если рассматривать рабочую группу, то необходимо знать, что для получения доступов к ресурсам ее участники передают друг другу не SID, а учетные данные. Кстати, именно это позволяет в рабочей группе создать две локальные учетки с одинаковым именем и паролем на двух разных машинах, чтобы получать доступ к ресурсам друг друга без запроса пароля. Ну а поскольку SID при взаимодействиях внутри рабочей группы не используется, менять его в рабочей группе необходимости нет.

Если же говорить о AD домене, то такое уже не прокатит — AD для аутентификации использует SID машин и юзеров. Казалось бы уж в этом случае сброс SID’а необходим, но здесь-то у нас и появляется второй момент: дело в том, что при аутентификациях в пределах AD домена, используются не SID локальных машин, а SID учетных записей этих машин и пользователей в домене. Эти SID генерируются на основе SID-а AD домена, к которому прибавляется так называемый RID (relative ID), а уникальность этого RID, в свою очередь, гарантируется правильно работающим домен-контроллером с FSMO ролью RID мастера. Таким образом машина, которая пытается получить доступ к доменным ресурсам, будет использовать доменный SID (SID домена + RID), уникальность которого в пределах домена гарантирована. В холодном остатке мы имеем то, что SID на безопасность никак не влияет.

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

Как видите, SID учетки (GATE$) состоит из SID домена (SAND) + RID 1105, и именно этот SID используется для аутентификации этого компьютера на домен контроллере.

Кроме всего этого, необходимо упомянуть о двух исключениях, когда SID все же имеет значение: первое — это сам домен. Дело в том, что SID домена равен SID машины, которая стала первым домен контроллером в лесу. Если посмотреть на SID машин, являющихся домен контроллерами (если их несколько), то можно увидеть, что эти SID одинаковы (при этом SID их учеток в домене — разные). Таким образом любое обращение к домену, на самом деле использует этот SID и обращается к одному из контроллеров. При попытке ввода в домен компьютера, имеющего SID домена, вылезет ошибка, т. к. этот компьютер не является домен контроллером.

Ну и второе исключение — это если какой-то софт использует SID машин для своей аутентификации. В компании Microsoft по заявлениям Марка Руссиновича такого софта нет, а вот как делал свой софт Вася Пупкин — мало кому известно.

И последний вопрос который осталось рассмотреть: значит sysprep делать не нужно?

Ответ: нужно. Дело в том, что sysprep сбрасывает не только SID, но и некоторые другие параметры. Например WSUS ID. Совсем недавно я столкнулся с проблемой, когда два компьютера не могли одновременно быть добавлены на WSUS. После некоторой доли траблшутинга я обнаружил, что на этих машинах не выполнялся sysprep и они имели одинаковый WSUS ID, который не позволял им добавиться на сервер вместе. А вот и злополучный ID:

Собственно, после удаления этой записи в реестре, второй компьютер получил новый SusclientId, после чего обе машины благополучно добавились на WSUS.

Надеюсь, эта статья была полезна.

 

trainithard.ru

Миф о дублировании SID компьютера – Mark Russinovich по-русски

3 ноября 2009 года Sysinternals закрыла проект NewSID - утилиты, которая предназначалась для изменения идентификатора защиты компьютера (machine SID). Я написал NewSID в 1997 году (первоначально она называлась NTSID), поскольку в то время единственным доступным инструментом для смены SID был Microsoft Sysprep, а он не поддерживал смену SID на компьютерах с уже установленными приложениями. SID компьютера - это уникальный идентификатор, генерируемый программой установки Windows Setup, который операционная система использует в качестве основы для идентификаторов SID, соответствующих локальным учетным записям и группам, определяемых администратором. После того, как пользователь осуществляет вход в систему, он представляется в системе своими идентификаторами SID пользователя и группы в соответствии с авторизацией объекта (проверки прав доступа). Если две машины имеют одинаковый SID, то учетные записи или группы на этих машинах также могут иметь одинаковые SID. Отсюда очевидно, что наличие нескольких компьютеров с одинаковыми SID в пределах одной сети может привести к угрозе безопасности, так? По крайней мере, это предположение не противоречит здравому смыслу. Причиной, заставившей меня начать рассматривать возможность отказа от дальнейшей поддержки NewSID, стал тот факт, что, несмотря на в целом положительные отчеты пользователей о работе утилиты на Windows Vista, я не проводил полноценное тестирование ее работы лично, и, кроме того, мне пришло несколько отчетов о том, что после использования NewSID некоторые компоненты Windows завершали работу с ошибкой. Когда я принялся за изучение этих отчетов, я решил начать с попытки понять, как дублированные идентификаторы SID могут стать причиной появления проблемы, так как я не мог принять возможность этого на веру, как все остальные. Чем больше я думал об этом, тем больше убеждался в том, что дублирование SID компьютера (т.е. наличие нескольких компьютеров с одинаковыми идентификаторами SID) не влечет за собой каких-либо проблем, связанных с безопасностью или чем-либо еще. Я обсудил свое заключение с командами разработчиков Windows, занимающихся вопросами безопасности и развертывания систем, и никто не смог придумать сценарий, при котором две системы с одинаковыми SID, работающие в пределах рабочей группы или же домена, могли бы стать причиной ошибки. В связи с этим решение о закрытии проекта NewSID стало очевидным.

Я понимаю, что новость о том, что в дублировании SID компьютеров не ничего плохо, станет для многих неожиданностью, особенно в связи с тем, что практика с изменением SID является фундаментальным принципом в развертывании систем из образов, начиная с первых версий Windows NT. Эта статья призвана разоблачить данный миф, для чего, во-первых, приводится объяснение понятия "SID компьютера", описывается то, как Windows использует SID, после чего наглядно показывается, что Windows (за одним исключением) никогда не предоставляет SID машины за пределами данного компьютера, что доказывает возможность существования нескольких систем с одинаковыми SID компьютера.

Идентификаторы защиты (абб. от security identifier, SID) Windows использует идентификаторы SID для представления не только машин, но и всех остальных объектов системы безопасности. Эти объекты включают в себя машины, учетные записи домена, пользователей и групп безопасности. Имена таких объектов представляют собой лишь более понятные для пользователей формы представления SID, позволяющие вам, например, переименовать вашу учетную запись без необходимости обновлять списки управления доступом (ACL), которые ссылаются на данную учетную запись, чтобы отобразить внесенные изменения. Идентификатор SID представляет собой числовое значение переменной длины, формируемое из номера версии структуры SID, 48-битного кода агента идентификатора и переменного количества 32-битных кодов субагентов и/или относительных идентификаторов (абб. от relative identifiers, RID). Код агента идентификатора определяет агент, выдавший SID, и обычно таких агентом является локальная операционная система или домен под управлением Windows. Коды субагентов идентифицируют попечителей, уполномоченных агентом, который выдал SID, а RID — не более, чем средство создания уникальных SID на основе общего базового SID (от англ. common based SID). Чтобы увидеть, что собой представляет SID машины, вы можете воспользоваться инструментом Sysinternals PsGetSid, запустив его через командную строку без параметров:

Здесь номер версии равен 1, код агента идентификатора - 5, а далее следуют коды четырех субагентов. В Windows NT SID использовался для идентификации компьютера в сети, вследствие чего для обеспечения уникальности идентификатор SID, генерируемый программой установки Windows Setup, содержит один фиксированный (21) и три генерируемых случайным образом (числа после "S-1-5-21") кода субагентов.

Еще до того, как вы создадите первую учетную запись, Windows определяет несколько встроенных пользователей и групп, включая учетные записи Администратор и Гость. Вместо того, чтобы генерировать новые случайные идентификаторы SID для этих учетных записей, Windows гарантирует их уникальность, добавляя к SID компьютера уникальные для каждой учетной записи числа, называемые относительными идентификаторами (Relative Identifier, RID). Для упомянутых выше встроенных учетных записей RID предопределены, так что, например, у пользователя Администратор RID всегда равен 500:

После установки системы Windows назначает новым локальным учетным записям пользователей и групп RID, начиная со значения 1000. Вы можете воспользоваться PsGetSid для того, чтобы увидеть имя учетной записи, которой принадлежит указанный SID; на скриншоте внизу вы можете видеть, что локальный SID с RID равным 1000 принадлежит учетной записи Abby - учетной записи администратора, имя которой Windows попросила меня ввести во время установки:

Помимо этих динамически создаваемых SID, Windows определяет несколько учетных записей, которые также имеют предопределенные SID. Примером может служить группа Everyone, которая в любой системе Windows имеет SID S-1-1-0:

Другой пример - учетная запись Local System, под которой выполняются некоторые системные процессы, такие как Session Manager (Smss.exe), Service Control Manager (Services.exe) и Winlogon (Winlogon.exe):

Компьютеры, объединенные в домен, также имеют доменный SID компьютера, основанный на SID домена. Вот скриншот PsGetSid, отображающей SID для домена NTDEV:

Вы можете просмотреть SID домена для учетной записи компьютера, указав имя компьютера вместе с символом "$":

Доменный идентификатор SID для моего компьютера представляет собой SID домена плюс RID 3858199. Довольно проблематично назначить двум компьютерам одинаковые доменные SID, тогда как смена только имени компьютера не окажет никакого эффекта ни на доменный, ни на обычный (локальный) SID компьютера. Если вы клонируете компьютер, подключенный к домену, то единственный способ получения уникальной доменной учетной записи - это исключение компьютера из состава домена, изменение его имени и обратное включение его в домен.

Идентификаторы SID и списки управления доступом (от англ. Access Control Lists, ACL) После того, как пользователь вошел в систему Windows под своей учетной записью, подсистема локальной авторизации (Local Security Authority Subsystem, LSASS) создает входную сессию и маркер для нее. Маркер - это структура данных, определяемая ядром Windows для представления в системе учетной записи, содержащая в себе SID учетной записи, SID групп, к которым принадлежит данная учетная запись на момент входа в систему, а также привилегии безопасности, назначенные данной учетной записи и группам. Когда последний маркер, ссылающийся на входную сессию, удален, LSASS удаляет эту входную сессию, что означает, что пользователь вышел из системы. Ниже вы можете увидеть информацию о моей интерактивной входной сессии, отображаемой с помощью утилиты Sysinternals LogonSessions:

А на этот скриншоте вы можете видеть информацию о маркере, созданном Lsass для данной сессии, в окне Handle Process Explorer. Заметьте, что число после имени учетной записи - 7fdee - соответствует идентификатору входной сессии из LogonSessions:

 

По умолчанию процессы наследуют копию маркера их родительского процесса. Например, каждый процесс, запущенный в моей интерактивной сессии, имеет копию маркера, изначально унаследованного им от процесса Userinit.exe, который первым создается Winlogon при каждом интерактивном входе в систему. Вы можете посмотреть содержимое маркера процесса, сделав двойной щелчок на строке процесса в Process Explorer и переключившись на вкладку Security диалогового окна свойств процесса:

Когда один из моих процессов открывает объект операционной системы, например, файл или ключ системного реестра, подсистема защиты выполняет проверку прав доступа, которая просматривает записи списка управления доступом (ACL) объекта, ссылающиеся на SID, находящийся в маркере процесса.

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

Дублирование SID Поддерживаемый Microsoft способ создания установки Windows, пригодный для развертывания системы для группы компьютеров, состоит в установке Windows на базовый компьютер и подготовке системы к клонированию с помощью утилиты Sysprep. Этот метод называется "обобщением образа", поскольку когда вы загружаете образ, созданный описанным способом, Sysprep запускает установку, генерируя новый SID компьютера, запуская определение установленных аппаратных средств, сбрасывая счетчик времени до активации продукта и устанавливая другие настройки системы, такие как имя компьютера.

Однако, некоторые IT-администраторы сначала устанавливают Windows на одну из своих систем, устанавливают и настраивают приложения, после чего используют инструменты развертывания, которые не сбрасывают SID на копиях установок Windows. До сих пор лучшим средством в таких случаях было использование утилит для смены SID, таких как NewSID. Эти утилиты генерируют новый SID компьютера, пытаются найти все возможные места в системе, где упоминается SID компьютера, включая всю файловую систему и ACL системного реестра, и обновляют его на новый SID. Причиной, по которой Microsoft не поддерживает подобный способ модифицирования системы, является то, что в отличие от Sysprep подобные утилиты необязательно должны знать обо всех местах, где Windows упоминает SID компьютера. Надежность и безопасность системы, использующей одновременно старый и новый SID компьютера, не могут быть гарантированы.

Так является ли проблемой наличие нескольких компьютеров с одинаковыми SID? Это возможно только в том случае, если Windows когда-либо ссылается на SID других компьютеров. Например, если во время подключения к удаленной системе SID локального компьютера был передан на одну из удаленных систем и использовался для проверки прав доступа, дублированный идентификатор SID стал бы причиной проблемы безопасности, поскольку удаленная система не смогла бы отличить SID удаленной учетной записи от такого же SID локальной учетной записи (в этом случае SID обеих учетных записей имеют одинаковые SID компьютера, являющиеся их основой, и одинаковые RID). Однако, Windows не позволяет вам проходить аутентификацию на другом компьютере, используя учетную запись, известную только локальному компьютеру. Вместо этого, вы должны использовать входные параметры или для учетной записи, локальной для удаленной системы, или для учетной записи доверенного для удаленного компьютера домена. Удаленный компьютер находит SID для локальной учетной записи в его собственной базе данных учетных записей (от англ. Security Accounts Database, SAM) и для учетной записи домена - в базе данных Active Directory на контроллере домена. Удаленный компьютер никогда не предоставляет SID компьютера подключенному компьютеру.

Некоторые статьи про дублирование SID, включая эту, предупреждают о том, что наличие у нескольких компьютеров одинаковых SID приводит к тому, что ресурсы на сменных носителях, таких как, например, отформатированный под систему NTFS внешний жесткий диск, не могут быть защищены средствами локальной учетной записи. Авторы таких статей не учитывают тот факт, что права доступа к ресурсам на таких сменных носителях в любом случае не могут быть защищены, поскольку пользователь может подключить их к компьютерам, работающим под операционной системой, не соблюдающей правил доступа файловой системы NTFS. Кроме того, зачастую сменные носители используют заданные по умолчанию права доступа, гарантирующие доступ известным идентификаторам SID, например, SID группы Администраторов, которые одинаковы на всех системах. Это фундаментальное правило физической защиты, и именно поэтому Windows 7 включает в себя функцию Bitlocker-to-Go, позволяющую вам зашифровывать данные на сменных носителях.

Последним возможным вариантом, когда дублирование SID может послужить причиной проблемы - это ситуация, когда распределенное приложение использовало бы SID компьютеров для однозначной идентификации компьютеров. Ни одно программное обеспечение Microsoft не работает таким образом, тем более что использование SID компьютера для данной цели не будет работать, поскольку все контроллеры домена имеют одинаковые SID. Программное обеспечение, которое полагается на уникальную идентификацию компьютеров, использует либо имена компьютеров, либо доменные идентификаторы SID компьютера (SID учетных записей компьютера в домене).

Наиболее подходящий вариант Немного удивительно то, что проблема дублирования SID так долго не подвергалась сомнению, каждый предполагал, что кто-то другой точно знает, почему это является проблемой. К моему огорчению, на самом деле NewSID никогда не выполнял какой-либо полезной функции, так что теперь, когда поддержка этой утилиты закрыта, нет никаких причин тосковать по ней. "Обратитевнимание, что Sysprep сбрасывает и другие идентификаторы (настройки) компьютера,котрые в случае их дублирования могут привести к проблемам в работенекоторых приложений, среди которых Windows Server Update Services (WSUS).Поэтому официальная политика Microsoft все еще требует, чтобы клонированныесистемы были сделаны уникальными с помощью Sysprep."

blogs.technet.microsoft.com

Миф о дублировании SID компьютера

Содержание статьи

Третьего ноября этого года в Sysinternals был закрыт проект по развитиюNewSID – утилиты, позволяющей менять идентификатор защиты компьютера(machine SID). Я написал NewSID (тогда она называлась NTSID) в 1997 году,поскольку на тот момент единственной программой, позволявшей менять SID, былаутилита от Microsoft под названиемSysprep, которая не поддерживала смену идентификаторов защиты на техмашинах, на которых уже были установлены приложения.

Идентификатор защиты компьютера – это уникальный идентификатор, генерируемыйпрограммой установки Windows Setup, который Windows использует как основнойидентификатор безопасности для определяемых администратором локальных аккаунтови групп. После того, как пользователь авторизуется в системе, он представляетсяей своими идентификаторами SID пользователя и группы в соответствии савторизацией объекта (проверками прав доступа). И если две машины могут иметьодинаковый идентификатор защиты, то и аккаунты с группами на них могут такжеиметь одинаковые идентификаторы. Кажется очевидным, что наличие несколькихкомпьютеров с одинаковыми SID в пределах одной сети небезопасно, не правда ли?По крайней мере, так принято было думать.

Причиной, по которой я начал рассматривать возможность отправки NewSID напокой, были отзывы пользователей. Хотя в целом применение утилиты на WindowsVista было успешным, некоторые пользователи сообщали об ошибках в работекомпонентов системы после использования NewSID. К тому же, сам я не проводил ееполного тестирования. Когда я принялся за изучение отзывов, я сделал шаг назад,чтобы понять, как дублированные SID могут становиться причинами проблем,поскольку раньше я принимал возможность этого на веру, как и все остальные. Ичем больше я об этом думал, тем крепче была моя убежденность, что дублированиесертификатов безопасности, то есть наличие множества компьютеров с одинаковымиSID, само по себе не может быть причиной для возникновения проблем сбезопасностью или чем-нибудь еще. Я поделился своими мыслями с командамиразработчиков Windows, занимающимися безопасностью и развертыванием систем, итам никто не смог придумать такую последовательность действий, при которой двесистемы с одинаковыми SID, работающие в пределах рабочей группы или домена,могли бы стать причиной ошибки. С этого момента решение закрыть NewSID сталоочевидным.

Я понимаю, что новость о том, что в наличии дублированных SID нет ничегострашного, станет для многих неожиданностью, особенно если учесть, что практикасмены идентификаторов безопасности при развертывании систем из образовприменяется еще со времен Windows NT. Эта статья разоблачает миф об опасностидублирования SID, и чтобы его развеять, я сначала объясню, что же такоеидентификаторы безопасности компьютера и как они используются Windows, послечего продемонстрирую, что за одним исключением, Windows никогда не показываетидентификаторы безопасности вне компьютера, а потому иметь машины с одинаковымиSID абсолютно нормально.

 

Идентификаторы безопасности (SID)

Windows использует идентификаторы SID для представления не только машин, авообще всего пространства имен System Security Principal, частью которогоявляются машины, учетные записи домена, пользователей и групп безопасности. Ихимена — лишь более понятные для пользователей формы представления SID,позволяющие например переименовать учетную запись без необходимости обновлятьдля отображения внесенных изменений ссылающиеся на эту учетную запись спискиуправления доступом (ACL). Идентификатор SID — это числовое значениепеременной длины, формируемое из номера версии структуры SID, 48-битного кодаагента идентификатора и переменного количества 32-битных кодов субагентов и/илиотносительных идентификаторов (RID). Код агента идентификатора (identifierauthority value) определяет агент, выдавший SID. Таким агентом обычно являетсялокальная система или домен под управлением Windows. Коды субагентовидентифицируют попечителей, уполномоченных агентом, который выдал SID, a RID —не более чем средство создания уникальных SID на основе общего базового SID.

Увидеть, что собой представляет SID машины можно, если воспользоватьсяутилитойPsGetSid, запущенной через командную строку без параметров:

В этом SID номер версии равен 1, код агента идентификатора — 5, а далее идуткоды четырех субагентов. Одно время в Windows NT идентификатор SID могиспользоваться для идентификации компьютера в сети, поэтому для обеспеченияуникальности при генерировании SID в Windows Setup он содержит одинфиксированный (21) и три генерируемых случайным образом (числа после "S-1-5-21")кода субагентов.

Еще перед тем, как вы создадите первую учетную запись в системе, Windowsопределяет несколько встроенных пользователей и групп, включая учетные записи"Администратор" и "Гость". Вместо того, чтобы генерировать новые случайныеидентификаторы SID для этих учетных записей, Windows обеспечивает ихнепохожесть, просто добавляя в SID уникальные для каждой учетной записи числа,называемые относительными идентификаторами (Relative Identifier, RID). Дляупомянутых выше встроенных учетных записей RID определены заранее, поэтому упользователя "Администратор" RID всегда равен 500:

После установки системы Windows назначает новым локальным учетным записямпользователей и групп номера RID, начинающиеся со значения 1000. Чтобы увидетьимя учетной записи, которой принадлежит указанный SID, можно воспользоватьсяPsGetSid. Пример внизу демонстрирует, что локальный SID с параметром RID, равным1000, принадлежит учетной записи Abby — аккаунту администратора, имя которогосистема обязала меня ввести во время установки:

Плюс к этим динамически создаваемым SID, система определяет несколькоаккаунтов, которые также всегда имеют предопределенные значения SID. Один изпримеров – группа Everyone, SID которой в каждой системе Windows имеет значениеS-1-1-0:

Другой пример — учетная запись Local System, под которой выполняютсянекоторые системные процессы, такие как Session Manager (Smss.exe), ServiceControl Manager (Services.exe) и Winlogon (Winlogon.exe):

 

Идентификаторы безопасности и списки управления доступом (ACL)

После того, как пользователь вошел в систему Windows под своей учетнойзаписью, подсистема локальной авторизации (Local Security Authority Subsystem,Lsass.exe) создает сессию входа и маркер для нее. Маркер — это структура данных,которую ядро Windows определяет для представления учетной записи и котораясодержит в себе SID этой учетной записи, а также SID групп, к которымпринадлежит данная учетная запись на момент входа в систему и назначенные дляэтой учетной записи и групп привилегии безопасности. Когда последний маркер,ссылающийся на сессию входа, удаляется, LSASS удаляет и сессию входа, после чегопользователь считается вышедшим из системы. Ниже можно увидеть информацию о моейинтерактивной сессии входа, отображенную с помощью утилиты SysinternalsLogonSessions:

А здесь (в окне Handle Process Explorer) можно увидеть информацию о маркере,который Lsass создал для этой сессии. Обратите внимание, что число, следующее заименем учетной записи (7fdee), соответствует идентификатору входной сессии изLogonSessions:

По умолчанию процессы наследуют копию маркера своего родительского процесса.

Так, каждый процесс, запущенный в моей интерактивной сессии, имеет копиюмаркера, изначально унаследованного им от процесса Userinit.exe, который первымсоздается Winlogon при каждом интерактивном входе в систему. Вы можетепосмотреть содержимое маркера процесса, сделав двойной щелчок на строке процессавProcess Explorer и переключившись на вкладку Security в диалоговом окнесвойств процесса:

Когда один из моих процессов открывает объект операционной системы, например,файл или ключ системного реестра, подсистема безопасности осуществляет проверкуправ доступа, в ходе которой сверяются те записи в списке управления доступом(ACL) объекта, которые ссылаются на SID, находящийся в маркере процесса.

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

 

Дублирование SID

Пропагандируемый Microsoft способ создания установки Windows, пригодный дляразвертывания системы на группы компьютеров, заключается в установке Windows наэталонный компьютер и подготовке системы к клонированию с помощью утилитыSysprep. Этот метод называется "обобщением образа", поскольку при его загрузкеSysprep персонализирует установку, генерируя новый SID компьютера, определяяимеющиеся аппаратные средства, сбрасывая счетчик активации и устанавливая прочиенастройки, в том числе – имя компьютера.

Однако, некоторые IT-администраторы сначала ставят Windows на одну из своихсистем, устанавливают и настраивают приложения, а затем используют такиесредства развертывания, которые не сбрасывают SID на установочных образахWindows. До сих пор наилучшим средством в таких ситуациях было использованиеутилит для смены SID, таких как NewSID. Эти утилиты генерируют новыйидентификатор безопасности машины, а затем пытаются обновить его во всехмыслимых местах, включая файловую систему и списки управления доступом вреестре. Причина, по которой Microsoft не поддерживает подобный способ изменениясистемы, довольно проста – в отличие от Sysprep, сторонние утилиты могут и незнать обо всех тех местах, где Windows хранит идентификатор безопасностикомпьютера. А раз так, то и надежность компьютера, на котором имеется и старый иновый SID, не может быть гарантирована.

Так что же, можно считать

xakep.ru