Forum Discussion
PowerShell script is triggering the AD alert when executing on any local server. as user or computer
Harm_Veenstra One thing I also understood that, The user who is executing the script is the local user not domain user. Its trying to collect the details from the target server but in backend some where its connecting to AD Server. And the error I am getting is like below. User and the error type.
Is the server level hardening to block the login or in the script which is trying to do get something from AD server instead of Target servers where the actual script is executing.
My expectation is that the NTLM event is coming from how the script is being called, not from the script itself.
Rather than focusing on the script content, focus on how it's being run, i.e. via something like psexec, Invoke-Command, a scheduled task, SCCM utility, etc., etc.
In theory, WMI can also be the source but the calls to Get-WmiObject and Get-CimInstance do not use such triggers (such as alternate credentials and/or impersonation levels) meaning that is irrelevant in this case. That only leaves how it's being launched.
While the script itself is not written very well, there's nothing in it that would trigger the events you're seeing.
Cheers,
Lain
- Yes Lain, We are using the BMC TrueSight Server Automation tool which push the script in 100 target servers in any directory and execute it on all 100 servers, After that Security team raise the concern like they have high volume alert which was around 4956 alerts.
It sounds like you can stop looking into the script and switch your focus onto engaging with the BMC instead.
You could perform a quick cross-check beforehand by distributing a much simpler one line script (below) via BMC TrueSight, in which case if you deploy it the exact same way as your original script above, I'd wager you'll see the exact same NTLM event reported by your security team.
Write-Host "Hello world!"If it does indeed trigger the NTLM event then at least you can be sure the configuration issue lies within TrueSight.
The authentication package used can very much be chosen by the launcher (BMC TrueSight in this case) and it appears it's chosen NTLM.
One thought - and this is only a guess - is that within your TrueSight configuration, see if you can specify the "run as" account in RFC822 format - more simply known as e-mail format.
So, for example, if you specified the account within the TrueSight package in NT4 format like:
mydomain\myLaunchAccount
Then try the RFC822 format of:
myLaunchAccount@mydomain.com
It may or may not make a difference but I have seen software use NTLM when the NT4 format is used and Kerberos (which is what your security team probably wants you to use) when RFC822-style is used. And it should be a reasonably quick to test, so I'd give that a go before reaching out to BMC.
Cheers,
Lain
