Записи с темой: security (список заголовков)
16:23 

File System Audit

Stance Dance

Наверняка каждый системный администратор сталкивался с задачей - вынуть да положить руководству на стол информацию о том, кто стер какой-либо очень нужный файл с сетевого хранилища. Почти все знают, как включить аудит событий файловой системы. Если кто-то не знает, очень рекомендую ознакомиться вот с этой статьей: How do I enable auditing on certain files/directories? - это очень просто и быстро.
После включения аудита в логе безопасности файлового сервера станут появляться события о работе с файловой системой. Вот как, например, выглядит запись о запросе на удаление какого-либо файла:


В этом сообщении видно все, что нам нужно для отчета. Единственная проблема заключается в том, что в логе безопасности сообщений будет огромное количество. И среди всего этого вороха данных нам нужно будет как-то отыскать нужную информацию. Известно, что все логи сервера - это файлы, значит, нужно каким-то образом в автоматическом режиме прочитать файл лога, вытащить оттуда записи согласно определенным критериям, и этот комплект записей выложить на стол руководству. Осталось лишь найти инструмент, которым можно этого добиться. Он есть, называется LogParser, взять можно вот здесь: LogParser @ Microsoft.com.
Инструмент этот относится к разряду CLI-утилит - вся работа осуществляется при помощи командной строки. В разборе того, что и куда вводить, чтобы прочитать нужные данные, мне очень сильно помогла вот эта страница: Log Parser - The "Swiss Army Knife" for Intrusion Investigators and Computer Forensics Examiners. По прочтению и пониманию материала был сформирован следующий ярлык вызова утилиты:


А в качестве содержимого файла запроса DeleteEvents.sql используется следующее:

Да, это самый обычный SQL запрос. Допустим, меня очень сильно интересовало, какой нехороший человек стер мой любимый файлик, называвшийся "тест.txt". Вводим запрос, нажимаем Enter, и в ответ получаем красивую табличку вот такого вида:

Откуда видим, что нахала, стершего файл, зовут user01, принадлежит он к домену TEST. И файл был стерт сегодня. Что ж, задача выполнена, мерзавец найден. Дальше уже пусть руководство разбирается, что с user01 делать и какие санкции к нему применять.

P.S. Все вышеописанное справедливо для Windows 2008 Server. В версии 2003 формат записей в логе безопасности был иным, поэтому файл sql запроса скорее всего нужно будет серьезно менять.
P.P.S. Небольшая хохма на десерт. Существуют платные решения из сферы аудита, одно из таких я сегодня захотел попробовать: sсript Logic File System Audit. Как всегда при запросе пробной версии нужно заполнить простыню. Ок, давайте, посмотрим, что и куда писать надо. Вот кусок этой простыни:

Ничего более подходящего, чем Вооруженные силы Европы я там не нашел. А что, хорошая страна ведь ;)

P.P.P.S. Окинул запись взглядом анонимного пользователя - ГРАФИЧЕСКИЕ СМАЙЛЫ! УБЕЙТЕ СЕБЯ О СТЕНУ В КРОВАВЫЕ ОШМЕТКИ!!!

@музыка: KOTO - Die Klapperschlange

@темы: Security

22:09 

PCI DSS

Stance Dance

Original @ ServerFault.com.
Перевод истории на Хабрахабре.
Читать всем, даже если вы не имеете никакого отношения к аудиту платежных систем и процессинговых центров. Это феерия.

@темы: Security, Этот безумный мир

19:25 

GFI EndPoint Security 4.3 Transition

Stance Dance

Решил посмотреть, как будет себя вести при обновлении программный комплекс GFI EndPoint Security. Вполне возможно, что придется это сделать, обновившись с 3-й на четвертую версию. В принципе, все достаточно гладко, за исключением пары-тройки моментов:
1. При обновлении 4-я версия не терпит присутствия на сервере своей старшей сестры, требует ее снести. Следовательно, бекап конфигурации должен быть. На всякий случай (впрочем, он должен быть в любом случае).
2. Для установки обязательно наличие .NET Framework версии 2.
3. Самое занятное: после установки основная служба отказалась стартовать. В окне установщика висит сообщение о том, что установщик эту службу пытается запустить, в оснастке служб она значится, как неработающая. Пробуем "помочь" установщику, запустив службу руками. Минута ожидания, и ОС выводит свое стандартное сообщение о том, что служба стартовала, но затем благополучно завершила работу, так как "ей нечего делать". Помнится, когда я с таким сообщением впервые столкнулся, оно меня очень сильно позабавило, вот тут ее пример описан: www.gotdotnet.ru/blogs/GRP/2838/
Ладно, веселье весельем, а запустить ее нужно. Лезем в базу знаний компании GFI и находим там следующее:
GFI EventsManager service does not start - Клац!
The GFI EventsManager executables are digitally signed by default. When trying to start the service, the application must download the Certificate Revocation List to authenticate. If the download fails due to network connectivity or security reasons the service will fail to start by timing out.

