Cat Mucius's questions

I have amazingly strange issue with monitoring a CIFS (SMB) shared folder mounted to Linux machines by Nagios + NRPE.

NRPE process runs on the Linux machines under dedicated user nrpe:

# systemctl status nrpe
  nrpe.service - Nagios Remote Program Executor
   Loaded: loaded (/usr/lib/systemd/system/nrpe.service; enabled; vendor preset: disabled)
   Active: active (running) since Tue 2023-05-02 14:46:47 IDT; 20h ago
     Docs: http://www.nagios.org/documentation
  Process: 30216 ExecStopPost=/bin/rm -f /run/nrpe/nrpe.pid (code=exited, status=0/SUCCESS)
 Main PID: 30218 (nrpe)
   CGroup: /system.slice/nrpe.service
           └─30218 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f

# ps -ef | grep nrpe
nrpe     30218     1  0 May02 ?        00:00:05 /usr/sbin/nrpe -c /etc/nagios/nrpe.cfg -f

The monitoring command is defined in its configuration /etc/nagios/nrpe.cfg file this way:

command[check_backups_share]=/usr/lib64/nagios/plugins/check_disk -w 7% -c 5% -p /mnt/backups

If I run the command manually as nrpe user on all machines, it succeeds:

# sudo -u nrpe bash
bash-4.2$ /usr/lib64/nagios/plugins/check_disk -w 7% -c 5% -p /mnt/backups
DISK OK - free space: /mnt/backups 2571991 MiB (61.32% inode=-);| /mnt/backups=1622248MiB;3900643;3984528;0;4194240

However, if I call it remotely from Nagios, it succeeds on one machine and fails on another:

$ /usr/local/nagios/libexec/check_nrpe -2 -H Machine01 -c check_backups_share
DISK OK - free space: /mnt/backups 2575536 MiB (61.40% inode=-);| /mnt/backups=1618703MiB;3900643;3984528;0;4194240

$ /usr/local/nagios/libexec/check_nrpe -2 -H Machine02 -c check_backups_share
DISK CRITICAL - /mnt/backups is not accessible: Permission denied

All other remote NRPE commands on Machine02 succeed. Even more, if I unmount the /mnt/backups folder on Machine02, it also succeeds (for root filesystem). But when it's mounted, I get this Permission denied error.

The folder is mounted identically on all machines, with the same credentials and options. In /etc/fstab file:

//Backups-Server/backups  /mnt/backups      cifs    vers=3.0,credentials=/path/to/creds    0 0

So:

• all credentials, permissions, users, groups are the same;
• command executed locally on all machines under the same user produces the same results;
• but when executed remotely, it fails on one machine complaining on permissions, but succeeds on all others,
• while the executing nrpe process configured the same way on all machines and has the same permissions.

So what on earth could this be?

Update:

Solved, see below.

I have an AlwaysOn cluster of SQL Server 2019, containing an Availability Group of 3 replicas in Synchronous mode. According to Microsoft documentation:

3. The secondary replica hardens the log and returns an acknowledgement to the primary replica.
4. On receiving the confirmation from the secondary replica, the primary replica finishes the commit processing and sends a confirmation message to the client.

This article goes into greater detail and explains that:

5. In the secondary replica, Log Receive gets the log records from the primary replica and writes to Log cache. This process is repeated on each secondary replica participating in synchronous-commit mode.
6. On each secondary replica, Redo thread exists, and it writes all changes mentioned in log records to the data page and index page. It flushes the log for hardening on secondary database log.
7. As stated earlier, in synchronous data commit, primary replica waits for the acknowledgement from the secondary replica. At this stage, secondary replica sends an acknowledgement that transaction hardening is completed on secondary.
8. Once Primary replica, receives an acknowledgement from the secondary replica, it sends the transaction completion message to the client.

So if I understand right: If I update a record via Primary replica successfully, this updated value should be immediately available for clients querying the Secondary replicas.

However, when I test this, this doesn't work so. I run a simple batch file, looking like this:

sqlcmd -E -S tcp:SQL-AG-Listener -d TestDB -Q "BEGIN TRANSACTION; UPDATE TestSyncTable SET CurrentTime='%currentTime%'; COMMIT TRANSACTION;"
sqlcmd -E -S tcp:SQL-Server01 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly
sqlcmd -E -S tcp:SQL-Server02 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly
sqlcmd -E -S tcp:SQL-Server03 -d TestDB -Q "SELECT * FROM TestSyncTable" -K ReadOnly

So I'm updating the CurrentTime field via the Primary replica (hosting the AG Listener) and then reading it right away via all three replicas. Each sqlcmd command is a separate client process, so it opens its own independent TCP connection.

And then I see something like this:

SQL-Server01: CurrentTime = 20:02:19.93
SQL-Server02: CurrentTime = 20:02:16.94
SQL-Server03: CurrentTime = 20:02:19.93

(Reformatted the output for better readability here)

