Before installing and configuring Azure Log Connector, several prerequisites must be in place in both your Microsoft Azure environment and your LT Auditor ^MP deployment. This article covers everything that needs to be confirmed or prepared before proceeding with installation.

LT Auditor ^MP prerequisites:

[Your administrator should confirm the exact download location for the Azure Log Connector package in your environment.]

Server requirements:

The machine where Azure Log Connector will be installed must meet the following requirements:

Required outbound network access:

Azure Log Connector requires outbound HTTPS access to the following Microsoft API endpoints. Confirm these are not blocked by your firewall or proxy:

Test connectivity from the Azure Log Connector server to each endpoint:

Test-NetConnection -ComputerName graph.microsoft.com -Port 443

Test-NetConnection -ComputerName manage.office.com -Port 443

Test-NetConnection -ComputerName login.microsoftonline.com -Port 443

All three should return a successful result. If any connection fails, work with your network team to allow outbound HTTPS traffic to those endpoints.

[Your administrator should confirm whether outbound internet access from the installation server requires proxy configuration, and if so, ensure the proxy settings are configured before proceeding.]

Microsoft Entra ID prerequisites:

Required API permissions:

The App Registration used by Azure Log Connector requires the following permissions. All permissions are Application type — not Delegated — as Azure Log Connector runs as a background service without a signed-in user. All permissions require Admin Consent from a Global Administrator.

Microsoft Graph — Application Permissions:

Office 365 Management APIs — Application Permissions:

This is a significantly broader set of permissions than the previous EntraConnector module required, reflecting the expanded scope of Azure Log Connector across both Entra ID and Microsoft 365. All permissions require Admin Consent before they become active.

Microsoft 365 license requirements:

Access to certain log categories requires appropriate Microsoft licensing. Confirm the following with your Microsoft licensing administrator:

[Your administrator should confirm your organization’s current Microsoft 365 and Entra ID license tiers and which log categories are available before configuring Azure Log Connector.]

Roles required for setup:

[Your administrator should coordinate with your Azure or Microsoft 365 administrator to complete the App Registration steps if they do not have access to the Azure Portal.]

Information to gather before installation:

Before proceeding to the App Registration and installation steps, gather the following. You will need all of these values during configuration:

The Client Secret value is only displayed once at the time of creation. Copy it immediately and store it securely. If the secret is lost, a new one must be generated.

Prerequisites checklist:

Before proceeding to the next article, confirm all of the following:

• [ ] Installation server meets Windows Server 2019 or newer requirement
• [ ] Outbound HTTPS access confirmed to all three Microsoft API endpoints
• [ ] LT Auditor ^MP server is installed and running
• [ ] LT Auditor ^MP syslog listener is active on the configured port
• [ ] Azure Portal access with appropriate privileges is available
• [ ] Microsoft 365 and Entra ID license tiers confirmed
• [ ] Tenant ID, Client ID, and Client Secret are ready to hand
• [ ] LT Auditor ^MP syslog port and protocol are confirmed

[Your administrator should complete this checklist before proceeding to the Registering the App in Microsoft Entra ID article to avoid interruptions during setup.]

Azure Log Connector replaces and significantly expands on the previous EntraConnector module. Where EntraConnector focused primarily on Entra ID identity events, Azure Log Connector extends coverage to include Microsoft 365 collaboration activity — including SharePoint Online and OneDrive — giving organizations a much more complete picture of their cloud environment.

What Azure Log Connector collects:

Azure Log Connector collects the following categories of cloud audit activity:

How Azure Log Connector works:

Azure Log Connector is installed as a Windows service on a server in your environment. It connects to Microsoft Azure and Microsoft 365 using a registered App Registration in Microsoft Entra ID, polls for new audit log entries on a configurable interval, and forwards collected events to the LT Auditor ^MP server via syslog.

Data flow:

1. Azure Log Connector authenticates to Microsoft Graph and the Office 365 Management APIs using the configured App Registration credentials
2. The collector polls for new events across all enabled log categories at the configured interval (default: every 5 minutes)
3. Collected events are forwarded to the LT Auditor ^MP server via syslog on the configured port (default: 5050)
4. Events are processed by LT Auditor ^MP transformation rules and stored in the database
5. Collected data becomes available in the LT Auditor ^MP dashboard, View module, alert rules, and compliance reports

Key capabilities include:

• Collection of sign-in, audit, and identity protection logs from Microsoft Entra ID
• Collection of SharePoint Online and OneDrive activity logs from Microsoft 365
• Configurable polling intervals and batch sizes for efficient API usage
• Lookback capability on startup to recover events missed during downtime
• Support for UDP, TCP, and TLS syslog transport to LT Auditor ^MP
• Configurable per-category enable/disable via appsettings.json
• Raw API response logging for troubleshooting purposes
• Integration with LT Auditor ^MP alerting, reporting, and compliance frameworks