Это уже интереснее. Выходит, что для старта службы программы EventsManager необходим доступ в Сеть. Да, на моем сервере доступа не было (ибо зачем?). И хоть EventsManager - это не EndPoint Security, решил проверить, сработает ли рекомендация для моего случая. После обеспечения доступа во всемирную паутину и повторного запуска установки EndPoint Security служба успешно стартовала, и GFI EndPoint Security 4.3 благополучно завершил установку.
Апгрейд клиентов же просто тривиален.

@музыка: Ryan Farish - Opus (2011)

@темы: Security

23:16 

Exchange 2003 OWA и кириллические учетные данные.

Stance Dance

Весьма любопытный случай.
Один из сотрудников жалуется на то, что из дома не может попасть на свой почтовый ящик - система просто не принимает его учетные данные. Провожу тест у себя, сбрасывая пароль на стандартный для таких случаев - все отлично срабатывает. Ну не иначе где-то ошибся человек.
Раз, второй, третий... Умом понимаю, что что-то не так. Ну не может человек настолько упорно набирать пароль неправильно. Тем не менее, проблема заглохла, больше звонков длительное время не поступало.
Недавно эта неприятность снова голову подняла, но уже с другим сотрудником. Этот поступил умнее, пришел в отдел лично. Лично набрал свой пароль на консоли администратора - не пускает. Прямо тут же меняем ему пароль на стандартный - все проходит на ура. Сотрудник меняет пароль на свой собственный - и тут же получает отлуп. Как так?! Посмеялись, потом начали размышлять, что и к чему. В глаза бросился тот факт, что тестовый пароль на английском языке, а сотрудник свой набирал на русском. И задавал его на русском. То есть мы пришли к тому, что OWA по какой-то ей ведомой причине не принимает национальные символы в пароле. Ладно, рекомендовали сотруднику использовать англоязычный пароль, а для себя пометили задачку в выполнению, но не как горящую.
Сегодня все же дошли руки до поднятия ручного Exchange 2003 SP2. Настраиваю OWA, меняю у тестового пользователя пароль на кириллический, жму Enter - и я в ящике этого пользователя. Все чудесатее и чудесатее (с).
Форумы молчат. Есть упоминания о том, что имеется проблема в случае кириллических логинов, но здесь другой случай. На яндекс в подобных вопросах уже давно не надеемся, гугл разводит руками. Полчаса вдумчивого сравнения конфигурации... Затем мысль - а что у нас с настройками регионов и кодовых таблиц. На самом деле региональные настройки не так важны, нам деньги не мерять. А вот кодовые таблицы - это уже любопытно. Оказалось, что на боевом сервере в настройках кодировок для non-Unicode приложений стоит английский язык, на тестовом же сервере - русский. Ну что же - смена на русский на боевом, перезагрузка... Долгие 3 минуты ожидания, смена пароля тестового доменного пользователя, заход на OWA... Success!!!
Exchange 2003 SP2 и настройки не-Юникод приложений - такого я представить себе не мог. Теперь представляю.
Еще одна поставленная галочка, еще один случай в копилку. Надеюсь, кому-то эта запись сэкономит немало времени в подобной ситуации.

UPD. Если конфигурация Exchange 2003 включает в себя два сервера, front-end и back-end, менять кодовую таблицу нужно на front-end-сервере.

@музыка: Rise Against - Help Is On The Way Shift 2 Remix

@настроение: Shocked

@темы: Security, MS Exchange

22:14 

Android.

Stance Dance

Да, я решил "узнать своего врага в лицо". Купил себе на пробу LG-P500, он же Optimus One.
Прошло уже больше года с того памятного мне дня, как я впервые столкнулся с этой платформой. Если уложиться в несколько слов - она обрела человеческое лицо. Как ни странно, теперь работать с телефонами на базе этой системы стало действительно удобно. Быстрые, функциональные, батарею сильно не кушающие...
Но не все так гладко, как может показаться на первый взгляд. И вот почему:
SMS are intermittently sent to wrong and seemingly random contact.
По ссылке очень много иноязычного текста, рекомендуется к ознакомлению всем обладателям андроидовых телефонов.

Сухая выжимка:
Рано или поздно любой андроидовый телефон может отослать сообщение не тому человеку. Вместо нужного адресата он подставит контакт из вашего списка, и сообщение уйдет именно ему. Что за этим может последовать - просто включите вашу фантазию.
Дата первого сообщения в этом баг-трекере - 28 июля 2010 года. Честно говоря, даже Microsoft покуривает в стороне от такой скорости реакции на события такой степени важности.

Я с этим столкнулся лично. Перерыв кучу материала и проведя несколько тестов пришел к следующему выводу - не отвечать на сообщения, используя область уведомлений. Схема работы этого бага следующая. Вы принимаете сообщение от человека А, читаете его, отвечаете или нет - неважно. Затем вы получаете сообщение от человека Б, при помощи области уведомлений отвечаете на него. Дальше вариантов два: либо сообщение уйдет человеку Б, и все довольны; либо аппарат подставит в качестве адресата того самого бедолагу А, от которого вы получили сообщение ранее, и оба участника получают конфуз.
Баг непостоянен, может проявиться, может нет, но во всех случаях подставлялся именно предыдущий абонент, приславший сообщение, не случайный.

На всякий случай, информация о телефоне:
LG-P500
ver. 2.2
Kernel 2.6.32.9
Build FRF91

