Знакомство с active directory rights management services для exchange, часть 1

Настройка и тестирование управления правами на доступ к данным

Для настройки функций IRM в Exchange 2013 необходимо использовать командную консоль Exchange. Чтобы настроить отдельные функции управления правами на доступ к данным, используйте командлет Set-IRMConfiguration. Вы можете включить или отключить IRM для внутренних сообщений, расшифровки транспорта, расшифровки отчетов журнала, поиска Exchange и Outlook Web App. Дополнительные сведения о настройке функций IRM см. в разделе Процедуры управления правами на доступ к данным.

После настройки сервера Exchange 2013 можно использовать командлет Test-IRMConfiguration для выполнения комплексных тестов развертывания IRM. Эти тесты полезны для проверки функциональности IRM сразу после начальной настройки IRM и на постоянной основе. Командлет выполняет следующие тесты:

Проверяет конфигурацию IRM для организации Exchange 2013.
Проверяет сервер службы AD RMS на предмет сведений о версии и исправлениях.
Проверяет, можно ли активировать сервер Exchange Server для RMS, получая сертификат учетной записи прав (RAC) и сертификат лицензиара клиента.
Получает шаблоны политики прав службы AD RMS с сервера службы AD RMS.
Проверяет способность указанного отправителя отправлять сообщения, защищенные службой IRM.
Получает для указанного получателя лицензию на использование суперпользователя.
Получает для указанного получателя предварительную лицензию.

Функции инфраструктуры

Azure RMS предоставляет следующие возможности для поддержки ИТ-отделов и инфраструктурных организаций:

Примечание

Организации всегда могут прекратить использование службы Azure Rights Management без потери доступа к содержимому, которое ранее было защищено с помощью Azure Rights Management.

Дополнительные сведения см. в статье » Списание и деактивация Службы управления правами Azure».

Создание простых и гибких политик

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

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

Настройте политики маркировки на портале соответствия Требованиям Microsoft Purview. Дополнительные сведения см. в .

Простая активация

Для новых подписок активация проводится автоматически. В существующих подписках для включения службы Rights Management достаточно нескольких щелчков мышью на портале управления или двух команд PowerShell.

Аудит и мониторинг служб

Проводите аудит и контролируйте использование защищенных файлов даже после того, как они покидают пределы организации.

Например, если сотрудник компании Contoso, Ltd участвует в совместном проекте с тремя сотрудниками компании Fabrikam, Inc, он может отправить им документ, на который установлена защита и который разрешено только читать.

Функция аудита системы RMS Azure может предоставлять следующую информацию:

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

Администраторы AIP могут отслеживать использование документов и отзывать доступ к файлам Office. При необходимости пользователи могут отзывать доступ к своим защищенным документам.

Возможность масштабирования в пределах организации

Azure Rights Management функционирует как облачная служба, которой присуща эластичность Azure (возможности вертикального увеличения и уменьшения масштаба), поэтому вам не нужно подготавливать или развертывать дополнительные локальные серверы.

ИТ-контроль над данными

Организации могут использовать возможности ИТ-управления, в том числе следующие:

Компонент	Описание
Управление ключом клиента	Используйте решения для управления ключом клиента, такие как создание собственных ключей (BYOK) и двойное шифрование ключей (DKE). Дополнительные сведения см. в следующих статьях:- Планирование и реализация ключа клиента AIP — DKE в документации по Microsoft 365.
Аудит и ведение журнала использования	Используйте функции аудита и ведения журнала использования для анализа бизнес-информации, отслеживания нарушений и проведения расследования при утечке информации.
Делегирование доступа	Делегированный доступ с использованием функции суперпользователя гарантирует, что ИТ-отдел всегда может получить доступ к защищенному содержимому, даже если документ был защищен сотрудником, который уже не работает в вашей организации. Для сравнения решения однорангового шифрования рискуют потерять доступ к корпоративным данным.
Синхронизация Active Directory	Синхронизация для поддержки стандартных удостоверений локальных учетных записей Active Directory, с помощью решения для управления гибридными удостоверениями, такого как Azure AD Connect.
Единый вход	Поддержка единого входа в облако без репликации паролей с помощью AD FS.
Переход с AD RMS	Если вы развернули службы Active Directory Rights Management (AD RMS), вы можете перейти на использование Azure Rights Management без потери доступа к данным, которые ранее были защищены с помощью AD RMS.