Common use cases:

• Monitoring privileged role assignments and administrative changes in Entra ID
• Detecting suspicious or risky sign-in activity across your Microsoft 365 tenant
• Auditing SharePoint Online and OneDrive file access and sharing for data governance
• Tracking conditional access policy changes that may affect your security posture
• Producing compliance evidence for GDPR, HIPAA, NIS2, ISO 27001, and other frameworks
• Gaining unified visibility across both on-premises and Microsoft cloud environments

How Azure Log Connector fits into LT Auditor ^MP:

Azure Log Connector acts as the Microsoft cloud data collection layer for LT Auditor ^MP. It works alongside other modules — EventLogCentral for Windows on-premises activity, PowerShell Orchestrator for Active Directory assessments, and PII Scanner for sensitive data discovery — to give LT Auditor ^MP comprehensive coverage across your entire environment, from on-premises infrastructure to the Microsoft cloud.

Prerequisites for Azure Log Connector:

• Windows Server 2019 or newer
• Internet connectivity to Microsoft Graph and Office 365 APIs
• Administrative access to the server
• Access to the Azure Portal with permissions to create App Registrations
• LT Auditor ^MP server installed and running
• Outbound network access to the LT Auditor ^MP syslog listener port

[Your administrator should confirm which Microsoft 365 services and Azure log categories are in scope for collection in your environment, and ensure the App Registration is created by someone with the appropriate privileges in your Azure tenant.]

When to run an on-demand scan:

Prerequisites:

Before running an on-demand scan confirm the following:

• At least one PII Scanner Agent is registered and showing as Online in the Clients page
• The intended agent has read access to the path you want to scan
• At least one target is configured in the Targets page
• The PII detection classes relevant to your scan are enabled in the PII Classes page

Creating an on-demand scan job:

1. Log in to the PII Scanner Server web interface at:

2. Navigate to Jobs
3. Click Add Job
4. Configure the job:

Job Name Use a name that clearly identifies this as an on-demand scan and captures its context:

Examples:

On-Demand — HR Share Audit Prep — June 2026

Incident Response Scan — FileServer01 — 2026-06-08

New Share Baseline — Finance Q2 2026

Client Select the agent that has access to the path you want to scan. Confirm the agent shows as Online in the dropdown.

Path to Scan Enter the full path to the directory or share to scan:

Windows:

\\fileserver01\departments\hr

C:\SensitiveData

Linux:

/mnt/shares/finance

/home/shared/legal

Include Extensions (optional) For a focused on-demand scan, limit to the most relevant file types to reduce scan time:

*.docx, *.xlsx, *.pdf, *.txt, *.csv

Leave blank for a comprehensive sweep of all file types — recommended for incident response scans.

PII Classes Select the PII detection classes to apply. For incident response or pre-audit scans consider enabling all available classes for maximum coverage.

Target Host Select your LT Auditor-MP server as the destination for scan results.

5. Click Queue Job

The job is submitted immediately with a status of Queued. The assigned agent will claim it on its next poll cycle and begin scanning.

Monitoring the scan:

1. Navigate to Jobs
2. Locate your job — the status updates from Queued to Running once the agent claims it
3. Review job progress:

4. Refresh the page periodically to see updated progress

For large directories scans can take significant time. PII matches are forwarded to LT Auditor-MP in real time as they are found — you do not need to wait for the scan to complete before reviewing results.

Viewing results as the scan runs:

Because PII matches are forwarded to LT Auditor-MP in real time you can begin reviewing results before the scan completes:

1. Log in to the LT Auditor-MP Web UI in a separate browser tab
2. Navigate to View
3. Select the PII Scanner environment and category
4. Set the date range to Today or Last Hour
5. Results populate as the agent finds and forwards matches
6. Click any result row to view full details:
   • File Path — where the PII was found
   • PII Class — the type of sensitive data matched
   • Timestamp — when the match was detected

Confirming scan completion:

1. Return to the PII Scanner Server web interface
2. Navigate to Jobs
3. Confirm the job status has updated to Succeeded
4. Note the Completed timestamp and Records Processed count for your records

If the job status shows Failed:

1. Review the result details in the job record for error information
   

Check the agent logs for more specific error details:

Linux:

cat /opt/bluelance/scanner/scanner.log

 Windows:

C:\Program Files\Blue Lance 2-0\LTA_PII_Scanner_Agent\logs\

3. Resolve the identified issue and create a new job to rerun the scan if needed
   

Documenting on-demand scan results:

For scans run in response to audits, incidents, or compliance queries, document the scan and its results:

1. Note the job name, scan path, date, time, assigned agent, and PII classes used
2. In LT Auditor-MP navigate to View and filter for the scan results
3. Export the results:
   • Click Export
   • Choose PDF for audit submission or CSV for detailed analysis
   • Click Download
