Cocowalla's questions

I'm working with Azure, and I have 2 VNETs, each in its own resource group

                                  Peering
                                     +
                                     |
                                     |
                                     |
                                     |
+------------------------------+     |      +-------------------------------------+
|     Test Resource Group      |     |      |          Prod Resource Group        |
|                              |     |      |                                     |
|   +----------------------+   |     v      |   +-----------------------------+   |
|   |       Test VNET      |   |            |   |          Prod VNET          |   |
|   |                      <--------------------+                             |   |
|   |                      |   |            |   |                             |   |
|   |                      +-------------------->                             |   |
|   |                      |   |            |   |                             |   |
|   |                      |   |            |   |                             |   |
|   +----------------------+   |            |   +-----------------------------+   |
|                              |            |                                     |
+------------------------------+            +-------------------------------------+

What I want to do is lock down the peering, such that traffic between the VNETs is restricted to a particular port on a particular VM, without affecting any of the existing firewall rules that are in place.

Would adding an NSG (Network Security Group) to the subnets allow me to do this?

I have an Azure subscription with 2 different resource groups, Test and Prod. Each resource group has a VNET with a bunch of VMs in it.

There is a VM in Prod that acts as a license server, and services in both Test and Prod need to be able to access it. Let's call it LICENSE-VM.

+------------------------------+            +-------------------------------------+
|     Test Resource Group      |            |          Prod Resource Group        |
|                              |            |                                     |
|   +----------------------+   |            |   +-----------------------------+   |
|   |       Test VNET      |   |            |   |          Prod VNET          |   |
|   |                      |   |            |   |                             |   |
|   |   +----+    +----+   |   |            |   |   +----------+    +----+    |   |
|   |   |VM-1|    |VM-2|   +----------------------> |LICENSE-VM| <--+VM-3|    |   |
|   |   +----+    +----+   |   |            |   |   +----------+    +----+    |   |
|   |                      |   |            |   |                             |   |
|   +----------------------+   |            |   +-----------------------------+   |
|                              |            |                                     |
+------------------------------+            +-------------------------------------+

Of course, this isn't an issue within the Prod VNET, but I'm struggling to find a secure way of allowing communication with LICENSE-VM from Test.

1. I thought of adding a public IP to LICENSE-VM, and using an NSG (Network Security Group) attached to the NIC to lock it down - but if I use a source IP rule that specifies the CIDR range of the TEST VNET, it doesn't work (can't connect)
2. I then thought of adding a public load balancer, but this seems to have the same problem as (1), in that I can't lock it down to a VNET in a diferent resource group
3. We could setup VNET peering, but it seems overkill when we only want access to a single port on a single VM. I'm also unsure if we could lock that down using Network Security Groups?

Any idea how I can lock down a public IP such that a VNET in a different resource group can access it? Alternatively, is there some other way I can approach this?

I feel like this must be a relatively common scenario, and I'm missing something obvious!

I've installed Postgres 10.1 on a Windows server, and it's running as a Windows service. It's installed into %APPDATA% for the Local System user, which is the user account the Window service is running with:

C:\Windows\System32\config\systemprofile\AppData\Roaming\My App Database

My server-side SSL certs are in this same directory, and my postgresql.conf is configured to find them:

ssl_cert_file = 'db.crt'
ssl_key_file = 'db.key'
ssl_ca_file = 'ca.crt'

My pg_hba.conf file seems to be configured correctly:

hostssl     my-database         my-username         0.0.0.0/0               cert clientcert=1 map=my-username

I'm trying to connect with the psql command line tool:

psql "postgresql://my-username@localhost/my-database?sslmode=verify-full&sslkey=C:\MyDir\MyClientCert.key&sslcert=C:\MyDir\MyClientCert.crt"

but I get this error:

psql: root certificate file "C:\Users\Administrator\AppData\Roaming/postgresql/root.crt" does not exist Either provide the file or change sslmode to disable server certificate verification.

I can't find any reference to root.crt in my config, and I've no idea why it's looking in %APPDATA%\postgresql, rather than the configured PGDATA directory, %APPDATA%\My App Database.

My goal is to configure advanced audit policy for file system objects on some Windows machines, such that it overrides group policy. I need this to work for both Windows Server 2008 (R1) and later editions.

From what I've read, this is possible by setting this registry value to 1:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\SCENoApplyLegacyAuditPolicy

And then running this command:

auditpol.exe /set /subcategory:"File System" /success:enable

Am I understanding this correctly, or can advanced auditing policy also be overriden by group policy?

* UPDATE *

I created a couple of VMs and created a test domain, to try this out. It seems it does work, but the setting Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings (which controls SCENoApplyLegacyAuditPolicy) can still be disabled by group policy - and if it is, I can't figure out how to override it such that auditing isn't disabled again at the next gpupdate. Is this possible?

I have a PostgreSQL 8.4 database running on Windows, but I've lost the name of the superuser username, so am unable to connect.

I've already configured pg_hba.conf to use trust to allow connections without a password, but I still need to know the name of a valid user to login.

I've tried postgres, admin etc, but I always get:

psql: FATAL:  role "USERNAME" does not exist