[OPENIDM-5288] OpenIDM install guide should not recommend use of windows administrative account to run as a service Created: 24/Feb/16  Updated: 13/Jan/18  Resolved: 02/Oct/17

Status: Closed
Project: OpenIDM
Component/s: documentation
Affects Version/s: OpenIDM 4.0.0
Fix Version/s: OpenIDM 6.0.0

Type: Bug Priority: Major
Reporter: Simon Harding Assignee: Nabil Maynard
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to OPENIDM-5354 Windows Service installation instruct... Closed
Target Version/s:
Verified Version/s:
Story Points: 2
Sprint: OpenIDM Sprint 83


In the OpenIDM installation guide, “To Install OpenIDM as a Windows Service”, the following steps are described:

4. Change the user account for this service from the default (local system) account to an account with administrative privileges. The local system account has limited permissions and an OpenIDM service that runs with this account will encounter problems during synchronization.

4c. Select This Account and browse for an Active Directory administrative account.


Running a service as a Windows administrator account is bad practice. In most enterprises, a Windows domain administrator account is the most privileged account in the enterprise. Running a service as a domain administrator (as 4c implies) is dangerous.


Accounts can be given specific file system permissions, registry permissions and user rights in the local security policy such as the “Log on as a service” right. If privileges are required in active directory, these can easily be assigned using any of the “delegate control” wizards.

It is highly unlikely that OpenIDM requires user rights such as “allow logon locally” and “perform volume maintenance tasks”, which administrative accounts have. (4c) implies that an account is required to have domain admin privileges. It is unlikely that OpenIDM requires anything further than the ability to read and modify certain user accounts on an active directory domain.

I recommend updating the documents to describe what file system/registry permissions are required, what user rights are required and what active directory permissions are required (if any).

I am willing to assist in this if need be.

Comment by Mike Jang [X] (Inactive) [ 24/Feb/16 ]

Simon Harding, sounds analogous to restricting use of the Linux root account.

Do you know "what file system/registry permissions are required" for a regular Windows user to have privileges to install / start / manage OpenIDM (and I think the Felix console) on a Windows server?

Comment by Mike Jang [X] (Inactive) [ 05/Mar/16 ]

Maybe this: http://stackoverflow.com/questions/4436558/start-stop-a-windows-service-from-a-non-administrator-user-account

Comment by Simon Harding [ 11/Mar/16 ]

Hi Mike Jang [X], sorry I've been a bit busy recently.

I'll have a look at this next week.
Is there a list somewhere of what read/write permissions are needed when running IDM on any OS?

Once I've got that, I can run some tests and produce a batch file if you think that would be suitable.

Comment by Mike Jang [X] (Inactive) [ 11/Mar/16 ]

Simon Harding I set that up in this install guide appendix

Essentially, post-config, most of OpenIDM works fine in a RO volume; however, it needs access to a RW volume for logs, audit info, cache, and PID, subject to one detail (OPENIDM-5367).

Comment by Mike Jang [X] (Inactive) [ 02/Aug/16 ]

Duplicate of OPENIDM-5344

Comment by Mark Gibson [ 02/Aug/16 ]

dup of OPENIDM-5344

Comment by Mike Jang [X] (Inactive) [ 15/Nov/16 ]

Reopening, as this has more info than the dup , OPENIDM-5344

Comment by Mike Jang [X] (Inactive) [ 03/Apr/17 ]

Moved out of GB 5.5 due to priorities

Comment by Mike Jang [X] (Inactive) [ 02/May/17 ]

Kavya Muthanna [X] what's the priority of this, compared to other JIRAs?

Comment by Mike Jang [X] (Inactive) [ 26/Jul/17 ]

Can we do this "cheaply" – , e.g. with the "login as a service" right?

Comment by Nabil Maynard [ 19/Sep/17 ]

I spent a little time doing some additional investigation on this. Some quick notes:

  • Figured out an issue with install-service.bat (filed as OPENIDM-9286) that was preventing the service from working as documented. Manually fixing it, things worked (and sync'd) just fine with the default service account (Local System).
  • Thing is, we don't want to recommend that as a solution either, since Local System has even more privileges than Administrator. Tried switching to Local Service (a minimal-permissions pre-built service account), and while the service could turn on, it didn't have privileges to actually start up IDM (or even write to the log file that it failed!).
  • Experimented with creating a new service account. Set up a Managed Service Account through Active Directory. It had the same minimal permissions as Local Service by default, so ran into a similar issue. If I manually added this new service account (IDMService) to have read-write-execute permissions on the openidm folder, the service would work as expected, but I'm not sure if this is good practice – it certainly keeps the potential damage the service account can do scoped down, but I suspect any actual Windows admin would give it some serious side-eye.
  • I feel like things are getting kind of into the weeds: since the default service account (Local System) now works, my current thought is remove the bit about switching to the Administrator account, and instead add a note to the Security chapter in the integrator's guide suggesting using service account with limited permissions that has access to the openidm directory. Thoughts?
Comment by Mike Jang [X] (Inactive) [ 19/Sep/17 ]

Looks consistent with https://docs.microsoft.com/en-us/dotnet/framework/windows-services/how-to-specify-the-security-context-for-services

Suggestion: unless we get into deployment documentation (which is a future possibility), find the right Microsoft doc, and refer to it for "best practices".

Perhaps talk directly with Simon Harding about this?

Comment by Nabil Maynard [ 02/Oct/17 ]

Fixed with this PR. Changes are in two spots: Install Guide, and Security chapter.

Comment by Laurent Bristiel [X] (Inactive) [ 03/Oct/17 ]

checked oK

Generated at Sun Sep 27 22:02:00 UTC 2020 using Jira 7.13.12#713012-sha1:6e07c38070d5191bbf7353952ed38f111754533a.