This issue will track the bugs being addressed by the branch created to fix them.

Get-LrCaseMetrics

182: Start-Sleep -Milliseconds 50

50 milliseconds isn't enough in some cases - need to come up with a more elegant way to handle throttle issues and slow down requests.

Get-LrCasePlaybookProcedures

This command uses CaseId, and Id for the id of the playbook attached to a case. Currently the command is sending Id to validate CaseId which will always result in an error.

Fix: Pass CaseId instead of Id for Test-LrCaseIdFormat (line 88)

Update-LrCasePlaybookProcedure

1. This command uses CaseId, and Id for the id of the playbook attached to a case. Currently the command is sending Id to validate CaseId which will always result in an error. Fix: Pass CaseId instead of Id for Test-LrCaseIdFormat (line 158)

2. Add validation to Status parameter. As a result lines 267-280 are no longer needed.

3. If the username provided to the command results in more than one account, we need to handle this. Fix: add -Exact parameter to Get-LrUsers.

Test-LrUserIdFormat

Somehow a codeblock ($OutObject) was moved outside of the Begin block, resulting in errors any time this command was run. Fix: Moved lines 36-40 into the Begin block.

(Missing) Update-LrCase

We definitely should have an Update-LrCase for 1.0 - not sure how we missed it. Fix: added

@Jt3kt want to make sure you review this.

Issues

• master is ahead of other branches by 7 commits, this should never occur
• development should only be merged into master for releases and bug fixes. (nothing I can do about that now)
• need to always use PRs when updating development or master

Actions

• I am going to merge master changes down into development to avoid any issues.
• Prune old branches that have already been merged.

Expected Behavior

When an IPv6 address is passed to Test-ValidIPv4Address, the function should return $false.

Actual Behavior

When an IPv6 address is passed to Test-ValidIPv4Address, the function returns $true, even though it is not a valid IPv4 address.

Steps to Reproduce the Problem

1. Import-Module LogRhythm.Tools
2. Test-ValidIPv4Address -IP '2406:da1c:20f:2f00::'
3. Returns $true

Specifications

• Version: LogRhythm.Tools 1.3.2, independent of LogRhythm version
• Platform: Windows(Desktop and Core), Mac, Linux
• Subsystem: General

The impact of this is that when performing a Find-LrNetworkByIP, and certain IPv6 networks are defined, these networks are matched incorrectly as only the last 4 "octets" of the IPv6 address are used in the comparison, frequently being between 0 and 4294967295.

Required Sections

1. How to install LR Tools
2. Guidance on handling permission issues, reference MS Docs as well
3. Guidance on how to test install was successful
4. Matrix on which LR Cmdlets are supported in which version of LR

Would like to capture gifs that showcase going through the installer.

Optional Sections

1. Teach me to crawl
2. Teach me to walk

Expected Behavior

When Update-LrList calls the API and gets an SQL Transaction Deadlock error, it should retry (up to max retries).

Actual Behavior

When Update-LrList calls the API and gets an SQL Transaction Deadlock error the list is not updated with new values.

Steps to Reproduce the Problem

This problem is somewhat intermittent, and dependent on overall platform performance.

1. Execute an Invoke-RfSync several times on a production system to induce the problem, perhaps concurrently from two shells.
2. Alternatively, execute an update of the same list using Update-LrList simultaneously using two shells.

Specifications

• Version: 1.2.2
• Platform: LogRhythm 7.7.0
• Subsystem: Admin/Lists

Output from error:

