Нет, сегодня речь пойдет не о таких вещах, как RDP или LogMeIn. На днях приехала первая из трех заказанных карт удаленного управления серверами Aten IP8000. Обычная PCI плата, которая добавляет функционал iLO (это если в привычных мне терминах HP), а по-русски - возможность управлять сервером на протяжении всего времени его работы, от самого старта по питанию до выключения этого самого питания. Ну и бонусом приятные штуки как Remote Media и ему подобное.
Все бы ничего, но захотелось настроить авторизацию на этой карте через Active Directory, это банально удобнее. Все необходимые настройки для этого есть. Открываем форму, вбиваем все необходимые данные:

Отличие от этого скрина в том, что галку Enable Authorization я тогда поставил.
Сохраняем настройки, даем рестарт карты... и понимаем, что LDAP-авторизация не заработала. Перепроверяем настройки еще раз - понимаем, что все внесено верно, но не работает. Штудируем мануал и видим, что в мануале раздел LDAP вообще никак не освещен. Что за...
Гугл, запрос. Ответом стала шокирующая информация из инструкции к другому KVM той же компании - для того, чтобы работала авторизация через MS AD, нужно расширить схему AD! Засада, потому что таких прав у меня нет, да и для чего такие сложности, вообще неясно.
Еще более вдумчивое изучение того же справочного файла сказало: отставить панику, сейчас все сделаем. И действительно, все сделали. Теперь по шагам:
1. Выбор между LDAP или LDAPS. Тут все очевидно - что используется, то и нужно выбирать, причем LDAPS предпочтительнее. Негоже пересылать информацию об учетных записях в открытом виде (привет старому доброму PsExec).
2. LDAP Server IP, Port. Тоже все понятно, где LDAP развернут - тот IP адрес и подставляем. Порты в подавляющем большинстве случаев используются стандартные.
3. Timeout. Как долго наша карточка будет ждать ответа от LDAP. Тоже ничего особенного.
4. LDAP Administrator DN. Имя административной учетной записи, от которой будут происходить операции в AD. До сих пор не могу в толк взять, для чего здесь нужно именно административную запись вводить. Ведь карта в самой AD ничего не меняет, а читать из каталога позволено всем. Но делать нечего, вводим учетку в формате:
CN=username,OU=users,DC=example,DC=com
5. LDAP Administrator Password. Все просто - пароль указанной административной учетки.
6. Search DN. Вот здесь уже интереснее. Это имя контейнера, в котором, а также во всех его подконтейнерах, учетные записи будут иметь право логина на нашу карточку.
7. IP8000 Admin Group. Параметр, связанный с предыдущим. Члены указанной группы из AD будут обладать правами администратора и на карточке. Все остальные - только базовыми, об этом чуть ниже.
И остается та самая галочка Enable Authorization. Именно она определяет логику работы карточки с AD. Итак:
1. Параметр включен. Для определения того, кто может зайти, кто не может, а кто является администратором, карточка будет искать среди атрибутов учетных записей два особенных, которые и создаются во время расширения схемы AD.
2. Параметр выключен. На карточку смогут зайти все пользователи, чьи учетные записи находятся в OU, указанном в пункте 6, и будут обладать урезанными правами. Пользователи же, чьи учетные записи находятся в группе, указанной в пункте 7, смогут делать с карточкой что угодно. Изменения схемы в этом случае не требуется.
Таким образом, параметр Enable Authorization я отключил, после чего авторизация через LDAP заработала так, как требовалось.
И отдельно о правах пользователей. Ради теста зашел под специальной технической учеткой, созданной для различного рода проверок, с ограниченными правами на карточке. Каким же было мое удивление, когда я увидел, что такой учетке доступен раздел Power Management и кнопки выключения сервера и его жесткой перезагрузки. Эта засада будет подстерегать тех, у кого административные учетные записи лежат в структуре AD в том же OU, что и обычные учетки сотрудников. Обходится этот момент просто - нужно создать отдельную OU, перенести туда нужные учетки, и именно эту OU прописать в настройках LDAP-авторизации карты. После этого обычным учетным записям зайти на нее просто не удастся, они будут отфильтрованы, а административные учетки будут обладать всеми необходимыми правами.