• ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
  • ×
    Information
    Windows update impacting certain printer icons and names. Microsoft is working on a solution.
    Click here to learn more
    Information
    Need Windows 11 help?
    Check documents on compatibility, FAQs, upgrade information and available fixes.
    Windows 11 Support Center.
  • post a message
Guidelines
The HP Community is where owners of HP products, like you, volunteer to help each other find solutions.
HP Recommended
ZCentral Connect 2020
Microsoft Windows Server 2016

We have 2 domains, 1 run by the main company and another that our department runs.  All usernames are part of the company domain which I have very limited access to so I set up the ZCentral Connect server in the departmental domain and want to authenticate company usernames to it.

I created a departmental security group on the DC with the company domain users added (there is a 1 way trust from departmental to company domain)  and added the security group to the pool permissions but the session manager won't authenticate, just says unknown username/password.  As the computers are in the departmental domain a user, when logging in locally, will normally prefix their username with company\username which the departmental DC will then forward the authentication request to the company DC and this works fine.  Using a prefix with RDP also works fine, so the issue is just the authentication of the session manager login page not processing the authentication the same way Windows does.

 

Edit: Sorry I should have specified, it works fine with usernames in the departmental domain (which were only created for testing), but not usernames in the company domain so is there a way to get the session manager to authenticate the company usernames the same way Windows already does?

5 REPLIES 5
HP Recommended

Hi Mark,

 

What type of account is being used to run the Manager service? Is it a Managed Service Account or a Domain account?

And which is the domain is that account associated with?

Or are you using LOCALSYSTEM to run the Manager service?

 

Thank you.

 

------------------------
I work on behalf of HP.
HP Recommended

Hi Lizzy,

 

The service is being run with a Domain account that was created in the departmental domain.

This is still a test system at the moment so I can make changes / reinstall with different settings if there is a way to get it to recognise company domain usernames.  The only things I can't do is put the Host PC's in the company domain as we need to restrict and control access to these PC's and we have no authority over the company domain to do this.

 

How does it query the DC for credentials and is there a way to get it to prefix the username with the company domain, i.e companydomain\username, we currently do this for normal Win10 logins (both local and RDP) via "Assign a default domain" in local policy, so that when the DC receives the authentication request it knows to forward to the company domain.

 

Cheers,

Mark

HP Recommended

Mark,

 

It should be ok that the Host PC is in the department domain. You have already demonstrated you can log in with a corporate user account on that machine, so the trust relationship seems to work.

 

The Manager does forward the authentication request to the corporate domain as long as you put the prefix of the corporate domain in front of the username when attempting to log in.

It doesn’t query the DC for credentials, it just forwards the credentials to the DC and lets the DC handle authentication.

 

We suspect the problem is that you are running the Manager using a department domain account. In a one way trust, we wouldn’t expect a trusting domain’s user (a department domain user) to have access to users in the trusted domain (the corporate domain.) So it could be that the Manager service, running as a department domain user, doesn’t have sufficient privileges to authenticate corporate domain users.

 

Can you try running the Manager service using an account from the corporate domain? It can be either a normal domain user account or a Managed Service Account but it should be from the corporate domain.

You will need to uninstall the Manager and install it again. Changing the account used to run the Manager service after installation is not supported.

------------------------
I work on behalf of HP.
HP Recommended

Hi Lizzy,

 

Thank you for your reply, I started from scratch and worked through what I was doing and realised I was installing the Connect as the local administrator account so even with the server on the company domain (which I had tried as a test) it still couldn't see/authenticate.  So I put the VM onto the department domain and logged in with my a company username (that was added to the local administrators group) and the installer found the domain, i was able to use my company\username as the manager account, continued the install but then threw the error "Failed to create self-signed certificate.  Installation will rollback" and that's were I'm stuck now.  I rolled the VM back to a snapshot before I installed anything and still get the same error.  I think I'm almost there,  any idea how to resolve the cert issue?

 

Cheers,

Mark

HP Recommended

All right, here are the next steps to resolve this issue:

 

The installer must be run as administrator. Usually this happens by default but not always.

 

The next thing to debug would be to run the installer with logging enabled:

From an administrator command line terminal,  run:

msiexec /I <path to installer> /L*V <log file>

 

Once the installer fails as it did before, open the log file and look for the line that contains: “Failed to create self-signed certificate:”.

Appended to the line should be the cause of the failure which will help debug the issue.

------------------------
I work on behalf of HP.
† The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the <a href="https://www8.hp.com/us/en/terms-of-use.html" class="udrlinesmall">Terms of Use</a> and <a href="/t5/custom/page/page-id/hp.rulespage" class="udrlinesmall"> Rules of Participation</a>.