MineMeld can not get O 365 JSON format list

Announcements

ATTENTION Customers, All Partners and Employees: The Customer Support Portal (CSP) will be undergoing maintenance and unavailable on Saturday, November 7, 2020, from 11 am to 11 pm PST. Please read our blog for more information.

Reply
Highlighted
L1 Bithead

MineMeld can not get O 365 JSON format list

Hello

 

[Failure event]
In the case of O365 's xml format, when MineMeld received traffic after ClientHello, I got a list but if I set config for JSON support I can not get a list.

 

[Prerequisites]
MineMeld will go through Paloalto and do Internet communication.

 

[Question]
I think that the packet flow that can be checked with Paloalto is incorrect.
We were able to get the list in xml format, but we can not get JSON format list.
Is there a relationship with the above? What is the cause if there is no relationship?


Accepted Solutions
Highlighted
L1 Bithead

P.S.

As a premise, MineMeld communicates with the Internet through Paloalto.

When we captured MineMeld traffic Paloalto, there is no traffic since "Client Hello" from MineMeld, so the application identification is "unknown-tcp". In xml format MineMeld can get a list even if it becomes "unknown - tcp". However, it can not be acquired in json format.

Is there anything related to the above?

There are other things to worry about. When confirming the number of captures from SYN to FIN / ACK in one request, there are more MineMeld's.

View solution in original post

Highlighted
L1 Bithead

The following is an excerpt of minemeld's "minemeld-engine.log". It is time when minemeld can not acquire the list.

"POST /login?_=1538387082 HTTP/1.0" 200 2 "https://172.16.2.20/#/login" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"
 [DEBUG] redis session connection pool: in use: 0 available: 5
[DEBUG] redis session connection pool: in use: 0 available: 5
[DEBUG] redis session connection pool: in use: 1 available: 4
[INFO] redis connection pool: in use: 0 available: 1

View solution in original post


All Replies
Highlighted
L1 Bithead

P.S.

As a premise, MineMeld communicates with the Internet through Paloalto.

When we captured MineMeld traffic Paloalto, there is no traffic since "Client Hello" from MineMeld, so the application identification is "unknown-tcp". In xml format MineMeld can get a list even if it becomes "unknown - tcp". However, it can not be acquired in json format.

Is there anything related to the above?

There are other things to worry about. When confirming the number of captures from SYN to FIN / ACK in one request, there are more MineMeld's.

View solution in original post

Highlighted
L1 Bithead

The following is an excerpt of minemeld's "minemeld-engine.log". It is time when minemeld can not acquire the list.

"POST /login?_=1538387082 HTTP/1.0" 200 2 "https://172.16.2.20/#/login" "Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0) like Gecko"
 [DEBUG] redis session connection pool: in use: 0 available: 5
[DEBUG] redis session connection pool: in use: 0 available: 5
[DEBUG] redis session connection pool: in use: 1 available: 4
[INFO] redis connection pool: in use: 0 available: 1

View solution in original post

L1 Bithead

It is part correction. The above log is "minemeld - web.log" instead of "minemeld - engine.log".

Highlighted
L1 Bithead
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!