4. Retain the export as evidence of the data discovery activity

[Your administrator should establish a standard process for documenting and retaining on-demand scan records, particularly those run in response to security incidents or compliance audits.]

Best practices:

• Always confirm the assigned agent is Online before creating a job — a job assigned to an Offline agent will remain Queued indefinitely
• For incident response scans leave the Include Extensions field blank and enable all PII classes for maximum coverage
• Use descriptive job names that capture the date, scope, and reason for the scan so the Jobs page serves as an auditable record
• Begin reviewing results in LT Auditor-MP as the scan runs rather than waiting for completion — this is especially important during incident response
• Export and retain scan results immediately after completion, particularly for incident response or audit-driven scans
• For recurring scans of the same path consider creating a schedule rather than repeatedly creating manual jobs

[Your administrator should document the on-demand scan process as part of your organization’s incident response and compliance procedures so it can be followed consistently by any team member.]

Understanding scan results:

Each result record forwarded to LT Auditor-MP represents a single PII match found in a scanned file. A single file may generate multiple result records if it contains multiple types of PII or multiple instances of the same PII type.

Each result record includes:

• File Path — the full path to the file where the match was found
• PII Class — the type of sensitive data detected
• Class Type — the category of the detected class (PII, PHI, Sensitive, Confidential, or Private)
• Timestamp — when the match was detected during the scan
• Agent — the client agent that performed the scan
• Job Name — the scan job that generated the result

Accessing scan results in LT Auditor-MP:

1. Log in to the LT Auditor-MP Web UI
2. Navigate to View in the main navigation menu
3. Select the view configured for PII Scanner data or create a new one:
   • Click Create View
   • Set the Environment to your PII Scanner environment
   • Set the Category to PII Scan Results
   • Set a default date range
   • Click Save
4. The log table populates with PII match records from your scans

Filtering scan results:

Filter by job name:

1. Click Advanced Filters
2. Add a condition:
   • Field — Job Name
   • Operator — Equals
   • Value — the name of the specific scan job
3. Click Apply Filters

Filter by PII class:

1. Click Advanced Filters
2. Add a condition:
   • Field — PII Class
   • Operator — Equals or Contains
   • Value — the class name to focus on (e.g., Social Security Number)
3. Click Apply Filters

Filter by class type:

1. Click Advanced Filters
2. Add a condition:
   • Field — Class Type
   • Operator — Equals
   • Value — PII, PHI, Sensitive, Confidential, or Private
3. Click Apply Filters

Filter by file path:

1. Click Advanced Filters
2. Add a condition:
   • Field — File Path
   • Operator — Starts With or Contains
   • Value — the directory path to focus on
3. Click Apply Filters

Filter by agent:

1. Click Advanced Filters
2. Add a condition:
   • Field — Agent
   • Operator — Equals
   • Value — the hostname of the agent that performed the scan
3. Click Apply Filters

Interpreting scan results:

When reviewing results focus on the following questions:

Is the sensitive data in an expected location? PII found in designated access-controlled directories is expected. PII found in unexpected locations — a public share, a developer’s working directory, or a temporary folder — requires immediate attention and remediation.

Is the class type appropriate for the location? PHI in a healthcare application directory may be expected. PHI in a general file share is not. Review whether the type of sensitive data found makes sense for the location it was discovered in.

How many files are affected? A single match in one file is very different from hundreds of matches across many files. Use grouping and aggregation in LT Auditor-MP reports to understand the scale of findings across a scan.

Viewing full result details:

1. Click on any result row in the log table
2. The detail panel opens and displays:
   • File Path — full path to the affected file
   • PII Class — the type of sensitive data detected
   • Class Type — PII, PHI, Sensitive, Confidential, or Private
   • Timestamp — when the match was detected
   • Agent — which client agent found the match
   • Job Name — which scan job generated the result
   • Raw Log — the original forwarded syslog record
3. Click Close to return to the results table

Identifying false positives:

Not every match represents a genuine sensitive data finding. Some regex patterns may produce false positives — matches that technically satisfy the pattern but do not represent real sensitive data. Use the file path and raw log context to validate whether a match represents actual sensitive data before acting on it.

If a PII class is consistently generating false positives:

1. Navigate to PII Classes in the PII Scanner Server web interface
2. Review and tighten the regex pattern for the relevant class
3. Consider disabling the class temporarily if the false positive rate is too high to manage

Acting on scan results:

When genuine sensitive data is found in an unexpected or unauthorized location:

1. Document the finding:

• Export the relevant results from LT Auditor-MP as PDF or CSV
• Note the file path, PII class, class type, scan date, and agent

2. Assess the risk:

• Determine who has access to the location where the sensitive data was found
• Review access logs in LT Auditor-MP to determine whether the file has been accessed recently
• Assess whether the finding represents a compliance violation that must be reported

3. Remediate:

