Issue with NPS Server in Workgroup - Getting DC name failed. Status = 1355 0x54b ERROR_NO_SUCH_DOMAIN

Products Privilege Secure Discussions & Questions
,
1

Hi everyone,
I am experiencing an issue with the NPS server configured in a Workgroup and I hope someone can help me find a solution.

the Action Service installed on my NPS server needs to contact the domain controller with the PDC Emulator role to manage critical functions.

To emulate the Domain Controller Location Services (DCLS) procedure, NPS use the command:

nltest /dsgetdc:next04.loc /PDC

This command works correctly only domain-joined computers, but when executed from a computer in a workgroup, it returns this error:

WhatsApp Image 2025-05-14 at 17.10.24 (1)
WhatsApp Image 2025-05-14 at 17.10.24 (1)2048Ă—1271 319 KB

This prevents NPS from creating the session to the target server.

The reason for the error is that the “nltest” cmdlet is engineered to work for some options by leveraging Kerberos, which requires special permissions and authentication.

After various tests, I verified that if I use the command “nltest /dsgetdc:”, which uses a simple DNS query, the command succeeds and returns the name of the Domain Controller present in the DNS record.

So if, as shown in the image, the identified DC is not the PDC, then the error persists and nothing works.

However, if I migrate the FSMO role to the identified server and everything starts working correctly!

Was anyone already aware of this issue? Do you have a workaround to solve the problem?

Thank you very much for any attempt to help.

Have a great day, everyone.

C.

2

Hello Carlo,

Thank you for your question.

Please make sure your NPS server has the ports open that it needs to your DCs
and that it is using your internal DNS.

Please see the documentation about [Ports]
(Netwrix Documentation)

For nltest /dsgetdc resolution, we have found port 445 is generally the issue.

HTH,
-Kevin

2 Likes
3

Hi Kevin, thanks for the response.

Regarding the firewall ports, they are all open as per the guide, and specifically the one you mentioned, I opened it by filtering the logs:

The image shows a network configuration interface displaying various servers and services, with a highlighted option for 'Microsoft-DS' indicating an allowed setting. (Captioned by AI)
The image shows a network configuration interface displaying various servers and services, with a highlighted option for 'Microsoft-DS' indicating an allowed setting. (Captioned by AI)3253Ă—292 84.5 KB

Additionally, the problem is not the nltest /dsgetdc command for DNS resolution but the switch used “/PDC” to locate the PDC which, as mentioned, does not work if the server is not domain joined.

In fact, I have the same error even if I have NPS servers and target servers in the same subnet

Carlo

4

Hi Carlo,

Thanks for following up.

I wonder if the DNS UDP port is coming into play here. I will experiment with my lab.

-Kevin

5

Hi Carlo,

I was talking to some other members of the team, and the docs are missing some ports.

Make sure that these ports are open to allow NPS to communicate with the PDC:

Ports:
TCP 53,135,389,445,464,636,9389
UDP 88,135,137,138,389

TCP 9389 should be open to all site DCs

HTH,
-Kevin

6

Hi Kevin,

I confirm that all the indicated ports are open between the PAM and the DCs.

Additionally, as previously mentioned, the problem persists even when there is no firewall between the NPS server and the DCs since they are on the same subnet.

The issue remains with how the PDC is detected because the command “nltest /dsgetdc:” with the “/PDC” option does not work if the NPS application server is in a workgroup.

Can you try this in your lab to see if you encounter the same problem?
Of course, there must be at least 2 DCs, and the one detected by the “nltest /dsgetdc:” query must NOT be the PDC.

Thank you very much for your responses and help.

Carlo

7

Hey Carlo,

We think it would be helpful to take a look at your environment to troubleshoot, but you’ll need to create a support ticket first. Do you mind creating one?

1 Like
8

Hi Dan,
Thank you for your interest.

I have just opened a ticket through our client’s portal.

I also wanted to inform you that I had the pleasure of discussing this issue with Martin during the Netwrix Connect Forum in Milan.

We hope to find a solution; otherwise, I won’t be able to proceed with the ongoing installations.

Thank you very much for the support.

Carlo

9

You’re welcome, Carlo!

I’m glad to hear you were able to connect with Martin in Milan - he had wonderful things to say about the event.

Our support team should be able to get this resolved for you, and if not then it will get escalated to my team.

- Dan

2 Likes
10

Hi Dan,
I wanted to update you that I have opened a support ticket and had a call with Joe last Friday.

At the moment, no one has been able to provide me with a solution, and I know the R&D team is working on it.

I hope a solution/workaround can be found soon because I am starting to have serious difficulties with clients who are waiting for updates.

I will update you as soon as I have more information.

Have a good day

C.

11

Hi Carlo,

Thank you very much for opening a support ticket. I understand how frustrating and disruptive this must be, and we are fully committed to resolving this issue.

Do you have a support ticket number so I can check on its progress?

- Dan

12

Hello everyone, we have likely reached an understanding of the issue at hand. As previously communicated to support, I have replicated the same physical and logical structure of the client’s ADDS, including the network setup, in my laboratory. I analyzed the network traffic and firewall logs during the various stages of NPS configuration (domain discovery phase) and throughout the activity execution. It was observed that communications were being blocked towards the following ports:

  • Domain discovery phase (during initial wizard): Port 445 TCP SMB
  • Activity execution phase: Port 88 KERBEROS TCP

I proceeded to add these ports to those already configured according to the documentation, and everything seems to be functioning properly!

Yesterday, I received confirmation when I replicated the installation for a new client where I must implement the solution in a high availability environment with ADDS in tiers. The command “nltest /dsgetsc: … /PDC” appears to respond correctly.

Below are the ports I configured between the NPS server and ALL domain controllers within the domain:

The image displays a table listing various network services with their corresponding names, destination ports, protocol agents, and types, focusing on TCP and UDP protocols. (Captioned by AI)
The image displays a table listing various network services with their corresponding names, destination ports, protocol agents, and types, focusing on TCP and UDP protocols. (Captioned by AI)1085Ă—1062 137 KB

I emphasized ALL because even though they are not part of the site where the PAM servers are located, it is crucial that all domain controllers are reachable. The role of the PDC is not static and could be transferred to any DC within the domain.

I hope this has been helpful. I await confirmation from support that they have also encountered this issue and will update the official documentation accordingly.

Best regards,

C.

4 Likes
13

Thank you for the in-depth follow-up!

14

Thanks for following up and providing such helpful information, Carlo!

Our documentation is currently frozen for maintenance, but in the interim I created another post in the Community emphasizing the necessity of both ports 88 and 445 TCP.

Since I am the Product Owner for Privilege Secure, this post can be considered official commentary from Netwrix:

Recommendation for Additional Open Ports Between Privilege Secure Servers and Domain Controllers - Privilege Secure / Discussions & Questions - Netwrix Community

3 Likes