Windows server 2012 выпуски — Ваш верный помощник с OS Windows

Пришло время посмотреть что нового нас ожидает в новой версии Windows Server 2012. На данный момент доступна версия Windows Server 2012 Release Candidate скоро будет доступна RTM версия. Скачав дистрибутив с сайта MS установил систему на виртуальную машину в тестовой среде. Сменил имя сервера и ip адрес, ввел сервер в домен — с этим проблем не возникло. После выполнения данных операций залогинился в систему под учетной записью администратора домена и как обычно первым что увидил это новая консоль Server Manager.

Первоначально работать с данной консолью непревычно но потом привыкаешь. Одна из функций которую давно ждали это управление несколькими серверами из одной консоли Server Manager. Так как в тестовой среде у меня нет больше систем работающих на Windows Server 2012 решил попробывать добавить в консоль Server Manager сервер под управлением Windows Server 2008 R2 SP1. В новой консоле Server Manager переходим в раздел «All Servers» и щелкаем по данному разделу правой клавишей мыши и в контекстом меню выбираем пунтк «Add Servers». Так же добавить сервер можно из любого раздела консоли щелкнув Manage -> Add Servers в правом верхнем углу консоли Server Manager.

В открывшемся окне вводим имя сервера который хотим добавить в консоль Server Manager и нажимаем Find Now. Будут отображены все сервера соответствующие критерию поиска.

Выделяем необходимый сервер и нажав на кнопку перемещаем его в окно Selected затем нажимаем кнопку OK.

Сервер DC появится в консоле Server Manager но управлять данным сервером будет невозможно т.к. на сервере не установлена служба WinRM 3.0.

Проблема с управлением сервером на базе ОС Windows Server 2008 R2 SP1 связана с тем что консоль Server Manager 2012 сервера использует Windows Management Framework 3.0. Для решения данной проблемы скачиваем и устанавливаем на Windows 2008 R2 SP1 следующие компоненты:

Windows Management Framework 3.0 — RC
Microsoft .NET Framework 4

После установки компонентов перезагружаем сервер. Теперь необходимо настроить Windows Remote Management для этого логинимся на сервер и открываем с правами администратора консоль PowerShell. Для настройки WinRM набираем следующую команду: winrm quickconfig. На сервере будет настроен прослушиватель для запросов к службе Windows Remote Management и добавлены правила исключения в настройках брендмуэра Windows. Теперь возвращаемся в консоль Server Manager. В консоли переходим в раздел «All Servers» щелкаем правой клавишей мыши по имени нашего сервера Windows 2008 и в контекстном меню выбираем «Refresh«. Состояние сервера измениться на «Online«.

Если состояние сервера станет «Online – cannot get performance counter data«, как на рисунке выше, то необходимо на управляемый сервер Windows 2008 R2 установить обновление KB2682011 и перезагрузить сервер. После перезагрузки сервера снова открываем консоль Server Manager и перходим в раздел «All Servers» теперь статус сервера должен быть «Online»и теперь слева станут доступны роли установленные на нашем сервере Windows Server 2008 R2 SP1.

Перейдя в раздел «Dashboard» можно контролировать состояние северов и ролей развернутых на этих серверах. О возникновении каких либо предупреждений или ошибок на серверах можно определить по цвету квадрата отвечающему за определенный сервер или роль.

Для перехода к описанию возникшей проблемы необходимо просто щелкнуть по компоненте в которой возникла проблема и откроется окно с описанием проблемы.

Выполнив немного операций можно настроить управление сервером Windows Server 2008 R2 SP1 из консоли Server Manager сервера Windows Server 2012 RC. Eof.

Источник

Powershell Remoting is very impressive feature from Windows server 2008 R2 / Powershell 2.0, it allows to run any PowerShell commands or access full PowerShell sessions on remote Server unlike the older native commands that run on the same server where the command been executed , so it’s powerful and easy to run a function from multiple system with less amount of time

What changes from native command execution?

PowerShell command is executed on the client
Same PowerShell command is transmitted to the server
Server executes the PowerShell command and then returns the output to the client
Client displays or uses the returned output

How to Enable Powershell Remoting on Windows server 2008, Windows 7 and other systems

By default Powershell Remoting is disabled on Windows server 2008 R2 and need to enable by running an enable-psremoting command on individual servers, we have others option to Enable Powershell Remoting on multiple servers remotely, methods are

Enable Powershell Remoting with PSEXEC (Remotely)

We can open psexec from CMD and connect each server and run enable-psremoting -force or run below command with different server name

psexec \\[Server name] -u [User name] -p [password] -h -d powershell.exe “enable-psremoting -force”