• Work with the file owner or relevant department to relocate, encrypt, or delete the sensitive file
• Review and update access controls on the affected location
• Run a follow-up on-demand scan of the same path after remediation to confirm the sensitive data has been successfully addressed

4. Report:

• If the finding represents a compliance violation follow your organization’s incident response and breach notification procedures
• Retain scan results and remediation records as evidence for compliance audits

[Your administrator should define a standard remediation workflow for PII findings and ensure all team members know how to follow it.]

Generating PII scan reports in LT Auditor-MP:

For compliance documentation and management reporting, generate structured reports from PII scan results:

1. Navigate to Report in the LT Auditor-MP Web UI
2. Click Create Report
3. Configure the report:
   • Environment — PII Scanner environment
   • Category — PII Scan Results
   • Date Range — the period to cover
4. Under Columns include:
   • File Path
   • PII Class
   • Class Type
   • Timestamp
   • Agent
   • Job Name
5. Under Grouping consider grouping by:
   • PII Class — to see a breakdown of finding types
   • Class Type — to distinguish PII from PHI and other categories
   • File Path — to identify the most affected locations
6. Click Save and then Generate Report
7. Download the report as PDF for audit submission or CSV for detailed analysis

Setting up alerts for PII findings:

Configure LT Auditor-MP to alert your team when PII matches are detected during a scan:

1. Navigate to Manage in the LT Auditor-MP Web UI
2. Select the PII Scanner environment and category
3. Click Add Filter
4. Configure the filter:
   • Filter Name — e.g., PHI Finding Alert
   • Condition — Class Type Equals PHI
   • Action — Alert
   • Recipients — your security or compliance team email addresses
5. Click Save and set to Active

[Your administrator should configure alerts for each sensitive class type relevant to your compliance obligations — at minimum PHI for HIPAA environments and PII for GDPR environments.]

Best practices:

• Review scan results promptly after each scan completes — sensitive data findings should not sit unaddressed
• Use the Class Type filter to prioritize PHI and PII findings for immediate investigation before reviewing Sensitive and Confidential findings
• Validate matches using the file path and raw log context before acting — not every match is a genuine sensitive data finding
• Export and retain scan results as part of your compliance evidence library
• Run a follow-up on-demand scan after remediation to confirm sensitive data has been successfully removed from the affected location
• Track remediation progress for all findings to demonstrate to auditors that your organization acts on data discovery results
• Set up alert rules in LT Auditor-MP for PHI and PII class type findings so your team is notified promptly rather than discovering findings during a scheduled review

[Your administrator should establish a regular cadence for reviewing accumulated scan results in LT Auditor-MP as part of an ongoing data governance review process.]

How PII Scanner works:

The server manages all aspects of the scanning program — clients, scan jobs, PII detection rules, target destinations, and scheduled jobs. Agents register with the server, poll for queued scan jobs, scan local or network file paths for sensitive data patterns, and forward results to a configured destination such as an LT Auditor-MP server.

Data flow:

1. Administrator defines PII detection classes and configures target destinations in the server web UI
2. Administrator creates a scan job or schedule, assigning it to a registered agent
3. The agent polls the server and claims the queued job
4. The agent scans the specified file path using the selected PII detection patterns
5. Detected PII matches are forwarded in real time to the configured target (LT Auditor-MP)
6. The agent reports job completion back to the server
7. Results are available in LT Auditor-MP for review, alerting, and compliance reporting

Core components:

PII Scanner Server An ASP.NET Core 8 web application that hosts the administrative interface and REST API. It manages client registrations, scan jobs, PII class definitions, target destinations, and scheduled jobs. The server runs as a Windows Service or Linux systemd service and uses a SQLite database for persistence. The web interface is accessible via browser on port 52766 (HTTPS) or 52765 (HTTP).

PII Scanner Agent A Python-based scanning agent deployed on machines whose file systems you want to scan. The agent registers with the PII Scanner Server, polls for available jobs at a configurable interval, executes scans against specified file paths, and forwards detected PII matches to the configured target destination in real time.

Key capabilities include:

• Detection of PII, PHI, and other sensitive data types using configurable regex-based patterns
• Support for scanning Windows and Linux file systems and network shares
• Centralized scan job management through a web-based administrative interface
• On-demand and scheduled recurring scan jobs
• Real-time forwarding of scan results to LT Auditor-MP via UDP, TCP, or TLS syslog
• Support for multiple simultaneous scanning agents across large environments
• Configurable file extension filtering per scan job
• Runs as a Windows Service or Linux systemd service

Supported PII and sensitive data class types:

• PII — Personally Identifiable Information
• PHI — Protected Health Information
• Sensitive
• Confidential
• Private

Common use cases:

• Identifying where sensitive data lives across your file systems
• Detecting PII or PHI in unexpected or unauthorized locations
• Supporting GDPR, HIPAA, PCI-DSS, and NIS2 compliance requirements
• Producing evidence of data discovery efforts for auditors
• Automating recurring data discovery across high-risk directories

How PII Scanner fits into LT Auditor-MP:

PII Scanner extends LT Auditor-MP’s capabilities into proactive data discovery. While other modules like EventLogCentral and Azure Log Connector monitor activity as it happens, PII Scanner actively interrogates file systems to find where sensitive data exists — giving organizations the visibility needed to make informed decisions about access controls, data governance, and compliance obligations.

[Your administrator should confirm which file systems and data types are in scope for scanning in your environment, and ensure scanning activity complies with any applicable data privacy policies.]

How PowerShell Orchestrator works:

The server manages all aspects of the platform — scripts, jobs, schedules, syslog targets, and connected agents. Agents are deployed on the Windows machines where scripts need to run. Each agent polls the server for queued jobs, executes the assigned PowerShell script locally, and forwards script output to the configured syslog destination.

Data flow:

1. Administrator uploads PowerShell scripts to the server and configures syslog targets
2. Administrator creates a job or schedule, selecting a script, agent, and target
3. The agent polls the server and claims the queued job
4. The agent downloads and executes the PowerShell script locally
5. Script output is forwarded to the configured syslog target in real time
6. The agent reports job completion, exit code, and execution logs back to the server
7. Results are available for review in the Jobs page and in LT Auditor-MP

Core components:

PowerShell Orchestrator Server An ASP.NET Core web application that hosts the administrative interface and REST API. It manages script storage, job queuing, schedules, syslog targets, and agent registrations. The server runs as a Windows service named PowerShellOrchestrator and uses a SQLite database for persistence. The web interface is accessible via browser on port 52866 (HTTPS) or 52865 (HTTP).

PowerShell Orchestrator Agent A .NET background service deployed on each Windows machine where scripts need to run. The agent polls the server for available jobs at a configurable interval (default: every 20 seconds), downloads and executes assigned PowerShell scripts, forwards output to the configured syslog target, and sends regular heartbeats to the server (default: every 60 seconds). The agent runs as a Windows service named PowerShellOrchestrator.Agent.

Key capabilities include:

• Centralized storage and management of PowerShell scripts
• Remote script execution across distributed Windows agents
• On-demand and scheduled recurring job execution using cron expressions
• Real-time job status monitoring and execution history
• Script output forwarding to syslog targets for centralized logging in LT Auditor-MP
• Secure HTTPS/TLS communication between server and agents
• Role-based access control with forced password changes
• Support for both Windows PowerShell 5 and PowerShell Core 7
• Runs as a Windows service on Windows or Linux systemd service on Linux

Common use cases:

• Automated assessment of Active Directory configuration and security posture
• Scheduled execution of compliance and security audit scripts across the environment
• Remote PowerShell script execution without requiring direct access to individual machines
• Centralized collection and forwarding of PowerShell script output to LT Auditor-MP
• Automating routine administrative tasks across distributed Windows infrastructure

How PowerShell Orchestrator fits into LT Auditor-MP:

PowerShell Orchestrator extends LT Auditor-MP’s capabilities into active script-based assessment and automation. Where other modules collect events passively as they occur, PowerShell Orchestrator actively executes scripts on demand or on a schedule — querying the state of your Windows environment and forwarding structured results to LT Auditor-MP for analysis, alerting, and compliance reporting.

[Your administrator should confirm which Windows machines are in scope for PowerShell Orchestrator agent deployment and which scripts will be used in your environment.]

Understanding managed endpoints:

A managed endpoint is any machine that PowerShell Orchestrator connects to in order to collect assessment data. This includes:

• Active Directory domain controllers
• Windows member servers
• Workstations (if included in your assessment scope)
• Microsoft Entra ID (connected via the configured service account, not a direct machine connection)

PowerShell Orchestrator connects to endpoints using PowerShell Remoting over WinRM. The service account configured during installation is used to authenticate to each endpoint.

Prerequisites:

Before adding managed endpoints, confirm the following on each target machine:

• WinRM is enabled and the WinRM service is running
• The PowerShell Orchestrator service account has read permissions on the target machine
• No firewall is blocking WinRM traffic between the orchestrator machine and the target endpoint

Default WinRM ports:

Anthropic recommends using HTTPS (port 5986) for WinRM connections in production environments to encrypt traffic between the orchestrator and managed endpoints.

[Your administrator should confirm which WinRM protocol and port are used in your environment.]

Enabling WinRM on target endpoints:

If WinRM is not already enabled on a target endpoint, run the following in PowerShell as Administrator on that machine:

Enable-PSRemoting -Force

To enable WinRM across multiple machines simultaneously, use Group Policy:

1. Open Group Policy Management Console
2. Create or edit a GPO linked to the relevant OU
3. Navigate to:

