SID для группы администраторов не отображается в учетной записи участника

Теперь, прежде чем я начну, я открою вам секрет: это на контроллере домена. *

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

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

* Причина та же, что указана выше. Принятый ответ объясняет несоответствие и был оплошностью с моей стороны, а не архитектуры (см. функции) безопасности Windows или контроллеров домена.

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

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

(New-Object System.Security.Principal.NTAccount('reserved')).Translate([System.Security.Principal.SecurityIdentifier]).Value

и я могу видеть, заканчивается ли SID на -500.

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

PS> [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups -match "S-1-5-32-544")
PS> False

Быстрая проверка, чтобы узнать, какую учетную запись он использовал:

PS> $env:username
PS> reserved

или излишне сложный способ (хотя иногда я предпочитаю его):

PS> Write-Host ((Get-WmiObject Win32_Account | ?{$_.SID.Substring($_.SID.Length-4,4) -eq '-500'}).Caption).Split("\",2)[1] -fore GREEN
PS> reserved

и я даже печатаю:

PS> net user reserved

где он мне говорит Local Group Memberships *Administrators.

Я открываю ADUC (dsa.msc), смотрю в контейнер Builtin и дважды щелкаю группу «Администраторы». Я выбираю тег Members, и вот, reserved на самом деле является участником!

Итак, резюме:

  1. Набрав net user reserved, я смог убедиться, что он входит в группу локальных администраторов.

  2. Я посмотрел в ADUC и подтвердил, что зарезервирован был членом встроенной группы администраторов

  3. Я убедился, что зарезервированная действительно была учетная запись локального администратора, проверив, что SID начинается с S-1-5... и заканчивается ...-500.

  4. Чтобы сделать еще один шаг вперед, я убедился, что SID соответствует группе Active Directory с именем «Администраторы», набрав Get-ADGroup -Identity "Administrators". Затем я набрал Get-ADGroupMember -Identity "Administrators" и удостоверился, что в списке есть reserved (совпадение И SID!).

  5. Когда я проверяю, находится ли известный SID группы администраторов в группах этой учетной записи (путем получения текущего идентификатора Windows), он говорит, что это не так.

Что дает?

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


powershell active-directory sid
person Rincewind    schedule 01.08.2016    source источник
comment
Вы убедились, что значение [Security.Principal.WindowsIdentity]::GetCurrent() и [Security.Principal.WindowsIdentity]::GetCurrent().Groups соответствует вашему мнению?   -  person Ansgar Wiechers    schedule 02.08.2016
comment
@AnsgarWiechers Это то, что происходило, когда я делал [bool](([System.Security.Principal.WindowsIdentity]::GetCurrent()).Groups -match "S-1-5-32-544"). Это искал текущий идентификатор Windows (зарезервирован), находил идентификаторы безопасности групп и проверял, был ли найден известный идентификатор безопасности для администраторов (S-1-5-32-544). Вернул false.   -  person Rincewind    schedule 02.08.2016

Ответы (2)


arrow_upward
2
arrow_downward

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

См. Также: https://serverfault.com/a/264327/236470

person briantist    schedule 01.08.2016
comment
Блин, побей меня на минуту. - person Bacon Bits; 01.08.2016
comment
Это правильно, но это не занимает четвертое место в списке. - person Rincewind; 01.08.2016
comment
@Rincewind какая основная группа пользователя reserved? - person briantist; 01.08.2016
comment
@briantist Основная группа - администраторы домена. Тем не менее, он по-прежнему указывает, что вы являетесь членом группы администраторов (локальных) и группы локальных администраторов, и учетная запись все еще найдена. - person Rincewind; 01.08.2016

arrow_upward
0
arrow_downward

Я случайно наткнулся на что-то и понял ответ на этот вопрос. Ради тех, кто приходит сюда за помощью, вот ответ на мой вопрос:

Очень просто - в отношении Powershell - если SID группы администраторов (S-1-5-32-544) не отображается в группах пользователя, это означает, что сценарий в первой строке не работает с учетными данными администратора.

Например, когда я печатаю:

([Security.Principal.WindowsIdentity]::GetCurrent()).Groups

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

Если вы щелкните Run As Administrator и введите то же, что и выше, вы увидите, что в Groups указан SID группы администраторов.

Причина, по которой я столкнулся с несогласованностью, заключается просто в том, что я не запускал процесс Powershell в качестве администратора.

Короче говоря, есть несколько способов проверить, есть ли у вашего текущего сеанса Powershell учетные данные администратора. Первый можно найти на бесчисленных веб-сайтах в Интернете и очень распространен (я не писал этот):

$myWindowsID = [Security.Principal.WindowsIdentity]::GetCurrent()
$myWindowsPrincipal = New-Object Security.Principal.WindowsPrincipal($myWindowsID)
$adminRole = [Security.Principal.WindowsBuiltInRole]::Administrator
if($myWindowsPrincipal.IsInRole($adminRole)) {
    \\ TODO: Process is running as Administrator
    Clear-Host
    } else {
        $newProcess = New-Object System.Diagnostics.ProcessStartInfo "Powershell"
        $newProcess.Arguments = "& '" + $script:MyInvocation.MyCommand.Path + "'"
        $newProcess.Verb = "runas"
        [System.Diagnostics.Process]::Start($newProcess)
        exit
        }

Вот еще один способ (я написал):

[Security.Principal.WindowsIdentity]::GetCurrent() | %{
    if($_.Groups -contains "S-1-5-32-544") {
        \\ TODO: Process is running as Administrator
        Clear-Host
        } else {
            Start Powershell -ArgumentList "& '$MyInvocation.MyCommand.Path'" -Verb runas
            exit
            }
        }

# The Foreach-Object (%) could be replaced with another pipeline filter

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

person Rincewind    schedule 05.08.2016