Esa Jokinen's questions

Let's Encrypt has started issuing ECC certificates by default since Certbot 2.0. This is not a problem for modern web browsers, but Let's Encrypt certificates can be used for other purposes than HTTPS, too. Namely, some SMTP servers do not support ECC certificates, yet. If such server tries to establish STARTTLS connection with Postfix that uses ECC certificates it fails.

The logs indicate there are no shared cipher despite, e.g., Wireshark shows the Client Hello in the TLS handshake clearly has common ciphers with the list configured via smtpd_tls_mandatory_ciphers = medium.

postfix/smtpd[1337]: connect from mail.example.net[198.51.100.1]
postfix/smtpd[1337]: SSL_accept error from mail.example.net[198.51.100.1]: -1
postfix/smtpd[1337]: warning: TLS library problem: error:0A0000C1:SSL routines::no shared cipher:../ssl/statem/statem_srvr.c:2220:
postfix/smtpd[1337]: lost connection after STARTTLS from mail.example.net[198.51.100.1]
postfix/smtpd[1337]: disconnect from mail.example.net[198.51.100.1] ehlo=1 starttls=0/1 commands=1/2

The problem is caused by the type of certificate. Is it possible to get both ECC & RSA certificates from Let's Encrypt using Certbot? How to configure Postfix to use them both at the same time?

The email virus filter wrapper for ClamAV, clamassassin, appends its headers to the message headers.

X-Virus-Status: No
X-Virus-Checker-Version: clamassassin 1.2.4 with clamscan / ClamAV 1.0.3/27134/Mon Dec 25 11:40:06 2023

It would be better that any MTA delivering the message only prepends to the headers, as RFC 5322, 3.6 suggests:

However, for the purposes of this specification, header fields SHOULD NOT be reordered when a message is transported or transformed. More importantly, the trace header fields and resent header fields MUST NOT be reordered, and SHOULD be kept in blocks prepended to the message. See sections 3.6.6 and 3.6.7 for more information.

For instance, spamassassin prepends its X-Spam-* headers above the existing headers. Why clamassassin does not do the same, and how to alter this behaviour? If, e.g., the .procmailrc had the following I would expect these headers to appear in the same place.

:0 fw
| clamassassin

:0 fw
| spamassassin

The BIND 9 Administrator Reference Manual e.g. for version 9.14.11 or 9.17.1 states in

• 5.2. CONFIGURATION FILE GRAMMAR
  • The category Phrase
    • queries

The query log entry first reports a client object identifier in @0x<hexadecimal-number> format.

This term has not been mentioned anywhere else in the ARM, and it's the only mention of any object identifier at all.

• It seems not to be related to the client that was sending the query:

  • it could be the same for queries from many unrelated IP addresses but
  • it could be different for two queries from the same IP address.

• For e.g. @0x123456789abc

  • the first half 123456 seems always stay the same
  • the second half 789abc changes from time to time.

• In query log examples it can be 32-bit @0xffffffff or 48-bit @0xffffffffffff.

• Alan Clegg, in this BIND Logging presentation from October 2019, only describes it through what it is not:

  A @0x followed by the client object identifier (nothing to do with the client address)

What is it and how is it calculated?
What information can we get out of it? Why is it logged anyway?

Background. Outlook Autodiscover has a certain order of trying to figure out configuration, and it's somewhat unchangeable, at least for Office 365 users with BYOD devices:

1. Domain apex https://example.com:443/Autodiscover/Autodiscover.xml. As this is typically a public web site hosted elsewhere, this seems like an unnecessary step for most.

2. https://autodiscover.example.com:443/Autodiscover/Autodiscover.xml is a way more reasonable alternative. Unfortunately, as of Sep 2019, Microsoft has screwed this up: for Office 365 users this is instructed to be a CNAME autodiscover.outlook.com., but...

   $ curl -vvv https://autodiscover.outlook.com:443/Autodiscover/Autodiscover.xml
   *   Trying 40.101.49.88...
   * TCP_NODELAY set
   * connect to 40.101.49.88 port 443 failed: Connection refused
   *   Trying 40.101.65.216...
   * TCP_NODELAY set
   * connect to 40.101.65.216 port 443 failed: Connection refused
   *   Trying 40.101.126.120...
   * TCP_NODELAY set
   * connect to 40.101.126.120 port 443 failed: Connection refused
   *   Trying 40.101.126.216...
   * TCP_NODELAY set
   * connect to 40.101.126.216 port 443 failed: Connection refused
   *   Trying 2603:1026:207:15::8...
   * TCP_NODELAY set
   * connect to 2603:1026:207:15::8 port 443 failed: Connection refused
   *   Trying 2603:1026:207:109::8...
   . . .
   

