Issue
This article aims to explain the issues surrounding using an LDAP User for the instance user that the MID Servers log in with.
Quick answers:
- Q: Is it sensible to use an LDAP user for the MID Server?
- A: No
- Q: Can a MID Server's password be updated from the instance?
- A: No
Related Links
The MID Server initiates a connection with the instance, and only once that connection is made is it Up and communicating with the instance. It is very similar to an inbound REST or SOAP integration in that respect, and will log into the instance in the same way.
The username and password of a mid_server role user in the instance is set in the config.xml file of the MID Server either during the initial installer setup or manually subsequently. That is the only way to set a MID Server installation's login password. The reason for that is likely because it would only work if the MID Server was up and communicating with the instance at the time of the change in the instance, which is not guaranteed.
There is no technical reason why a user that is synchronized with LDAP can't be used for the MID Server, but this has caused problems with the MID Server suddenly being unable to authenticate with the instance, which means the MID Server instantly goes Down. This has lead to many support Cases in the past, including:
- The account may become Locked Out or Inactive for any reason in LDAP. Perhaps someone or something else using that username for a different system caused it to be locked out due to too many failed attempts. Or perhaps it wasn't reset before a password policy deadline. The “User must change password at next logon” may be enabled for the account due to AD password complexity requirements.
- The account password was changed in LDAP, and would then be imported to the instance user table. The MID Server will continue to use the password from the config.xml file. Perhaps a username had been shared between other integrations in addition to the MID Server, and the MID Servers were forgotten in the process.
- If LDAP Authentication is also used for the MID Server user, in addition to LDAP Import for user details, then a problem with the LDAP server would cause the MID Server to fail to authenticate and go Down, even though there is no issue with the ServiceNow Instance, MID Server, or connection between.
To prevent those clear risks of an unplanned MID Server outage, and therefore an integrations/Discovery/event management etc. outage, the recommendation is:
- Create the user in the sys_user table of the instance directly, and enter the password in there at the time. That can be confirmed for existing users by checking that the 'source' field of the user record is empty.
- Do not use an external user that is synced to the instance, such as via LDAP.
Note: If you must use an LDAP password due to security requirements, make sure you have a manual or preferably automated password sync tool in place such as CyberArk, which is known to be able to do this. For help with what would need automating on the MID Server-side, see KB0746702 How to Update a MID Server password - Never use a user that relies on LDAP Authentication for the instance. An LDAP outage will cause a MID Server outage.
- Do not use this user for anything else other than as the username for MID Server installations, and make the username clear that it is for a MID Server. Don't allow real people to log in from a browser with this username. Don't run scheduled jobs such as Imports as the user.
- Only assign the mid_server role to this user, and not admin. There is no need for the user to be admin, and if you find this works as a workaround for a problem, then this is a bad workaround and the ACL rules should be fixed properly instead.
- MID Servers don't all have to share the same user. For improved auditing and troubleshooting, and to prevent a single user issue affecting more than it could, creating a different user for each MID Server is possible, or possibly a user per region or MID Server Cluster if you feel that's over the top.