На сегодняшний день все, что мы имеем по этому инциденту, это признание компанией Google проблемы и обещание выпуска заплатки в ближайшее время:
www.bbc.co.uk/russian/science/2011/01/110107_go...
Смотрим на дату новости - 8 января.

@темы: Этот безумный мир, Security, Android

23:16 

NLA - Network Layer Authentication

Stance Dance

Признаться, когда только вышел SP3 для Windows XP, я не до конца понимал, что же это за опция такая. Полностью ее прелесть осознал только теперь, когда появилась возможность в спокойной обстановке поковырять веб-доступ до опубликованных на сервере терминалов приложений. Суть в следующем. При попытке запустить любое из приложений TS Web App, пользователь вынужден ввести свой логин и пароль, даже несмотря на то, что в системе он авторизова. А как мы помним, Active Directory на том и стоит, что пользователь, прошедший авторизацию уже должен иметь доступ ко всем ресурсам, на которые у него есть права. SSO - Single Sign-On - так зовется этот замечательный механизм. Повторный ввод пароля же обусловлен тем, что RDP клиент, который и используется при работе с TS Web App, SSO в Windows XP не поддерживает.
SP3 поменял расстановку сил, но даже установив этот пакет обновлений, просто так SSO не получить. Для этого нужно как раз включить ту самую опцию - NLA. Именно на сетевом уровне аутентификации Windows и будет передавать учетные данные.
Сам по себе процесс включения NLA довольно прост, нужно лишь изменить два параметра в реестре каждой системы, на которой будет использоваться веб-доступ к терминальным приложениям (а в идеале - для всех рабочих станций с Windows XP SP3). Очень подробно все это описано вот тут: MS Knowledge Base. При помощи групповых политик результат достигается очень быстро и просто.
Однако, не было бы этой записи, будь все так гладко. Убеждаюсь, что рабочие станции удовлетворяют требованиям для включения NLA - сделано (долго ли проверить две тестовые виртуальные машины). Требования там, кстати, следующие:
- наличие RDP-клиента версии 6 и выше (выполняется автоматически при установке SP3)
- наличие клиентских расширений групповых политик (без этого система не получит сведения о модификации реестра). Взять эти расширения можно здесь: MS Download Center.
Пробую запустить любое приложение. И получаю вот такое:

an authenication error has occured code 0x507

В то же время тестовая Windows 7 спокойно заходит на терминал, спокойно может запустить любое из опубликованных приложений. Значит, что-то не так с включением NLA. Пробегаюсь по политике и настройкам терминального сервера. В настройках сервера было указано следующее: Allow connections from computers running any version of Remote Desktop. Рассудив, что в тестовом домене все компьютеры теперь поддерживают NLA, устанавливаю следующее: Allow connections from computers running verision of Remote Desktop with NLA. Подтверждаем изменения.
В политике же ревизия показала следующее - по идее, в параметры Security Packages и SecurityProviders нужно дописать названия соответствующего пакета и библиотеки. Однако, политика старалась дописать в значение еще и то, что там было раньше. Неверно, так как может привести к дублированию информации. Устанавливаю действие "Заменить", а в значения прописываю все то, что там должно быть. Сохраняю изменения, даю команду двум машинкам с XP SP3 на обновление политик, после чего перезагружаю их.
После всех этих операций искомый результат был получен - пользователи компьютеров под управлением Windows XP SP3 получили возможность запускать терминальные приложения в режиме прозрачной аутентификации (привет клиентам Citrix и режиму pass-through ;) ).
Ради интереса снова переключил терминальный сервер в режим разрешения подключений от любых клиентов Remote Desktop - все прекрасно работает.

@музыка: Ryan Farish - Shine

@темы: Security

22:48 

Software Restriction Policy

Stance Dance

Три слова, которые могут очень многое. А впридачу к ним - очень познавательная статья об этой самой политике:
The Six Dumbest Ideas in Computer Security
Настоятельно рекомендую к прочтению и осмыслению всем тем, кому по должности приходится следить за порядком в корпоративных компьютерных сетях.

@музыка: Peter Sterling - Forever and a Day

@темы: Security

18:44 

Hardware...

Stance Dance

