Teams Integration Broken

InsightConnect
1

Thought I would post here in case others run across a similar issue.

Up until about two months ago, the Microsoft Teams plugin worked great for me. One of my key workflows was to whitelist blacklist IPs on my firewall. I’m not sure what changed, but my Teams workflows no longer work.

Testing the connection is successful but the workflow never starts.

I’ve tried updating the plugin to version 4.0.0 without any luck.
The account I’m using to connect is an Owner of the Team I’m trying to interact with.

I have a case open with Rapid7 and time scheduled to work with an engineer. I will post more info about a fix as I learn more.

1 Like
2

Did you look at the teams trigger logs on the orchestrator? Wonder if the creds expired or authorization expired in Azure AD.

3

Also, check your RegEx and make sure you are starting a new conversation and not responding to a previous one.

4

I would also check the app registration permissions and make sure something didn’t get changed.

You need:

  • Delegated Permissions:
    • Chat.ReadWrite
    • Group.ReadWrite.All
  • Application Permissions:
    • Directory.ReadWrite.All
    • Group.ReadWrite.All

The above is from: Microsoft Teams Connection Guide | InsightConnect Documentation

I recently saw a perfectly working setup suddenly stop working and it was due to the above. Some helpful admin had removed the ReadWrite.All permissions.

5

Can you point me to those trigger logs? I’m not sure where to find them.

6

I’m assuming the RegEx is correct as the workflow is an imported workflow from the extensions library and was created by Rapid7.

7

If a trigger isn’t working or an action is failing, the best way to debug the issue is to get the docker container ID of the orchestrator to get logs and manage or stop problematic processes.
If you’re specifically looking for a trigger, it can be helpful to run this command: sudo docker ps -a | grep Teams | grep trigger on the orchestrator

Once you have the container ID, use the following command to grab associated logs for further troubleshooting: sudo docker logs -f <trigger container id>

These logs may tell you enough about the issue to understand what’s going wrong. For example, it is common to see a very hard failure to start a trigger due to incorrect credentials.

The container ID is the left-most column in the output of the command. You can continue to use grep to further isolate specific containers, per your level of comfort with grep

8

I reviewed these permissions in Azure and reapplied a couple of them so they match the document exactly. That did not seem to fix the issue.

9

You may want to disable and then re-enable the workflow so it rereads them.

10

Thanks rfried.
I found this in the log. What license is required for the user? It seems someone may have removed a license from the account.

{“error”:{“code”:“Forbidden”,“message”:“Failed to get license information for the user. Ensure user has a valid Office365 license assigned to them.”

11

Your service account must have a Teams license. That is probably what it is referencing.

12

Alright! It’s working now. We have not had the license assigned for several months, so for some reason it was working for a while without the license assigned. A sys admin reassigned a license and it’s working again.

Thanks Matt and rfried for the feedback!

1 Like