Требования к оборудованию и программному обеспечению

Службы AD RMS можно использовать на компьютерах с системой Windows Server 2008 R2. При установке роли сервера AD RMS устанавливаются необходимые службы, в частности службы IIS. AD RMS также использует лес доменных служб Active Directory и базу данных, например Microsoft SQL Server, которая может быть расположена либо на одном сервере с AD RMS, либо на удаленном сервере.

В приведенной ниже таблице представлены рекомендации и минимальные требования к оборудованию для запуска серверов Windows Server 2008 R2 с ролью сервера AD RMS.

Требование	Рекомендация
Один процессор Pentium 4 с частотой 3 ГГц или выше	Два процессора Pentium 4 с частотой 3 ГГц или выше
512 МБ ОЗУ	1024 МБ ОЗУ
40 ГБ свободного места на жестком диске	80 ГБ свободного места на жестком диске

Примечание
Для варианта установки компонентов сервера в Windows Server 2008 и Windows Server 2008 для компьютеров на базе процессоров Itanium доступен ограниченный набор ролей сервера.

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

В приведенной ниже таблице представлены минимальные требования к программному обеспечению для запуска серверов Windows Server 2008 R2 с ролью сервера AD RMS. Некоторые требования можно выполнить, включив определенные функции в операционной системе. При установке роли сервера AD RMS выполняется соответствующая настройка этих функций, если они не были настроены ранее.

Программное обеспечение	Требование
Операционная система	Windows Server 2008 R2
Файловая система	Рекомендуется использовать файловую систему NTFS
Обмен сообщениями	Служба очереди сообщений
Веб-службы	Службы IIS. Необходимо включить ASP.NET.
Active Directory или доменные службы Active Directory	AD RMS необходимо установить в домене Active Directory, в котором расположены контроллеры домена с системой Windows Server 2000 с пакетом обновления 3 (SP3), Windows Server 2003, Windows Server 2008 или Windows Server 2008 R2. Все пользователи и группы, использующие AD RMS для получения лицензий и публикации содержимого, должны иметь адрес электронной почты, настроенный в Active Directory.
Сервер баз данных	Для работы AD RMS требуется сервер баз данных, например Microsoft SQL Server 2005 или Microsoft SQL Server 2008, и поддержка хранимых процедур. Роль сервера AD RMS на компьютере с Windows Server 2008 R2 не поддерживает Microsoft SQL Server 2000.

Клиент с поддержкой AD RMS должен включать браузер или приложение (такое как Microsoft Word, Outlook или PowerPoint из пакета Microsoft Office 2007) с поддержкой AD RMS. Клиент с поддержкой службы AD RMS должен включать браузер или приложение (такое как Microsoft Word, Outlook или PowerPoint из пакета Microsoft Office 2007) с поддержкой службы AD RMS. Для создания содержимого, защищенного правами, в этих приложениях необходим пакет Microsoft Office Корпоративный 2007, Профессиональный плюс 2007 или Максимум 2007.
Для обеспечения дополнительной защиты AD RMS можно использовать вместе с другими технологиями, например смарт-картами.

Системы Windows 7 и Windows Vista включают клиент AD RMS по умолчанию, однако в других клиентских операционных системах клиент службы управления правами необходимо устанавливать отдельно. Клиент службы управления правами с пакетом обновления 2 (SP2), который можно загрузить с веб-сайта центра загрузки Майкрософт, совместим с клиентскими операционными системами, выпущенными до Windows Vista и Windows Server 2008.