Please replace “\\[Server name]” with an IP address, or even “@C:\[path]\serverlist.txt” to automatically enable psRemoting on a big list of computers on your environment

Enable Powershell Remoting with schedule task

We have to create the batch file or ps1 file with enable-psremoting –force command and created a schedule task using the schtasks command pointing to created patch file or ps1 file

Scheduled a task to run the script (batch file or ps1 file) and enable the Powershell Remoting

Enable Powershell Remoting with Server Manager

Open Server Manager
On Server Manager home page, click Configure Server Manager Remote Management.
Next,
Select Enable Remote Management of This Server from Other Computers.
Ok

Enable Powershell Remoting via Group Policy

Create a new GPO, or edit an existing GPO
Browse to: Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
Open the Allow Automatic Configuration of Listeners Policy, select Enabled, and then define the IPv4 filter and IPv6 filter as *(Server 2008 and earlier).
Open the Allow Remote Server management through WinRM Policy, select Enabled, and then define the IPv4 filter and IPv6 filter as *(Server 2008 R2 and later).
Click OK.

For Firewall Rules

Browse to: Computer Configuration> Policies> Windows Settings> Security Settings> Windows Firewall with Advanced Security> Windows Firewall with Advanced Security> and then Inbound Rules.
Right-click Inbound Rules, and then click New Rule.
In the New Inbound Rule Wizard, on the Rule Type page, select Predefined.
On the Predefined pull-down menu, select Remote Event Log Management. Click Next.
On the Predefined Rules page, click Next to accept the new rules.
On the Action page, select Allow the Connection, and then click Finish. Allow the Connection is the default selection.
Repeat above steps to create inbound rules for the Remote Service Management and Windows Firewall Remote Management

If you are using Windows server 2012 then no need to do any of above configuration to enable powershell remoting, Yes it’s enabled by default, start using the feature without any extra effort

Источник

Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу WinRM для пользователей без прав администратора.

WinRM, также называемый WSMan, это технология удаленного управления, которая предоставляет для таких средств как WMI, PowerShell, Перенаправление событий (Event Forwarding) и даже Диспетчер сервера (Server Manager) транспорт по протоколу HTTP. WinRM принимает запросы по HTTP или HTTPS протоколу, которые затем передает зарегистрированным в нем провайдерам (плагинам). PowerShell, WMI и Перенаправление событий зарегистрированы в WinRM как соответствующие провайдеры.

Если бы вы были разработчиком клиент-серверного приложения, то вы могли бы создать свой провайдер (плагин) для WinRM, который можно было бы использовать для удаленного управления вашим приложением. Конечно можно и самому написать DCOM или HTTP веб-интерфейс, но WinRM предоставляет стандартный каркас приложения (фреймворк), что облегчает его администрирование.

WinRM поддерживает методы встроенной аутентификации Windows, такие как Kerberos, Negotiate (включая NTLM) и Schannel (сертификаты). Поскольку он использует обычный HTTP, то поддерживаются также методы аутентификации Basic и Digest.

Для удаленного доступа к инструментарию управления Windows (WMI, winmgmt) можно настроить специальный DCOM интерфейс на прием удаленных команд и запросов (WQL), или же использовать WinRM для этого. PowerShell, с другой стороны, не имеет своего собственного сервера, поэтому для приема удаленных команд используются специальные командлеты Enter-PSSession и Invoke-Command, которые передают запросы по WinRM протоколу. PowerShell принимает эти команды, обрабатывает их локально и возвращает ответ по протоколу WinRM.

Таким же образом работает Диспетчер сервера (Server Manager) и Перенаправление событий (Event Forwarding). Хотя у перенаправления событий, есть свой сервис Windows Event Collector (wecsvc), но Microsoft решила использовать WinRM для пересылки сообщений.

Во всех описанных случаях WinRM использует специальный провайдер (плагин), запущенный под аутентифицированным пользователем, делающим запрос.

По умолчанию WinRM запрещает удаленный доступ на системах Windows 2008 R2 и старше. Но его можно включить командой

winrm quickconfig

Начиная с Windows 2012, WinRM разрешает удаленное подключение для аутентифицированных HTTP запросов.

Однако в обоих случаях, только членам группы локальных Администраторов разрешен удаленный доступ. Даже если вам нужно проверить состояние сервиса или совершить другое непривилегированное действие, необходима аутентификация под пользователем из группы Администраторов. В данном случае это напоминает работу административных общих папок (C$), доступных также только Администраторам.

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

Дальше будет рассмотрена настройка WinRM 2.0 (входящего в Windows 7 и 2008R2 в составе Windows Management Framework 2.0) и WinRM 3.0 (входящего в Windows 8 и 2012 в WMF 3.0).