Прошедший понедельник стоил мне пары седых волос, не иначе.
Если пытаться обрисовать ситуацию двумя словами - хрень нереальная, других определений не находится, потому что такого на моей памяти не случалось никогда.
Вполне невинная процедура - вывод из домена сервера, предназначенного к полной переустановке операционной системы (плановый апгрейд до windows 2008), операция, проведенная за всю жизнь уже очень большое количество раз, ошибиться в которой можно только в одном случае - выведя из домена не тот сервер.
Выглядело все это следующим образом. Спуститься в серверную, на KVM переключиться на нужный сервер, отдать все необходимые команды для вывода из домена, перезагрузить его. А пока перезагружается, подключить почему-то неиспользуемый порт iLO (какая расточительность, однако).
Где-то в середине процесса в серверную поступает звонок из админской и вопрос - "что у нас за апокалипсис?".
В самой серверной все неизменно, только теперь уже бывший контроллер домена пущен в рестарт после вывода из домена. После этого сообщают, что по сети недоступны первый DC, почтовый сервер, шлюз. Смотрю на передние панели указанных хостов и понимаю, что двое из них - контроллер и шлюз, уже спят. Переключаюсь на почтовик, и вижу, что он в состоянии выключения операционной системы. Что за ересь?! В довершение всего этого дела намертво повисает KVM, лишая нас консольного доступа к серверам.
Ладно. DC у нас в домене не один и не два. Проживем. Шлюз - уже критичнее, почта - совсем критично. Запускаю шлюз, запускаю почтовик, запускаю DC. Первый и третий поднимаются довольно быстро. Почтовик же задумался. Дожидаюсь вывода на экран стандартного приглашения на ввод логина и пароля, и в трубку: "Проверяй, почтовик поднялся". Ответ убил - коннекта от Outlook до Exchange не наблюдается, но пинги есть. Плохи дела. Ctrl+Alt+Delete, и у меня волосы встают дыбом - Exchange выпал из домена.
Что за этим может последовать, лучше и не думать. Провести ночь в серверной борясь с конфигами, со структурой в AD, не хотелось абсолютно. Абсолютно не понимая, почему такое могло произойти, захожу под локальным админом, лезу в логи. Параллельно открываю консоли контроллера и шлюза. Офигеваю от того, что шлюз тоже вне домена. А в логах видно, что и шлюз, и почтовик выпали из домена в результате штатной операции, выполненной... мной же! Я в ауте... В голове всплывает один из давным-давно прочитанных документов о повторном присоединении рабочей станции к домену под существующим именем. Вот и появилась возможность проверить эти сведения на практике, хотя я и предположить не мог, что проверять это все буду на Exchange, для которого членство в домене - это альфа и омега.
ADUC, Find Computer, Reset Account. После чего на почтовике выполняется штатная операция присоединения к домену и рестарт. Долгие пять минут ожидания, вопрос в трубку "ну как?" и ответ: "У Егорыча почта поднялась!".
Все выдохнули. С этого момента Outlook'и медленно, но верно начали находить сервер и штатно работать с почтой. По аналогичному сценарию добавляем в домен шлюз, после чего работа сервисов нормализуется. А у нас теперь великий геморрой - найти причину этого бардака.
Логи контроллера, логи почтовика, логи шлюза, гугл. И при помощи этого всего нашли причину. Ей оказалась та самая несчастная KVM, через которую я и выводил из домена нужный сервер. Эта, с позволения сказать, железка, в результате какого-то одной ей ведомого сбоя ретранслировала все, что я вводил с консоли на нужный сервер, еще на три порта. А потом вылетала напрочь. Судя по логам всех участвующих в представлении серверов, на все 4 машины в одно и то же время были посланы одни и те же команды, в одно и то же время. У меня все же не 4 пары рук и не 4 головы, чтобы подобное вытворить. Даже комментарий к операции перезагрузки был на всех 4 машинах одним и тем же - "12". Контроллеру домена повезло, его из домена так просто не вышибить, потому он просто перезагрузился и заработал в обычном режиме. А вот почта и шлюз оказались уязвимы.
Что ж, по крайней мере, теперь точно известно, что случайный вывод Exchange-сервера из домена (дико звучит, но все же) не является фатальным. Заодно стало понятно, почему при выводе рабочей станции из домена не удаляется ее учетная запись из базы данных, и как эту учетную запись можно использовать.
Но все же иногда эти знания даются слишком дорогой ценой...

@музыка: Stone Age - Sellet

@темы: Security, Этот безумный мир

17:29 

Windows System Logs

Stance Dance

Недавно мне уже доводилось писать о том, что пропуск лог-файлов при полном бекапе сервера под Windows 2003 Server имеет место быть. Сегодня дошли руки произвести эксперимент по полному резервированию и восстановлению уже Windows 2008 Server. Здесь все куда лучше - логи сохранились в бекапе и при восстановлении системы оказались на своем законном месте. Это радует.

@музыка: Ronald Jenkees - Guitar Sound

@темы: Security

23:50 

Chain of Earth -> Stone Shock.

Stance Dance

Да, да, именно шок.
Преамбула - поставлена задача: найти, кто сидел за конкретным компьютером в определенный промежуток при условии, что сотрудники могут пересаживаться. Казалось бы, что сложного, открываем журнал Security и смотрим логи. Проблема в том, что требуемый промежуток - это уже довольно дальнее прошлое, в текущих логах уже давным давно стертое. Ладно, есть бекапы. Открываем их, лезем в заветную папку %windir%\system32\config, ищем там secevents.evt... и понимаем, что в полном бекапе контроллера домена этого лога нет. Как нет и любого другого из системного журнала событий. Вдумчивое ковыряние гугла подтверждает мысль - ntbackup даже при полном резервном копировании не сохраняет логи. Это касается Windows 2003 Server, платформу 2008 на это еще не тестировали (есть повод создать новую виртуальную машину и поиздеваться над ней).
Что ж, задачу удалось решить, но несколько иным и довольно кривым методом, но осадок остался. Одновременно с этим встал вопрос - что делать с бекапом логов. В итоге был найден и доработан напильником вот такой скрипт:
Backup Security Events.vbs

