Узнать список доменных пользователей с админскими правами

[Ololosh]

День добрый знатоки.

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

нашёл некий скрипт:


$ExportFile = "C:\папка_для_лога\remotes.txt"
$SearchBase = "OU=ALL_Users,DC=contoso,DC=com"
$AdminList = @{}
$ToCSV = ""

function Get-LocalAdmin {
param ($strcomputer)
try {
$users = Gwmi win32_groupuser –computer $strcomputer -ErrorAction Stop
} catch {
Write-Host $strcomputer
}
if ($users) {
$admins = $users |? { ($_.groupcomponent –match 'Администраторы') -or ($_.groupcomponent –match 'Administrators') }
$return = $admins |% {
$_.partcomponent –match “.+Domain\=(.+)\,Name\=(.+)$” > $nul
$matches[1].trim('"') + “\” + $matches[2].trim('"')
}
return $return
}
}

$ServersList = Get-ADComputer -SearchBase $SearchBase -Filter * -Properties OperatingSystem | Where { $_.OperatingSystem -match "Windows" }
$ServersList | Select-Object Name | ForEach-Object {
$UserList = Get-LocalAdmin $_.Name
if ($UserList) {
$AdminList[$_.Name] = $UserList
}
}

$AdminList.Keys | % {
$ServerName = $_
$AdminUsers = $AdminList[$ServerName]
$ToCSV += "$ServerName;$AdminUsers`r`n"
}

if (Test-Path $ExportFile) {
Remove-Item $ExportFile
}

$ToCSV >> $ExportFile



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

Как можно добавить проверку на группу локальных админов, а также добавить проверку локальных юзеров на админские права?

[DJ Mogarych]

Примерно так:

foreach ($comp in (Get-ADComputer -filter 'enabled -eq "True"' -Properties OperatingSystem |? OperatingSystem -match "Windows").name) {
$comp
(Gwmi win32_groupuser -ComputerName $comp |? {$_.groupcomponent -match "Администраторы|Administrators" -and $_.partcomponent -notmatch "Administrator|Администратор|Администраторы домена|Domain admins"}).partcomponent -replace "^.*=" -replace '"'
""
}

[Ololosh]

что-то ругается что прав нету:


Gwmi : Отказано в доступе. (Исключение из HRESULT: 0x80070005 (E_ACCESSDENIED))
строка:34 знак:2
+ (Gwmi win32_groupuser -ComputerName $comp |? {$_.groupcomponent -matc ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Get-WmiObject], UnauthorizedA
ccessException
+ FullyQualifiedErrorId : System.UnauthorizedAccessException,Microsoft.Pow
erShell.Commands.GetWmiObjectCommand

[DJ Mogarych]

Ну так надо запускать от того, у кого есть права на все компьютеры, обычно это администратор домена.

[Elven]

обычно это администратор домена. »
DJ Mogarych, как раз если так - то это не очень хорошо (вроде по бестпрактис весьма хорошо когда доменный администратор не имеет прав локального админа на не контроллерах, лучше для этого делать отдельную группу).
Ololosh, для этого можно завести отдельную учетку, запретить ей вход как локальный так и по RDP и запустить от ее имени, если так уж хочется запускать именно вручную, но это не оптимальный вариант (держать такую учетку - не есть хорошо, кроме того не факт что на момент запуска все компьютеры будут включены и в сети). Если нужно собрать такую информацию наверняка, то можно например так:
1. Создать шару
2. Дать на эту шару права на запись для Domain Computers (достаточно на запись, чтение не обязательно, без удаления тоже обойдемся)
3. Научить скрипт складывать результат на эту шару (есть много способов, в т.ч. много вариантов именования файлов. лично мне нравится в качестве имени файла использовать дату, а файл складывать в папку имени компьютера)
4. Создать через групповые политики таск запускающийся, ну например через минут десять после старта включения компьютера (чтобы гарантированно всё нормально запустилось и могло достучаться туда куда нужно). Таск должен запускаться от имени NT AUTHORITY\SYSTEM
5. На несколько дней, а то и недель забыть об этом.
6. Проверить получившийся результат и сделать с ним то что хочется ;)