Основы WinRM

WinRM является сервисом, запущенным под пользователем NT AUTHORITY\NetworkService. Он принимает запросы от клиентов, аутентифицированных через WIA механизмы: Negotiate, Kerberos, NTLM или Schannel (TLS сертификаты). На серверных ОС сервис стартует автоматически, на клиентских системах его нужно запустить вручную.

Информацию о сервисе можно получить, воспользовавшись командой:

C:\sc query winrm

SERVICE_NAME: winrm
        STATE              : 4  RUNNING

C:\sc qc WinRM

[SC] QueryServiceConfig SUCCESS

SERVICE_NAME: winrm
        TYPE               : 20  WIN32_SHARE_PROCESS
        START_TYPE         : 2   AUTO_START
        ERROR_CONTROL      : 1   NORMAL
        BINARY_PATH_NAME   : C:\Windows\System32\svchost.exe -k NetworkService
        LOAD_ORDER_GROUP   :
        TAG                : 0
        DISPLAY_NAME       : Windows Remote Management (WS-Management)
        DEPENDENCIES       : RPCSS
                           : HTTP
        SERVICE_START_NAME : NT AUTHORITY\NetworkService

C:\sc qsidtype winrm

[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: winrm
SERVICE_SID_TYPE:  UNRESTRICTED

Стоит обратить внимание, что сервис работает под собственным пользователем (SID unrestricted), что означает, что можно определять права этому пользователю NT SERVICE\winrm.

Ранее упоминалось, что WinRM использует HTTP протокол, однако напрямую он не взаимодействует с HTTP запросами. Это привело бы к конфликтам с другими веб-сервисами на том же сервере, такими как IIS, SQL Reporting Services или Hyper-V Replication. Поэтому WinRM получает HTTP запросы через системный драйвер HTTP.SYS, также, как и сервисы, указанные выше.

HTTP.SYS это драйвер ядра, который принимает входящий HTTP и HTTPS запрос, обрабатывает некоторые HTTP заголовки (обычно Host Header URL) и перенаправляет запрос к одному из запущенных веб-серверов. HTTP.SYS присутствует в системе независимо от IIS, поэтому когда вы устанавливаете IIS, он регистрирует свои URL в HTTP.SYS. Таким образом, когда HTTP.SYS получает HTTP запрос для одного из зарегистрированных в IIS URL, то он передает его соответствующему рабочему процессу W3SVC пула, если такой запущен, или обращается к Windows Process Activation Service (WAS) для его запуска.

По этой же причине, SQL Server Reporting Services не использует IIS. Он регистрирует свой URL в HTTP.SYS по адресу /Reports и /ReportServer. Другими пользователями HTTP.SYS являются: SSTP VPN сервер (с URL /sra_{BA195980-CD49-458b-9E23-C84EE0ADCD75}) и IPHTTPS сервер (с URL /IPHTTPS).

WinRM регистрирует свой /WSMan URI в HTTP.SYS на нестандартном порту (не 80 TCP).

Посмотреть зарегистрированные в HTTP.SYS URI можно через команду:

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000320000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000340000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 1
            Registered URLs:
                http://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            152

Вывод команды показывает настройку WinRM по умолчанию в системе Windows 2008R2. WinRM регистрирует URI /WSMan и привязывает его к порту TCP 47001. Можно посмотреть, что порт действительно прослушивается:

C:\netstat -ano | findstr :47001

  TCP    0.0.0.0:47001          0.0.0.0:0              LISTENING       4
  TCP    [::]:47001             [::]:0                 LISTENING       4

Означает ли это, что WinRM доступен удаленно по этому порту? Если попробовать открыть этот порт в брандмауэре, то подключиться все равно не получится. HTTP.SYS действительно примет запрос пришедший на этот порт, и перенаправит его к WinRM. WinRM проверит, является ли клиент локальным или удаленным, и если клиент удаленный, то WinRM вернет HTTP ошибку со статусом 404 Not Found. Если запрос пришел от локального клиента, то WinRM его примет.

Как было сказано ранее, Windows 2012 принимает по умолчанию удаленные подключения WinRM (параметр AllowRemoteAccess = true в выводе команды ниже). Для удаленных запросов WinRM использует порт TCP 5985, при этом порт 47001 также продолжает прослушиваться. Помимо автоматического запуска сервиса, в брандмауэре открыт доступ на этот порт.

C:\netsh http show servicestate

Snapshot of HTTP service state (Server Session View):
-----------------------------------------------------

Server session ID: FF00000120000001
    Version: 1.0
    State: Active
    Properties:
        Max bandwidth: 4294967295
        Timeouts:
            Entity body timeout (secs): 120
            Drain entity body timeout (secs): 120
            Request queue timeout (secs): 120
            Idle connection timeout (secs): 120
            Header wait timeout (secs): 120
            Minimum send rate (bytes/sec): 150
    URL groups:
    URL group ID: FE00000140000001
        State: Active
        Request queue name: Request queue is unnamed.
        Properties:
            Max bandwidth: inherited
            Max connections: inherited
            Timeouts:
                Timeout values inherited
            Number of registered URLs: 2
            Registered URLs:
                http://+:5985/WSMAN/
                http://+:47001/WSMAN/

Request queues:
    Request queue name: Request queue is unnamed.
        Version: 1.0
        State: Active
        Request queue 503 verbosity level: Basic
        Max requests: 1000
        Number of active processes attached: 1
        Process IDs:
            960

Небольшое уточнение. Существуют два режима работы WinRM: в режиме Service Hosting Model WinRM использует собственный сервис для принятия запросов. Если же запросов становится слишком много, то могут возникнуть проблемы с доступностью. Поэтому существует другой режим работы — через расширение для IIS. Таким образом WinRM становится виртуальной папкой внутри IIS и управляется через IIS (через отдельный рабочий процесс W3SVC). В таком режиме работает Exchange используя WinRM IIS Extension Hosting Model. При запуске удаленных команд, через HTTP.SYS они попадают в виртуальную папку WinRM в IIS на сервере Exchange, и затем в локальный PowerShell.

После HTTP.SYS конфигурации, настало время посмотреть настройки WinRM. Сделать это можно через команду WINRM. Ниже приведены настройки по умолчанию в системе Windows 2008R2:

C:\winrm get winrm/config

Config
    MaxEnvelopeSizekb = 150
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 15
        EnumerationTimeoutms = 60000
        MaxConnections = 25
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 180000
        MaxConcurrentUsers = 5
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 15
        MaxMemoryPerShellMB = 150
        MaxShellsPerUser = 5

Настройки в Windows 2012 немного отличаются правами в RootSDDL:

Config
    MaxEnvelopeSizekb = 500
    MaxTimeoutms = 60000
    MaxBatchItems = 32000
    MaxProviderRequests = 4294967295
    Client
        NetworkDelayms = 5000
        URLPrefix = wsman
        AllowUnencrypted = false
        Auth
            Basic = true
            Digest = true
            Kerberos = true
            Negotiate = true
            Certificate = true
            CredSSP = false
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        TrustedHosts
    Service
        RootSDDL = O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
        MaxConcurrentOperations = 4294967295
        MaxConcurrentOperationsPerUser = 1500
        EnumerationTimeoutms = 240000
        MaxConnections = 300
        MaxPacketRetrievalTimeSeconds = 120
        AllowUnencrypted = false
        Auth
            Basic = false
            Kerberos = true
            Negotiate = true
            Certificate = false
            CredSSP = false
            CbtHardeningLevel = Relaxed
        DefaultPorts
            HTTP = 5985
            HTTPS = 5986
        IPv4Filter = *
        IPv6Filter = *
        EnableCompatibilityHttpListener = false
        EnableCompatibilityHttpsListener = false
        CertificateThumbprint
        AllowRemoteAccess = true
    Winrs
        AllowRemoteShellAccess = true
        IdleTimeout = 7200000
        MaxConcurrentUsers = 10
        MaxShellRunTime = 2147483647
        MaxProcessesPerShell = 25
        MaxMemoryPerShellMB = 1024
        MaxShellsPerUser = 30

Стоит обратить внимание на настройку портов по умолчанию (DefaultPorts). Она отвечает только за то на каких портах будет прослушивать WinRM при включении удаленного доступа. Но сам удаленный доступ выключен по умолчанию на Windows 2008R2 и включен только для HTTP в Windows 2012.

Пояснение по поводу шифрования. Может показаться, что сообщения в WinRM передаются нешифрованными поскольку включен только HTTP транспорт. Однако это не совсем так, действительно TLS шифрование не применяется, однако сами сообщения все равно шифруются самим WinRM (параметр AllowUnencrypted = false) ключами, полученными из метода аутентификации Windows используемого по умолчанию.

Теперь посмотрим на настройки получателя запросов WinRM:

C:\winrm enumerate winrm/config/listener

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 10.10.0.12

При наличии сертификата с именем машины, можно включить HTTPS доступ к WinRM

winrm create winrm/config/listener?Address=*+Transport=HTTPS @{Port="5986"}

Как упоминалась ранее, WinRM поддерживает плагины для поддержки удаленного доступа к различным приложениям. Посмотреть список зарегистрированных плагинов (DLL) можно командой WINRM, ниже представлен вывод для системы Windows 2008R2:

C:\winrm enumerate winrm/config/plugin -format:pretty

 Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 
 microsoft.servermanager (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.servermanager
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 URI: http://schemas.dmtf.org/wbem/wscim/1/*

Для системы Windows 2012 количество плагинов отличается, также обратите внимание на права в SDDL:

Event Forwarding Plugin (wevtfwd.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/windows/EventLog
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GR;;;ER)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

 microsoft.powershell (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 
 microsoft.powershell.workflow (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell.workflow
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.powershell32 (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.powershell32
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 microsoft.windows.servermanagementworkflows (pwrshplugin.dll)
 URI: http://schemas.microsoft.com/powershell/microsoft.windows.servermanagerworkflows
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 SEL Plugin (wsmselpl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/logrecord/sel
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;S-1-5-80-4059739203-877974739-1245631912-527174227-2996563517)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

 WMI Provider (wsmwmipl.dll)
 URI: http://schemas.microsoft.com/wbem/wsman/1/wmi
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/cim-schema
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/wscim/1/*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)
 URI: http://schemas.dmtf.org/wbem/cim-xml/2/cim-schema/2/*
 SDDL: O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-3411848436-3231049841-1657526397-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

У WMI провайдера в Windows 2012 появился свой SDDL, когда провайдер не имеет своего SDDL он использует RootSDDL, который мы видели ранее в выводе команды winrm get winrm/config.

Что же такое SDDL? Это контроль доступа к WinRM и его провайдерам. SDDL расшифровывается как Security Descriptor Definition Language и представляет собой текстовое описание прав доступа к компонентам системы: файлам и папкам, реестру, WMI и самому WinRM.
При приеме запроса WinRM аутентифицирует пользователя, определяет права к провайдеру, к которому хочет подключиться пользователь, и принимает запрос только в том случае, если SDDL провайдера разрешает данному пользователю подключаться. Если у провайдера не указан собственный SDDL, то используется RootSDDL. Важно понимать, что RootSDDL используется только в том случае, если у провайдера нет своего SDDL.

Рассмотрим структуру SDDL:

O:<владелец>D:P<разрешение>S:P<аудит>

Нас интересует секция, начинающаяся с D:P. Она состоит из одной или нескольких записей (Access Control Entry), заключенных в круглые скобки. Первая буква в секции может быть A — разрешить, или D — запретить. Дальше идет уровень доступа:

Сокращение	Полное название
GA	Generic All (Full Control)
GR	Generic Read
GW	Generic Write
GX	Generic Execute

И последним идет идентификатор пользователя или группы (SID):

Сокращение	Полное название
BA	BUILTIN\Administrators
WD	Everyone
ER	BUILTIN\Event Log Readers
IU	NT AUTHORITY\Interactive
RM	BUILTIN\Remote Management Users
S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000	WinRMRemoteWMIUsers__

Рассмотрим RootSDDL в Windows 2008R2, который применяется к WMI, поскольку у него нет своего SDDL:

O:NSG:BAD:P(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GWGX;;;WD)

Единственна строчка доступа, позволяет (A) полный доступ (GA) локальным администраторам (BA).

В Windows 2012 WMI использует собственную SDDL:

O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;IU)(A;;GA;;;RM)(A;;GA;;;S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-1000)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

Она состоит из четырех записей доступа. Первая запись, такая же как в Windows 2008R2, вторая для интерактивных пользователей. А вот третья позволяет (A) полный доступ (GA) локальной группе удаленных пользователей (RM — Remote Management Users). Четвертая запись использует конкретный SID от группы WinRMRemoteWmiUsers__. Таким образом может показаться, что достаточно пользователя добавить в группу Remote Management Users или WinRMRemoteWMIUsers__ , что позволит удаленно обращаться к WMI. Но это не совсем так.

Попробуем удаленно подключиться к WMI через WinRM под пользователем из этой группы.

winrm get wmicimv2/Win32_Service?Name=spooler –remote:srv-data1

И получим ошибку доступа.
Fault Code Value = s:Receiver Subcode Value = w:InternalError Reason Text = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error.

Detail MSFT_WmiError CIMStatusCode = 2 CIMStatusCodeDescription = null ErrorSource = null ErrorSourceFormat = 0 ErrorType = 0 Message = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error. MessageID = HRESULT 0x80338104 OtherErrorSourceFormat = null OtherErrorType = null OwningEntity = null PerceivedSeverity = 0 ProbableCause = 0 ProbableCauseDescription = null error_Category = 18 error_Code = 2150859012 error_Type = HRESULT error_WindowsErrorMessage = The WS-Management service cannot process the request. The WMI service returned an 'access denied' error.

Error number: -2147023537 0x8007054F An internal error occurred.

Подключение по WinRM произошло, SDDL провайдера WMI разрешил доступ, но сам WMI запретил доступ.

Заглянув в Просмотр событий, можно увидеть следующее:

Event Viewer Application and Service Logs Microsoft Windows Remote Management правая кнопка мыши View - Show Analytic and Debug Logs правая кнопка мыши Analytic - Enable Log

Подключение к WinRM
User ... authenticated successfuly using Kerberos authentication Authorizing the user Updating quota for the user The authorization of the user was done successfully
Подключение к WMI провайдеру в WinRM
SOAP listener receiving Processing client request for operation GET The WinRM service loaded the following plugin: WMI Provider (WsmWmiPl.dll) Entering plugin for operation Get with Resource URI of ... Authorizing the user
И наконец подключение к самому WMI
Plugin reporting data object for operation Get SOAP listener sending Plugin reporting operation complete for Get

Для того чтобы предоставить удаленный доступ к WMI для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users
В настройке прав пользователей в WMI, дать право удаленного подключения (Remote Enable) группе Remote Management Users

Картинка с сайта: gamelton.wordpress.com

Для того чтобы предоставить удаленный доступ к PowerShell для пользователей без прав администратора на Windows 2012 и выше нужно:

Добавить пользователя в группу Remote Management Users

Поддержать блог

Источник

В предыдущей статье я рассказал про установку Windows Server Core, теперь о том, как управлять серверами развернутыми в core. Сервера, с которых будет выполнятся администрирование будем называть source, а сервера которые будем администрировать – target.

Target и source могут входить как в домен, так и в рабочую группу. Source может быть рабочим ПК администратора и работать под управлением Windows 7/8/8.1/10 с установленным пакетом RSAT соответствующей версии.

Рабочий ПК администратора не должен быть единственным местом откуда инфраструктурой можно управлять, его можно дополнить высокодоступным сервером размещенным в Microsoft Azure или Amazon, но их точкой отказа будет Интернет-канал.

Кроме RSAT, управлять серверами можно с помощью PowerShellWebAccess, но это скорее дополнительная возможность на случай недоступность RSAT. О настройке PSWA Вы можете почитать в моей статье “Настройка PowerShell Web Access“.

Перейдем непостредственно к настройке удаленного управления.

Чтобы посмотреть текущее значение удаленного управления на target можно выполнить:

Configure-SMRemoting.exe -get

Для удаленного управления, на целевом сервере должен быть настроен WinRM, его текущую конфигурацию можно запросить так:

winrm get winrm/config

Обратите внимание, Device Manager недоступен для удаленного управления в любых сценариях:

А все дело в том, что Microsoft “выпилила” удаленный доступ к PnP из соображений безопасности – http://support.microsoft.com/kb/2781106/en-us

Вместо этого, предлагается использовать PowerShell – http://blogs.technet.com/b/wincat/archive/2012/09/06/device-management-powershell-cmdlets-sample-an-introduction.aspx

Если Вам все-таки нужнен полноценный Device manager, вам придется установить хотя бы minimal GUI (о том, как это сделать написано выше).

Создадим и распространим на source и на target групповую политику, которой включим правила Firewall Remote Event Log Management, Remote Service Management, Windows Firewall Remote Management, Remote Volume Management:

В кажом правиле можно указать с каких сетей (лучше выделить админов в отдельную сеть, чем указывать список IP админских машин) разрешен этот трафик, на каких профилях и т.д. Хорошим вариантом будет использование IPSec.

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

Если вас интересует управление Windows Firewall с помощью PowerShell рекомендую эту статью.

Теперь рассмотрим сценарий когда source находится в домене, а target в рабочей группе. В начале нужно убедится что source и target корректно разрешают fqdn и netbios имена друг друга, если нет – нужно поправить это в DNS. Как и в большинстве случаев, предпочтительно использование fqdn имен.

После этого, на source нужно добавить имя target в TrustedHosts:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value %target_fqdn% -Concatenate -Force

После этого, можно будет использовать PowerShell remote sessions.

Вы можете посмотреть содержимое TrustedHosts:

Get-Item -Path WSMan:\localhost\Client\TrustedHosts | fl Name, Value

.. и очистить его содержимое при необходимости:

Clear-Item -Path WSMan:\localhost\Client\TrustedHosts

Теперь доступ к target есть по PowerShell, bus воспользуемся им чтобы включить на target таке правила firewall:

Set-NetFirewallRule -DisplayGroup "Windows Remote Management" -Enabled True -RemoteAddress "192.168.1.0/24"

Set-NetFirewallRule -DisplayGroup "Remote Event Log Management" -Enabled True -RemoteAddress "192.168.1.0/24"

Set-NetFirewallRule -DisplayGroup "Remote Service Management" -Enabled True -RemoteAddress "192.168.1.0/24"

Set-NetFirewallRule -DisplayGroup "Windows Firewall Remote Management" -Enabled True -RemoteAddress "192.168.1.0/24"

Set-NetFirewallRule -DisplayGroup "Remote Volume Management" -Enabled True -RemoteAddress "192.168.1.0/24"

Set-NetFirewallRule -DisplayGroup "File and Printer Sharing" -Enabled True -RemoteAddress "192.168.1.0/24"

Чтобы снять ограничения которые накладывает UAC на target нужно выполнить:

New-ItemProperty -Name LocalAccountTokenFilterPolicy -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -propertyType DWord -value 1

Теперь можно добавить target в ServerManager на source и, а затем нужно выбрать опцию “Manage As..” и ввести учетные данные администратора target

Последний сценарий – когда source находится в рабочей группе, а target в домене – аналогичен предыдущему, и не требует дополнительных комментариев.

Если вам нужно управлять старыми версиями Windows Server, это сделать можно, 2012R2 и 2012 добавляются без проблем, а вот на 2008R2 и 2008 нужно будет поставить WMF 3.0 + Hotfix + выполнить:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned
Enable-PSremoting -Force

После этого (само собой нужно включить правила firewall, о которых выше) серверами 2008 и 2008R2 можно будет ограниченно управлять, но нельзя, например, устанавливать роли и фичи.

Вообще, запускать скрипты без цифровой подписи в рабочей инфраструктуре не очень хорошо, поэтому есть смысл поставить политику AllSigned:

Set-ExecutionPolicy AllSigned

Если серверов больше чем несколько, есть смысл сделать это через групповую политику (Administrative Templates\Windows Components\Windows PowerShell):

Вот еще наглядный пример, почему большинство задач желательно выполнять через Remote Access:

Для подписи скриптов я буду использовать Comodo Code Signing certificate:

Для подписывания используется командлет Set-AuthenticodeSignature :

Подписанный скрипт будет выглядеть следующим образом:

При запуске необходимо будет принять решение по издателю, я обычно использую Run once – работая с большим количеством скриптов от коллег это становится необходимостью.

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

Добавление Windows Sever 2003 я не описываю т.к. во-первых в нем потолок PS 2.0, во-вторых его поддержка заканчивается в обозримом будущем, а в-третьих за годы его эксплуатации процессы управления наверняка налажены и менять их нецелесообразно.

Новый Server Manager сделал большой шаг перед на пути к выполнению массовых операций, но на практике PowerShell более функционален.

Команду на удаленном компьютере можно выполнить указав в Invoke-Command -ComputerName (по-умолчанию Invoke-Command добавляется ко всем командлетам выполняемым локально):

Если команду нужно выполнить на нескольких сервера, откроем на них сессии и выполним операции на каждом параллельно:

Можете посмотреть разницу в скорости выполнения командлетов:

Подробнее про управление:

http://technet.microsoft.com/en-us/library/hh831456.aspx

… старыми версиями –

http://blogs.technet.com/b/servermanager/archive/2012/09/10/managing-downlevel-windows-based-servers-from-server-manager-in-windows-server-2012.aspx

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.

Источник

Бывают случаи, когда требуется выполнить какую-либо команду на сервере локально (например, сконфигурировать iSCSI Initiator). Подключаться для этого через Remote Desktop и запускать cmd — неудобно, использовать Telnet — небезопасно, ставить на сервер демона ssh — не… хочется…

Специально для таких

запущенных

случаев, Microsoft, начиная с Windows Server 2003 R2, снабдила администраторов новым средством управления — Windows Remote Management (WinRM), позволяющим удаленно выполнять команды, используя стандартные средства ОС, и обеспечивая при этом должный уровень безопасности.

Вам даже не придется устанавливать дополнительных программ и компонентов — все, что называется, включено:

Настройка WinRM
В качестве примера я рассмотрю процесс настройки WinRM на Windows Server 2008. Эта процедура никак не отличается от настройки WinRM, например, на Windows Vista или Hyper-V Server.

Проще всего WinRM настроить можно, используя режим быстрой конфигурации, набрав в CMD:
winrm quickconfig
и ответив утвердительно (‘y‘) на вопрос о создании нового объекта-listener’а, прослушающего порт TCP 80, и использующего протокол HTTP для коммуникаций между клиентом и сервером.

И все, сервером можно управлять удаленно, используя команду:
winrs -r:<ИМЯ_СЕРВЕРА> <КОМАНДА>
,где <ИМЯ_СЕРВЕРА> — имя или IP адрес сервера, к которому осуществляется подключение;
<КОМАНДА> — удаленная команда, которую требуется выполнить.

Если клиент и сервер не являются членами одного домена, вам потребуется дополнительно указать имя пользователя из-под которого будет запускаться команда и его пароль:
winrs -r:<ИМЯ_СЕРВЕРА> -u:<ИМЯ_ПОЛЬЗОВАТЕЛЯ> -p:<ПАРОЛЬ> <КОМАНДА>

, а заодно, как советует появившееся сообщение, добавить сервер в список доверенных узлов, либо использовать более надежный протокол для коммуникации (HTTPS).

Для добавления узла в список надежных, выполните на клиенте, с которого планируете подключаться:
winrm set winrm/config/client @{TrustedHosts=»<ИМЯ_УЗЛА1>[,<ИМЯ_УЗЛА2>]»}

После настройки вы можете получить информацию о существующих listener’ах с помощью команды:
winrm enumerate winrm/config/listener

Удалить существующий listener можно следующим образом:
winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Настройка WinRM с использованием HTTPS
В ряде случаев вам может потребоваться создать надежный канал для безопасной пересылки команд между клиентом и сервером. Для этого можно использовать HTTPS.

Однако, для создания listener’а с поддержкой HTTPS вам потребуется цифровой сертификат, который можно запросить у доверенного Центра Сертификации, либо воспользоваться различными утилитами по созданию самоподписанных (самозаверенных) сертификатов, например, Makecert, входящей в состав Windows SDK. Скачать Makecert отдельно можно отсюда.

Для создания самоподписанного серитификата выполните следующую команду:
makecert -a sha1 -r -pe -n «CN=<ИМЯ_СЕРВЕРА>» -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 -m 12 <ФАЙЛ_СЕРТИФИКАТА>
, где <ИМЯ_СЕРВЕРА> соответствует имени, которое будет использовать клиент при подключении к серверу;
<ФАЙЛ_СЕРТИФИКАТА> — путь к файлу, куда будет сохранен сертификат с открытым ключем.

Сертификат с закрытым ключем будет создан и помещен в хранилище сертификатов локального компьютера. Добавьте его к доверенным корневым сертификатам:
certutil -addstore root cert.cer

Теперь просмотрите хранилище сертификатов, найдите там требуемый сертификат и запишите его Thumbprint (Cert Hash):
certutil -store my

Наконец, можно приступать к созданию HTTPS listener. Введите команду:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=»<ИМЯ_УЗЛА>«;CertificateThumbprint=»<ХЭШ_СЕРТИФИКАТА>«;Port=»<ПОРТ>«}
,где <ИМЯ_УЗЛА> — имя, которое указывается при обращении к серверу
<ХЭШ_СЕРТИФИКАТА> — Thumbprint, который вы узнали на предыдущем шаге (без пробелов).
<ПОРТ> — порт, на который будет подключаться клиент (TCP 443 по-умолчанию).

Если на сервере включен брандмауэр Windows, не забудьте добавить правило:
netsh advfirewall firewall add rule name=»allow WinRM on 4443″ protocol=TCP dir=in localport=4443 action=allow

При использовании самоподписанных сертификатов, вам придется добавить его к доверенным корневым сертификатам на клиенте.

После выполнения всех шагов, вы, наконец, получите возможность удаленного выполнения команд:

Обратите внимание, что в случае использования нестандартного порта, вам потребуется специально его указать. Чтобы не делать этого каждый раз, вы можете изменить стандартный порт, который клиент использует при подключении по HTTPS, с помощью команды:
winrm set winrm/config/client/DefaultPorts @{HTTPS=»4443″}

Заключение
Как видите, настройка Windows Remote Management достаточно проста в классических ситуациях (с использованием единого домена и CA), однако, при небольшом отклонении от данного шаблона могут обнаружиться несколько подводных камней. К WinRM привыкнуть можно достаточно быстро, особенно, если вы частенько пользуетесь консолью для настройки системы.

При подготовке статьи использовались следующие материалы:

How to enable Windows Remote Shell
Средство создания сертификатов (Makecert.exe)
How to use makecert.exe to create a self-signed test certificate that can be used with IIS for SSL

Источник