Далее - Планировщик задач и задача по созданию резервной копии журнала на регулярной основе.

@музыка: Alice in Videoland - Ladykiller

@темы: Security, Scripting

15:34 

Ключи...

Stance Dance

... от квартиры, где деньги лежат.
Нет, на самом деле речь пойдет о ключах другого рода, лицензионных. Первое, что приходится учитывать компаниям, это ключи на ОС и офисный пакет, если используется MS Office. И может сложиться такая ситуация, когда нужно быстро собрать информацию о ключах на довольно большом количестве машин. Как это сделать?
На помощь может прийти утилита под названием Produkey. Свободно распространяемое мелкое приложение, которое позволяет узнать ключи Windows, MS Office и некоторых других пакетов. Сама эта утилита содержит в себе возможность сканирования удаленных машин с целью сбора информации о лизензиях. Но есть один момент - компьютер для этого должен быть включен. Другой же вариант решения проблемы - запустить Produkey в момент запуска компьютера. Это можно сделать сценарием запуска машины.
Групповые политики, Параметры компьютера, Сценарии запуска. Сюда нужно будет положить сценарий, шаблон которого представлен ниже: GetKeys.vbs

Что делает этот сценарий? При загрузке компьютера из папки \\NETWORK-SHARE\ вызывается программа produkey.exe с определенным набором параметров. Результатом ее выполнения будет созданный в корне диска С: файл с информацией об установленном на компьютере ПО (в той части, которую "распознает" produkey). Далее этот файл копируется в сетевую папку "\\REPORTS-FOLDER-SHARE\", после чего из корня диска С: файл будет удален. Таким образом в папке "\\REPORTS-FOLDER-SHARE\" создается набор файлов, каждый из которых соответствует одному компьютеру. Этот набор файлов уже можно анализировать в спокойной обстановке.
Отдельно об анализе этого набора файлов. Например, требуется узнать, что творится с ключами ОС (типичная в России ситуация для нового системного администратора на предприятии). Известно, что в отчетах produkey информация об ОС идет первой строкой. Значит, задача сводится к тому, чтобы пробежать по всему набору отчетов, вытащить из каждого отчета первую строку и внести ее в файл итоговой таблицы. Эту задачу можно легко решить при помощи Powershell, например:

$ReportPath = "\\REPORTS-FOLDER-SHARE\"
foreach ($name in ls $ReportPath) {get-content $ReportPath\$name -totalcount 1 | Out-file winkeys.txt -append}

Этот нехитрый сценарий пройдет по всем файлам в папке \\REPORTS-FOLDER-SHARE\, прочитает по одной строке из каждого файла в ней, после чего результат скинет в файл winkeys.txt, находящийся в домашней папке пользователя. Работать с единой таблицей же куда проще, чем с набором файлов.

@музыка: Stone Age - Maribrengall

@темы: Security, Scripting, PowerShell

14:29 

Windows 2008 Server RODC

Stance Dance

RODC - Контроллер домена в режиме "Только для чтения". Новый режим работы КД, появившийся в Windows 2008. Предназначен для установки в филиалы, где нет достаточного уровня безопасности хоста контроллера (читай, самого компьютера). Этот режим выгоден тем, что не хранит на себе пароли пользователей, за исключением специально выбранных - как правило, работников того самого филиала. Чем выгодно? В самом паскудном сценарии - краже хоста (и такое бывает), нужно будет сбросить пароли только тех учетных записей, пароли которых кэшированы на этом контроллере, а не всего домена. Удобно? Удобно.
Еще одно преимущество работы контроллера в таком режиме кроется в самом его названии - Только для чтения. Это значит, что никакие операции над структурой домена с этого контроллера невозможны, он способен только читать информацию, но не изменять ее. Случайное удаление каталогов, атрибутов в этом случае исключается. Опять же - удобно? Да.
Однако, как и довольно часто, при установке такого контроллера есть свои нюансы. Про режим работы леса в целом и отдельных его доменов я говорить не буду. Это расписано в документации по RODC достаточно подробно.
Первый и главный момент - в домене уже должен быть полный КД уровня Windows 2008 Server. Полный - это значит способный записывать информацию в Active Directory. RODC в процессе своей работы будет общаться именно с таким контроллером, на КД предыдущих версий он даже не посмотрит. Если устанавливается новый домен на базе Windows 2008 Server - это требование будет выполнено автоматически. В случае же перехода с КД Windows 2003 Server этот момент нужно учитывать.
Второй момент - перед установкой RODC ко всему лесу нужно применить команду adprep /rodcprep. Эта команда расширяет текущую структуру каталога, добавляя в нее элементы, обеспечивающие репликацию данных с обычного контроллера на RODC. Если этого не выполнить, в процессе установки будет выдана ошибка следующего содержания:
You will not be able to install a read-only DC in this domain because "adprep /rodcprep" was not yet run.