Ну и наконец совсем классный вариант это использовать для этого то, что специально для этого предназначено, здесь тоже видится два варианта (как минимум):
1. Жестко вычищать группу локальных админов добавляя туда только доменную группу с правами локальных админов и/или избранные учетки. (имеет свои минусы, например т.о. нельзя добавить человеку права локального админа даже если это нужно, т.к. при ближайшем обновлении политик группа вычистится).
2. Использовать для мониторинга админских учеток специализированный софт (емнип SCCM это умеет)

[DJ Mogarych]

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

[Elven]

DJ Mogarych, ссылка почитать (https://blogs.msmvps.com/acefekay/2012/01/06/using-group-nesting-strategy-ad-best-practices-for-group-strategy/).
Пожалуй я выразлися не совсем корректно: не то чтобы это были именно бестпрактис, но рекомендации в эту сторону есть. Когда-то я еще напарывался на весьма хорошую статью на русском, с довольно неплохими аргументами, но вспомнить их формулировки я пожалуй не осилю, а статья, к сожалению, не нашлась.

[Iska]

3. Научить скрипт складывать результат на эту шару (есть много способов, в т.ч. много вариантов именования файлов. лично мне нравится в качестве имени файла использовать дату, а файл складывать в папку имени компьютера) »
Удалённая база данных. Плюсом будет накапливание по датам.

[DJ Mogarych]

Elven, это рекомендации по вложенности групп, при чём здесь права доменного админа на локальных тачках?

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

[Charg]

2. Использовать для мониторинга админских учеток специализированный софт »
Никогда не устану рекомендовать PDQ Inventory (https://www.pdq.com/pdq-inventory/) для этих целей.
Базовый функционал (которого для этой задачи с головой хватает) вообще бесплатен.

[Elven]

это рекомендации по вложенности групп, при чём здесь права доменного админа на локальных тачках? »
Не только. В блоке Local Group Usage Best Practice это вкратце упоминается, и далее дается ссылка на статью как это настроить.
Так или иначе, скрипт надо запускать от той учётки, которая имеет права на локальных машинах. »
И для этого NT AUTHORITY\SYSTEM - выше крыши.
DJ Mogarych, я понимаю, что бывает неприятно, когда поправляют, но я оскорбить не пытался. Опять же поправился что это не то чтобы бестпрактис, а просто разумные рекомендации, да даже если бестпрактис - нет же никаких требований к использованию оных. Посему я не понимаю сути наезда. Если есть конкретные претензии, или я ошибаюсь и так как я рекомендую делать нельзя от слова вообще - аргументы в студию, т.к. голословные утверждения, что это не так не менее оскорбительны.

[DJ Mogarych]

Elven, мне не неприятно. Просто я не нашёл там упоминания о том, что
весьма хорошо когда доменный администратор не имеет прав локального админа на не контроллерах »

То, что нужно контролировать членов группы локальных администраторов, с этим глупо спорить. Но учётка, имеющая права доменного админа, должна иметь права на локальных машинах, это стандарт. Учётка, таких прав не имеющая, но тоже привилегированная, называется "Администратор предприятия".

Хотя, каждый может изобретать какие угодно схемы, никто не мешает.

NT AUTHORITY\SYSTEM - это учётка локальной системы. Как вы будете от неё скрипт запускать, который должен отработать на куче компьютеров домена?

[Elven]

NT AUTHORITY\SYSTEM - это учётка локальной системы. Как вы будете от неё скрипт запускать, который должен отработать на куче компьютеров домена? »
элементарно:
4. Создать через групповые политики таск запускающийся, ну например через минут десять после включения компьютера (чтобы гарантированно всё нормально запустилось и могло достучаться туда куда нужно). Таск должен запускаться от имени NT AUTHORITY\SYSTEM »
Когда-то большую часть скриптов на такой запуск и перевел, и всё работает как часики - локально эта учетка не уступает по правам ни одному админу, а если нужно чтобы она куда-то логи складывала или наоборот что-то забирала, то здесь работает
2. Дать на эту шару права на запись для Domain Computers »
(если нужно чтение - добавить права на чтение)
Насчет того, что доменным админам нужно ограничивать права на не контроллерах - согласен, это не бестпрактис, и даже в рекомендациях этого не было. Однако если есть десяток админов, каждый из которых имеет учетку и доменного админа и доменную учетку локального админа, то в лучшем случае восемь из них будут ВЕЗДЕ пользоваться только учеткой доменного админа. Я думал что две работы назад решил этот вопрос радикально - отобрал на не контроллерах права админа у domain admins. Но аккурат работу назад напоролся на еще более радикальное решение - доменным администраторам был запрещен логин на не контроллерах. Вот так это работает, хоть и не бестпрактис но жиза.

[DJ Mogarych]

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

А разве у учётки "система" есть сетевой доступ?

отобрал на не контроллерах права админа у domain admins »
Ну если десяток человек имеет права доменного админа - это, конечно, неправильно само по себе. Но тут дело не в самой роли доменного админа, а не совсем правильном её использовании.
В данном случае я бы просто убрал этих людей из доменных админов и сделал бы отдельную группу с правами на локальные компы, куда их и включил бы.

[YuS_2]

А разве у учётки "система" есть сетевой доступ? »
По умолчанию СИСТЕМной учетной записи предоставлены разрешения на полный доступ ко всем файлам на томе NTFS. Здесь у учетной записи SYSTEM есть те же функциональные права и разрешения, что и для учетной записи администратора.
Это можно проверить:
# Создание простой задачи, исполняемой от имени СИСТЕМА
$a = new-scheduledtaskaction -execute "powershell.exe" -argument {-exe bypass -f "d:\get-curuser.ps1"}
$t = new-scheduledtasktrigger -once -at (get-date)
$p = new-scheduledtaskprincipal "System"
$s = new-scheduledtasksettingsset
$task = new-scheduledtask -action $a -principal $p -trigger $t -settings $s
register-scheduledtask -taskname 'Run_PS_System' -taskpath '\' -inputobject $task
в аргументы можно записать что угодно для проверки, здесь записан запуск скрипта с диска d:\

[Charg]

YuS_2, речь о сетевом доступе шла. Учётка "система" же локальная для компьютера, она не сможет (насколько я знаю) пойти и взять файл с \\другойкомпьютер\шара

[Busla]

Charg, она не "локальная для компьютера", она учётка компьютера - почти такой же доменный пользователь, как и "человеческие пользователи".

она не сможет (насколько я знаю) пойти и взять файл с \\другойкомпьютер\шара »
значит, вы вообще не знаете как AD работает

[Charg]

она не "локальная для компьютера", она учётка компьютера »
Этого не знал.
значит, вы вообще не знаете как AD работает »
Выходит да, пойду завтра искать вакансию дворника.

[Elven]

Charg, как-нибудь можете полюбопытствовать от чьего имени происходит установка софта при раздаче оного групповыми политиками, заодно имеет смысл посмотреть почему сие не работает, если папка из которой берется софт, не имеет разрешения на чтение для Domain Computers. А еще (и это мое любимое) от чъего имени вообще читаются политики применяющиеся на компьютеры. Коллега Busla правильно говорит, NT AUTHORITY\SYSTEM - по сути учетка компьютера, она имеет те права, что определены для него.
Busla, не будьте так критичны, я догадываюсь откуда растут ноги у заблуждения Charg. В этом определенно виноваты MS ибо именно им в голову пришло наплодить такое количество учеток. Полагаю Charg рассуждает о другой встроенной учетной записи - Local Service. тык (https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/local-accounts#sec-localsystem)

[Charg]

Полагаю Charg рассуждает о другой встроенной учетной записи - Local Service. »
Да нет, я действительно не сопоставлял учётку SYSTEM c учёткой компьютера. Не знаю почему, не задумывался никогда а само в голову не приходило.
Я думал что SYSTEM это нечто вроде root - учётка операционки с правами на всё (ну, почти) но только локально. Собственно нигде никогда об этом не читал и не интересовался подробностями.

А еще (и это мое любимое) от чъего имени вообще читаются политики применяющиеся на компьютеры. »
Раз уж вопрос судя по всему с подвохом - видимо не от имени учётки компьютера?