Forum Discussion
PowerShell script is triggering the AD alert when executing on any local server. as user or computer
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
- Thanks Lain for your clarification. I have tested this without any tool on servers manually, same alert triggered and security team reported it again. With the help of BMC also checked but it was coming to the script and user. If manual execution is triggering the alert then might be something at firewall rule or user level permission or server hardening. I also don't any see commands which are creating a issue here.
Reflecting on Ned's article (linked above) - he's such a good writer! - make sure BMC TrueSight is connecting to these servers by name and not IP address.
Connecting via IP address precludes the use of Kerberos, meaning NTLM is the only option.
It's so easy to forget basic requirements like this one.
Cheers,
Lain
- Hello Lain,
First I need to solve without tool or without using the tool user login, Then I will go for the tool.
I am checking myself in one server with PowerShell. Also checking the things which you have mentioned.
Thanks Lain
I'm not quite understanding what you tested manually. Do you mean you ran the script manually on the server - i.e. as a PS1 file - and it generated an NTLM event?
If so, were you running the PS1 as yourself or the TrueSight action account?
You might also want to look at the following two policies and configure them for auditing (if they're not already configured). I'd be looking to configure them locally on:
- The TrueSight server (notably setting the Restrict NTLM: Outgoing to Audit all);
Network security Restrict NTLM Outgoing traffic (Windows 10) - Windows security | Microsoft Docs - A single server managed by TrueSight to be used as a test bed (notably setting the Restrict NTLM: Audit incoming to Enable auditing for all accounts).
Network security Restrict NTLM Audit incoming NTLM traffic (Windows 10) - Windows security | Microsoft Docs
You can then runs some commands from the PowerShell console and see the impact in the event log at "Applications and Services Log\Microsoft\Windows\NTLM\Operational".
You can use a domain group policy to do this, but if neither policy is already set, then I'd simply use the local group policy editor during the testing phase (gpedit.msc) as it's easier/quicker to undo once testing is complete.
Read more about NTLM auditing policies here: NTLM Blocking and You: Application Analysis and Auditing Methodologies in Windows 7 - Microsoft Tech Community.
As an aside, the Windows Firewall won't feature in this in any way, shape or form - if that's the firewall you were referring to. It has zero per cent to do with authentication packages unless you're using Connection Security Rules, which I'd safely wager you're not using (and they're IPsec-based anyway, putting NTLM a long way out of reach.)
I'm also not familiar with any policy that forcibly degrades Kerberos to NTLM, so I wouldn't suspect hardening. Misconfiguration of something, maybe, but not hardening.
Cheers,
Lain
- Script manually on the server - i.e. as a PS1 file - and it generated an NTLM event?
Yes manually executed the same script in the PowerShell console with my user id on one server. Which triggered the alert. I am referring your given article to know more about it.
- The TrueSight server (notably setting the Restrict NTLM: Outgoing to Audit all);