Информативность текста ошибки стопроцентная. Что делать - ясно без подсказок.
И вот тут-то кроется главный подводный камень, рассчитанный на тех, кто переходит с домена 2003 на домен 2008. Для того, чтобы установить RODC в смешанной среде (где есть и КД 2003, и КД 2008), просто выполнить adprep /rodcprep недостаточно. После ее выполнения вы будете снова натыкаться на приведенную ошибку. В документации по RODC описания подобной проблемы мне найти не удалось, решение откопалось на одном из блогов - Клац!
Интерес на этой странице представляет следующий комментарий:
Just adding a Windows Server 2008 DC to the domain doesn’t mean that you can install RODC in it too – actually you can and that’s when you will experience problems. You have to make sure that the Windows Server 2008 DC is configured (and is really functioning) as a GC and the PDC master role has been transferred to it.
Если это перевести на русский язык, то получаем следующее: простой установки КД 2008 в текущую среду недостаточно. Для получения возможности установки RODC в текущий домен на контроллер домена под управлением Windows 2008 Server нужно передать роль Глобального Каталога (GC) и роль эмулятора первичного контроллера домена (PDC Emulator). Только в этом случае установщик RODC опознает текущий домен, как удовлетворяющий всем требованиям, и согласится на установку RODC.
Как всегда - все дело в волшебных пузырьках одной волшебной галочке. Но нужно знать, где ее искать. Надеюсь, кому-то эта информация позволит сэкономить свое время на поиск решения проблемы.

@музыка: Sleepthief - World Gone Crazy

@темы: Security

23:19 

PsExec

Stance Dance

Программа PsExec является частью пакета PSTools, разработанного компанией SysInternals. Представляет собой утилитку, которая способна запускать произвольные процессы на удаленной системе, чем и полюбилась системным администраторам. Ее удобство может превзойти разве что ssh протокол. Но есть и несколько подводных камней, одним из которых является вот такая ошибка:

Error establishing communication with PsExec service on XXX:
All pipe instances are busy.


Меня эти слова преследовали полтора года. Самое удивительное, что утилита процесс на удаленной машине запускает, но результат выполнения получить не может. А чаще всего именно результат и важен. Ковыряние интернета и гугля выдало одну из возможных причин: блокирование данной программы антивирусными средствами. В целях проверки истинности предположения антивирус на целевом компьютере был снесен, после чего была выполнена чуть ли не классическая команда:
psexec \\xxxx ipconfig

Результатом стали все те же строки об ошибке. Что за дьявольщина? Затем вспомнилось, что многие антивирусы считают практически весь набор PsTools зараженным вирусом вида Remote Admin. Вирусов там нет, но сами программы как раз и являются средствами удаленного администрирования. Дальше взгляд упал на красную букву K в системном трее на исходном компьютере, после чего файл psexec.exe был внесен в список доверенных. Ошибка исчезла.

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

@музыка: Runestone - The Well of Secrets

@темы: Security

23:24 

Runas command + Internet Explorer 7

Stance Dance

IE 6 для администраторов был очень удобен. Тем, что если требуется запустить на клиентской машине несколько программ, от своей учетной записи, не нужно было использовать команду Runas для каждой программы. Достаточно было открыть административный сеанс IE, а в нем уже, набрав, например, С: переместиться к файловой системе компьютера. Типичное применение подобного трюка - установка новых шрифтов в систему, особенно если выгружать сеанс пользователя нельзя, а быстрое переключение выключено (доменная среда).
С приходом Internet Explorer 7 все идет к чертям. Нет, сам браузер по-прежнему можно запустить от административного логина, но возможность ходить по файлам в таком виде компания MS убрала. Зачем - неясно. Но ясен сам факт - дела обстоят не самым удобным для администратора образом.
Логично было бы поступить так: Пуск, Выполнить, и далее ввести команду:
runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe
Но не тут то было. Эта команда не возымеет эффекта.
Решением может стать запуск какой-либо сторонней файловой оболочки, например, того же Total Commander или Free Commander. И в большинстве случаев это даже удобнее. Но есть моменты, где и этот подход бессилен - например, все та же установка шрифтов, простого копирования в каталог %systemroot%\fonts там мало, при установке через проводник происходит еще и регистрация шрифтов в реестре, тот же Тотал на такое неспособен.
Что делать?
Пуск, Выполнить, taskmgr.exe. В появившемся окне Менеджера Задач нужно перейти на вкладку Процессы и завершить процесс explorer.exe, это потушит оболочку, но оставит в фоне все запущенные пользователем программы. Далее необходимо выбрать Файл, Новая задача. А уже там вводить знакомое до боли: runas /user:< MACHINE or DOMAIN NAME >\< USER NAME > explorer.exe. В этом случае открывшееся окно проводника будет в том самом elevated-режиме, то есть с правами того пользователя, от чьего имени было запущено. При этом у нас все так же будет открыто окно диспетчера задач. Его не выключаем. После того, как все административные действия будут выполнены, нажимаем Пуск, Выйти из системы. А после выхода в имеющемся диспетчере задач через меню Файл, Новая задача снова запускаем explorer.exe, но уже в обычном режиме. Все довольны. Пользователь не потерял свои данные и программы, администратор выполнил все необходимые действия с "минимальными потерями".

