HelpDesk под колпаком. Аудит создания учетных записей пользователей в AD

    Всех приветствую.

    Еще только в начале своего познания профессии системного администратора мой начальник поведал мне о такой профессии (вернее ее направлении) как дизайнер AD. Эти люди наводят порядок в домене и приводят в порядок учетные записи. Кто с этим сталкивался и возился может понять то раздражение, которое вызывают корявые имена учетных записей, созданных каким-нибудь сотрудником, который чихал на твой порядок.
    Взяв в руки PowerShell мы дали им бой!

    Не надо мусорить!


    Суть состоит в том, что для HelpDesk было создано специально подразделение в AD (назовем его NewUsers), в котором они могли создавать новые учетные записи (делегирование прав пользователям здесь обсуждать не будем).
    Их задача — по необходимости создавать новые учетные записи в этом подразделении.
    Моя задача — отслеживать правильность заполнения нужных полей (особенно login) и перемещать по отделам.

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

    В итоге я получил кучу учетных записей, непонятно чьих, и самое главное — непонятно кем созданных. На вопрос: «кто это создал?», все работники дружно отнекивались. Естественно, что я не горел желанием разбираться в этих учетках, и без того дел хватало.
    Как ответственный за домен, отвечать перед начальником за Tania и Gosha приходилось мне.

    На глаза попалось замечательное слово — аудит.

    Способы решения


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

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

    Для начала мне надо было установить политику аудита для определенных подразделений (в нашем случае папка NewUsers) и добавить к аудиту группу, за которой будем просматривать (можно не раздумывать о группах и добавить просто всех пользователей).
    Вот здесь можно почитать про аудит доменных служб Active Directory, а вот здесь Вас ждет пошаговая инструкция, как настроить аудит.
    В итоге в журнале безопасности контроллера домена будут появляться события создания новых объектов пользователей.
    Нас же интересует событие с кодом 5137 (Создание объекта в каталоге).

    Переходим к сбору информации с контроллеров. Конечно, если у вас 1 КД, вам достаточно просто настроить фильтр журнала, и забыть про остальную часть статьи, но тогда Вам придется превратиться в дядю Ваню, сторожа кукурузного поля, который всегда на посту. Другими словами — есть свободное время? Загляни в журнал безопасности.
    Если же хочется остаться самим собой и у вас более 1 КД, стоит читать дальше.

    А что же PowerShell?


    В PowerShell просматривать журнал на помогает cmndlet Get-eventlog. С помощью него мы и будем выбирать нужные нам сообщения. Дабы обойти проблемы с подписанием скриптов, мы поступили так: засунули нужный нам код в файл профиля и определили его как функцию.

    Для тех, кто не знаком с профилями, можно почитать это или, кому не хочется покидать Хабр, это.
    Так же, для загрузки профиля понадобится выполнить команду:

    Set-ExecutionPolicy RemoteSigned

    Вернемся к нашим баранам. Собственно, код нашей функции:

    function Audit
    {
    Get-eventlog security -InstanceID "5137" -Newest 1 |
    Where-Object {$_.Message -match "OU=NewUsers,DC=contoso,DC=com"} |
    Select-object TimeWritten,Message,MachineName | Format-list | out-file \\MyComp\d$\Audit.txt -append
    }

    Для себя я выбираю только время записи события, сообщение и имя КД, на котором все это происходило. Если кому то этой информации недостаточно, можно расширить список. Пишем:
    Get-eventlog security -InstanceID "5137" | get-member
    и получаем полный список всех свойств.
    Вывод осуществляется в текстовый файл, который находится на моем рабочем компьютере.
    Так же меня интересуют учетные записи только в определенном подразделении, так что мы выбираем сообщения, в которых присутствует путь к нашей папке (OU=NewUsers,DC=contoso,DC=com).
    Если интересно, почему я выбираю только 1 последнюю запись, читаем далее.

    Нам надо вызывать эту функцию каждый раз, когда в журнале будут появляться нужные нам события. Для этого воспользуемся стандартным планировщиком заданий. Как создавать задание я рассказывать не буду, остановлюсь на важных моментах:
    Действие: Запуск программы
    Программа или сценарий: powershell
    Добавить аргументы: -windowstyle Hidden audit
    Триггер:
    Назначить задачу: При событии
    Журнал: Безопасность
    Код события: 5137

    Так же не забываем поставить галочки:
    «Выполнять вне зависимости от регистрации пользователя» — дабы задача могла выполняться не требуя нашего присутствия.
    «Выполнять с наивысшими правами» — дабы у нас был доступ к журналу Безопасность.

    После создания задания, можно экспортировать его в xml файл и таким образом распространить его на остальные КД.

    Стукачей не любят


    В итоге мы получили персонального «стукача» на каждом КД, который будет реагировать на нужные нам события в журнале безопасности.
    Теперь можно ловить за руку тех, кто не соблюдает принципы Фен-Шуй и мешает свободному потоку энергии у нас в домене.
    Поделиться публикацией

    Комментарии 18

      0
      Аццки плюсую ибо актуально.
        0
        Как я вас понимаю. У меня тоже принята строгая политика именования объектов AD. Например, имя компьютера должно содержать инвентарный номер. Но некоторые личности это не соблюдают, и иногда там можно встретить всякий мусор. Приходится иногда повышать голос.
        Кстати, создателя кривого объекта можно вычислить, посмотрев владельца объекта.
        А чтобы понять кто где работает, в logon скриптом можно вставлять в атрибуты description или managedBy компьютера логин или имя пользователя.
          0
          Можно по подробнее про Владельца объекта? Что то мне такое не попадалось на глаза.
            0
            Сам же себе отвечу, извините, затупил.
            Да, можно посмотреть и там, но, в моем случае, у меня показывается только группа, в которую входит создатель (например Domain Admins). Может у Вас по другом?
              0
              У меня AD на 2003. Как посмотреть безопасность через стандартную консоль я не нашел. В adsiedit.msc ПКМ на объекте, Properties, вкладка Security->Advanсed->Owner. У меня там стоит пользователь владелец, считай создатель объекта.
                0
                Я кажется понял. На technet сказано, что:
                By default, the owner is the creator of the object, except for objects created by an administrator, in which case «Administrators» is the owner.
                Аналогично Domain Admins будет владельцем объектов созданных его членами. Кстати, раньше в упор этого не замечал. :)
                А у меня специальные группы, что-то типа SG-Admins-Who-Can-Create-Users-In-This-OU.
                  0
                  Хах, интересно, у нас тоже есть группа для HelpDesk`а. Но два человека еще являются и членами группы Domain Admins.
              +1
              Мы используем в качестве хостнеймов мак-адреса+ код локации. В настройках WDS выглядит как RU%MAC%
              А для того, чтобы знать кто где сидит — надо иметь программу инвентаризации, коих великое множество, все же AD для этого не предназначена, большой трафик репликации, нагрузка на DC итд.
              Да и кстати поздравляю — автор сложно решил несуществующую проблему!
                +2
                Ну не знаю. AD на то он и AD, чтобы хранить информацию. Юзеры в миллионы раз больше говнотрафика генерируют, могу ли я выделить немножко для своего удобства? :)
                А так по имени и описанию компьютера из «бухгалтерской программы» могу узнать о нем все. В общем, меня устраивает.
              0
              Я не буду много писать, вся ваша статья умещается в это:

              «Логины должны вида Вася.Пупкин»

              get-qaduser |? { ($_.samaccountname -notmatch ("{0}\.{1}" -f $_.FirstName,$_.LastName )}

              Остальное сами додумаете, если чего пишите, помогу.
                0
                Кривых login`ов полно по нашему домены ибо домен большой, а занимаюсь я дизайном относительно недавно.
                С помощью вашего примера же Вам выйдет список всех кривых логинах, а дальше что? Смысл в статьи не только в этом.
                  0
                  Смысл статьи — найти, покарать и уничтожить, поставить барьер.

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

                  Аудитом Вы видите только тех кто завел УЗ, причем пост фактум — и это не правильно.

                  Необходимы организационные меры, через руководство, и коли у вас большой домен, это должно сработать.
                    0
                    Найти можно и средствами AD.
                    Смысл статьи — направить праведный гнев начальства не на меня, а на тех кто создает эти УЗ.
                    Вот тогда и пойдут организационные меры.

                    С моей стороны до этого было сделано несколько шагов: и объяснения что и как и даже создание инструкции. Увы, не до всех удается достучаться.
                      0
                      Отбирайте права у попавшихся.

                      А вообще объяснения тут важно именно начальству — неверное заведение УЗ: увеличивает стоимость обслуживания, усложняет связывание сервисов, осложняет работу самого сотрудника (кому эта УЗ была выдана), вообще может привести к нарушению безопасности. Безалаберность, это угроза для безопасности.

                      А если всё-еще с Вас продолжают спрашивать за «них», то можно сделать сервис заведения УЗ, который по определению не ошибается.

                      У нас используется скрипт с блэк..., ну это уже другая тема, у нас мы сами заводим УЗ и простого заполнения ФИО и SAMACCOUNTNAME у нас недостаточно…
                        0
                        Если я отберу права у всех попавшихся, я вернусь к тому, с чего начинал — опять ко мне ходят толпы и конючат «создай учетку».

                        Понятно, что у нас не совершенная фирма в плане IT безопасности, есть куда стремиться.
                        Требовать от них чего то большого, мне пока никто не позволит, ибо мое начальство и начальство этих «эникейщиков» совершенно разное.
                        По этому приходится маленькими шажочками выводить всех (себя в том числе) на истинный путь.

                        На счет специального сервиса — интересно. Надо будет подумать.
                        Спасибо за совет и за Ваше стремление к общей безопасности :)
                          0
                          Да, как вариант — сделайте веб-страничку, куда вводятся имя, фамилия и еще что-нибудь общее (должность) в форму для новых сотрудников. Скрипт автоматически создает логин на основе введенных данных, и в AD. Отберите у сотрудников права на AD и оставьте только на такую веб-страничку.
                            0
                            А, если не секрет, сколько у вас юзеров? Походу даже в относительно небольших буржуйских конторах (>500) пользуются специально обученными программами, типа www.quest-software.ru/activeroles-server/
                              0
                              Не секрет, около 1300 (честно — не считал). Предприятие государственное, так что покупка производится строго регламентированного ПО. А за пиратские никто по голове не погладит — по этому приходится выкручиваться :)

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

                Самое читаемое