[07/14/21 09:13:41] - Updating List: RF : IP : ConfLo : Phishing Host
Invoke-RestMethod: F:\Installers\LogRhythm\LogRhythm.Tools\build\debug\d45d613f-b7bb-4478-b811-ac79fd4c8e15\1.2.1\Public\LogRhythm\Admin\Lists\Update-LrList.ps1:427
Line |
 427 |  … $Response = Invoke-RestMethod $RequestUrl -Headers $Headers -Method $ …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | {"statusCode":500,"message":"mssql: Transaction (Process ID 123) was deadlocked on lock resources with
     | another process and has been chosen as the deadlock victim. Rerun the transaction."}

Overview

Install Scope is used as the path to where modules are installed for the system.

• User Scope: $HOME + Documents\WindowsPowerShell\Modules
• System Scope: $PSHOME or $Env:ProgramFiles - typicall t

Option 1

Update Install-Lrt to prompt the user for an install location if the standard install scope path can't be found.

Option 2

Update Setup.ps1 to accept a custom module install location which is then passed to Install-Lrt as a parameter.

Expected Behavior

Scenario:

• User has LRT installed w/ config in place
• New release that includes changes to config LogRhythm.Tools.json
• When new version is installed, the two are merged or otherwise updated with the new structure
• Previous values are retained?

Actual Behavior

Currently the existing configuration in LocalAppData is not changed at all.

Steps to Reproduce the Problem

1. Make a new section to LogRhythm.Tools.json
2. Run from tests\Lrt.Publisher\Test-LrtPublish.ps1
3. Setup will fail to update configuration because the old version wasn't updated.

The property 'DomainName' cannot be found on this object. Verify that the property exists and can be set.
At C:\repos\_community\LogRhythm.Tools\tests\Lrt.Publisher\data\lrt-install\Setup.ps1:202 char:17
+ ...             $LrtConfig.($ConfigCategory.Name).($ConfigField.Name) = $ ...
+                 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : PropertyNotFound

Expected Behavior

Output from Get-LRIdentityById handles UTF-8 names correctly.

Problem

Actual Behavior

Output is encoded using "ISO-8859-1"

Steps to Reproduce the Problem

1. Create Identity with first name Joël (for example).
2. Perform Get-LrIdentityById [INSERT_ID]
3. Output shows Joëll

Workaround

1. $bytes = [System.Text.Encoding]::GetEncoding("ISO-8859-1").GetBytes($identity.nameFirst)
2. [System.Text.Encoding]::UTF8.GetString($bytes)

Specifications

• Version: LogRhythm.Tools 1.2.2
• Platform: LogRhythm 7.8.0.8004
• Subsystem: Admin/Identities API

Should we build a more complete Case object? Include Playbooks, Notes, etc?

Feature
Story board design the public & private cmdlets that would be required to support:

• Retrieving health status for Elasticsearch

  • Cluster
  • Node
    • Status
    • Roles
  • Shards
  • Indexes
    • Status

• Apply configuration changes to support

  • Rolling restarts
  • Cluster Zones
  • Close Indexes
  • Open Indexes
  • Delete Indexes

System Capability to:

• Remote authentication
• Service management
• Service health

Expected Behavior

When calling Update-LrAlarm -AlarmId 1234 -RBP 96, the function should use the current status of the alarm.

Actual Behavior

When calling Update-LrAlarm -AlarmId 1234 -RBP 96 it returns an error as follows:

Test-LrAlarmStatus: F:\Installers\LogRhythm\LogRhythm.Tools\build\debug\7ff64328-a280-42ac-80a9-eb0e29ceef64\1.2.1\Public\LogRhythm\Alarms\Update-LrAlarm.ps1:150
Line |
 150 |  …       $ValidStatus = Test-LrAlarmStatus -Id $AlarmDetails.alarmStatus
     |                                                ~~~~~~~~~~~~~~~~~~~~~~~~~
     | Cannot bind argument to parameter 'Id' because it is an empty string.

This is because the alarmStatus property is a sub-property of $AlarmDetails.alarmDetails.

$AlarmDetails is obtained using Get-LrAlarm -AlarmId 1234, without the -ResultsOnly option when no updated status is supplied.

PR Incoming.

Steps to Reproduce the Problem

1. Locate a valid AlarmId
2. Call Update-LrAlarm -AlarmId $AlarmId -RBP 96
3. Observe the error

Specifications

• Version: development
• Platform: LogRhythm
• Subsystem: Alarms

Decouple ID handling logic from the Lr Case commands into a private test command.

Existing Code

# Test CaseID Format
$IdFormat = Test-LrCaseIdFormat $Id
if ($IdFormat.IsGuid -eq $True) {
    # Lookup case by GUID
    try {
        $Case = Get-LrCaseById -Id $Id
    } catch {
        $PSCmdlet.ThrowTerminatingError($PSItem)
    }
    # Set CaseNum
    $CaseNumber = $Case.number
} elseif(($IdFormat.IsGuid -eq $False) -and ($IdFormat.ISValid -eq $true)) {
    # Lookup case by Number
    try {
        $Case = Get-LrCaseById -Id $Id
    } catch {
        $PSCmdlet.ThrowTerminatingError($PSItem)
    }
    # Set CaseNum
    $CaseNumber = $Case.number
} else {
    # Lookup case by Name
    try {
        $Case = Get-LrCases -Name $Id -Exact
    } catch {
        $PSCmdlet.ThrowTerminatingError($PSItem)
    }
    # Set CaseNum
    $CaseNumber = $Case.number
}

Is your feature request related to a problem? Please describe.
In processing the results from the AIE Drilldown Cache API, LogRhythm.Tools removes the Rule Block identifier from the Summary Fields. This precludes formatting the resulting data in a fashion similar to what is provided the LR Web Console as there is no indication which rule block each summary came from.

Describe the solution you'd like
If the RuleBlockId is included in the Get-AieDrillDownResults.SummaryFields as well as in Get-AieDrillDownSummary then the resulting information can be formatted/presented in a similar way to the Web Console Inspector.

Describe alternatives you've considered
Re-summarising the DrilldownLogs provided in the Get-AieDrilldownResults is challenging to achieve the same results, and essentially re-performs the work already performed by the AIE Cache Drilldown Service.

Additional context
The following screenshot is representative of the type of information presented in the WebConsole:

I'd like to add LogRhythm Web Console hostname to LrtConfig for future use.

Creates problems when you try to build the module, it creates "binary" files.

Expected Behavior

When requesting all network entries for an Entity, the results should be returned quickly, with no duplicates. For 1261 networks, by default, that should be 2 pages.

Actual Behavior

When requesting all network entries for an Entity, the results take a while to retrieve. Using verbose, this indicates that ~262 requests are made.

Steps to Reproduce the Problem

1. Call Get-LrNetworks on an entity with > 1000 entries, or use a smaller value for PageValuesCount with Verbose option
2. Observe large number of requests.

Specifications

• Version: LogRhythm.Tools 1.3.2, LogRhythm 7.9.0
• Platform: Windows Server 2016
• Subsystem: lr-admin-api - Networks

Sample Logs

Get-LrNetworks -Entity 'Global Entity' -verbose
VERBOSE: [Get-LrNetworks]: Validating Entity as String.  EntityName: Global Entity
VERBOSE: [Get-LrEntities]: QueryString is [?count=1000&offset=0&dir=ascending&name=Global Entity&orderBy=name]
VERBOSE: [Get-LrEntities]: Request URL: https://lab-xm:8501/lr-admin-api/entities/?count=1000&offset=0&dir=ascending&name=Global Entity&orderBy=name
VERBOSE: GET with 0-byte payload
VERBOSE: received 203-byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrEntities]: Exact list name match found.
VERBOSE: [Get-LrNetworks]: QueryString is [?count=1000&offset=0&Entity=Global Entity&recordStatus=active]
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=0&Entity=Global Entity&recordStatus=active
VERBOSE: GET with 0-byte payload
VERBOSE: received -byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrNetworks]: Begin Pagination
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=1&Entity=Global Entity&recordStatus=active
VERBOSE: GET with 0-byte payload
VERBOSE: received -byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=2&Entity=Global Entity&recordStatus=active

