С недавнего времени, после выпуска очередного обновления Майкрософтом, изменился состав фильтра безопастности для групповой политики. Распространяется это и на Windows Server 2008, 2012. Теперь для того, что бы GPO применилась, неободимо в фильтр безопастности добавить КОМПЬЮТЕРЫ или ГРУППУ КОМПЬЮТЕРОВ, а в настройках безопастности GPO добавляется группа ПРОШЕДШИЕ ПРОВЕРКУ с правами чтения. Для примера несколько зарисовок:
А во вкладке Делегирование Добавляем ПРОШЕДШИЕ ПРОВЕРКУ с правами на чтение:
А вообще, более подробно описано в этой статье и в этой.
Пришлось как-то раз заняться довольно абсурдным занятием - установка на Windows сервиса Tacacs+. Связано это с тем, что в конторе отродясь не было серверов на Linux, а сетевого оборудования развелось довольно много + штат сотрудников IT отдела составлял 9 человек.
Присутпим. На tacacs.net скачиваем дистраибутив и выполняем установку по-умолчанию. При установке, возможно, инсталятор предложит ввести ключ для шифрования соединения между сервером авторизации и сетевым устройством. Можно не указывать, а потом ввести вручную через файл конфигурации. Всё, можно лезть в конфигу. Все ссылки на конфижные файлы есть на меню "Пуск" в соответствующих разделах.
Стояла задача удалить следы пребывания на рабочих станциях агента System Center Configuration Manager. Сделать это нужно было в домене в котором более 1000 машин с разными ОС. При установке агента в папке Windows создаётся директория ccmsetup в которой находится инсталятор ccmsetup.exe. При его запуске с параметром /uninstall агент удаляется. Однако, директории которые создаются агентом при установке не удаляются после деинсталяции агента. Т.е. нужна перезагрузка ПК и после этого можно удалить рабочие директории агента. Для это, собрав информации в интернете, зарисовал небольшой скриптик:
В этой статье расскажу об установке и настройке Squid на контроллере домена на базе Windows 2008 R2. Помимо всего прочего реализована авторизация пользователей живущих в Active Directory и проверка нахождения их в определённой группе. Каждой группе назначены свои разрешения и доступные ресурсы.
Чего стоило реализовать эту схему - лучше промолчать. Не смотря на то, что документации и готовых примеров в интернете пруд пруди, пришлось собирать мозаику из кучи источников что бы схема стала работоспособной. Изначально, хотелось реализовать авторизацию и проверку в группах через Kerberos, но на это у меня просто терпения не хватило. Затык наступил на создании .keytab файла.
Ладно, начнём.
Немного простонародной теории. По-умолчанию, после установки Squid, не важно на какой платформе, прохождение всего трафика разрешено. Плюс ко всему возможность авторизации в AD и запроса информации от туда, осуществляется так называемыми хелперами. Т. е. само приложение или демон Squid запускает другие приложения или скрипты для выполнения тех или иных действий. Речь о действиях, в нашем случае, идёт в AD. Для того чтобы запрашивать информацию в AD, необходимо это делать от имени пользователя, находящегося в AD. Поэтому плавно переходим к пратике с иллюстрациями.
После неудачной попытки прикрутить прокси на базе Squid к Active Directory с учётками на кирилице, вынужден был искать альтернативу. Серверов на линуксе в конторе отродясь не было, поэтому решил отказаться от *nix систем. Начал искать альтернативу для Windows. Вообще, задумка такова, что в каждом из 80 филиалах компании установлен DC. На этот DC устанавливался бы сервис прокси. Конфигурация же для всех филиалов бралась из какого-нибудь места. После не продолжительных поисков наткнулся на китайскую CCProxy. Небольшая программа. Почитал описание на сайте. Авторизацию через LDAP вроде поддерживает.
Начал разбираться. Установка особого интереса не представляет. После установки запускаем приложение: