IMan Security Considerations¶
This section covers IMan's security considerations and the configuration IMan needs to work properly. Where IMan needs non-default Windows permissions, use the IMan Permissions Function to configure the local permissions.
Background¶
IMan is distributed: its services perform different but sometimes overlapping tasks. All six IMan services and the IManWebAPI application pool must therefore run under the same, or very similar, security contexts. See IMan Architecture for what each part does.
A default IMan installation runs all six IMan services as LocalSystem, and the IManWebAPI application pool as its own application pool identity, IIS AppPool\IManWebAPI.
The Message Broker service always runs as LocalSystem. It talks only to IMan's own processes on the server, and the Permissions function does not change its account.
When to Alter IMan Service & WebAPI AppPool Security¶
In broad terms, you need to change the security context IMan runs under if IMan needs access to:
- Local file resources whose permissions explicitly remove access for LocalSystem and the WebAPI application pool's identity.
- ANY file resource located on a remote server.
- Applications using Windows or Active Directory based authentication.
See Security Consideration for Resources for more detail.
IMan Permissions Function¶
Describes how to use the IMan Permissions function.
Security Consideration for Resources¶
Describes the local and domain user considerations when using the Permissions function.
IMan Service & WebAPI Application Pool Permissions¶
Describes the access each IMan service and the WebAPI application pool need.
Local Machine Required Permissions¶
Describes the shared permissions required by different components of IMan.