Feature
Feature to add in support for creating dedicated PowerShell Core packages.

As Linux/PowerShell Core has a different yet consistent folder structure we should establish the automation to create dedicated release packages to support this platform to enable installation and management.

Describe the solution you'd like
A release experience that would be similar to this:

Publish-LrtBuild -BuildId 3a975a7a-f843-4c2d-a76b-61cf5736d118 -Destination "C:\temp" -PackageType "PSCore-Linux"

It would be acceptable for the default release package produced to be the Windows 5.1 experience we have today.

1. Command name should be updated, improper verbs can result in users receiving warning messages.
2. Command uses abbrev LrPs, should be Lrt. Commands inside of the LogRhythm folder / specific to LogRhythm use Lr. Outside of LogRhythm folder use Lrt, since they are still associated with LogRhythm.Tools.

Alternative: Since this command chops up a collection into the desired number of smaller collections - the verb split would be appropriate here:

• Split-LrtCollection (more generic than "array")
• Split-LrtArray

Expected Behavior

When calling Get-LrNetworks with either or both of the BIP or EIP arguments, their values should be added to the query string, resulting in the API performing filtering of the networks.

Actual Behavior

When calling Get-LrNetworks with either of the argument, their values are ignored, and all networks that match remaining parameters are returned.

Steps to Reproduce the Problem