Computer Configuration → Policies → Windows Settings →

Security Settings → System Services → Windows Remote Management

4. Set the service startup mode to Automatic
5. Apply the GPO

[Your administrator should confirm whether WinRM is already managed via Group Policy in your environment before making manual changes.]

Testing connectivity to a target endpoint:

Before adding an endpoint to PowerShell Orchestrator, test that the orchestrator machine can successfully connect to it:

Test-WSMan -ComputerName <hostname or IP> -Credential (Get-Credential)

A successful result returns the WinRM service information for the target machine. If the test fails:

• Confirm WinRM is running on the target machine
• Confirm no firewall is blocking ports 5985 or 5986
• Confirm the service account has permission to connect remotely

Adding managed endpoints in LT Auditor ^MP:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure → PowerShell Orchestrator
3. Click Add Endpoint
4. Configure the endpoint details:
   • Name — a descriptive name for the endpoint (e.g., DC01 — Primary Domain Controller)
   • Hostname or IP Address — the address of the target machine
   • Connection Protocol — HTTP or HTTPS
   • Port — 5985 (HTTP) or 5986 (HTTPS)
   • Credential — select the configured service account
5. Click Test Connection to verify connectivity before saving
6. Click Save

Repeat this process for each endpoint you want to include in assessments.

[Your administrator should maintain a list of all managed endpoints and their roles in your environment.]

Adding Microsoft Entra ID as a managed target:

Entra ID is connected as a cloud target rather than a direct machine endpoint.

1. Navigate to Configure → PowerShell Orchestrator → Cloud Targets
2. Click Add Entra ID Target
3. Enter the following details from your App Registration in the Azure Portal:
   • Tenant ID
   • Client ID
   • Client Secret
4. Click Test Connection to verify the credentials
5. Click Save

[Your administrator should refer to the EntraConnector Prerequisites article for instructions on creating and configuring the App Registration in the Azure Portal if this has not already been done.]

Verifying endpoint connectivity:

After adding endpoints, confirm they are showing as reachable in LT Auditor ^MP:

1. Navigate to Configure → PowerShell Orchestrator
2. Review the endpoint list — each endpoint should show a status of Reachable
3. If any endpoint shows as Unreachable, check:
   • The WinRM service is running on that machine
   • The hostname or IP address is correct
   • No firewall is blocking the WinRM port
   • The service account credentials are valid and have not expired

Removing a managed endpoint:

If a machine is decommissioned or no longer needs to be included in assessments:

1. Navigate to Configure → PowerShell Orchestrator
2. Locate the endpoint in the list
3. Click the Delete icon next to it
4. Confirm the deletion

Removing an endpoint stops future assessments from running against it. Historical assessment data collected from that endpoint is retained in the LT Auditor ^MP database and is not affected.

Best practices:

• Always test connectivity before saving a new endpoint to catch configuration issues early
• Use HTTPS for WinRM connections in production to encrypt assessment traffic
• Use a dedicated, least-privilege service account — avoid using a domain admin account for orchestrator connections
• Keep the endpoint list current — remove decommissioned machines promptly to avoid failed assessment runs
• Manage WinRM configuration via Group Policy for consistency across large environments
• Document each managed endpoint and its role so other administrators understand the assessment scope

[Your administrator should review the managed endpoint list regularly to ensure it reflects the current state of your environment.]

Understanding scripts in PowerShell Orchestrator:

A script in PowerShell Orchestrator consists of:

• The PowerShell code to execute on the target endpoint or against Entra ID
• The target endpoint or cloud target the script runs against
• A schedule defining when and how often the script runs
• Optional alert linkage that triggers the script automatically in response to a security event

Scripts are stored centrally in LT Auditor ^MP and pushed to the relevant endpoint at execution time. Output from each script run is captured and forwarded to the LT Auditor ^MP server as structured assessment data.

Accessing the script library:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Configure → PowerShell Orchestrator → Scripts
3. The script library displays all saved scripts with their name, target, schedule status, and last run time

Creating a new script:

1. Click Add New Script
2. Configure the script details:
   • Script Name — a clear, descriptive name (e.g., “AD Privileged Group Membership Assessment”)
   • Description — the purpose of the script and what it assesses
   • Target Type — select either a managed endpoint or an Entra ID cloud target
   • Target — select the specific endpoint or cloud target from the configured list
3. Enter or paste your PowerShell script code in the script editor:

# Example: List all members of the Domain Admins group

Get-ADGroupMember -Identity “Domain Admins” -Recursive |

Select-Object Name, SamAccountName, DistinguishedName |

ConvertTo-Json

4. Configure output settings:
   • Output Format — JSON is recommended for structured data forwarding to LT Auditor ^MP
   • Max Output Size — set a limit to prevent excessively large outputs
5. Click Save

