ну и какие критерии активности учетки предлагают хорошие практики?

Это вам определять, вы же в компании работаете, знаете инфраструктуру, бизнес-процессы и конкретные ситуации. Определите условия, которые в вашем конкретном случае являются признаком активности учётки, запишите в политку/стандарт/инструкцию, чтоб не забыть и живите с этим, периодически пересматривая, не нужно ли обновить.

ну получается советы блокировать по неактивности больше теоретические

По нашей практике по неактивности редко идет блокировка, во первых нужно еще правильно определять эту неактивность - не везде есть last login, коннекторы к системе должны получать еще эту информацию.

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

Для IDM информация о неактивности учтеной записи может забираться из целевой системы, если там есть атрибуты last login и платформа и коннектор такое подерживают, иначе надо подключать сторонную систему для получения таких данных об активности УЗ сотрудников.

Речь идет про персонафицированные УЗ, по сервисным, привилиговарнным УЗ - здесь отдельный процесс

При чем тут idm и привелиг уз?

Не надо idm функционал Pam

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

а при чем тут пам/не пам? любая учетка относится к айдентити

При том что сервисные и технологические уз имеют другой жц

IDM не заменяет функционл PAM, эти два решения работают совместно  и дают эффект при  интегрированных сценариях

Вот сейчас безотносительно IdM или PAM. Нет одного идеального решения, бизнесы разные, используемые системы разные. Любые подходы и практики (типа блокировки при неактивности) существуют потому, что решают какую-то проблему, с которой кто-то столкнулся. Но не все "лучшие практики" надо у себя внедрять. Ответьте на вопрос - а нам оно надо? Если ответ "да", то блокируйте. Если ответ "да, но не все", определите внутренние правила и живите с ними. Если ответ "нет", то вам оно не надо.

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

Да конечно можно технически через фиктивные ТУ загнать и в idm ....сервисные..ток зачем

если в айдиэм блочится владелец учетки, то и привилегированные блочатся, а служебным меняется владелец

зачем? для аудита и закрепления сервисных и технологических УЗ за владельцем

Вот поэтому и должно быть все в комплекте. Я на самом деле не могу чётко сказать , нужно ли при наличии idm лочить уз - ведь это идёт на основании кадров

не всегда изменение/предоставление доступа завязано на кадровой структуре

И сразу вспоминается пляски с прикручиванием в one identity этих уз через dummy employ

это отдельные процессы для IDM в части сервисных и технологических, привилигированных УЗ и они не завзяаны с кадрами. Здесь не стоит путать с персонафицированными УЗ