Forums - Thread Details
  • Replies 10 replies
  • Subscribers 12 subscribers
  • Views 5414 views
  • Users 0 members are here
Related

Service/Impersonation Accounts and Initial HighQ Admin Accounts Questions

Michael Sevarino

I have some questions about what appear to be service/impersonation accounts in my fresh HighQ instance. I have attached screenshots of the accounts in question, as well as a system created org group, which some of them are in. My question is what is the purpose of these accounts? It seems they are for api functionality with different modules in highq, some are self explanatory, such as the AI hub and document automation, however, others less so, like the matter management and project budget and planning accounts. Any insight anyone has on this would be great. 

Related to this is the group I mentioned that has some of these accounts as members. If they all work in the same way, but just for different functions/modules, why aren't they all members of the group?

The last question is somewhat unrelated but is ultimately the reason I am asking questions about these service accounts. When others were set up with their instances, did they have a separate user type called HighQ users, and also about 20 different users who had access to the instance, as well as 5 who had System Admin rights? Indeed, one of these users appeared to be some kind of super admin/root level rights, who if I hadn't inactivated and archived all of these accounts, would ostensibly have been able to lock me out of the account entirely. From what I can tell, these accounts comprised essentially the entire US and UK support teams and some engineers possibly. One of the five system admin accounts was a support person who I spoke with on a support ticket. As I said, none of these users have access to the system anymore, as I couldn't really put any client data in there with such broad access to scores of people I don't know and have nothing to do with my firm, but this would seem like the opposite of what is described in the security documentation re: highq staff access. Did anyone else have this experience?

  • Btw, i can see that you created this posted then edited it soon after, which results in 2 separate activities appearing. When you edit a post, you can choose to suppress the edit activity from appearing in the activity stream.

  • Re your substantive question. I think that is quite common for new instances. When we received our new instances, after the initial setup was complete, I went in and remove System Admin access from any HighQ staff.

  • Under Notifications when you edit (or create) a post.

  • Agreed. Basically, HighQ should deliver your instance and have a formal period where you are doing your final review and any config changes. During that time giving HighQ staff access makes sense, as they may need to make changes. When that period formally ends, HighQ should remove those accounts. When you have a support question that requires System Admin access to your instance, the access can be granted again and then remove when that is over.

    We have similar Service Accounts:

    You may have more or less based on extras you have licensed.

  • Mark Salamon Oh thanks for this. I don't see an option to suppress the activity broadcast, is it in the general setting maybe?

  • Mark Salamon Yea I have no doubt this is standard procedure for setting up the instance, but it seemed excessive and also something I feel like should be mentioned at some point, like "hey these people are users in your instance to set it up starting out, when thats finished do this with them." I am much more interested in the mechanics of how those impersonation/service principal accounts are used and function. Do you have the same accounts in your instance? Different ones?

  • Thomson Reuters Thomson Reuters staff member

    Hi Michael Sevarino ,

    The accounts which you have identified as service accounts facilitate communication between different internal microservices of ours and the main application. Every instance has them.
    --------------
    With regards to the support team being automatically included in your instance: please accept my apologies if this wasnt made clear to you during your onboarding. As you've probably deduced from Mark's comments above, this is standard for new instance builds. If you have any comments regarding information you've recieved about our support processes, during your onboarding, please reach out to me peter.simpson@thomsonreuters.com and I can ensure that my boss, Mark Edwards, the Global Head of Support, takes a look.
    --------------------
    From our point of view the processes surrounding this are as follows:

    In the application there is a separation between 'System Level' and 'Site Level'. A member of the support team will never enter a Site (where we assume the majority of your sensetive data is), unless explictly instructed to do so. Site access is fully auditable, so were we to ever trangress this, it would be easily provable. Our accounts are there, ( along with some key infrastructure engineer ones), so we can be responsive incase of emergencies or mission critical issues.

    The one exception to this is the 'HighQ Maintenance Site', which is supposed to be a 'sandboxed' site in your instance, for our testing. If you have a problem which requires replication, we will ordinarily first attempt on a seperate UAT instance running the same version of the code. Next we would try in the maintenance site and then lastly we would ask to inspect the site in question. We recognise, given our domain and client's use-cases, that its not always allowable.

    --------------------------------------

    The key thing here is that you are completely in control of manging the system administration of your isntance. You are more than welcome to 'Inactivate' or 'Archive' any of these accounts and you can also archive the HighQ Maintenance Site. A number of our clients do either of these things, although id say that they were a minority. Doing this, at worst, would mean an extra step or two on your side, were you to, for example, upgrade to a new piece of functionality, which requires someone with our level of access to switch on in the backend... Again, its all entirely upto you. If you raise an issue with Support, you will tell us how you want us to interact with your instance.

    ------------------------------------------------

    Please see this Knowledge Base page regarding Site Level security settings which I believe may be of interest to you. System Admins are also subject to these settings, so we couldnt, for instance, bypass an IP Restricted site.

    I hope this helps, if you have more follow ups, probably best to raise a support ticket.

  • Thomson Reuters Thomson Reuters staff member

    Michael Sevarino not security, just support :) - probably best raise a ticket with us and put 'FAO Peter' in the subject line - ill ensure that I pick it up.

  • Hi Peter Simpson thanks for the reply. May I PM you about this and a few other questions I have? You seem to be the resident security person, if I am wrong let me know.

  • That’s a valid concern, especially when dealing with default service accounts and elevated admin privileges. It’s crucial to audit these accounts early to maintain security and ensure only authorized access. I encountered something similar during a platform setup. 
    -Delwood | Owner of Flux Interiors