Fedoseyev.ru

По умолчанию, для контроллеров домена действует политика, запрещающая подключения к ним через RDP членам группы Remote Desktop Users, если они не входят в группу Domain Admins. При попытке подключения такого пользователя к DC, появляется сообщение: «To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of Remote Desktop Users group have this right. If you are not a member of the Remote Desktop Users group or another group tha has this right, or if the Remote Desktop User group does not have this right, you must be granted this right manually.»

Определенная логика в такой политике есть, но бывают ситуации, когда на DC развертываются службы, управляемые не доменными администраторами. И в этом случае возникает необходимость предоставить им возможность управления сервером с соответствующим делегированием полномочий. Как было упомянуто, добавление администраторов в группу Remote Desktop Users не срабатывает. Зато срабатывает следующее:

1. Открываем из меню Start -> Settings -> Control Panel -> Administrative Tools -> Terminal Services Configuration;
2. В разделе Connections открываем Properties соединения RDP-Tcp;
3. Во вкладке Permissions добавляем учетную запись, которой требуется доступ к серверу через Remote Desktop, и даем ей необходимые права (User Access, например):

4. Празднуем победу.

admin Default Windows Server, Дела админские, Удаленное администрирование

Одна из самых непротиворечивых концепций безопасности гласит, что без крайней необходимости работать под учетной записью администратора не следует. Особенно под учетной записью администратора домена. Однако, решение административных задач, требующих повышенных привилегий, эта концепция не отменяет. Удаленный доступ к серверу через Remote Desktop – это лишние телодвижения, да и, опять же, небезопасно. Наиболее подходящий путь – локальный запуск нужных оснасток управления с использованием команды RunAs, которая позволяет администратору выполнять любые задачи в системе, зарегистрировавшись в ней с использованием учетной записи рядового пользователя.

Для управления удаленными серверами Windows я использую пакеты Administrative Tools для своей клиентской ОС. Они доступны для загрузки с сайта Microsoft:

Windows Server 2003 Administration Tools Pack: http://www.microsoft.com/downloads/details.aspx?FamilyID=c16ae515-c8f4-47ef-a1e4-a8dcbacff8e3&displaylang=en

Microsoft Remote Server Administration Tools for Windows Vista: http://www.microsoft.com/downloads/details.aspx?FamilyId=9FF6E897-23CE-4A36-B7FC-D52065DE9960&displaylang=en

Remote Server Administration Tools for Windows 7: http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en

Установив соответствующий вашей системе пакет администрирования, вы получите доступ прямо со своего компьютера к большинству оснасток управления серверами, таких как Active Directory Domains and Trusts, Active Directory Sites and Services, Active Directory Users and Computers, Distributed File System, DNS, Group Policy Editor, DHCP и пр.

Для запуска любой из оснасток с привилегиями доменного администратора, применим команду RunAs. Например, запустим оснастку Active Directory Users and Computers от имени пользователя admin, принадлежащего к домену domain.ru:

Синтаксис RunAs достаточно прост, чаще всего с ней используются следующие ключи:

1) /user – имя пользователя;

2) /netonly – использование полномочий только для доступа к удаленным ресурсам;

3) /env – использование текущего окружения, без создания окружения, характерного для указанного ключем /user пользователя;

4) /profile – загрузка профиля пользователя;

5) /noprofile – загрузка профиля пользователя не будет осуществляться.

По аналогии можно запускать любую из оснасток, входящих в состав Administration Tools:

Active Directory Domains and Trusts — domain.msc

Active Directory Sites and Services — dssite.msc

Active Directory Users and Computers — dsa.msc

Computer Management — compmgmt.msc

Distributed File System — dfsgui.msc

DNS — dnsmgmt.msc

DHCP – dhcpmgmt.msc

Group Policy Editor — gpedit.msc

Local Security Settings — secpol.msc

Routing and Remote Access — rrasmgmt.msc

Само собой, оснастки для управления локальными ресурсами, которые по умолчанию установлены в любой Windows-системе, начиная с Windows XP, можно использовать и для администрирования удаленных систем. Приведу список самых используемых:

Services – services.msc

Device Manager — devmgmt.msc

Disk Management — diskmgmt.msc

Local Users and Groups — lusrmgr.msc

Shared Folders — fsmgmt.msc

Напоследок напомню, что для работы RunAs необходимо, чтобы была запущена служба Secondary Logon.

admin Default Software, Windows Server, Безопасность, Удаленное администрирование

Я уже давно приучил себя к мысли, что выполнять любые операции с системой, для которых не требуются привилегии администратора, необходимо под учетной записью обычного пользователя. Применительно к UNIX, это вообще стандарт де-факто, идея-фикс, канон, догма и так далее. А когда речь идет об удаленной машине, имеет смысл вовсе запретить логиниться на нее root’ом. Но права root’а иногда все-таки нужны, а FreeBSD — система консервативная, не слишком быстро реагирующая на перемены в мире, и, скажем, распространенной в среде Linux команде sudo не обучена. Зато в числе групп безопасности FreeBSD имеется группа wheel, которой делегированы права выполнять команду su (от SuperUser — команда, повышающая привилегии пользователя до уровня root). Сложив вышеназванные факты воедино, приходим к следующему решению:

Создаем нового пользователя:

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

