EcoStruxure Control Expert Security Editor Server Won't Start

[JeffKrol]

Hello,

I'm trying to set up the Control Expert Security Editor in a client-server configuration to manage roles for Control Expert in a centralized manner. I can't get the Server to change state (it only shows "Stopped"). When I click on the "Certificate Actions" tab and change the product selection to "SecurityService", I see that there is no certificate in the certificate store (red X on the certificate icon and confirmed via tool tip). When I click "Generate Self Signed Certificate" I get a popup dialog box that says "SecurityService: Certificate creation failure". I checked the Windows Event Viewer for Application events and every time I try to generate this certificate I see an error that says something like:

0x80040072 : Fatal error : p:\p-unit\dev\securitymngt\securityservice\securitycertificates.cpp:653 [PID: 43152]

I've got this program installed and running as Administrator. I've tried this on another VM and I'm having the same issue. What would cause this certificate creation to fail? This is preventing us from running the Security Editor server.

[MarkZoer]

Dear Schneider, any clues as to why this is happening? It looks similar to my case.

[Ricard]

Hello

I don't know what version of Expert Control you are using, but I would recommend using the latest version 16.1. If not, try updating all the HFs.

Certificate issues are usually problems with credentials or domains. However, your problem is that the service does not start. Look at the screenshot that I attach relating the concepts of the Security Service. To see the ports used with the PIDs, use "netstat -a -on" in CMD. If you still can't find the service problem, contact your country's technical support.

[JeffKrol]

Ricard,

Thank you so much for the reply and information. I am using ControlExpert 16.0 with all hotfixes applied. I do see the SecurityService service running with the correct "Log On As" field. When I run the 'netstat -a -on' command, I do not see anything listening on port 50051 nor do I see any entry with the appropriate PID. I had a case with support opened and they were not able to figure anything out. I got tied up with more important issues, so the case is currently closed, but I'm going to keep working on this with them soon.

Any suggestions?

[MarkZoer]

We are running ECE 15.3 as part of process expert 2023.

What Jeff says also applies here. The server state in the security editor shows as stopped. The securityservice shows as running in the services menu. When following the PID of that service (in windows resource monitor) there is no process listening on port 50051 nor can the  PID be found there.

[JeffKrol]

Ricardo,

Can you send me a copy of 16.1? All of the links I found or were emailed don't work! I tried to private message you but can't figure out how.

Thanks!

[Ricard]

I see it, I will contact my colleagues to see what happened. In the meantime, use 16.0

BR

Ricard

[JeffKrol]

Thanks for the info. Yes, that's the problem with this issue though. Support can't figure out why the certificate creation is failing so they advised me to try out 16.1. So, in the meantime, we can't use the Security Editor in a server-client configuration.

I find this very strange since we have some Windows event captures showing the exact line number in the source code where the process is failing.

[MarkZoer]

I received feedback from Schneider that might be of help. It was found out that LSA was active on our server and that this doesn't work with the security editor. I asked for LSA to be temporarily deactivated and after reinstalling Control Expert (with a fresh install of the security editor) the Control Expert and Security Service certificates were generated.

[JeffKrol]

Mark, thanks for the reply. This is very concerning that the only way to get Security Editor to generate the Security Service certificate is by disabling a core functionality of Windows. From Copilot:

"The Local Security Authority (LSA) process is essential for a Windows server. The LSA, which includes the lsass.exe process, is responsible for enforcing security policies, handling user logins, and managing authentication and authorization1. Without the LSA process, the server would not be able to validate user credentials, enforce security policies, or manage access tokens, which are crucial for maintaining system security and functionality2.

In summary, the LSA process is a critical component for the secure and proper operation of a Windows server."

If the LSA running prevents the Security Service certificate from ever being generated, this implies that the Server-Client architecture would never function natively in Windows 10/11 or Windows Server 2016/2019/2022. In addition, this would indicate to me that they never tested this functionality on any of these OS versions. In fact, I was told by support that they are unable to reproduce this issue. Very curious....

[Ricard]

Please, I think we are mixing up issues, both cases may be different problems. Please don't jump to conclusions without prior analysis, pls

What I advise you is to talk to the technical support of your country, I am sure my colleagues at ST will be able to help you.

[MarkZoer]

I agree Richard, the could be different.

But what I pointed out in an earlier post, might be of help in finding a solution for someone else. In our case (server-client setup of security editor, with LDAP authentication) it helped to get the server state from showing only stopped to showing running, listening on the right port, being able to generate certificates, etc.

Once you get it up and running it might be easier to take small steps back and see when it stops running instead of trying many things without ever getting it to run, don't you agree?

[JeffKrol]

I wanted to chime in here and mention that I was able to test this with v16.1 last week. That did appear to fix the issue in our test environment. However, this release is not currently available so we're going to have to hold off on upgrading until it's officially out.

I appreciate the info regardless, Mark. It's good to at least point someone in a direction that is worth testing. I did not feel comfortable disabling this in our environments to even test in v16.0, especially since v16.1 appears to have fixed our issue. If v16.1 still had this issue, I would have tried disabling as a test. My support experience resulted in them saying "unable to reproduce, try v16.1 to maybe fix it".

So now we're just waiting for v16.1 to officially release and we'll upgrade. Hopefully that happens sooner rather than later!