Дополнительные сведения об оборудовании и программном обеспечении, необходимом для работы AD RMS, см. в разделе, посвященном подготовке к установке службы управления правами Active Directory, в библиотеке технической документации по Windows Server 2008 (https://go.microsoft.com/fwlink/?LinkId=84733) (на английском языке).

Установка клиента RMS

Клиент RMS содержится в исполняемом файле установщика с именем setup_msipc_arch>.exe<, где <арка> — x86 (для 32-разрядных клиентских компьютеров) или x64 (для 64-разрядных клиентских компьютеров). 64-разрядный пакет установщика (x64) устанавливает как 32-разрядный исполняемый файл среды выполнения для совместимости с 32-разрядными приложениями, работающими на 64-разрядной установке операционной системы, так и 64-разрядным исполняемым файлом среды выполнения для поддержки встроенных 64-разрядных приложений. 32-разрядный (x86) установщик не запускается в 64-разрядной версии Windows.

Примечание

Вам потребуется более высокий уровень привилегий, чтобы установить клиент RMS, например права члена группы администраторов на локальном компьютере.

Клиент RMS можно установить с помощью любого из следующих методов установки:

Автоматический режим С помощью параметра командной строки /quiet можно автоматически установить клиент RMS на компьютерах. В следующем примере показана автоматическая установка клиента RMS на 64-разрядном клиентском компьютере:
Интерактивный режим Кроме того, можно установить клиент RMS с помощью программы установки на основе графического пользовательского интерфейса, предоставляемой мастером установки клиента RMS. Чтобы установить интерактивно, дважды щелкните пакет установщика клиента RMS (setup_msipc_<архива>.exe) в папке, в которую он был скопирован или скачан на локальном компьютере.

Какие атаки может предотвратить Active Directory?

Как видите, Active Directory — это центральный инструмент для управления рядом функций безопасности бизнеса. Существует ряд распространенных атак, которые могут помочь предотвратить хорошие практики Active Directory:

Атака передачи хэша: эта атака существует уже более десяти лет. Несмотря на то, что данный тип один из самых известных, ему все же удалось нанести значительный ущерб. Используя атаку передачи хэша, злоумышленник извлекает хешированные (более короткие значения фиксированной длины) учетные данные пользователя, чтобы перейти на удаленный сервер. Проще говоря, если злоумышленник добьется успеха с помощью тактики передачи хэша, в вашем процессе аутентификации есть слабость.
Brute-force: простая, но эффективная атака методом «грубой силы», включает в себя перебор случайных имен пользователей и паролей в быстрой последовательности, чтобы получить доступ к вашей системе. Каковы шансы хакера на успех с помощью этого метода? Больше, чем ты думаешь. Злоумышленники, практикующие грубую силу, используют усовершенствованное программирование для создания триллионов комбинаций за считанные секунды.

Инструменты управления Active Directory

Управлять сервером Windows можно как непосредственно сидя за перед ним, так и удалённо. Удалённо сервером можно управлять как с другого сервера, так и с помощью рабочих станций, но для того, чтобы рабочие станции могли использоваться для управления сервером, могут потребоваться дополнительные действия по установке компонентов.

Управление сервером осуществляется через:

Оснастки в Microsoft Management Console (MMC) (Консоли управления Microsoft). На сервере эти инструменты доступны по умолчанию, а на рабочих станциях для получения этой оснастки необходимо предварительно установить средства удалённого администрирования. Сами оснастки перечислены чуть ниже.
Active Directory Administrative Center (Центр администрирования Active Directory), dsac.exe, как показано на скриншоте ниже, является универсальным местом, которое используется для управления службами каталогов Windows Server.
Windows Admin Center. Как на сервере, так и на рабочих станциях необходимо установить сам Windows Admin Center, а затем плагин для Active Directory.
Active Directory Module for Windows PowerShell (Модуль Active Directory для Windows PowerShell). На серверах Windows данный модуль устанавливается автоматически во время развёртывания Active Directory Domain Services. На рабочих станциях Windows требуется его отдельная установка.

Имеются следующие оснастки в Microsoft Management Console (MMC) (консоли управления Microsoft), mmc.exe:

Active Directory Users and Computers (Пользователи и компьютеры Active Directory), dsa.msc, используется для управления пользователями, компьютерами, группами, организационными единицами и другими объектами Active Directory.
Active Directory Domains and Trusts (Домены и доверие Active Directory), domain.msc, используется для управления доменами, доверительными отношениями между доменами.
Active Directory Sites and Services (Сайты и службы Active Directory), dssite.msc, используются для управления репликацией и службами между сайтами.

Всего будет рассмотрено четыре набора инструментов для управления Active Directory. Может показаться, что столько вариантов это избыточно. Особенно если учесть, что Центр администрирования Active Directory и Windows Admin Center это просто графические обёртки для PowerShell, который также доступен в виде Модуля Active Directory для Windows PowerShell. Тем не менее, разница между ними заключается не только в интерфейсе инструментов, между ними есть более значимая практическая разница.

Инструмент	Позволяет управлять с компьютера, не являющегося частью домена	Подходит для локальной настройки Windows Server Core
Оснастки в Microsoft Management Console (MMC)	Нет	Нет
Active Directory Administrative Center	Нет	Нет
Windows Admin Center	Да	Нет
Active Directory Module for Windows PowerShell	Да	Да

Одинаковые характеристики в таблице имеют только два инструмента, но они различаются интерфейсом.

Разница между группой безопасности и группой рассылки

AD состоит из двух основных групп — групп рассылки и групп безопасности.

Группы рассылки — создаются в первую очередь для распространения электронных писем. Они полезны для таких приложений, как Microsoft Exchange или Outlook, и, как правило, позволяют легко добавлять и удалять контакты из одного из этих списков. Нельзя использовать группу рассылки для фильтрации параметров групповой политики, группа не предназначена для работы с предоставлением доступа на ресурсы. По возможности, пользователей следует назначать в группы рассылки, а не в группы безопасности, поскольку членство в слишком большом количестве групп безопасности может привести к замедлению входа в систему.

Группы безопасности — позволяют ИТ-отделу управлять доступом к общим ресурсам, контролируя доступ пользователей и компьютеров. Группы безопасности можно использовать для назначения прав безопасности в сети AD. (Эти группы также можно использовать для рассылки электронной почты.) Каждой группе безопасности назначается набор прав пользователей, определяющих их возможности в лесу. Например, некоторые группы могут восстанавливать файлы, а другие нет.

Эти группы обеспечивают ИТ-контроль над параметрами групповой политики, что означает, что разрешения могут быть изменены на нескольких компьютерах. Разрешения отличаются от прав — они применяются к общим ресурсам в домене. Некоторые группы могут иметь больше доступа, чем другие, когда дело доходит до общих ресурсов.

Состав службы управления правами

Здесь все достаточно просто. Есть два ключевых компонента:

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

Служба управления правами использует формат сертификатов XrML (eXtensible rights Markup Language), отличный от распространенного стандарта X509v3. Стандарт XrML является расширением языка XML. Дополнительные сведения можно найти на сайте http://www.xrml.org/. Используется несколько видов сертификатов.

Таблица 1. Типы сертификатов AD RMS

Сертификат	Префикс
компьютера	CERT-Machine.drm
учетной записи службы управления правами	GIC-<имя пользователя>
лицензиара клиента	CLC-<имя пользователя>
лицензии на использование	EUL-<имя пользователя>
Сертификат	Префикс

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

Понятие сертификата в службе управления правами точно такое же, как и в службе сертификации. Есть пара ключей – открытый и закрытый, которые находятся в цифровом сертификате. Сертификат находится в хранилище, доступ к которому защищается клиентом с помощью шифрования AES.

Можно посмотреть, как выглядят цифровые сертификаты, они находятся для Windows XP — %USERPROFILE%\Local Settings\Application Data\Microsoft\DRM, для Windows Vista и выше — %USERPROFILE%\AppData\Local\Microsoft\DRM.

Каждый пользователь должен иметь заполненное поле электронной почты в домене Active Directory.

Рисунок 1. Рабочий процесс использования AD RMS.

Рассмотрим на примере, как работает AD RMS:

Автор создает документ и получает сертификат учетной записи пользователя, а также сертификат лицензиара клиента (выдается на компьютер) в первый раз, когда пытается защитить документ с помощью службы управления правами с помощью приложения.
С использованием приложения (например, Microsoft Word), поддерживающего клиента AD RMS, автор создает документ, и указывает, какие права или состояния будут использоваться для этого файла.
Приложение шифрует файл симметричным ключом, которым шифруется публичный ключ автора документа. Ключ вставляется в публикуемую лицензию и связывается с файлом. Только автор может использовать эту лицензию для расшифровки документа.
Автор выкладывает файл, например, на внутренний ресурс компании.
Пользователь, который желает получить доступ к содержимому документа, открывает его с использованием приложения поддерживающего AD RMS. Если пользователь не имеет сертификата своей учетной записи, расшифровка будет невозможна. В таком случае происходит процесс выдачи сертификата учетной записи пользователя, а также сертификата лицензиара клиента, так как описано в пункте 1.
Приложение посылает запрос кластеру AD RMS. Запрос включает сертификат учетной записи получателя (содержащий публичный ключ получателя) и публичную лицензию использования (содержит симметричный ключ для расшифровки файла).
Кластер службы управления правами проверяет запрос и создает лицензию на использование. Во время данного процесса сервер расшифровывает симметричный ключ с использованием закрытого ключа кластера, перешифровывает симметричный ключ с использованием публичного ключа получателя и добавляет шифрованный симметричный ключ в лицензию. Операция проходит успешно только в том случае, если получатель имеет права на данный документ.
Когда подтверждается использование, кластер возвращает лицензию на использование на компьютер получателя.
После получения лицензии на использование, приложение проверяет ее и сертификат учетной записи, делает проверку сертификатов. Если сертификаты действительны и не отозваны, а также не фиксируется состояния блокирующего доступ к документу (например, дата использования документа) приложение расшифровывает документ и возвращает его пользователю, в соответствии с правами, указанными в документе.

IRM в Exchange 2013

Сервер Exchange 2013 предоставляет функции управления правами на доступ к данным (IRM) для обеспечения постоянной защиты сообщений и вложений. В службе IRM используется службы Active Directory Rights Management (AD RMS), обеспечивающие защиту данных в Windows Server 2008 и более поздних версий. Использование функций управления правами на доступ к данным в системе Exchange 2013 позволяет организации и ее пользователям управлять правами получателей на доступ к сообщениям электронной почты. C помощью IRM можно разрешить или запретить получателю пересылать сообщение другим получателям, печатать сообщение или вложения, а также копировать текст сообщения или вложений. Защита IRM может применяться пользователями приложений Microsoft Outlook или Microsoft Office Outlook Web App, или она может основываться на политиках обмена сообщениями организации и применяться с помощью правил защиты транспорта или правил защиты Outlook. В отличие от других решений шифрования электронной почты, IRM также позволяет организации расшифровывать содержимое в целях обеспечения соблюдения требований политики.

Для сертификации компьютеров и пользователей и защиты содержимого служба AD RMS использует сертификаты и лицензии на основе eXtensible Rights Markup Language (XrML). Когда содержимое, документ или сообщение, защищено с помощью службы AD RMS, к нему прикрепляется лицензия XrML, содержащая права уполномоченных пользователей на содержимое. Чтобы получить доступ к содержимому, защищенному службой IRM, приложения с поддержкой AD RMS должны получить лицензию на использование для уполномоченных пользователей из кластера AD RMS.

Приложения, используемые для создания содержимого, должны иметь поддержку службы RMS для обеспечения постоянной защиты содержимого с помощью AD RMS. Приложения Microsoft Office, такие как Word, Excel, PowerPoint и Outlook имеют поддержку RMS и могут использоваться для создания и потребления защищенного содержимого.

Служба IRM помогает:

предотвратить пересылку, изменение, печать, отправку по факсу, сохранение и копирование уполномоченными получателями содержимого, защищенного службой IRM;
обеспечить для вложений в поддерживаемых форматах такой же уровень защиты, что и для сообщения;
поддерживать функцию управления сроком действия сообщений и вложений с защитой IRM, которая не позволяет просматривать их по истечении указанного периода;
предотвратить копирование содержимого, защищенного службой IRM, с помощью средства «Ножницы» в Windows.

Однако служба IRM не может предотвратить копирование сведений следующими методами:

создание снимков экрана с помощью программ сторонних производителей;
фотографирование содержимого, защищенного службой IRM, с экрана с помощью таких устройств, как камеры и фотоаппараты;
запоминание данных пользователем или их запись вручную.

Повторное распространение клиента RMS

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

Рекомендация. Внедрите установщик клиента RMS в установку приложения и запускайте его в автоматическом режиме (параметр /quiet, который описывается в следующем разделе).
Сделайте клиент RMS необходимым компонентом для работы приложения. В этом случае необходимо предоставить пользователям дополнительные инструкции для получения и установки клиента на компьютер, прежде чем они смогут использовать приложение.

Шаг 1. Настройка колонки пользователей и групп

Каталог ресурсов имеет один или несколько ресурсов для совместного использования. На этом шаге вы создадите группу с именем Маркетинговые ресурсы в каталоге банка Woodgrove Bank, которая будет целевым ресурсом для управления правами. Можно также настроить внутреннюю запрашивающую сторону.

Требуемая роль: глобальный администратор или администратор пользователей.

Войдите на портал Azure как глобальный администратор или администратор пользователей.
В области навигации слева выберите Azure Active Directory.

Создайте двух пользователей. Используйте указанные ниже или другие имена.

Имя	Роль каталога
Admin1	Глобальный администратор или администратор пользователей. Этим пользователем может быть пользователь, под именем которого вы сейчас вошли.
Requestor1	Пользователь

Создайте группу безопасности Azure AD с именем Маркетинговые ресурсы и типом членства Назначено. Эта группа будет целевым ресурсом для управления правами. Для начала работы группа должна быть пустой.

Является ли мой компьютер частью домена?

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

Вы можете быстро проверить, является ли ваш компьютер частью домена. Откройте приложение «Параметры» (Win+x).

Нажмите «Система».

Перейдите на вкладку «О программе» и найдите пункт «Переименовать этот ПК (для опытных пользователей)»:

Если вы видите «Домен»: за которым следует имя домена, ваш компьютер присоединён к домену.

Если вы видите «Рабочая группа»: за которым следует имя рабочей группы, ваш компьютер присоединён к рабочей группе, а не к домену.

В англоязычной версии это соответственно «Settings» → «System» → «About» → «Rename this PC (advanced)».

Используя командную строку (PowerShell) вы также можете узнать, прикреплён ли компьютер к домену или входит в рабочую группу.

Для этого выполните команду (можно за один раз всё скопировать-вставить в окно терминала):

$ComputerSystem = Get-CimInstance -Class Win32_ComputerSystem;
$ComputerName = $ComputerSystem.DNSHostName
if ($ComputerName -eq $null) {
    $ComputerName = $ComputerSystem.Name
}

$fqdn = (::GetHostByName($ComputerName)).HostName

$ComputerSystem | Microsoft.PowerShell.Utility\Select-Object `
@{ Name = "ComputerName"; Expression = { $ComputerName }},
@{ Name = "Domain"; Expression = { if ($_.PartOfDomain) { $_.Domain } else { $null } }},
@{ Name = "DomainJoined"; Expression = { $_.PartOfDomain }},
@{ Name = "FullComputerName"; Expression = { $fqdn }},
@{ Name = "Workgroup"; Expression = { if ($_.PartOfDomain) { $null } else { $_.Workgroup } }}

Подробности смотрите в статье: Как в PowerShell узнать, прикреплён ли компьютер к домену или к рабочей группе