Добавляем его в группу wheel. Для этого необходимо отредактировать строку в файле /etc/group, добавив нужного пользователя через запятую после root:

Запрещаем root’у логиниться по ssh. Для этого правим конфигурационный файл демона ssh — /etc/ssh/sshd_config. Нас интересуют 2 параметра:

Осталась самая малость. Перезапускаем демон ssh:

Готово. Самое время проверить результаты работы. Для начала стукнемся root’ом:

Нельзя, что нам и требовалось. Логинимся созданным пользователем и повышаем привилегии до суперадминистратора (когда в ответ на команду su система спросит пароль, она, само собой, будет иметь ввиду пароль root’а):

Вуаля.

admin Default FreeBSD, SSH, Безопасность, Удаленное администрирование

Всемогущий Кризис воистину явился музой для всего креативного человечества. Например, он вдохновил Microsoft (которая, безусловно, креативна до безумия) включить в состав Windows Server 2008 R2 некую фичу, именуемую Banch Cache. Ее предназначение понятно из названия: она кэширует трафик, проходящий из удаленных офисов через пограничный сервер в филиале. И эти данные сотрудники филиала могут получать из кэша, экономя тем самым трафик и время.

Ведь как было раньше? Существовала Организация, в головном офисе которой стоял файл-сервер, на котором, как ни странно, располагались файлы, среди которых был очень-важный-документ document.doc. В филиале Организации работали пользователи Вася и Петя, оба отчаянно нуждались в документе document.doc. Что и сподвигало их на незамысловатые действия: зайти на файл-сервер, да скачать себе файл. Один и тот же дважды. Короче, паскудно было раньше.

Но Microsoft не дремала. Она уже изучала поведение Васи и Пети, обливаясь горючими слезами из-за непотребно раздутых счетов за интернет, выставленных Организации. И, изучив, выдала замечательное решение Branch Cache, которое способно как трафик сэкономить для Организации, так и время для Васи и Пети.

И стало так: в головном офисе стоит файл-сервер, на котором лежит некий файл document.doc. В филиале стоит сервер, сконфигурированный как Branch Cache. И все так же работают Вася и Петя. Вася заходит на файл-сервер головного офиса и качает файл document.doc. Петя, дабы не отставать от коллеги, тоже заходит на файл-сервер и тоже качает document.doc, но, оказывается, этот файл уже скэширован на сервер Branch Cache, и Петя получает его именно оттуда. Выгода налицо: и трафик сэкономили, и скачал файл Петя гораздо быстрее, чем Вася. Ну разве не сказка?

Если представить себе организацию, в которой объемы данных, гуляющих между филиалами, реально велики, а количество сотрудников, их использующих, исчисляется хотя бы десятками, то польза от такой фичи видна невооруженным глазом. Для крупных организаций — однозначный must have.

Кстати, Branch Cache кэширует только трафик, переданный по протоколам SMB и HTTP, и может быть настроен через групповые политики.

P.S. Невыясненным остается только один вопрос: если ИТ-департамент взялся экономить на грошовом трафике, где он возьмет денег на апгрейд ОС, чтобы легально приобрести Windows Server 2008 с нужным количеством пользовательских лицензий, а также на сервер, куда предполагается этот Windows ставить?..

admin Default Microsoft, Windows Server 2008, Передовые технологии, Удаленное администрирование

Столкнулся с проблемой: очень медленная работа клиента RDP из-под Vista при подключении к терминальному серверу на Windows 2003. Собственно, столкнулся и с решением. Необходимо на клиенте выполнить команду:

Тормоза исчезнут. Наступит благодать.

P.S. Применимо к Windows 7.

admin Default RDP, Vista, Windows, Windows 8, Удаленное администрирование

Оперируем реестр. Интересующий нас раздел:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp. Открываем параметр DWORD PortNumber, в окне правки меняем систему исчисления на десятичную и вводим вместо значения 3389 новый номер порта ожидания RDP, например, 3399.

При подключении к данному хосту через клиент RDP, необходимо указывать новый порт после адреса хоста через двоеточие: hostname:3399.

admin Default Windows, Удаленное администрирование

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

К примеру, нам нужно получить доступ к Windows-серверу, имеющему внутренний IP-адрес 192.168.0.10, спрятанный за маршрутизатором с IP 89.94.250.116. Порт ожидания для RDP — TCP 3389, для SSH — 22. Создаем на маршрутизаторе правило, где source — WAN (интерфейс, смотрящий в интернет), destination — Firewall (маршрутизатор), Service/Port (сервис/порт) — произвольно выбранный порт, желательно из диапазона 20.000-50.000 (на самом деле можно использовать абсолютно произвольный порт, но т.к. правило, возможно, будет работать не один год, необходимо использовать порт, не привязанный к широко распространенным сервисам и службам), скажем, 22.000, действие — Permit (разрешить), translation — MAP 192.168.0.10 PORT 3389.

Если перевести данное правило на человеческий язык, то мы получим следующее: при обращении к маршрутизатору с произвольного внешнего хоста на порт 22.000 транслировать данное обращение к внутреннему хосту с IP-адресом 192.168.0.10 на порт 3389.

Подобные правила можно создавать на практически любых программных маршрутизаторах, вроде Kerio Winroute Firewall, MS ISA, UserGate, а также на абсолютном большинстве аппаратных маршрутизаторов.

admin Default Маршрутизация, Удаленное администрирование