Наверх

База знаний
Try 2 Fix
beta

Windows Server: Контроль доступа пользователей в систему

Контролировать когда, под каким пользователем и с какого хоста был осуществлён вход на Windows Server можно встроенными средствами ОС. Также можно следить за тем, кто и когда пытался войти в систему, но безуспешно. По умолчанию эти средства контроля в Windows Server отключены. Настраиваем всё необходимое.

  1. Заходим в Редактор локальной групповой политики: в окне Выполнить набираем команду
    gpedit.msc

    и нажимаем Enter.

  2. В открывшемся окне Редактор локальной групповой политики переходим в раздел «Политика Локальный компьютер» > «Конфигурация компьютера» > «Конфигурация Windows» > «Параметры безопасности» > «Локальные политики» > «Политика аудита».
  3. В правой части окна поочерёдно открываем политики «Аудит входа в систему», ставим обе галочки «Успех» и «Отказ», далее делаем тоже самое для политики «Аудит событий входа в систему».
  4. На всякий случай в том же окне Выполнить набираем команду
    gpupdate /force

    Она пришла к нам из мира контроллеров доменов, но я по привычке ввожу её каждый раз после любого изменения политик.

  5. На этом работа с Локальными политиками завершена.
  6. Идём в Журнал событий Windows для проверки работоспособности (если у Вас вход/выход пользователей происходит крайне редко, попробуйте сами выйти из системы и зайти снова): в окне Выполнить вводим команду
    eventvwr.msc
  7. Двигаемся к следующему разделу: «Просмотр событий (Локальный)» > «Журналы Windows» > «Безопасность». Здесь мы видим множество событий.
    Итак, кликаем на событие с Категорией задачи «Вход в систему» (код события 4624). Что мы можем узнать об этом событии:

    Новый вход:
    ИД безопасности: SRV\UserAccount
    Имя учетной записи: UserAccount
    Домен учетной записи: SRV
    Код входа: 0x6cdb7f203
    GUID входа: {00000000-0000-0000-0000-000000000000}
    
    Сведения о процессе:
    Идентификатор процесса: 0x0
    Имя процесса: -
    
    Сведения о сети:
    Имя рабочей станции: UserHost
    Сетевой адрес источника: 192.168.1.14
    Порт источника: 51626

    Новый вход — данные о пользователе, под которым выполнен вход в систему.
    Сведения о сети — NetBIOS имя ПК, с которого был осуществлён вход, его IP адрес и порт.
    → Дата (в нижней части окна) — дата и время возникновения события.

Точно также будет выглядеть отчёт о неудачном входе в систему, что в последствии может помочь получить хоть какую-то информацию о злоумышленниках, который пытаются получить несанкционированный доступ к Вашему Windows Server.

Остались вопросы?

Лоджик Флоу


Аутсорсинг / Системное администрирование / Техническая поддержка / Сопровождение 1С:Предприятие

+7 (8634) 383-490 / +7 (906) 430-7000
mail@logicflow.ru

Что-то пошло не так? Специалисты нашей компании помогут Вам разобраться с возникшими проблемами! Обращайтесь! →

Также Ваши вопросы Вы можете задать в нашей группе ВК или на нашем YouTube канале!

Эти статьи будут Вам интересны

Не удаётся обновить Декларант-Алко: процесс не может получить доступ к файлу.

Начиная с версии Декларант-Алко 4.30.10 у наших клиентов появилась проблема при обновлении программы через её интерфейс. Пользователь выбирает файл обновления, появляется окно со списком изменений программы, а затем появляется ошибка "Процесс не может получить доступ к файлу, так как этот файл используется другим процессом". Предложенное решение не является самым изящным, однако позволяет обойти эту проблему. Приступим.

1С:Предприятие: hardlock.sys file (null) processing error. Status code 12 4 2163 32

При установке платформ 1С:Предприятие 8.3, начиная с версии 8.3.10.х, у многих наших клиентов при установке драйвера защиты HASP стала появляться следующая ошибка: hardlock.sys file (null) processing error. This is an internal error. For assistance, contact your administrator or the software manufacture. Status code 12 4 2163 32. Ошибка была замечена пока что только в Windows 10. Все простые шаги вроде чистки мусора и кэша, чистки реестра, запуска установки от имени администратора уже пройдены - не помогло. Но мы нашли решение! Рассказываем!    

Zimbra 8.6 OSE: Произошла неизвестная ошибка (mail.TRY_AGAIN). Ошибка сети. postfix/postqueue fatal: Queue report unavailable — mail system is down

На корпоративном почтовом сервере Zimbra OSE пользователи при отправке внутренней почты стали получать сообщение "Произошла неизвестная ошибка (mail.TRY_AGAIN)", другие пользователи увидели "Ошибка сети". А мы во всех логах (/var/log/zimbra.log, /var/log/mail.log и /var/log/mail.err)  увидели это волшебное сообщение "postfix/postqueue fatal: Queue report unavailable - mail system is down". Работа была парализовано, но решение оказалось простым.