As far as I've seen, the Primary replica always returns the updated value. And the Secondaries also do - but only some short delay.

So the question is: why? Shouldn't Synchronous mode guarantee that the result of reading operation is consistent with the writing one? If the Secondary replica sends acknowledgement only after its Redo thread updates the data page - then how can it be?

Thanks, Mucius.

Good day,

As we know, creating IP based TLS binding (contrary to SNI binding) allocates a dedicated IP address to App Service webapp. But it still remains accessible via the IP shared with other webapps (including webapps of other customers).

In some situations I'd prefer to allow traffic via the dedicated IP only, blocking traffic via the shared one. Is it possible somehow to unbind the webapp from the shared endpoint?

(Why would I prefer this? Let's say, I place a some WAF-as-a-service in front of this app, so it would inspect the traffic. I can use Access Restrictions to limit access to my app for WAF address ranges only, but this won't help, if an attacker opens an account on the same WAF and points his own site to my IP. A remedy for this - the WAF service can register this IP as dedicated for my account, so other WAF users won't be able to point their sites to it. But, of course, I cannot do this with the shared Azure IP, because then legitimate WAF users having sites on Azure App Services will be affected).

Thanks, Mucius.

We have an instance of SSRS (SQL Server Reporting Services) which uses Kerberos Constrained Delegation to fetch data for its reports from SQL Server on behalf of its users.

For this purpose, SSRS was configured to use <RSWindowsNegotiate/> authentication option.

Unfortunately, this option allows NTLM sign-in as well. Users successfully login with NTLM, and then get an error when trying to launch a report (because the delegation obviously fails).

There is also <RSWindowsKerberos> option, but unfortunately it's not supported by browsers.

What's even worth, after such NTLM login SSRS won't try for some period of time to get a Kerberos ticket on behalf of a user - even if the user now logs in using Kerberos, even from another browser or from another station. I guess, this is because SSRS launches some session object for the user after successful login, and associates new logins to this session - so until it expires (in ~10 minutes), no delegation would be attempted.

Is there a way to make NTLM logins fail, or at least give user a warning that he should close his browser, wait for some time and re-login by Kerberos?

I noticed that our IIS 8.5 returns "401 Unauthorized" response to non-authenticated HTTP request right after receiving its headers, without waiting for the body:

the client:

POST /some/protected/page HTTP/1.1
Host: server.example.org
Content-Length: 4666

the server, without waiting for the rest:

HTTP/1.1 401 Unauthorized
Server: Microsoft-IIS/8.5

the client goes on:

<xml>some large XML block of 4666 bytes in total</xml>

Now, by itself it doesn't represent a problem, but our load balancer (FortiGate v6.0.3) decided to be smart, so it drops the request's body after seeing the "401 Unauthorized" response. And this, as I understand, causes next request over the same TCP pipe to fail, since the server interprets next bytes as a payload promised by the "Content-Length: 4666" header.

The question: is it possible to make IIS to wait for the whole request before responding with 401?

Good day,

• I have a CSR (certificate signing request) file, which was generated on some remote non-domain station.
• I have created some AD user account.
• I have Enrollment Agent certificate signed for my own account.

The question is: can I somehow submit this CSR to an Enterprise CA for signing on behalf of this user account? Preferably from command line (but not necessary)?

Different pages I found on this topic only demonstrated, how to create fresh new CSR on behalf of domain user (using .inf file), and then submit it to CA (example). But can I do it with existing CSR, not created by myself?

Does anybody know if it's possible to store private keys, belonging to service account or computer account, on Windows 8 VSC (virtual smart card)?

As far as I understand, requirement for 8-symbols (at least) PIN prevents it. Service process, like IIS, cannot authenticate against VSC with the PIN, and I didn't find how to set empty PIN for the VSC.

Are there any workarounds? It's awful pity to lose the non-exportability feature, which TPM provides, for server-side certificate keys just because of this PIN thing.

I have a Windows 2008 R2 server with IIS7.5 installed. I need to provide users with read-write access to some directory tree via WebDAV. The same users will also be able to reach the same directories by other means - FTP, SFTP, CIFS, etc.

My aim: I don't want someone to be able to upload / modify web.config files in the published folders, thus modifying behavior of IIS. If such file is created, IIS should simply treat it as any other file.

Is it possible to concentrate all settings for the site in the applicationHost.config or in any other file outside the published tree, and make IIS ignore any additional web.config files?

Thanks!

Are there tools to define in Linux something similar to Policy-based Routing, but on Layer2 level? Usual Linux bridge uses destination MAC to decide, which interface to send frame to. Can this behavior be altered?

Let's say we have a machine with several interfaces - physical, virtual, VLAN-tagged subinterfaces, etc. A frame arrives at one of them. Can we decide, which outgoing interface the frame will be delivered to, according to parameters such as VLAN tag in the frame, source MAC address, source interface, 802.1p priority, etc.?