1. Call Get-LrNetworks -BIP 1.1.1.0 -Verbose
2. Output shows repeated calls to get more networks until all networks are returned. Verbose output shows query string with empty BIP parameter.

Specifications

• Version: LogRhythm.Tools dev-1.3.3 and earlier, LogRhythm 7.9.0
• Platform: Windows Server 2016, PowerShell Core 7.2.5
• Subsystem: lr-admin-api/networks

Sample Logs

 Get-LrNetworks -BIP "51.13.16.0" -Entity 'Global Entity' -verbose
VERBOSE: [Get-LrNetworks]: Validating Entity as String.  EntityName: Global Entity
VERBOSE: [Get-LrEntities]: QueryString is [?count=1000&offset=0&dir=ascending&name=Global Entity&orderBy=name]
VERBOSE: [Get-LrEntities]: Request URL: https://lab-xm:8501/lr-admin-api/entities/?count=1000&offset=0&dir=ascending&name=Global Entity&orderBy=name
VERBOSE: GET with 0-byte payload
VERBOSE: received 203-byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrEntities]: Exact list name match found.
VERBOSE: [Get-LrNetworks]: QueryString is [?count=1000&offset=0&Entity=Global Entity&BIP=&recordStatus=active]
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=0&Entity=Global Entity&BIP=&recordStatus=active
VERBOSE: GET with 0-byte payload
VERBOSE: received -byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrNetworks]: Begin Pagination
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=1&Entity=Global Entity&BIP=&recordStatus=active
VERBOSE: GET with 0-byte payload
VERBOSE: received -byte response of content type application/json
VERBOSE: Content encoding: utf-8
VERBOSE: [Get-LrNetworks]: Request URL: https://lab-xm:8501/lr-admin-api/networks/?count=1000&offset=2&Entity=Global Entity&BIP=&recordStatus=active

Expected Behavior

When creating a list that is not a General Value list, such as IP, Host, Log Source, Classification, etc., list creation should succeed.

Actual Behavior

When creating a list that is not a General Value list the Use Context is supplied with an empy value, breaking LR's List Creation API.

Steps to Reproduce the Problem

1. New-LrList -Name "List Name" -ListType ip -ShortDescripion "List Description" -ReadAccess private -WriteAccess private -Owner 3 -EntityName "Primary Site"

List creation fails with error:

