5087 views

Table of Contents

  1. Is the MID Server user configured correctly in the config.xml?
  2. Is the MID password in the config.xml correct?
  3. Does the MID password have special characters?
  4. Does the MID Server user in the config.xml file have correct roles on the instance?
  5. Is the MID Server user locked out on the instance?
  6. Was the instance recently cloned?
  7. Was the instance recently reinstalled?

 

Symptoms

  • All MID Servers are down
  • CIs are duplicated during Discovery
  • The MID Server keeps going down
  • The MID agent log is reporting: 404, could not authenticate
  • The MID Server upgrade is hung
  • The MID Server cannot restart

Details

Along with a clear communication path to the instance, the MID Server requires a valid user to authenticate with. The inability of the MID Server to successfully authenticate with the instance will affect the MID Server's ability to install, upgrade, and execute services for the instance. Most authentication issues are reported either in the MID Server's agent log or wrapper log. 

Question and Answer

  • Is the MID Server user ID entered accurately into the agent/config.xml on the MID host machine?
    • I don’t know.
      • To determine whether the MID Server user is properly entered into the config.xml:
        1. Log on to the host machine as a local admin or the MID Server user.
        2. Navigate to the /agent directory where the MID was installed.
        3. Edit the config.xml file.
        4. Search for the parameter: mid.instance.username.
        5. Copy the value of that parameter into your buffer.
        6. Return to the instance.
        7. In the text editor, navigate to Organization > Users.
        8. Search for User ID = [the name in your buffer].
          • NOTE: you could also attempt to log in to the instance from the browser of the host instance using the user name.
    • Yes, the MID Server user is entered correctly in the Organization > Users database.
      • If the MID Server user's ID is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]
    • No, the MID Server user does not exist in the user database on the instance.
      • ROOT CAUSE: The MID Server user on the instance and the MID Server user in the config.xml must match. Sometimes after cloning a production instance to a development instance, there are mismatches in the user name and passwords as MID Servers are not cloned along with the instance.
      • SOLUTION: Either update the MID Server user's user name on the instance or in the config.xml file. As a word of caution, often a single MID Server user name is used across multiple MID Servers and MID Server clusters. Therefore, updating the config.xml is the least problematic option.

 

  • Is the MID Server user password properly entered into the agent/config.xml?
    • I don’t know
      • If the MID Server user password is not correct, the agent log will report a 'failed to authenticate' error. To see if this is the case:
        1. Log on to the host machine of the MID Server in question.
        2. Navigate to the agent/logs directory.
        3. Edit the agent log.
        4. Search for the phrase: failed to authenticate.
        5. If you find the authentication error, the MID Server user password is not correct providing you have already validated that the MID Server user ID is correct.
    • Yes, the MID Server user password is properly entered into the agent/config.xml.
      • An incorrect password in the config.xml file is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]
    • No, the MID Server user password is not properly entered into the agent/config.xml.
      • ROOT CAUSE: The MID Server relies on the mid.instance.password parameter in the config.xml to provide the appropriate authentication to connect to the instance. The value set is typically entered in clear text, either directly in the config.xml or through the MID Installer. Once the MID Server reads the password, it rewrites the parameter value as the encrypted version of the password. Because of this, it is difficult to validate the password in the config.xml visually. You have to rely on the logs to do that. 
      • SOLUTION: If you know the password, you can stop the MID using the scripts in the /agent directory on the host machine and edit the config.xml file with the correct known password. Restart the MID Server. If the password is correctly entered, the MID Server will resume service. If the password is not correct, you may need to reset the MID Server user password.

 

  • Does the MID Server user password contain special characters?
    • Yes, the MID Server user password contains special characters.
      • ROOT CAUSE: Though it is common practice to include special characters when creating a strong password, at this time the MID Server cannot guarantee these characters will be parsed accurately when the config.xml file is consumed. Passwords in the config.xml file are entered in clear text and encrypted and re-written as soon as the MID Server is started for the first time. Essentially, the special characters can interfere with the xml parse of the configuration during this encryption phase.
      • SOLUTION: Update the MID Server user password to use letters and numbers to create strong passwords.
    • No, the MID Server user password is not properly entered into the agent/config.xml.
      • Special characters in the password is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]

 

  • Does the MID Server user exist on the instance with the appropriate roles? 
    • I don’t know.
      • To find out if the MID Server user has appropriate role:
        1. Navigate to Organization > Users.
        2. Search for User ID = {{your MID Server user Name}}
        3. In the Related Lists section at the bottom of the form, select the Roles tab.
        4. At a minimum, there should be an entry to mid_server.
    • Yes, the MID Server user is assigned the mid_server role.
      • Lack of mid_server role is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]
    • No, the MID Server user is not assigned the mid_server role.
      • ROOT CAUSE: In order for the MID Server user to have access to tables like the ECC queue and to have permission to execute tasks specific to managing MID Server requests, the user must be assigned at a minimum the role of mid_server. Other services and applications, such as Discovery and Orchestration, may require other roles. Read more about the list of roles that could be used by services provided by MID Server.
      • SOLUTION: Assign the MID Server role to the MID Server user. 

 

  • Is the MID Server user locked out?
    • I don't know.
      • To find out if the MID Server user has been locked out:
        1. Navigate to Organization > Users from the left navigation text filter.
        2. Search for User ID = to you MID Server user ID.
        3. Open the user record.
        4. Locate the Locked Out field. If it is checked, the user is locked out.
    • Yes, the MID Server user is locked out.
      • ROOT CAUSE: The password associated with your MID Server user ID is locked out. This is caused by a delta between what is in the config.xml of one of the MID Servers that the MID Server user is authenticating for, and the password in the user record. Some causes of this can be a newly installed MID with a typo in the config.xml, a recent clone of the instance that has running MID Servers running against an instance will attempt to log in several times and fail. This could cause the user to be auto-set to locked out. System administrators may also proactively set the user to locked out manually.
      • SOLUTION: Reset the MID Server user password.
    • No, the MID Server user is not locked out.
      • The MID Server user not being locked out is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]

 

  • Was the instance recently cloned?
    • I don't know.
      • There is no way to determine if an instance has been cloned looking at the instance. The clone is initiated by your SNC Administrator from the source instance. Contact your Administrator for confirmation of a clone.
    • Yes, the instance was recently cloned.
      • ROOT CAUSE: When an instance is cloned, MID Servers that are pointing to the cloned instance are not cloned over. Because of this, there may be a mismatch with your MID user and/or MID password if the sys_user account for your MID Server gets modified or removed based on the clone (since sys_user records are cloned over by default).
      • SOLUTION: Reset the MID Server user password.
    • No, the instance was not recently cloned.
      • Mismatched credentials due to MID Servers pointing to a cloned instance is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]

 

  • Was the MID Server recently reinstalled?
    • I don't know.
      • There is no way to determine if MID Server has been reinstalled. The reinstallation of a MID Server is a manual process performed on the host machine of the MID. Contact your system administrator or network administrator to determine if the MID Server was reinstalled. 
    • Yes, the instance was recently reinstalled.
      • ROOT CAUSE: When a MID Server is reinstalled, the MID Server must be re-validated from the instance. This requires a reset of the keystore on the MID Server host. 
      • SOLUTION: Reset the MID Server user password.
    • No, the instance was not recently reinstalled.
      • A corrupted keystore due to the MID reinstall is not the issue preventing successful authentication. Keep troubleshooting. [Back to top]

 

Article Information

Last Updated:2018-05-29 06:08:20
Published:2018-05-29