Настойка политик на Windows Server 2003

[Maikll]

Оффтоп

честно говоря, не ожидал, что мне придётся это объяснять

Расширения ntfs не меняются в зависимости от залогинившегося пользователя, поэтому достаточно применить скрипт к нужной папке под админом или под именем админа. По результату смотрим, в какие группы попадает пользователь (или не попадает) и какие разрешения ему в итоге применяются. Напомню, что разрешения групп перекрывают разрешения пользователей.

З.Ы. а вот остальные утилиты надо запускать именно под пользователем.

[Ejik]

У обычных юзеров права только на чтение и выполнение.

Regmon из дома скачаю и завтра проверю.

Большое спасибо, за помощь.

[Maikll]

У обычных юзеров права только на чтение и выполнение.

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

[Ejik]

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

Тоже не дал результата.

Еще такую вешь заметил, если я настраеваю внешний вид под себя, т.е открываю свойства понели задач и ставлю галочки Отобразить панель быстрого запуска и ставлю Класическое меню Пуск, то при перезагрезки все опять меняется на первоначальные настройки, т.е применяются настройки по умолчанию. Такое впечатления что изменение не сохраняется в NTUSER.

[Maikll]

:blush2: Не стал я заострять внимание на этом ранее, а видимо зря...

Ejik: а как копировались профили? Простым копированием файлов, я полагаю? Тогда работать и не должно.

Все дело в том, что разрешения на запись в ветку реестра HKCU даются только администраторам и профилю-владельцу учетки, остальные - только чтение. Отсюда и все проблемы, т.к. несмотря на то, что имена совпадают, сиды у них разные.

Ручное решение проблемы:

1. Входим в систему как пользователь с правами администратора

2. В редакторе реестра Файл - загрузить куст и выбираем ntuser.dat из того профиля который нам нужен.

3. На этом кусте в меню Разрешения добавляем нужного доменного юзера в владельцы куста с полными правами.

После этого все изменения должны записываться.

[Ejik]

Да, я просто копировал. :)

А теперь можно по подробнее.

1. Я отркыл реестр и выбрал файл нужный мне NTUSER.dat

2. Открывась окно Загруска куста реестра где нужно ввести имя раздела (вот здесь тупик не могу понять что именно нужно ввести. :) )

[Maikll]

2. Открывась окно Загруска куста реестра где нужно ввести имя раздела (вот здесь тупик не могу понять что именно нужно ввести. blushing.gif

произвольное ;)

Куст с таким именем появится вложенным в тот раздел, на котором указал загрузить

[Ejik]

Maikll, загрузка куста возможно лишь в том случае если курсор стоит на HKEY_USERS, во вложеных кустах такой возможности нет. А я так понимаю что NTUSER.dat нужно загрузить в определенный раздел реестра, так?

[Maikll]

Ejik: Все правильно, это так и должно быть. Грузить можно в любой доступный раздел, я обычно загружаю в hklm. После установки разрешений куст можно выгрузить (это уже выделять именно его надо).

[Ejik]

Ага, получилось

Вывод: при переноси машины из одной группы в другую, пользователь теряет права на свой профиль, так получается???

[Maikll]

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

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

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

[Ejik]

А как проверить, кто был владельцем?

[Maikll]

желательно посмотреть на том профиле, разрешения которого еще не исправлялись (на рабочей машине, где проблемы а не в виртуалке)

[Ejik]

Так и зделаю, СПАСИБО!!!!!

[Ejik]

Maikll: Я теперь совсем ни чего не понимаю.

Опишу все по порядку.

1. Перенес машину в другую OU и начались проблемы описанные выше.

2.Захожу на эту машину под админом, открываю реестр, проверяю разрешения, во вкладке «Безопасность» 4 группы пользователей 1.SYSTEM, 2.Администраторы(MARIYA\Администраторы), 3.Все, 4.ОГРАНИЧЕНЫЕ,.

Во вкладке «Владелец» только данный пользователь, а на вашей картинки еще присутствует запись админа.

3.Выполнил описанные вами действия по предоставлению прав к профилю, это частично решило проблему.

Остались такие проблемы: не запускается Outlook Express, 1С 8 версия (пишет что не может получить доступ к файлу находящийся в профайле пользователя, проверяю физически доступ к файлу есть.) хотя 7 версия работает, почему то спарк при подключении не конектится, висит в состоянии подключения. SEP (Symаntec Endpoint Protection) тоже не подключается к базе.

Пришлось временно дать права админа.

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

[Maikll]

Я теперь совсем ни чего не понимаю.

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

Остались такие проблемы: не запускается Outlook Express, 1С 8 версия (пишет что не может получить доступ к файлу находящийся в профайле пользователя, проверяю физически доступ к файлу есть.) хотя 7 версия работает, почему то спарк при подключении не конектится, висит в состоянии подключения. SEP (Symаntec Endpoint Protection) тоже не подключается к базе.

Заходим как администратор, по адресу C:\Documents and Settings\имя_проблемного_юзверя даем в параметрах безопасности этому пользователю полные права на всю папку и все подпапки и пр. Проверяем.