Public\LogRhythm\Admin\Lists\New-LrList.ps1:314
Line |
 314 |  … $Response = Invoke-RestMethod $RequestUrl -Headers $Headers -Method $ …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | {"statusCode":400,"message":"Bad Request","validationErrors":["body.useContext must match one of the
     | following:
     | None,Address,DomainImpacted,Group,HostName,Message,Object,Process,Session,Subject,URL,User,VendorMsgID,DomainOrigin,Hash,Policy,VendorInfo,Result,ObjectName,CVE,UserAgent,ParentProcessId,ParentProcessName,ParentProcessPath,SerialNumber,Reason,Status,ThreatId,ThreatName,SessionType,Action,ResponseCode"]}

Specifications

• Version: development
• Platform: LogRhythm 7.7.0
• Subsystem: Admin API - Lists

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Add capability for LRT to send mail - primary use case would be for notifications used in SmartResponses, such as failures / status, but could be much more.

Describe the solution you'd like
A clear and concise description of what you want to happen.

Multiple templates stored in the config dir (localappdata), which can be specified when the command is run.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

We could leave this up to the user, but I've desired it often enough it may be worthwhile.

Additional context
Add any other context or screenshots about the feature request here.

Expected Behavior

When you Invoke-RfSync, the lists that it creates should be able to be created with a Specific Entity.

Actual Behavior

Since Invoke-RfSync does not cater for specifying the Entity Name (only the Owner), when it calls New-LrList, the default is to use Primary Site. If this entity does not exist, list creation fails.

\LogRhythm\Admin\Lists\New-LrList.ps1:314
Line |
 314 |  … $Response = Invoke-RestMethod $RequestUrl -Headers $Headers -Method $ …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | {"statusCode":404,"message":"Entity name 'Primary Site' not found."}

Steps to Reproduce the Problem

1. Have an LR deployment without a Primary Site entity name
2. Obtain and configure API Keys for both LR and RecordedFuture
3. Run Invoke-RfSync -Owner "Owner Name"

Specifications

• Version: 1.2.0
• Platform: RecordedFuture/LogRhythm
• Subsystem: Lists

Is your feature request related to a problem? Please describe.

When working with LogRhythm Lists, it is possible for lists with Duplicate Names to exist where both Active and Retired lists are present. The default behaviour for Get-LrLists would preferably only return Active Lists, and only return Retired Lists when specifically requested.

Describe the solution you'd like

An added option on the CmdLet to return retired lists when requested would be the preferred solution. This woudl also be in line with behaviour in both LogRhythm Console as well as the Web UI.

Describe alternatives you've considered

Alternatives are to ensure that every list name is unique (for both active and retired lists), and to specify ExactMatch when only one list is desired.

Additional context

This specifically tied in with the Recorded Future functionalith in which it updates lists. I encountered an issue with automation, where I use the Invoke-RfSync, which created lists, then I imported AIE rules from another platform, which also created the same lists, with the same names (some truncated).

Expected Behavior

Expected behavior is to complete successfully when supplying new filePath value to Log Source where the filePath value is currently null or empty.

Actual Behavior

Exception is thrown that states:

Exception setting "filePath": "The property 'filePath' cannot be found on this object. Verify that the property exists and can be set."

Steps to Reproduce the Problem

1. Call Update-LrLogSource on existing Log Source with empty FilePath value. Works fine if there is an existing value.

Specifications

• Version: 1.3.2
• Platform: Windows 10 21H2
• Subsystem: Powershell 5.1

Expected Behavior

I should be able to use LR Tools in cases where the script already set TrustAllCertsPolicy
Add-Type : Cannot add type. The type name 'TrustAllCertsPolicy' already exists.

 At C:\Program Files\WindowsPowerShell\Modules\LogRhythm.Tools\1.0.0\Private\Enable-TrustAllCertsPolicy.ps1:40 char:13
 +             Add-Type $PSDesktopException
 +             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 + CategoryInfo          : InvalidOperation: (TrustAllCertsPolicy:String) [Add-Type], Exception
 + FullyQualifiedErrorId : TYPE_ALREADY_EXISTS,Microsoft.PowerShell.Commands.AddTypeCommand
 

Actual Behavior

Calls to points such as Get-LrAieDrilldown -AlarmID xxx will caught by try/catch logic if 'TrustAllCertsPolicy' is preexisting in the script. I added a bit of logic in my Enable-TrustAllCertsPolicy to avoid the issue:

if ("TrustAllCertsPolicy" -as [type]) {
	break 
} 

Currently it is first, but will rarely be used since the configuration handles API keys. For convenience move this parameter to the end of each cmdlet.

Expected Behavior

Calling New-LRList should create the requested list specified by -name property.

Actual Behavior

Bad request exception is throw that states, "{"statusCode":400,"message":"Invalid owner id available in request body."}"

Steps to Reproduce the Problem

1. New-LrList -name AndruskList -ListType Host -Owner 2

Specifications

• Version: 1.3.2
• Platform: Windows 10 21H2
• Subsystem: Powershell 5.1

Overview

LrtConfig.LogRhythm: The DataIndexerIP field can actually be either its ip OR hostname.

Two changes:

• LogRhythm.Tools.json: Change DataIndexerIP to DataIndexerHost
• Lrt.Config.Input.json: Update Prompt, Hint, and InputCmd

Note

The other properties that can accept a hostname or ip are all URLs. Need to test to ensure that won't be a problem.

Requirement

LR cmdlets that update or create new entities should not return new/modified objects by default, similar to the way built-in cmdlets work.

Milestone

Note: I'd like this to be done in 1.0.1, and I can do all of these myself, but need to make sure there aren't any other significant changes being made to any commands that would be difficult to merge with these changes. That's why I've added you to this issue as well, @Jt3kt .

Detail

I've tried to incorporate as many standards and best practices as possible while developing SRF/LRT, but some things weren't immediately obvious, and Passthru is one of them. At first I expected that commands should always produce output, but in the PowerShell world, returning nothing is good and expected, unless you are working with commands that specifically retrieve information ( e.g., Get-Something). Or unless you specifically ask for output via the Passthru parameter.

To bring LRT in line with PowerShell design principles, we should update commands that manipulate data (New/Add/Set/Update) to return nothing, unless the -Passthru parameter is specified, which will then return the new or modified object.

This blog entry sort of articulates how this is a common design in PowerShell.

Expected Behavior

Some systems or users may not have $env:Home or $home set. It turns out $env:Home may not be standard at all. Need to catch this scenario for user scope when these are missing.

Error Message / Diagnostics

PS C:\Users\erich\Documents\GitHub\SmartResponse.Framework\dist> .\Setup.ps1

Join-Path : Cannot bind argument to parameter 'Path' because it is null.
At C:\Users\erich\Documents\GitHub\SmartResponse.Framework\dist\installer\include\Get-LrtInstallerInfo.ps1:93 char:15
+         -Path $Env:HOME `
+               ~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Join-Path], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorNullNotAllowed,Microsoft.PowerShell.Commands.JoinPathCommand
Join-Path : Cannot bind argument to parameter 'Path' because it is an empty string.
At C:\Users\erich\Documents\GitHub\SmartResponse.Framework\dist\installer\include\Get-LrtInstallerInfo.ps1:96 char:15
+         -Path $UserScope.Path `
+               ~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Join-Path], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.JoinPathCommand
Test-Path : Cannot bind argument to parameter 'Path' because it is an empty string.
At C:\Users\erich\Documents\GitHub\SmartResponse.Framework\dist\installer\include\Get-LrtInstallerInfo.ps1:103 char:19
+     if (Test-Path $UserScope.InstallPath) {
+                   ~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidData: (:) [Test-Path], ParameterBindingValidationException
    + FullyQualifiedErrorId : ParameterArgumentValidationErrorEmptyStringNotAllowed,Microsoft.PowerShell.Commands.TestPathCommand

Possible Solution

Remove $env:Home and replace it with $home, as well as a check to make sure its valid.

Steps to Reproduce

1. Publish LRT
2. Run Setup.ps1

Is your feature request related to a problem? Please describe.
Not a problem, just laziness.

Describe the solution you'd like
It'd be nice if i could run something like Get-LrToolsUpdate and have it check the repo for a newer release, and download / install it for me instead of having to come here and download it again.

Describe alternatives you've considered
I'm lazy so there are no other alternatives, semi-automatic updates or bust!

Is your feature request related to a problem? Please describe.
LogRhythm Identities do store the Title of the person. But there is no way to provide it while calling Add-LrIdentity

Describe the solution you'd like
Having a -Title [string] parameter that would allow providing the Title for the user/person.

Describe alternatives you've considered
None.

Additional context
Other Identities related functions might be missing this feature too.

Expected Behavior

When setting up LR.Tools for LogRhythm cloud the schema in the LR.Tools.json needs to be updated.

LogRhythm Cloud's API endpoints are available over TCP port 443 and not over 8501.

Actual Behavior

Adding in the URL's for a LogRhythm Cloud endpoint creates:
https://URLforLogRhythmCloud.cloud:8501/endpoint/

Recommended fix:
Inspect the provided URL based on regex for the url.cloud and when that is applied seed in the LR.Tools.json config to align to schema:
https://URLforLogRhythmCloud.cloud/endpoint/

Specifications

• Version: Any
• Platform: LogRhythm Cloud
• Subsystem: LogRhythm.Tools 1.0.0

Expected Behavior

Based on the function name, it should associate a Pending Agent record to an existing agent using the /lr-admin-api/agents-request/{guid}/associate API Endpoint. This requires the existing Agent ID to associate to.

Actual Behavior

Returns 405 - Method Not Allowed

Steps to Reproduce the Problem

1. Call the function with just the agent ID as per spec

Specifications

• Version: dev-1.2.5
• Platform: 7.9.0
• Subsystem: lr-admin-api

Additional Notes

I was reviewing the general module for release readiness, and noted that the function's description differed greatly from what it attempts to do. Additionally, for this function to work, a Get-LrPendingAgent function will be required to get the required guid for the association.

It may be that this function was added by copy/paste, in readiness for new functionality, but not completed.

Overview

We used to have a script called New-TestBuild that would make it easier for developers to re-load the LogRhythm.Tools module with the changes they've made. This was lost when the updated/new Lrt.Builder and Lrt.Installer modules were developed.

Solution

Re-implement New-TestBuild for the current generation of the project.

Expected Behavior

Lookups to Get-LrLogSources should allow lookups with the flag -MessageSourceTypeId xxxx and return specific results

Actual Behavior

All log sources are returned.

Steps to Reproduce the Problem

Get-LrLogSources -MessageSourceTypeId "12345" -verbose

VERBOSE: [Enable-TrustAllCertsPolicy]: Cert Policy is not enabled. Enabling.
VERBOSE: []: QueryString is [?count=1000&offset=0&recordStatus=active]
VERBOSE: GET https://xx:8501/lr-admin-api/logsources/?count=1000&offset=0&recordStatus=active with 0-byte
payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: [Enable-TrustAllCertsPolicy]: Cert Policy is not enabled. Enabling.
VERBOSE: []: QueryString is [?count=1000&offset=1000&recordStatus=active]
VERBOSE: GET https://xxx:8501/lr-admin-api/logsources/?count=1000&offset=1000&recordStatus=active with 0-byte
 payload
VERBOSE: received -1-byte response of content type application/json
VERBOSE: [Enable-TrustAllCertsPolicy]: Cert Policy is not enabled. Enabling.
VERBOSE: []: QueryString is [?count=1000&offset=2000&recordStatus=active]
VERBOSE: GET https://xxx:8501/lr-admin-api/logsources/?count=1000&offset=2000&recordStatus=active with 0-byte
 payload
VERBOSE: received -1-byte response of content type application/json

Specifications

• Version: 1.0.0

Requirement

All LR cmdlets should support rate limiting to throttle requests should the LR API return HTTP 429. As commands are frequently combined via the pipeline, it is possible for any of the LR cmdlets that access the RestAPI to trigger such an error.

For Example, this is a 429 received by Get-LrCaseById as a result of calling Get-LrCases

> $July[300].Metrics

LookupType : CaseNumber
IsValid    : False
Value      : 3833
CaseNumber :
CaseName   :
CaseGuid   :
Note       : Rate Limit Exceeded

Milestone

Include in 1.0.1 as a fix for this issue

Detail

This issue pops up primarily in the metrics commands, because it works like this:

1. Get-LrCases: Rest Request to /cases/
2. Get-LrCaseMetrics: receives the Case ID via pipeline, and needs to test it with Test-LrCaseIdFormat, which hits the API
3. Get-LrCaseMetrics: Rest Request to /cases/$CaseNumber/metrics`

That's three requests for each request returned by Get-LrCases, and when you pull a couple hundred cases or so, the rate limit of the API will be triggered.

Expected Behavior

Being able to create multiple Identities using the same SyncName

Actual Behavior

Any subsequent Identities creation attempts simply override the first one created using the same SyncName

Steps to Reproduce the Problem

1. Add-LrIdentity -EntityId 1 -NameFirst 'Bob' -NameLast 'Pop' -SyncName 'Test-Import' -DisplayIdentifier '[email protected]' -Identifier1Type email -Identifier1Value '[email protected]'
2. Add-LrIdentity -EntityId 1 -NameFirst 'Bill' -NameLast 'Pop' -SyncName 'Test-Import' -DisplayIdentifier '[email protected]' -Identifier1Type email -Identifier1Value '[email protected]'
3. Get-LrIdentities

Result:
Only one Identity created, with the details of the last request:
identityID : 7 nameFirst : Bill nameMiddle : nameLast : Pop displayIdentifier : [email protected] company : department : title : manager : addressCity : domainName : entity : @{entityId=1; rootEntityId=0; path=Primary Site; name=Primary Site} dateUpdated : 2020-10-12T16:50:00.773Z recordStatus : Active identifiers : {@{identifierID=8817; identifierType=Email; [email protected]; recordStatus=Active; source=}} groups : {@{name=Domain Admins}}

Specifications

• Version: LRT v1.0.0
• Platform: 7.5.0
• Subsystem:

Validate Set for the values below anywhere a Case Status Parameter is used.

• Created
• Completed
• Incident
• Mitigated
• Resolved

Validate set for values below anywhere a Procedure Step Status Parameter is used.

• Completed
• NotCompleted

Is your feature request related to a problem? Please describe.
Expand the LrtConfig to permit the optional addition of DX Cluster(s). At the install/re-configure of LogRhythm.Tools the user should be able to prompted to configure DX environment. I do recommend we put in place step in the LogRhythm setup for L.rTools for Advanced or Basic as expanding into the direction this configuration is intended to support is for Advance use cases only.

The installer should have the ability to dynamically scale/set the LogRhythm.Tools.json based on the installing user's provided input for DX to reduce bloat and keep the config focused on relevant enabled content.

Describe the solution you'd like
Expand the LogRhythm config to permit the following structure example:

"LogRhythm": {
        "Version":"7.5.0",
        "AdminBaseUrl": "https://[NOT_SET]:8501/lr-admin-api",
        "CaseBaseUrl": "https://[NOT_SET]:8501/lr-case-api",
        "AieBaseUrl": "https://[NOT_SET]:8501/lr-drilldown-cache-api",
        "SearchBaseUrl": "https://[NOT_SET]:8501/lr-search-api",
        "ApiKey": "",
	"DX": {
		"Cluster1": {
			"Health": "",
			"Master": "",
			"Open": "",
			"Closed": "",
			"Zones": {
				"Zone1": "",
				"Zone2": ""
			}
			"Node1": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node2": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node3": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			}
		},
		"Cluster2": {
			"Health": "",
			"Master": "",
			"Open": "",
			"Closed": "",
			"Zones": {
				"Zone1": "",
				"Zone2": ""
			}
			"Node1": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node2": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node3": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			}
		},
		"Cluster3": {
			"Health": "",
			"Master": "",
			"Open": "",
			"Closed": "",
			"Zones": {
				"Zone1": "",
				"Zone2": ""
			}
			"Node1": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node2": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			},
			"Node3": {
				"Hostname": "",
				"IPAddress": "",
				"2xDx": false,
				"WarmNode": false,
				"Zone": ""
			}
		}
	}
}

Additional context
The primary goal of this will be to expand into advance DX management to support controlled automated rolling restarts, troubleshooting, and applying advance DX configuration(s).