Windows Server 2016 Backup - error with user of network share

If you are running a Windows Server 2016, are using the integrated Windows Server Backup utility and you want to save the backup to a remote destination, which is a CIFS/SMB network share, then during the setup the following error might occur:

"The user name being used for accessing the remote share folder is not recognized by the local computer."

Soltuion

1. Create a local user at your Windows Server, which has the same username and password as the cifs/smb user
2. Add this user to the "Backup Operators" user group:

3. Go back to setup the backup job using the "Previous" button and click next/finish again -> Your scheduled backup job using a cifs/smb network share should now be created successfully.

Outlook connection protocol, auth, encryption & status

A quick way to check or beginn to troubleshoot the used protocol, authentication, encryption and connection status of Microsofts Outlook client as well as to find out which version is running on your Microsoft Exchange server or Microsoft Office 365 server is to use:

1. CTRL + right-click on the outlook icon:
    
2. Select "connection status":
   
3. The following window will appear:
   
   There the server, the proxy-server, the used protocol, the authentication method, the encryption, the status and the exchange-server version can be quickly checked.

More in the Microsoft support article.

Security fixes in PRTG 19.3.51/19.4.52

The current version PRTG 19.3.51/19.4.52 includes some security fixes:

• PRTG Core Server XSS Cross-Site-Scripting
  We fixed potential reflected XSS vulnerabilities with medium severity on the PRTG core server. The potential vulnerabilities affected tag filters, object IDs, and the contact support/feedback page. Please note that the fixed vulnerabilities required a logged in PRTG user account to be exploited.
• Sensors DoS
  We fixed a potential Denial of Service (DoS) vulnerability of the HTTP Full Web Page sensor. Please note that the fixed vulnerability required a logged in PRTG user account with elevated rights to be exploited. (CVE-2019-11074) 

Besides those security fixes some new improvements made it into the release, too. More information can be found in the release notes https://www.de.paessler.com/prtg/history/stable or in the blog of the vendor: https://blog.paessler.com/prtg-release-19.3.51-and-19.4.52-news-roundup. Information regarding previous security issues with proof of concept are listed here: https://sensepost.com/blog/2019/being-stubborn-pays-off-pt.-1-cve-2018-19204/

SonicWALL E-Mail-Security AntiSpam Troubleshooting & Firmware

If you are using SonicWALL E-Mail-Security as your antispam solution there are some useful ways to troubleshoot issues using different logs. They help to understand what happend to a certain mail, why communication to another mailserver is slow/lost and how the SNWL E-Mail-Security or your ES Remote Analyzers work internally.
These logs contain very sensible information in terms of privacy, make sure your data protection & legal processes are fully in place.

1. Which firmware to use?

SonicWALL uses the SNWL E-Mail-Security themselfs. The version of the used SonicWALL E-Mail-Security is written in their SMTP Banner:

1. DNS-Query to find MX-Records:
   > set q=mx
   > sonicwall.com
   Server:  dns9.quad9.net
   Address:  9.9.9.9
   
   Non-authoritative answer:
   sonicwall.com   MX preference = 15, mail exchanger = mail1.sonicwall.com
   sonicwall.com   MX preference = 15, mail exchanger = mail3.sonicwall.com
   sonicwall.com   MX preference = 15, mail exchanger = mail2.sonicwall.com
   
   
2. Connecting to them using a TCP-Session on TCP-Port 25 (e.g. telnet 25 or nc -C 25):
   nc -C mail1.sonicwall.com 25
   220 mail.sonicwall.com ESMTP SonicWall (9.1.2.3763)
   220 mail.sonicwall.com ESMTP SonicWall (9.1.1.3121)
   220 mail.sonicwall.com ESMTP SonicWall (9.1.2.3761)

There you can see which firmware SonicWALL themselfs are using.

2. Audit log

Use the audit log. It helps you most of the time and is very easy to understand.

3. Log level

Set the loglevel to "level 2" or "debug". That gerenates a lot of logs, but is necessary for fully troubleshooting mail-problems, either with other or your own mailservers or with mails "lost" in antispam.

1. Login to the SonicWall and navigate to Manage -> Anti-Spam -> Advanced Settings
   
2. Now select the Log Level 2 and then select the Type of Log file and then click on Download. We have chosen MlfAsgSMTP in the screenshot shown below to download the SMTP Logs, however depending on the issue the desired log files may be selected.
   
3. Save the logs in the desired location.
   Source: https://www.sonicwall.com/support/knowledge-base/how-to-obtain-smtp-logs-from-anti-spam/170503798824694/

You can use the CLI to adjust the maximum log filesize:

Logfile names:
Some log file names, such as those found in the commonlogs directory, contain a two-digit number such as 12.log. The "12" indicates that the log is for the 12th day of the most recent month. Some log file names end with a digit, such as MlfThumbUpdate_2.log. The "2" indicates that this is an older log. The current log is MlfThumbUpdate.log. The next most recent log is MlfThumbUpdate_0.log, followed by MlfThumbUpdate_1.log, and so forth.

The following logs are very useful:

• pmta:logs
• logs:MlfAsgSMTP
• logs:smtp

Use the timestamp, unique-message-id or the destination-address in order to follow a mail. Sometimes the E-Mail-Security sends a mail to localhost on another internal tcp socket. You can see that, because the destination is 127.0.0.1:*highport*. Because sometimes an action is done while the second inspection time, you need to follow that session, which will be documented in the logs, too.