Powershell Get-ADComputer - Fehlende Rechte?

[mte]

Moinsen,

will mir per Powershell-Call und WINST aus dem AD die Computerbeschreibung auslesen.
Irgendwie scheitere ich aber dran, dass per WINST-Powershell-Call die Authentifizierung im AD flöten geht. Wäre jetzt davon ausgegangen, dass die Skripts als NT-Authrität\System ausgeführt werden, also mit dem AD-Maschinenkonto..

Unter welchem Scope läuft das ganze?

Hier der Code

Code: Alles auswählen

[DosInAnIcon_Posh]
powershell "Get-ADComputer $env:COMPUTERNAME -Properties 'Description' | Select-Object -Expandproperty 'Description'"

Und die Debug-Ausgabe

Code: Alles auswählen

(386)     [5] [Nov 22 11:30:14:228] [business-config]   Execution of: DosInAnIcon_Posh
(387)     [7] [Nov 22 11:30:14:229] [business-config]     Save to file with encoding: system
(394)     [7] [Nov 22 11:30:14:230] [business-config]     Start including tail of LogFile "c:\opsi.org\tmp\_opsiscript_Tb64Wd42.cmd with encoding: cp1252"
(395)     [7] [Nov 22 11:30:14:230] [business-config]     ################################################################
(396)     [7] [Nov 22 11:30:14:230] [business-config]     ==>: powershell "Get-ADComputer $env:COMPUTERNAME -Properties 'Description' | Select-Object -Expandproperty 'Description'"
(397)     [7] [Nov 22 11:30:14:231] [business-config]     ################################################################
(398)     [7] [Nov 22 11:30:14:231] [business-config]     End including LogFile "c:\opsi.org\tmp\_opsiscript_Tb64Wd42.cmd"
(404)     [7] [Nov 22 11:30:14:231] [business-config]     Executing "cmd.exe" /C c:\opsi.org\tmp\_opsiscript_Tb64Wd42.cmd
(405)     [6] [Nov 22 11:30:18:457] [business-config]     ExitCode 1
(406)     [7] [Nov 22 11:30:18:457] [business-config]             
(407)     [7] [Nov 22 11:30:18:457] [business-config]             output:
(408)     [7] [Nov 22 11:30:18:457] [business-config]             --------------
(409)     [7] [Nov 22 11:30:18:457] [business-config]             
(410)     [7] [Nov 22 11:30:18:457] [business-config]             C:\Windows\system32>powershell "Get-ADComputer $env:COMPUTERNAME -Properties 'Description' | Select-Object -Expandproperty 'Description'"
(411)     [7] [Nov 22 11:30:18:457] [business-config]             Get-ADComputer : Der Server hat die Clientanmeldeinformationen zurückgewiesen.
(412)     [7] [Nov 22 11:30:18:458] [business-config]             In Zeile:1 Zeichen:1
(413)     [7] [Nov 22 11:30:18:458] [business-config]             + Get-ADComputer $env:COMPUTERNAME -Properties 'Description' | Select-O ...
(414)     [7] [Nov 22 11:30:18:458] [business-config]             + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(415)     [7] [Nov 22 11:30:18:458] [business-config]                 + CategoryInfo          : Sicherheitsfehler: (XXXXXXXX:ADComputer) [Get-ADComputer], AuthenticationException
(416)     [7] [Nov 22 11:30:18:458] [business-config]                 + FullyQualifiedErrorId : ActiveDirectoryCmdlet:System.Security.Authentication.AuthenticationException,Microsoft.A
(417)     [7] [Nov 22 11:30:18:458] [business-config]                ctiveDirectory.Management.Commands.GetADComputer

[RobWo]

Hab es mal getestet:

Code: Alles auswählen

(136)     [7] [Nov 25 15:40:56:287] [test-powershell] nt-autorität\system

Vielleicht reicht es aus, wenn du der Gruppe "Domänencomputer" im Rootverzeichnis deines ADs Leseberechtigungen gibst. (Unter dem Reiter Sicherheit)

So könntest du über Umwege andere Credentials zur Ausführung von Skripten verwenden:

Code: Alles auswählen

$user = "domain.com\username01"
$password = "password_stronk" --- #man kann natürlich auch eine Variable von OPSI einpflegen
$sicherpw = $password | ConvertTo-SecureString -AsPlainText -Force
$credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $sicherpw

Start-Process powershell.exe -Credential $credentials -NoNewWindow -ArgumentList "-noexit -command FooBar"

Wenn du die Ausgabe in einer Variable haben willst, dann mach es vielleicht so:

Code: Alles auswählen

DefStringList $output$

Set $output$ = powershellCall('$user = "domain.com\username01";$password = "password_stronk";$sicherpw = $password | ConvertTo-SecureString -AsPlainText -Force; $credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $user, $sicherpw; Start-Process powershell.exe -Credential $credentials -NoNewWindow -ArgumentList "-noexit -command Get-ADComputer $env:COMPUTERNAME -Properties 'Description' | Select-Object -Expandproperty 'Description" ')

[mte]

Das tolle ist ja, wenn ich den Befehl als nt-authorität\system (hochgestuft per psexec -s -i cmd.exe) ausführe, funktionierts auch - nur nicht per winst...???
Anderer User ist leider keine wirkliche Alternative (da 30 Tage Kennwortablauf und keine User bei denen das nicht der Fall ist)....

[RobWo]

Das tolle ist ja, wenn ich den Befehl als nt-authorität\system (hochgestuft per psexec -s -i cmd.exe) ausführe, funktionierts auch - nur nicht per winst...???

Mhh, komisch.

Anderer User ist leider keine wirkliche Alternative (da 30 Tage Kennwortablauf und keine User bei denen das nicht der Fall ist)....

Erstelle doch ein User, bei dem das Kennwort nicht abläuft, der sich aber nicht interaktiv anmelden kann - sogesehen ein Servicekonto im AD. Mache ich auch so mit vielen Diensten.

[mte]

Erstelle doch ein User, bei dem das Kennwort nicht abläuft, der sich aber nicht interaktiv anmelden kann - sogesehen ein Servicekonto im AD. Mache ich auch so mit vielen Diensten.

Ist leider nicht möglich, sieht unser Dienstleister nicht vor (kann im AD nur rudimentär steuern).
Werde mir jetzt wohl mit einem Powershell-Script beim Computerstart helfen, was den Namen aus dem AD ausliest (da läufts) und danach per JSON-API ins Backend schreibt...blöd...

[wolfbardo]

Moinsen,

will mir per Powershell-Call und WINST aus dem AD die Computerbeschreibung auslesen.

Workaround:

Computerbeschreibung landet doch auf dem Client in

[HKLM\SYSTEM\ControlSet001\services\LanmanServer\Parameters] srvcomment")

???

Gruss
Bardo Wolf

[mte]

Workaround:

Computerbeschreibung landet doch auf dem Client in

[HKLM\SYSTEM\ControlSet001\services\LanmanServer\Parameters] srvcomment")

Leider nicht bei uns, die Computerbeschreibung am Client selber wird über die Installationsroutinen nicht gepflegt..