[RESOLVED] REPO HS

Geoffroy · January 2, 2023 - 2:53 PM

Hello everyone,

First of all, best wishes to the whole team.

WAPT server 2.2.3 Enterprise license, Windows Server 2019.

So, to counter a potential attack, the client asked us to set up VLANs in each classroom with multiple subnets. But since this setup, the PCs using repositories are no longer accessing the repositories but the main server. We

have updated the rules ourselves, but without success.

Example: repository on 10.2.0.93,
PC network 10.2.110.0/24 and 10.2.111.0/24,

server ping workstation
, workstation ping server.

Then, someone from Active Directory security told us to implement two Group Policy Objects (GPOs) on the Active Directory server:
one that disables NetBIOS over TCP/IP and one that disables intelligent multi-resident name resolution.

Do you have a solution?

It worked before this implementation. Are there any additional ports besides those specified in the WAPT document that need to be opened for repositories?

January 2, 2023 - 4:37 PM

Could you please provide a screenshot of one of the rules for the remote site VLANs?

We need a rule that considers each VLAN and directs it to the correct server.

And of course, the secondary repository must be visible from the workstation in question. The server itself doesn't need to see the workstation, but the workstation must be able to perform HTTP/HTTPS GET/POST requests to both the server and the secondary repository.

Regards,

Denis

Geoffroy · January 2, 2023 - 4:49 PM

Hello,

Please find attached the rules

January 3, 2023 - 10:12

Hello,

on one of the problematic machines, in the software inventory under /wapt_status/repositories/, are the rules correctly applied?

Is HTTPS properly configured on the secondary repositories?

Does short repository name resolution work correctly on the affected machines?

Regards,

Denis

Geoffroy · January 3, 2023 - 11:32

dcardon wrote: ↑January 3, 2023 - 10:12 AM Hello,

on one of the problematic machines, in the software inventory under /wapt_status/repositories/, are the rules correctly applied? Is

HTTPS properly configured on the secondary repositories?

Does short repository name resolution work correctly on the machines in question?

Regards,

Denis

The first two points are OK.
I think this stems from the fact that in the security audit, they made us add the blocking of NETBIOS over TCP/IP.
The problem must be with the DNS zone, which isn't taking over, because on a non-domain machine, the rule for this machine works correctly

January 3, 2023 - 12:10

Okay, if you can use a fully qualified domain name (FQDN) for the repositories with the corresponding DNS resolution, that should solve the problem.

Regarding your short name resolution issue, disabling NetBIOS is a security step I highly recommend.

I'm marking this topic as resolved.

Regards,

Denis