Еще один вариант решения проблемы кроется в особенности установки IE 7 или IE 8 (если последний был установлен сразу поверх шестой версии). Дело в том, что седьмой и восьмой "ослики" позволяют откатиться назад на шестую версию, и ради обеспечения этой возможности копируют IE 6 в папку %systemroot%\ien, где n - текущая версия IE. И именно оттуда можно достать старый добрый шестой браузер.

@темы: Security

22:07 

WebMarshal 6.x

Stance Dance

Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!

В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.

UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.

@темы: Security, Этот безумный мир

21:56 

Windows Update Services #4 (продолжение банкета)

Stance Dance

Итак, Client-side targetting. А если по-русски - клиент сам лезет в назначенную ему группу на сервере WSUS, а не администратор его туда определяет руками. Как этого добиться?
1. Создать все требуемые группы на WSUS. Сами они создаваться не будут.
2. При помощи групповых политик назначить компьютерам их группы.
3. Перевести сам WSUS в режим Client-side Targetting, задав еще пару параметров автоматического одобрения обновлений (немаловажный процесс, кстати).
Создание групп на WSUS - дело тривиальное, щелкай себе правой кнопкой в списке групп да имена новосозданным задавай. Переключение режима работы WSUS - не сложнее: Options - Computers - Use Group Policy or Registry setting on computers.
С назначением же групп компьютерам интереснее. Не то, чтобы процесс сильно сложен, просто нужно учитывать один момент, который из моей дырявой головы все же вылетел. Назначение групп политиками делается все там же, где и вся остальная работа с GPO домена - оснастке групповых политик. В том GPO, который регулирует механизм автоматического обновления нужно лишь включить параметр Enable Client-Side Targetting. Там же задается и имя группы, куда будут помещены компьютеры, к которым данная политика применяется. Путь к этой настройке выглядит так:
Computer Configuration, Administrative Templates, Windows Components, Windows Update, Enable Client-Side Targetting.

После того, как политика будет применена к группе компьютеров, все они во время следующего сеанса связи с WSUS переползут в определенную им группу. Все просто. А теперь о том нюансе, который важно не забыть.
Если до включения рассматриваемой настройки компьютеры уже были распределены по группам руками, а после применения оной для определенного числа компьютеров группа оказалась не заданной, то все эти сиротливые машины вовсе не останутся на своих местах (на что я, признаться, очень надеялся). Они довольно быстро переползут в стандартную группу под названием Unassigned Computers, где и будут находиться вплоть до момента назначения им какой-либо группы на WSUS. Признаться, для меня было довольно неслабым шоком, когда я увидел, что все серверы из группы Servers куда-то подевались, а на месте осталась лишь файлопомойка - она просто не успела по-тихому смыться. Пришлось политиками перетаскивать их за шкирки назад.

@музыка: Roxette - Fireworks

@темы: Этот веселый мир, WSUS, Security

01:10 

Windows 7

Stance Dance

Установлена, настроена. Введена в местную комнатную сеть. И первая же неприятность - нельзя просмотреть список моих сетевых папок. Вообще нельзя, нет их. Хотя в системе заявлено, что они есть. О доступе на администраторские ресурсы и разговор не идет.
Ковыряния с этой проблемой привели в знакомую до боли еще по временам настройки XP оснастку gpedit.msc.

Local Computer Policy, Computer COnfiguration, Windows Settings, Security Settings, Local Policies, Security Options.
Параметр Network security: LAN Manager authentication level. Читаю его описание и понимаю, что либо врет описание, либо найден баг, и довольно серьезный. Склоняюсь ко второму варианту. В описании указано вот что:

Default:
Windows 2000 and windows XP: send LM & NTLM responses
Windows Server 2003: Send NTLM response only
Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2: Send NTLMv2 response only


На практике же этот параметр по-умолчанию не задан вовсе. Такая настройка просто не позволяет ОС осознать, какой же протокол использовать при аутентификации пользователей сети. Принудительно выставил в Send NTLM response only. После этого сетевые папки стали видны. Одна из частей проблемы устранена, но остается решить, как же включить административные ресурсы.
При попытке доступа на заветный \\COMPUTER-NAME\C$ удаленная система получает отлуп - неверные логин и пароль. В то же время в Управлении Компьютером на Windows 7 показывается, что мой административный пользователь успешно авторизовался и держит открытым сетевой сеанс. Снова бомбим Google поисковыми запросами, в результате чего на одном из форумов натыкаемся на любопытную заметку: Клац!
Суть в том, чтобы создать в реестре парметр LocalAccountTokenFilterPolicy (тип DWORD) по следующему пути: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\System. Значение параметра - единица.
После перезагрузки доступ к административным ресурсам появился как по волшебству.

Любопытен тот факт, что согласно заметке на форуме, эта проблема тащится еще со времен ОС Vista, но лично я с ней там не сталкивался...

@музыка: Blue Stone - Dreamcatcher

@темы: Security

21:46 

Windows Automatic Updates #3

Stance Dance