3. Fallback to HTTP redirect method, the only method working.

   This time http://autodiscover.example.com:80/Autodiscover/Autodiscover.xml, configured as a CNAME autodiscover.outlook.com., answers with a redirect to a working site.

   Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml
   

   This one is serving correctly in most cases, although lines seems to be long for new Application Passwords to make it this far. This, how ever, takes a lot of request and additional time. (Also, this makes it harder to debug why certain versions of Outlook can't currently connect to Office 365 at all, but must be ugraded before even trying...)

Possible solution to make this faster is to add a reverse proxy at the domain apex, pointing to the working Office 365 Autodiscover site. E.g. with Apache this is as easy as enabling the module with a2enmod proxy_http and adding a simple configuration to the VirtualHost:

# Office 365 Autodiscover Hack 20190918
SSLProxyEngine on
ProxyPass "/Autodiscover/"  "https://autodiscover-s.outlook.com/Autodiscover/"
ProxyPassReverse "/Autodiscover/"  "https://autodiscover-s.outlook.com/Autodiscover/"

According to the Microsoft Remote Connectivity Analyzer test for Outlook Autodiscover this seems to work perfectly fine, and it also seems to make Outlook Autodiscovery seemingly faster on actual Outlook installations.

As this is a hack rather than an actual solution documented anywhere, my question: is there any possible consequences from this approach you could think of?

Is the autodiscover-s.outlook.com for example a static hostname for the service, or does it ever give other redirects? Wouldn't Outlook just continue with steps 2 & 3 in any case this proxy gives unexpected results?

HP EliteBooks (with Windows 10) keep turning off the WiFi when VPN connection is established, because the virtual network adapter is recognized as wired connection, causing both to fail.

This happens despite the LAN/WLAN switching being disabled in BIOS settings and Power Management for the adapter being turned off.

There are many tutorials on how to setup OpenDMARC on your favorite flavor of Linux, but they all focus on single server configurations. My goal was to keep backup secondary MX servers, but enforce RejectFailures true for DMARC p=reject to be actually satisfied.

This led to a problem: the example configuration has TrustedAuthservIDs HOSTNAME for uptream SPF and DKIM sources. If this was used to list secondary MX servers, it would allow bypassing the OpenDMARC checks completely on the primary MX with a single forged header.

Authentication-Results: <HOSTNAME>;
        dkim=pass (1024-bit key; unprotected) header.d=example.com [email protected];

How to configure trust between the primary and the secondary MX without this flaw?

This is a rewrite of another question on Security Stack Exchange for the scope of Server Fault.

Environment: A company network has a Firebox M-series appliance with Total Security Suite at headquarters. Every branch office has a smaller T-series Firebox without subscription services. For this reason, all traffic from the branch offices is routed through the M-series appliance at headquarters. Some of the branch office Fireboxes has a static IP, some obtains it via DHCP.

Occasionally there might be some problems with the tunnel (for example if the HQ network is down). Therefore, the branch office Fireboxes need to be able to abandon the 0.0.0.0/0 route through the tunnel and work standalone for a while, since BO Internet connectivity is crucial for the business. This works with BO Virtual Interface, but not with 0.0.0.0/0 over BO GW & Tunnel.

Simplified (just one External and Trusted if) related configuration, a branch office with DHCP.

• Firebox-HQ (10.9.0.1) - M670 [Fireware OS v12.2.1.B572649]
  • Interfaces (Routed Mode)
    • eth0: ISP1 [External] - 198.51.100.123/24 (Static)
    • eth1: Trusted [Trusted] - 10.9.0.1/24
  • VPN Interface (bvpn20): BovpnVif.BO20 [IKEv1]
    • Route to 10.9.20.0/24
• Firebox-BO20 (10.9.20.1) - T55 [Fireware OS v12.2.1.B572649]
  • Interfaces (Routed Mode)
    • DNS Servers: 192.0.2.10 & 192.0.2.20 (ISP2's DNS servers)
    • eth0: ISP2 [External] - 203.0.113.33/24 (DHCP)
    • eth1: Trusted [Trusted] - 10.9.20.1/24
  • VPN Interface (bvpn1): BovpnVif.HQ [IKEv1]
    • Route to 0.0.0.0/0
    • VPN Settings: [x] Remove VPN routes when the tunnel for a BOVPN vif is down.

Everything works just as expected when the tunnel is down. The Firebox-BO20 can work as a DNS resolver for its eth1 network. Both 10.9.20.0/24 and Firebox itself can access the Internet.

Problem: When the tunnel is up and the 0.0.0.0/0 route through bvpn1 is added, the clients on eth1 can access the Internet through the VPN and all the resources (incl. DNS servers) at the HQ.

IPv4 Routes
------------
Destination     Gateway         Genmask         Flags   Metric    Interface   
0.0.0.0         0.0.0.0         0.0.0.0         U       1         bvpn1       
0.0.0.0         203.0.113.1     0.0.0.0         UG      5         eth0        
10.9.20.0       0.0.0.0         255.255.255.0   U       0         eth1        
203.0.113.0     0.0.0.0         255.255.255.0   U       0         eth0        
127.0.0.0       0.0.0.0         255.0.0.0       U       0         lo           

However, Firebox stops working as a DNS resolver and loses its own Internet connectivity. This is due to the fact that Firebox own connections starts to use the route, too.

• The ISP2's DNS servers 192.0.2.10 & 192.0.2.20 aren't accessible from ISP1.
• The devices on network 10.9.20.0/24 can access the Internet through bvpn1.
• Firebox doesn't use its internal IP 10.9.20.1 through the tunnel, but 203.0.113.33.
• The Firewall rule Any From Firebox-00 is hard-coded and doesn't show up in Policy Manager. Otherwise it would have been easy to force it to use eth0 with <policy-routing>.

There are firewall policies to allow all the necessary traffic on both appliances; the problem is therefore delimited to the routing, alone.

Microsoft Security & Compliance center with Microsoft Secure Score has a long list of good, excellent and non-relevant security advises. Sometimes they seem a bit incompatible together...

Consider a situation where these are already done:

1. Enable MFA for Azure AD privileged roles
2. Enable MFA for (all) users

Then: Enable mailbox auditing for all users
using O365-InvestigationTooling / EnableMailboxAuditing.ps1:

#This script will enable non-owner mailbox access auditing on every mailbox in your tenancy
#First, let's get us a cred!
$userCredential = Get-Credential

#This gets us connected to an Exchange remote powershell service
$ExoSession = New-PSSession -ConfigurationName Microsoft.Exchange `
    -ConnectionUri https://outlook.office365.com/powershell-liveid/ `
    -Credential $userCredential -Authentication Basic -AllowRedirection
Import-PSSession $ExoSession

#Enable global audit logging
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox" `
    -or RecipientTypeDetails -eq "SharedMailbox" -or RecipientTypeDetails `
    -eq "RoomMailbox" -or RecipientTypeDetails -eq "DiscoveryMailbox"} `
    | Set-Mailbox -AuditEnabled $true -AuditLogAgeLimit 180 -AuditAdmin Update, `
        MoveToDeletedItems, SoftDelete, HardDelete, SendAs, SendOnBehalf, Create, `
        UpdateFolderPermission -AuditDelegate Update, SoftDelete, HardDelete, SendAs, `
        Create, UpdateFolderPermissions, MoveToDeletedItems, SendOnBehalf `
        -AuditOwner UpdateFolderPermission, MailboxLogin, Create, `
        SoftDelete, HardDelete, Update, MoveToDeletedItems 

#Double-Check It!
Get-Mailbox -ResultSize Unlimited `
    | Select Name, AuditEnabled, AuditLogAgeLimit `
    | Out-Gridview

However, New-PSSession fails with a Global Administrator account:

New-PSSession : [outlook.office365.com] Connecting to remote server 
outlook.office365.com failed with the following error message : 
Access is denied.

I believe this is because the Get-Credential or New-PSSession doesn't support MFA. The documentation for AuthenticationMechanism Enum doesn't seem to have such an authentication: changing Basic to Default doesn't help. Am I wrong?

Is there any other way for enabling mailbox access auditing for all users / checking its status?

This is a Canonical Question about interpreting the GDPR as discussed on meta.

While Server Fault may help you when you have a specific problem on implementing something related to the regulation, general questions about GDPR compliance are too broad, we are not lawyers who could interpret the legal issues, and Q/A style doesn't allow the in-depth discussion needed to know all the details in your organization to be sure that you actually comply.

I have a question regarding General Data Protection Regulation (GDPR), EU regulation 2016/679.

• How to comply with GDPR?
• Is my organization ready for GDPR?
• Should I do X to comply with GDPR?
• Does the GDPR forbid me from doing Y?
• Is Z still allowed under the GDPR?

I noticed that an Azure AD Connect Password sync was giving Warning: no recent synchronization, which was clearly caused by misconfiguration: password synchronization was indeed disabled. Trying to modify settings however failed, Connect to Azure AD claiming that the account wasn't an administrator.

Please provide administrator credentials for contoso.onmicrosoft.com - AAD.

Double checked that this account has the Global administrator role and also tried another account. Trying with a wrong password or an account with a pending forced password change gives another, reasonable error: there's nothing wrong with the connection. Updated from 1.1.561.0 to the latest 1.1.750.0, but that didn't help either.

Both time ADSync gives following event 6306,

The server encountered an unexpected error while performing an operation for the client.

"BAIL: MMS(5036): ..\mastate.cpp(8818): 0x80230613 (Operation failed
     because the specified management agent could not be found.)
BAIL: MMS(5036): ..\mastate.cpp(10113): 0x80230613 (Operation failed...
BAIL: MMS(5036): ..\ma.cpp(316): 0x80230613 (Operation failed...
BAIL: MMS(5036): ..\ma.cpp(437): 0x80230613 (Operation failed...
BAIL: MMS(5036): ..\server.cpp(2007): 0x80230613 (Operation failed...
Azure AD Sync 1.1.750.0"

followed by .NET Runtime event 1026 and Application Error (event 1000):

Faulting application name: Microsoft.Identity.AadConnect.Health.AadSync.Host.exe, 
    version: 3.0.127.0, time stamp: 0x59eb08bc
Faulting module name: RPCRT4.dll, version: 6.3.9600.18939, time stamp: 0x5a7f2493
Exception code: 0xc0000005

Should I continue debugging this or simply completely remove the Azure AD Connect and start from scratch? I'm a bit afraid that Azure AD Connect DB could have something extra for matching the local AD accounts with the corresponding Azure AD accounts, possibly leading to duplicated or orphaned accounts on the cloud side. What are the actual risks here?

I'm using Debian 9 with PHP-FPM 7.0.26-2 & 5.6.32-1 from repository deb.sury.org. The same configuration is working fine on a Debian 8 server with PHP-FPM 5.6.30

• I've copied the pool.d/user.conf from that server.
• Both php.ini files are having cgi.fix_pathinfo=1.
• The parameter is also forced using php_admin_value[cgi.fix_pathinfo] = 1.

• Both servers uses this pool similarly from <VirtualHost> context with:

  ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/run/php/user.sock|fcgi://localhost/home/user/public_html
  

Now, there's an AJAX page that needs to read path from PATH_INFO (possibly PATH_TRANSLATED). However, while these variables have correct content on the Debian 8 server:

["SCRIPT_NAME"]=>
string(14) "/path/ajax.php"
["ORIG_SCRIPT_NAME"]=>
string(25) "/path/ajax.php/para/meters"
["PATH_INFO"]=>
string(12) "/para/meters"
["PATH_TRANSLATED"]=>
string(34) "/home/user/public_html/para/meters"

They seem to work differently on the fresh Debian 9 + dub.sury.org:

["SCRIPT_NAME"]=>
string(25) "/path/ajax.php/para/meters"
["PATH_TRANSLATED"]=>
string(22) "/home/user/public_html"

And the prameters ORIG_SCRIPT_NAME and PATH_INFO are completely missing.

For some reason, Windows Firewall was disabled on an AD domain of my client. The RSoP report shows the setting is originated from the Extra Registry Settings on Default Domain Policy.

If this was on any other GPO I could have just removed it, but it's the Default Domain Policy. On the Domain Controller there's no such ADM/ADMX template set up that controls these registry keys, so I can't edit them using the Group Policy Management Editor. (Probably some admin at some point had one on an external computer having the Remote Server Administration Tools installed.)

What would be the correct way to delete these settings? Should I find and install the correct ADM(X) template or is there any shortcut? (All the settings I actually need can be found under Network\Network Connections\Windows Firewall\ already, but this keeps Windows Firewall disabled for public and home networks.)

Despite the modern virus protection is based on prevention by scanning network traffic and by real-time protection, many companies still have policies, that full scans must be performed regularly. Since hard drives are getting bigger and bigger, this kind of scans takes longer and eats up resources. Also, if users turns off their computers when leaving office, the scans must be scheduled at times when they should be using the computer for something more meaningful.

I've come to a solution, that it's best to make a compromise by setting virus scanner process ProcessorAffinity to just one or two cores, allowing the user to use the rest of the resources. That allows to fulfill the strict policy of regular scans without frustrating the users with the slowdowns, not to mention the unnecessary problem reports caused by it.

I don't have any problem setting this up: I can easily automate it by deploying a scheduled task currently triggered by user logon, e.g. for F-Secure (Scanner Manager process):

schtasks /create /tn "F-Secure Affinity" \
  /tr "PowerShell '$Process = Get-Process fssm32; $Process.ProcessorAffinity=2'" \
  /sc onlogon /delay 0001:00 /ru System

Here, the affinity is set when the user logs in, since before that there's no other need for the resources on regular workstations.

I'm just curious whether this is best practice or has any disadvantages.

• Is this giving malware a potential head start? Is this a notable risk?
• Should I have different triggers than logon and should I set it back after the scan finishes?
• Is there a better way to achieve the goal of satisfying both: the company policy and the users?