About jgomes

Can you kindly share the integration instance settings? namely the query used for fetch. If set correctly, XSOAR should not be returning any incidents from the API with 'magnitudes' under threshold - used to filter 'fetch' I also suggest test query in Qradar API playground to ensure it performs as expected. If it doesn't, cross reference the search/query syntax with Qradar documentation, test again Qradar API playground, then update you integration instance in XSOAR. Hope this helps. ... View more

The error indicates permission related to the Index or macro.. I do see you have the 'first fetch' look back to 3 months which should find data otherwise. If this was the first fetch. I suggest testing the query in Splunk API directly and double check your API permissions.  https://docs.splunk.com/Documentation/Splunk/8.2.5/RESTTUT/RESTsearches Do you get same error on your original search query without using expand token? Perhaps try that again with larger window.. like 1 month+ to cover time the data datetime range If XSOAR has fetched once already (the radio button for fetch in integration) then it will fetch the look back window once, then every minute (for the last minute) by default. Here you should delete instance and create a new one, so the first fetch goes back one month as configured.  First use test to ensure no permission issues. Hope this helps. ... View more

Hello! 1. Please also try encapsulating the index name as per default example when creating new instance. eg. search `notes` | expandtoken 2. Reset timestamp - unless you know you have new data coming in or within the look back windows (15mins by default) 3. Double check you you have latest content pack installed 4. double check time on your new system (sync with NTP) 5. You can debug a test fetch with:  !<instance_name>-fetch debug-mode=true      reference - xsoar.pan.dev/docs/reference/articles/troubleshooting-guide  Please let us know how you go! ... View more

Just pass it as another argument. This should work: return_results(demisto.executeCommand("azure-sentinel-list-incident-entities", {"incident_id":"xxxxxxx-xxxxxx-xxxxx", "raw-response":"true"})) ... View more

Hi, just checking-in on this older post that you had you question resolved. If any posts have helped you resolve your issue, please kindly accept one of the solution answers. ... View more

How did you go with your support ticket?   If my posts have helped you resolve your issue, please kindly accept one of the solution answers.   ... View more

How did you go?  You could simply clone the integration, duplicate one of the API (Get/Post) functions, and add new command name. This way your simply adding the additional API end-point your looking for (re-using instance credentials). If this has now answered your question, please kindly accept one of the solution answers. ... View more

I noticed no other responses to your additional question. XSOAR will continue to run but with the license restrictions noted for community edition. This is normally adequate for Dev and training. During or soon after you evaluation, someone should reach out to you to discuss evaluation and if you require a production license. This is based on the information you filled in when obtaining the community edition. If you are an existing PAN customer, you will have an account team to reach out to - to discuss production license. If your new PAN customer, you can contact sales directly https://www.paloaltonetworks.com/company/contact-sales As noted, you are are eligible for additional dev/training license matching you production license and seat count If this has now answered all your questions, please kindly accept one of the solution answers. ... View more

Yes, BYOI is one way. BTW there is an good tutorial here if you like:  https://xsoar.pan.dev/docs/tutorials/tut-integration-ui/ It does sound like however the integration has what you need to fetch report and update group. So your ‘report parsing’ code could be converted to an automation - and do this in the playbook. Eg fetch report, taking report data from context when you run your script/automation, which create list of ips in context. Then the next playbook task the standard ‘update group’ with $ctx.key[] using existing integration commands. You could also take approach to clone OOTB integration. Modify the code with your function to run/ get api response result and additional api actions all in the customer integration code. Just add to the new command in code and yaml config.   Hope that helps! ... View more

Yes, you can self obtain Community Edition https://start.paloaltonetworks.com/sign-up-for-community-edition.html It is fully functionally for 30days, and thereafter some limitations of feeds and daily automations counts imposed. https://docs.paloaltonetworks.com/cortex/cortex-xsoar/6-2/cortex-xsoar-admin/cortex-xsoar-overview/cortex-xsoar-licenses.html When you subscribe to a license, you're also eligible for Dev or Training licenses as part of your subscription. Good luck in your evaluation! ... View more

Hi Thomas,   It is correct the platform is geared towards using integration to safely store and handle credentials. Integrations come with other features like integration context to store instance objects and methods like fetch.  Yoda Speaks is a good tutorial on creating your first simple integration - https://xsoar.pan.dev/docs/tutorials/tut-integration-ui That said, if the credentials is not very sensitive you can still leave in automation code. You can use RBAC to restrict access for less privileged users to see automation IDE and code.   There is also a automation setting argument tick box called ‘sensitive’. When set, it will popup a password box at time of run for analyst to type in password, and thus not stored in code. This would be for on demand playground CLI or war room.   cheers ... View more

Debug appear not very useful in this case. I would imagine this still has to do with being on-premise, and our content tested for Cloud Cherwell. Please raise a support ticket and/or raise AHA request for content enhancement - in order to support on-premises version of Cherwell as well. Best of luck going forward. https://xsoar.ideas.aha.io/ideas/search?utf8=%E2%9C%93&query=Cherwell   ... View more

From playground, run fetch and test module in debug mode. This may provide more clarity on what fetch and test failure is doing:     !<instance name>-fetch debug-mode=true !<instance name>-test-module debug-mode=true   ref: https://xsoar.pan.dev/docs/reference/articles/troubleshooting-guide   Also on 6.2 you can select debug mode in instance settings (drop list) which saves the debug log to disk in: /var/log/demisto/ integration-instance.log Also, you may want to check the API directly with POSTMAN or with basic REST Python script. https://help.cherwell.com/bundle/cherwell_rest_api_940_help_only/page/oxy_ex-1/content/system_administration/rest_api/csm_opening_swagger.html#OpenSwagger   I also assume your were using Windows auth for SSO. There also appears other options like LDAP, SAML, and 'internal' - depending on your on-premise setup. ie. for getting a token successfully appending ?auth_mode= https://help.cherwell.com/bundle/cherwell_rest_api_940_help_only/page/oxy_ex-1/content/system_administration/rest_api/csm_rest_about_authentication_modes.html   ... View more