Снова WSUS, будь он неладен. Хотя нет, WSUS-то как раз спокойно работает, раздает обновки и есть не просит. А вот тот самый разношерстный бардак на клиентской стороне...
Windows XP Service Pack 3, SP3 в просторечии так же, как и обычные мелкие заплатки может быть распространен посредством системы обновлений. Но поскольку эта "запчасть" весьма немалая, с ней могут возникнуть проблемы. Одна из таких, весьма неприятных, выглядит следующим образом. Клиент закачивает к себе файлы обновления, ждет условленного времени на установку. После наступления минуты "Х" начинает инсталляцию и буквально сразу прерывает ее, снова становясь в режим ожидания следующего интервала установки. В журналах при таком развитии событий пишется ошибка с кодом 0x80070005. Код этот обозначает нехватку прав.
МС написали по данной проблеме весьма подробную статью в базе знаний, вот она:
При попытке установить пакет обновления 3 (SP3) для Windows XP выводится сообщение об ошибке: "Отказано в доступе" или "Установка пакета обновления не завершена" - Клац!

Сценарий, описанный в третьем способе, сбрасывает разрешения на реестр и файлы на "заводские". Это и обеспечивает неограниченный доступ службы обновлений к нужным ей ресурсам.
Все бы ничего, но указанный скрипт некорректен для Windows XP. В нем указывается файл defltbase.inf, которого в системе просто не существует. Как быть? Поиски во всемирной сети снова дали свой результат, скрипт преобразился вот к такому виду:
Reset.cmd

Как это все запустить? Прежде всего, понадобится установочный диск с Windows XP. В дистрибутиве есть хороший набор утилит, называемый Windows Resource Kit. Устанавливаем этот набор, после чего копируем из него одну программу - subinacl.exe Именно она и является ключевым инструментом. Создаем cmd-файл, приведенный выше, сохраняем его рядом с subinacl.exe. Пакет для ремонта разрешений готов. Осталось только его запустить на том компьютере, где наблюдается проблема. Исполняться сценарий будет довольно долго, до десятка минут.

@музыка: G.E.N.E. - Faru Love Affair

@темы: Security, WSUS

21:02 

Windows Automatic Updates #2

Stance Dance

Итак, после атаки Kido эту службу требуется снова поднять из пыли, отряхнуть и поставить на место. Проблема решаема при помощи принудительной установки типа запуска службы в "Автоматически". В этом случае после перезагрузки компьютера служба поднимется сама.
Easier said than done. На выходе получаем ошибку следующего содержания: Ошибка 0x80004015: Класс настроен на использование идентификатора безопасности, отличного от используемого вызывающей стороной.
После чего служба послушно становится автоматически запускаемой, но запускаться не желает, в списке служб гордо красуется надпись Stopped.
С этой проблемой я столкнулся еще ранее, как раз пытаясь службу включить принудительно, но поняв, что политика рушит функционал, просто снял ее, тем самым восстановив статус-кво. На этот раз надо все же докопаться до причины. В прошлый раз у меня на руках не было кода ошибки, теперь же он есть.
Что делать? Правильно, спросить решение у всемогущего Google. Великий и тут не подвел, ответ нашелся довольно быстро:
WU client failed to initialize with error 0x80004015 - Клац!
Если по-русски, то получается следующее.
При принудительном включении службы через доменные политики изменяется набор прав на эти самые службы. Политика по умолчанию предлагает проставить следующие разрешения:
Система (System) - полный доступ;
Администраторы (Administrators) - полный доступ;
Интерактивный вход (Interactive, читай, зашедший пользователь, не относящийся к первым двум категориям) - только чтение состояния.
Все. А на деле нужно проставить еще одну сущность, имя которой NetworkService:
В результате должно получиться:
System - полный доступ;
Administrators - полный доступ;
NetworkService - полный доступ;
Interactive - только чтение состояния.
Дальнейшее - тривиально. Определить область действия политики, подключить ее к домену и просто подождать, пока перезагрузятся системы.

Важно! Функционал автоматического обновления системы использует в своей работе две службы - Automatic Updates (Автоматическое обновление) и Background Intellegent Transfer Service (Фоновая интеллектуальная передача данных). Соответственно, принудительно включать надо их обе.

@музыка: Nickelback - If Today Was Your Last Day

@темы: WSUS, Security

22:55 

Kido #4 - Предупреждение.

Stance Dance

Trend Micro.Inc - New Version of Conficker
Покой нам только снится. С недавних пор я достаточно часто бываю на сайте своего антивирусного вендора (странно, да? ;), отслеживаю изменения версий антивирусных баз и движка сканера. Все жду, когда же версия выше, чем 8.911 появится на серверах ActiveUpdate. Пока что нет.
Внимание привлек заголовок с уже ставшим ненавистным словом - Conficker. Ссылка на статью выше. Если вкратце - 7 апреля обнаружена новая версия вредоноса, судя по тому, что она попалась в ловушку компании Trend Micro - пятое поколение червя снова научили размножаться (версии С и D не распространялись по сетям). Пути распространения остались теми же - уязвимость, флешки, P2P-соединения.
Паниковать не стоит, но быть в курсе - обязательно.

P.S> На момент составления записи страница с новостью не отзывалась, выдавая ошибку базы данных - Error establishing a database connection. Видимо, популярной оказалась.
P.P.S> 10.04.2009 - статья доступна для ознакомления. Так что рекомендую.

@музыка: Nickelback - If Today Was Your Last Day

@темы: Security, Viruses and Spam

Записная книжка

главная