Какие ошибки показывают утилиты reg и filemon?

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

Не может. У меня на локализованных системах все подразделения и сами пользователи, и даже аккаутны задаются кириллическими символами (я сам к этому привык и пользователям удобнее) К тому же ос давно уже корректно работает с любыми символами (самому приходилось видеть сеть, в которой все имена компьютеров русские. И ничего, работает даже ;) ).

[Ejik]

Совершенно точно, что кроме переноса на сервере из одного подразделения в другое больше ничего не было?

Точно.

Заходим как администратор, по адресу C:\Documents and Settings\имя_проблемного_юзверя даем в параметрах безопасности этому пользователю полные права на всю папку и все подпапки и пр. Проверяем.

Какие ошибки показывают утилиты reg и filemon?

Сработало, позже проверю утелитами для полной у верености.

[Ejik]

Maikll: когда перекидываю комп с одной группы в другую у не которых компов точнее у юзеров пропадают права на их профаил. Когда я вручную даю права ни их профайл при перезагрузке компа опять такая же ситуация, теряют права. Главное это происходит не со всеми пользователями. В данном случае речь идет о всей папке пользователя.

Почему после 2-3 перегрузок машины, назначенные мной права, обнуляются?

[Maikll]

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

Второй вариант ,что в момент логона у пользователя нет прав (или что-то мешает) на доступ к профилю, поэтому загружается профиль по-умолчанию.

Забираем здесь утилиты dcdiag и netdiag. Выполняем обе на контроллере домена, затем netdiag на одном из проблемных клиентов. Результаты выкладываем здесь.

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

Какие записи появляются в логах компьютера при входе пользователя когда слетают настройки +-10 мин от времени Х? и на сервере в это же время...

Что-то мне кажется, что дело тут не в политике. Попробуй для теста скопировать аналогичные gpo в тестовое подразделение и перенеси туда комп (т.е. чтобы подразделение поменялось, но применяемые политики остались теми же) и посмотри, будут ли такие проблемы на нем.

[Ejik]

Первое впечатление такое, что в некоторый момент времени у юзера меняется SID , система думает что это новый юзер и создает ему новый профиль (имя остается прежним). Документы и пр. не теряется при этом?

У меня тоже такие подозрения. Были такие случаи что при переноси компа в другую группу терялись некоторые доки.

Попробуй запиши SID пользователи и при след сбое посмотри, не поменялся ли он.

Спомошью утелиты getsid или еще как то можно?

[Maikll]

Можно GetSid.exe воспользоваться, можно локально реестр открыть и по пути HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<SID>\ProfileImagePath найти какой кому принадлежит.

Логи все-таки выложи, может домен работает некорректно. Ну и тестовое подразделение сделай само собой.

[Ejik]

При попытки запустить netdiag на раб. станции выходит ошибка: Точка входа в процедуру DnsNetworkInformation_CreateFormFAZ не найдена а библиотеке DLL DNSAPI.dll.

не понятно, что это значит?

А логи с сервера к вам на мыло скинуть?

[Maikll]

не понятно, что это значит?

возьми аналогичную утилиту из Windows XP Support Tools. Она заработает, просто эти из Windows 2003 Support Tools.

Логи как удобнее, можно на мыло, вечером посмотрю. И евенты с клиента и сервера, ага?

[Maikll]

Maikll я, как вы говорили, создал новую OU и применил те же политики, перенес туда проблемный комп(с него и прекрепил евенты) после перегрузки компа все работает.

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

А Симантек хоть обновляется-то? В логах смотрю постоянная ошибка id 13 от SescLU.

Раз уж прислал весь лог, не мог не обратить внимание, что в свое время эта ХР была обновлена от 2000. Проверь, на других проблемных клиентах тоже так или там чистая установка хрюхи. Нарабатываем статистику...

Из логов сервера: что за компы 605SH1D4 и DB? Случайно не эти, на которых проблемы? У них какие-то проблемы со входом в домен.

[Ejik]

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

Да, действительно рано радоваться, теперь у этого пользователя нет доступа к шаболу ворда Normal.dot. Хотя доступ полный, проверил зайдя через проводник создал\удалил файл.

А Симантек хоть обновляется-то? В логах смотрю постоянная ошибка id 13 от SescLU.

Раз уж прислал весь лог, не мог не обратить внимание, что в свое время эта ХР была обновлена от 2000. Проверь, на других проблемных клиентах тоже так или там чистая установка хрюхи. Нарабатываем статистику...

Да, обновляются.

Из логов сервера: что за компы 605SH1D4 и DB? Случайно не эти, на которых проблемы? У них какие-то проблемы со входом в домен.

Заметил, но 605SH1D4 - без проблем, а DB - давно токого компа нет.

Раз уж прислал весь лог, не мог не обратить внимание, что в свое время эта ХР была обновлена от 2000. Проверь, на других проблемных клиентах тоже так или там чистая установка хрюхи.

А какая запись говорит что 2000 был обновлен до ХР? что то я не замертил.