[Your administrator should populate the script library with assessment scripts relevant to your environment. Blue Lance may provide a default set of assessment scripts — refer to the Blue Lance documentation at https://www.bluelance.com/docs for details.]

Recommended assessment scripts to create:

[Your administrator should adjust this list based on your organization’s specific assessment requirements and compliance frameworks.]

Scheduling a script:

1. Open the script configuration
2. Navigate to the Schedule tab
3. Click Add Schedule
4. Configure the schedule:
   • Frequency — Daily, Weekly, Monthly, or a custom interval
   • Day and Time — when the script should run
   • Time Zone — the timezone for schedule execution
5. Click Save

The script will run automatically at the configured time and forward its output to the LT Auditor ^MP server.

Stagger script schedules to avoid running multiple assessment scripts simultaneously, particularly against the same domain controller. Concurrent assessments can impact domain controller performance.

Running a script on demand:

To run a script immediately without waiting for the scheduled time:

1. Open the script from the script library
2. Click Run Now
3. Monitor the execution progress in Configure → PowerShell Orchestrator → Execution Log
4. When complete, navigate to View in the Web UI to see the assessment results

Editing an existing script:

1. Open the script from the script library
2. Click the Edit icon
3. Make the necessary changes to the script code, target, or schedule
4. Click Save

Changes to a script take effect on the next scheduled run or the next time the script is run manually. Any currently running execution of the script will complete using the previous version.

Duplicating a script:

To create a similar script quickly without starting from scratch:

1. Select the script from the script library
2. Click Duplicate
3. Modify the name, target, or code as needed
4. Click Save

This is useful when you need to run the same assessment against multiple different endpoints.

Enabling and disabling scripts:

To temporarily suspend a script without deleting it:

1. Open the script configuration
2. Toggle the Active switch to off
3. The script will not run on its schedule until re-enabled

Deleting a script:

1. Select the script from the script library
2. Click the Delete icon
3. Confirm the deletion

Deleting a script removes it and its schedule permanently. Historical execution results and assessment data already forwarded to LT Auditor ^MP are retained and are not affected.

Best practices:

• Use descriptive script names and descriptions so other administrators understand the purpose of each assessment without needing to read the code
• Always test new scripts with Run Now before activating their schedule to confirm they produce the expected output
• Use JSON output format wherever possible for clean, structured data forwarding to LT Auditor ^MP
• Stagger schedules across scripts and endpoints to avoid performance impacts during peak hours
• Store scripts in source control outside of LT Auditor ^MP as a backup, especially for complex assessments
• Review the script library regularly and remove or update scripts that are no longer relevant
• Use the least privilege principle for the service account — scripts should only have the read access they need

[Your administrator should document the purpose and expected output of each script in the library so the team can interpret assessment results correctly.]

Understanding alert-linked scripts:

When a script is linked to an alert rule, the following happens automatically:

1. An incoming event matches the alert rule’s conditions
2. LT Auditor ^MP generates an alert
3. PowerShell Orchestrator immediately executes the linked script against the configured target
4. The script output is forwarded to LT Auditor ^MP and associated with the alert for investigation

This creates a closed-loop response — the alert fires, evidence is automatically collected, and the results are immediately available in the platform for review.

Common alert-linked script use cases:

[Your administrator should define the automated response workflows most relevant to your environment and configure them accordingly.]

Prerequisites:

Before linking a script to an alert rule, confirm the following:

• The alert rule is already created and active in LT Auditor ^MP (see Configuring Alert Rules)
• The script is already created and tested in the PowerShell Orchestrator script library (see Creating and Scheduling Scripts)
• The script’s target endpoint or cloud target is reachable and connected

Linking a script to an alert rule:

1. Log in to the LT Auditor ^MP Web UI
2. Navigate to Manage
3. Select the Environment and Category containing the alert rule
4. Locate the alert rule you want to link a script to and click the Edit icon
5. In the filter configuration, navigate to the Actions tab
6. Click Add Action
7. Select Run PowerShell Script as the action type
8. Configure the action:
   • Script — select the script from your PowerShell Orchestrator library
   • Target Override (optional) — if the script should run against the machine that generated the alert rather than a fixed target, enable dynamic targeting
   • Execution Delay (optional) — set a delay in seconds before the script runs, if needed
9. Click Save Action
10. Click Save to update the alert rule

The script will now run automatically every time this alert rule fires.

Using dynamic targeting:

By default, a linked script runs against the fixed target configured in the script definition. Dynamic targeting allows the script to instead run against the machine or user that generated the alert — making the response more relevant to the specific incident.

To enable dynamic targeting:

1. In the Run PowerShell Script action configuration, enable Dynamic Target
2. Select the field from the alert event that identifies the target:
   • Host — runs the script against the machine that generated the event
   • User — passes the affected username as a parameter to the script
3. Click Save

Dynamic targeting requires that the identified machine is already a registered managed endpoint in PowerShell Orchestrator. If the machine is not registered, the script will fail to execute.

Viewing alert-linked script execution results:

When an alert fires and triggers a linked script, the execution results are available in two places:

In the alert record:

1. Navigate to Alerts → Active Alerts or Alerts → Alert History
2. Open the alert that triggered the script
3. Scroll to the Automated Response section
4. View the script execution status and output directly within the alert record

In the execution log:

1. Navigate to Configure → PowerShell Orchestrator → Execution Log
2. Filter by Trigger Type — Alert to see all alert-triggered executions
3. Click any execution entry to view full output and status details

Managing alert-linked scripts:

Removing a script link from an alert rule:

1. Open the alert rule in Manage
2. Navigate to the Actions tab
3. Locate the Run PowerShell Script action
4. Click the Delete icon next to it
5. Click Save

Temporarily suspending automated responses: If you need to stop automated script execution without modifying the alert rule itself, disable the script in the script library:

1. Navigate to Configure → PowerShell Orchestrator → Scripts
2. Open the linked script
3. Toggle the Active switch to off
4. The alert rule will continue to fire alerts, but the script will not execute until re-enabled

Best practices:

• Start with read-only assessment scripts for automated responses before implementing any scripts that make changes to your environment — collect evidence first, remediate manually until you are confident in the automation
• Always test linked scripts manually using Run Now before activating the alert rule to confirm the output is as expected
• Use dynamic targeting where possible so automated responses are relevant to the specific machine or user involved in the alert
• Monitor the execution log regularly to confirm automated responses are firing correctly and producing useful output
• Set an appropriate execution delay for scripts that need the triggering event to fully complete before the assessment runs
• Document all alert-linked scripts and their intended purpose so the team understands what automated actions may occur in response to alerts
• Review linked scripts periodically to ensure they are still appropriate as your environment evolves

[Your administrator should establish a review process for automated response workflows, particularly any scripts that make changes to directory objects or account configurations.]

Prerequisites:

Before installing, confirm the following:

Download the PowerShell Orchestrator package:

[Your administrator should confirm whether packages are distributed internally or downloaded directly from the portal in your environment.]

Enabling WinRM on the installation machine:

If WinRM is not already enabled, run the following in PowerShell as Administrator:

Enable-PSRemoting -Force

Confirm WinRM is running:

Get-Service WinRM

The service should show as Running.

[Your administrator should confirm whether WinRM is managed via Group Policy in your environment before enabling it manually.]

Installation steps:

1. Copy the lta-mp-orchestrator.zip package to the target Windows machine
   
2. Extract the zip file to a working directory
   
3. Open PowerShell as Administrator and navigate to the extracted directory:
   

cd C:\path\to\extracted\orchestrator

4. If not already done, allow PowerShell scripts to run:

Set-ExecutionPolicy Unrestricted

5. Run the installation script:

.\Install.ps1

6. Follow any on-screen prompts during installation, including:
   
   • Entering the LT Auditor ^MP server IP address or hostname
   • Confirming the syslog port (default: 514)
   • Selecting the communication protocol (UDP, TCP, or TLS)
   • Entering the service account credentials to be used for Active Directory and Entra ID assessments
7. Once installation is complete, reset the PowerShell execution policy:
   

Set-ExecutionPolicy Restricted

[Your administrator should fill in the exact installer prompts and any environment-specific options that appear during installation.]

Post-installation verification:

After installation completes, confirm that PowerShell Orchestrator is running and communicating with the LT Auditor ^MP server.

1. Check the service status:

sc query PowerShellOrchestrator

The service should show as Running.

2. In the LT Auditor ^MP Web UI, navigate to Admin → Modules and confirm the PowerShell Orchestrator instance appears with a status of Connected
   
3. Check the PowerShell Orchestrator logs for any errors:
   

\Program Files\Blue Lance 2-0\PowerShellOrchestrator\Logs\

4. Verify that assessment data is appearing in the LT Auditor ^MP View module by navigating to View and selecting the Active Directory environment

If the module does not appear as connected in the Web UI, confirm that no firewall is blocking communication between the installation machine and the LT Auditor ^MP server on the configured syslog port.

[Your administrator should note the specific port, protocol, and service account used in your environment, and document which machine PowerShell Orchestrator is installed on.]

Verifying service account permissions:

The service account used by PowerShell Orchestrator requires the following minimum permissions:

Active Directory:

• Read access to all user, group, and computer objects in the monitored domains
• Read access to Group Policy Objects (GPOs)
• Read access to Active Directory Sites and Services

Microsoft Entra ID:

• Directory.Read.All — read access to directory objects
• AuditLog.Read.All — read access to audit logs
• Policy.Read.All — read access to conditional access and other policies

[Your administrator should confirm the exact permissions required in your environment and ensure the service account is configured accordingly before running the first assessment.]