TGIF is BACK! Every Friday, we bring you the tips, tricks, and FME insights to make you the most powerful person in the room when it comes to data integration. Today’s post is brought to you by one of our Flow Technical Support Specialists, Aaron! So with that, let's dive into this week’s topic - service accounts in FME Flow!
Every deployment of FME Flow has 5 main components:
- Application Server
- Core
- Database
- Engine(s)
- System Share
The System Share refers to the physical location of the directory that stores Repositories and Resources on FME Flow. This can be in the default location, on the local system, or on a file server (accessed using a UNC path). However, the other four FME Flow components run as system services on the host server.
It’s worth noting that by default, FME Flow is not configured to start as a system service on Linux. Configuring this is considered an advanced task, and therefore is not recommended for new FME Flow users. Due to this distinction, the remainder of this post will focus on Windows installations of FME Flow. If you would like to learn more about Linux deployments, please consult our documentation.
On an Express installation of FME Flow, these 4 services currently run under the “Local System” account by default. However, there are certain features or workflows in FME that require these services to be run by a different account, often referred to as a service account. Within FME Flow, service accounts can typically include group-managed service accounts (gMSAs), domain service accounts, or domain user accounts.
This post won’t get into the nitty-gritty of which type you should use (see this article if you are interested in this topic). However, this will act more as an introduction to service accounts, why/how to use them in FME Flow, and some important requirements and considerations to know beforehand.
Why Use a Service Account?
Here are some common scenarios of when a user would want to run the Flow services under a service account:
- Accessing a Network File Share - as mentioned previously, Express installations of FME Flow utilize the Local System account for all four services by default. However, this account does not allow FME Flow to access directories outside of the host server (e.g. a network-based file share). If your workspaces require you to read/write files that are located in such a directory, you will need to utilize a service account.
A common use case for FME users is running a workspace that accesses an Esri SDE geodatabase. Accessing these databases requires a connection (.sde) file, which organizations will often store on a shared network drive. In order to access these geodatabases and run these workspaces in FME Flow, that network drive location must be accessible to the service account running the system services.
Another example would be reading/writing to an Excel spreadsheet that is shared within an organization. Shared resources like these that need to be accessed outside of FME are often not stored in the System Share, but rather on a shared file server.
- Accessing other Authenticated Endpoints - this is closely related to the previous point, as some workspaces require access to certain authenticated endpoints apart from a file directory.
A common example is a SQL Server database that utilizes Windows Authentication. In this situation, having a Database Connection which is stored in FME Flow isn’t enough to access the database in your workspace - the service account running the services (specifically the Engine service) needs to have permission to access the database as well.
- Distributed/Fault-Tolerant Installations - if you are performing a Distributed or Fault-Tolerant installation of FME Flow, a service account is often used (and is required whenever the System Share is located on a separate server than other components). The service account ensures proper communication between the various servers that make up a typical distributed installation.
We won’t go too in-depth on this topic in this post, so be sure to review our documentation if you plan on distributing FME Flow components across multiple servers.
Requirements and Considerations
If you’ve decided that you want to run your Express installation under a service account, there are a few key requirements and points to consider before making this change:
- File Permissions - as stated previously, the Local System account that currently runs FME Flow by default will already have access to the directories required for basic functionality. However, if you are switching to a service account, you will have to give the account explicit read/write access to both the System Share, as well as the installation directory to ensure that FME Flow runs properly (jobs can be submitted to the queue, logs are generated, etc.). If you are using ArcGIS Server for related formats, you will also need to ensure the user can access the ArcGIS Server installation folder in order to execute licensing requests and access the ArcGIS Python interpreter.
Additionally, if you are planning on reading or writing files in a specific directory (e.g. network file share), the service account will need explicit access to these locations as well.
- User Permissions - it’s important to remember that certain workflows will require additional permissions at the FME Flow user level, as well as at the service account level.
To continue with the previous geodatabase example - not only will the service account need access to the file share location where the connection file is stored, but if a user is logged into the UI and triggering the job, that user account also needs permission to access the Database Connection stored in FME Flow for that geodatabase. Understanding the relationship between service account permissions and user permissions is key, and will hopefully help you avoid access-related errors in your workflows.
- FME Flow Database Requirements - when switching to a service account, it’s important that only the Core, Engines, and Application Server services run under the service account. Due to dependencies with the FME Flow Database, this service must remain under the Local System account. This applies only to the FME Flow Database service - if you have distributed your database and are using PostgreSQL, SQL Server, or Oracle Server, this does not apply.
- Single Service Account - we generally recommend using a single service account to run the Core, Engines, and Application Server, rather than using multiple accounts across these services.
This is the recommended approach because when a job is submitted in FME Flow, these three services interact in such a way that they all require the same level of access to any associated files/directories (uploaded data, network shares, etc.). Rather than having a different service account to run each service, it is much simpler to manage a single account that has the necessary permissions for all three services.
Final Thoughts
If you’re looking to expand the capabilities of your Express installation of FME Flow, using a service account to run the system services is a great choice! As long as your account is set up with the proper permissions, this can allow you to integrate even more data sources in your enterprise workflows.
If you’re interested in setting this up for yourself, please review the following sections of our documentation:
Thanks for spending part of your Friday with us learning about Service Accounts. Next week we're diving into Data Lakehouses — you won't want to miss it. See you then! 👋