Почему отлетают права пользователя в домене win2016?
Добрый день.
Есть у меня домен с настроенным АДом, DFS, и прочие доменные мульки.
Есть пользователи которые прекрасно работают в этой среде, файлы хранят на сетевых дисках подключенные через GPO и DFS которые бекапятся, изменяются пути незаметно для пользователей, и все рады.
НО есть и один пользователь с которым идет только одна проблема, у него слетают права на файлы во время работы. Слетают права - это значит что пользователь, по логам существует прекрасно, он может создавать документы/папки на файловом ресурсе, но в один прекрасный рандомный момент, пользователь, теряет возможность редактировать и удалять файлы. Помогает только либо релогин, либо перезагрузка.
Думал проблема в учетной записи. Удалили из АД и создали новую, Сделали локальный профиль - не помогло.
Думал отъехало DFS - нет. Но на всякий создал новый ресурс - не помогло.
Раньше пользователь работал на RDS - перенесли его работу на физическую машину, создали новый профиль. Результат решения проблемы ноль.
В логах безопасности все прекрасно, пользователь существует и домен его видит и подтверждает его права доступов.
В чем может быть проблема и куда копать?
Диски
Политиками и группами безопасности ничего не меняется? Что говорит RSOP?
Квоты дисковые какие-нибудь имеются у пользователя?
Новую УЗ пересоздавали с нуля или копированием с какой-то существующей УЗ?
Если помогает релогин и перезагрузка, значит протухает авторизация. Попробуйте вместо "релогина" блокировку рабочей станции( win + L ), поможет ли это?
Вообще нужно смотреть записи журнала на рабочей станции, и с 99% это не журналы безопасности. Проблем может быть множество, от компа который криво переехал из одного домена в другой, до DNS и других сетевых проблем.
Да, проверьте в пользователе дело или в рабочей станции, пересадите его на другой компьютер.
Политиками и группами безопасности ничего не меняется? Что говорит RSOP?
Нет. Более 100 пользователей работают нормально в т.ч.девять из отдела проблемного профиля.
RSoP говорит что все прекрасно пользователь живой и все политики назначаются корректно.
Квоты дисковые какие-нибудь имеются у пользователя?
Нет. Квот нет.
Новую УЗ пересоздавали с нуля или копированием с какой-то существующей УЗ?
УЗ создавалась путем удаления с из домена, вычищение старых UID и как вишенка выдачей нового компьютера с чистой ОС.
@nApoBo3
Если помогает релогин и перезагрузка, значит протухает авторизация. Попробуйте вместо "релогина" блокировку рабочей станции( win + L ), поможет ли это?
Я не спорю что протухает авторизация, но она как то странно покидает чат, доступы остаются, но только на файловом ресурсе пользователь не может вносить изменения. т.е. Создавать может, копировать НА ресурс может, Удалять или редактировать файл нет. Система говорит "Запросите разрешения у пользователя в UID " и UID текущего пользователя.
Антон Нагаец, т.е. не отказ в доступе, а запросите разрешение у пользователя. Это сильно разные симптомы. Что с сфотом и настройками? Такая ошибка возникает когда пользователь лочит файл, например подобные "глюки" бывают при подготовке миниатюр для мультимедийных данных. Возможно конкретно этот пользователь использует какой-то специфический софт.
Но судя по всему авторизация не протухает, перелоги помогает поскольку убивает какой-то процесс.
nApoBo3,
почти. Пользователь сидит в базовом офисном пакете (Доки, таблицы, почта) и именно с этими файлами возникают проблемы.
Пользователь может целый день работать, сохранять, редактировать, удалять и в какой-то момент Всё, баста. релогин.
50% ответа в правильном вопросе. Остальное мануал.
В общем не мытьем так каКтанием.
Проблема была в Касперском.
Если очень кратко то на сетевом диске выполнялось шифрование архива через КриптоАРМ для отправки в госорганы и доблестный каспер воспринимал работу с шифрованием сертифицированных СКЗИ, как вторжение вируса шифровальщика и блокировал все подключения от АРМ.
