When you run software solutions that make use of TLS secured communication channels the applications need to have access to the certificate's private key. The private key is part of the certificate stored in the local certificate store of the computer. In most cases the software solution creates a new self-signed certificate and configures access rights appropriately.
When establishing TLS communication channels to external partners, the use of a public SSL/TLS certificate is a must have requirement.
The following step-by-step instructions describe how to assign Read permisson for the Email Security Solution Gateway NoSpamProxy. In this case the solution does not utilize a classic service account, but a so-called virtual service account. Virtual service accounts provide a much better access security when executing Windows services.
Open the local computers certificate store using the MMC Snap-Ins.
Select the certificate to use and open the context menu (right click).
Select Manage Private Keys to manage the private key permissions.
Click Add and add the required service accounts.
In this case the virtual service accounts are part of the local computer entity. Select the local computer and not the Active Directory domain as source when searching accounts. Virtual accounts us the prefix NT Service.
Add the follow accounts to configure read access for NoSpamProxy on a server having the Gateway and Intranet role installed.
Add the follow accounts to configure read access for NoSpamProxy on a server having the Gateway role installed only.
Click Check Names to verifiy the existence of the entered service accounts.
When correctly resolved the accounts names are replaced by theis respective display names. Click OK to add the accounts.
Configure read access for all added service accounts and click OK.
The software solution is now capable of accessing the private key of the certificate.
This script deletes user from the NoSpamProxy NoSpamProxyAddressSynchronization database table [Usermanagement].[User] table that have not been removed by the NoSpamProxy Active Directory synchronization job.
The script was developed due to a process flaw in how Active Directory accounts are handled as part of a leaver process. So this script does not fix a software bug, but a process glitch.
Due to the Active Directory account process the accounts still exist in Active Directory and are synchronized to the NoSpamProxyAddressSynchronization database.
When executed without the -Delete parameter all identified users are wirtten the log file only.
# EXAMPLE 1
# Check for Active Directory existance of all users stored in NoSpamProxy database. Do NOT delete any users from the database.
# EXAMPLE 2
# Delete users from NoSpamProxy database hosted on SQL instance MYNSPSERVER\SQLEXPRESS that do NOT exist in Active Directory.
.\Remove-NspUsers.ps1 -Delete -SqlServerInstance MYNSPSERVER\SQLEXPRESS
This script helps you to monitor message flow in a NoSpamProxy environment using a PRTG custom PowerShell sensor.
This custom sensor contains the following five channels:
The default interval is five minutes. But you might want to change the interval as needed for your environment.
These channels can easily be modified and additional channels can be added as well.
NoSpamProxy is a powerful anti-spam gateway solution providing additonal functionality like centralized S/MIME and PGP encryption for on-premises and Exchange Online deployments.
PRTG is a industry standard system monitoring solution.
The script itself does not take any additional attributes and is called by PRTG probe.
To verify your setup, you easily execute the PowerShell script. It returns a Xml result.
PS C:\Scripts> .\Get-NoSpamProxyPrtgData.ps1
The PRTG channel configuration
The following screenshot shows PRTG example graphs.
The custom PowerShell script must be saved to the following location of the PRTG probe:
[INSTALLPATH]\PRTG Network Monitor\Custom Sensors\EXEXML
Ensure to have the PowerShell execution policy set correctly. Otherwise the PRTG service won't be able to execute the PowerShell script.
Ensure that the service account used by the PRTG probe has access to the script and is a member of the NoSpamProxy Monitoring Administrators security group.
Additional credits go to Brian Addicks, https://github.com/brianaddicks/prtgshell