Graham

Hello @Helen Chaytor I'll take your questions in turn: 1. You can't apply MFA to this account as it is used non-interactively by the SIS service to connect to the servers and workstations on your internal network, and since it's non-interactive, there's no way to present any MFA prompt or accept a response. 2. I'm not quite sure what you mean by "token life". The account you need is one that is internal to your network, and is typically one in Active Directory, so it can be configured by your organisation with any restrictions that are considered suitable. 3. The use of this account, which is active only on your on-premise network, cannot be monitored from within Hornbill. This account is not used to access Hornbill and is not a Hornbill account in any way. For example, if someone logged on to a on-premise server using this account, no Hornbill system would have any visibility of that action. You could configure account logon auditing within your environment, but that is not an ITOM or Hornbill function. Graham

Hi @Adam Toms Thanks for the detail. When we run jobs, these are supervised by a separate executable, which is remotely deployed to the target computer. Before doing this, in order to validate system integrity, the digital signature of this executable is checked. It is this check which is failing. The error code 0x800B0109 translates as "A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider." If, on the computer running the SIS service, you navigate to C:\Program Files\Hornbill\Site Integration Server\exec\win\x64 and display the properties of the EspSisExec.exe file in that folder and then pick the Digital Signatures tab, select the signer from the list and then click the "Details" button., what is displayed?

Hi @Adam Toms Can you post details of the error you're seeing, please? Graham

Hi @Sam P You need to use custom criteria. Try configuring your report like the screenshot fragment below. Graham

@AnthonyUSS You can do this:

@davidrb84 See Hornbill Cloud - Firewall IPs and Ports for the source IPs.

@Jim To follow up on the above, we've now chatted all this through within the team, and there will be some changes made to how the system processes password changes for users. Going forward, only a user who currently holds the admin-level privilege will be able to change a user's password directly. This will prevent the scenario you outlined above whereby an analyst would be able to change your password. For users that do not hold the admin-level privilege, the ability to directly set a user's password from within the Administration section of Hornbill will be replaced by a facility to initiate a password reset request to the user via e-mail. Also, I would re-iterate the point that accounts with the admin-level privilege are not intended for day-to-day usage, but rather are for system setup and emergency situations, and I would encourage you to review those users who currently do hold that privilege and remove it where possible. Finally, for resetting the passwords of basic users, I would be interested to understand why it is the analysts that are taking on this task. A user can request a password reset directly from the login page. Is there a reason why this self-service approach is not being used?

@Jim Yes, it's something we're now discussing internally.

@Jim That's not really a recommended approach. As it says in the role description: This role provides super user functionality to the system as it overrides all rights and permissions. A super user should never log into the user application, and the role should only ever be used when first setting up the system, or in an emergency to recover the system. I would suggest that you remove this role from any account which is used for day-to-day activities within Hornbill and grant those accounts a more granular set of roles dependent on the tasks carried out by their respective users.

@Jim Ok, got you. So do those user have the Platform Super User Role granted? If so, how many users have that role granted?

True, because that's one of the activities enabled by holding the Manage Users right. This is where I think we may be talking at cross purposes. What's your definition of an "admin account"? They can't do this, since only someone who can log on as "admin" can reset the password for "admin".

@Jim That behaviour is by design. A user with the Manage Users right can change the password for any user on the system apart from the "admin" user. However, we may be using the same term for different things. What's your definition of an "account with admin privileges"?

@Jim Not sure what you mean by this. Do these rights include the Manage Users right? Can you change the password for the user with the user id "admin"?

@Jim The Manage Users right allows a user to manage all users apart from the "admin" user (or any other account with the Admin privilege). As I understand it, you're looking for two different rights - one to manage full and basic users and one that can only manage basic users?

@Jim Does your test account have a role with the Manage Users right?