The forthcoming section outlines the organizational structure of the GYTPOL working directory, located by default at "c:\gytpol". This directory houses various files, particularly within the Data subfolder. Following the installation of GYTPOL Server, the subsequent folders will be established, containing database files, configuration files, and predefined settings files:
Data Folder: This folder, located within the "gytpol" directory, serves as the repository for crucial files. The following files are situated here:
Database Files: These files constitute the heart of GYTPOL's data management system.
Configuration Files: These files hold the system's configuration settings.
Predefined Settings Files: These files contain predetermined configurations and settings for specific functionalities.
GytpolServer Folder: The "GytpolServer" folder, also positioned within the "gytpol" directory, encompasses a multitude of essential components:
System Executables: These files are responsible for driving the core functionalities of the GYTPOL system.
Binaries: This directory houses binary files required for various operations.
Libraries: Libraries contain essential code resources that contribute to the system's functionality.
Two important notes to consider:
Elevated Editing: All JSON files mentioned in the following context must be edited using an elevated text editor such as Notepad (run as Administrator) or Notepad++, which will elevate itself when necessary. This practice ensures that the modifications are carried out with the appropriate privileges.
Installation Drive Variability: It's important to recognize that the drive designated for software installation might differ, contingent on the Windows Server settings. As a result, the installation drive could be labeled as D drive, E drive, or any other drive letter based on the configuration.
By understanding this directory structure and following the guidelines provided, you can proficiently navigate and manipulate the essential files within the GYTPOL working directory.
Analyzer
Relevant service and DBs
For LocalDB: For installations utilizing LocalDB, the databases are stored in the "c:\gytpol\data\Analyzer" folder. This folder contains the following database files:
Data: "gytpol_analyzer.mdf"
Log: "gytpol_analyzer_log.ldf"
For External SQL: In cases where an external SQL server is employed, the connection string within the "appsettings.json" configuration file needs to be adjusted accordingly. This modification facilitates the establishment of a connection between GYTPOL and the external SQL server.
Configuration Changes and Service Restart: It's vital to recognize that if any modifications are made to settings within any configuration file, restarting the GYTPOL service is imperative. This restart ensures that the system incorporates the updated configurations and operates seamlessly with the altered settings.
All the below files are located in c:\gytpol\data\Analyzer
appsettings.json
The file contains the database connection string and includes critical information about the SQL server name and the database name. Here are a few important points to consider regarding this file:
Connection String Content:
The connection string in the file outlines the SQL server's name and the specific database being accessed (found on line 3#).
External/Shared SQL Servers and Encryption:
If you're using an external, dedicated, or shared SQL server without database encryption, it's essential to ensure that the connection string includes the parameter "Encrypt=False". This parameter configuration caters to scenarios where encryption is not required for the communication between GYTPOL and the SQL server.
Example of Default LocalDB File:
Below is an example of a connection string for a default localDB file. This serves as a reference for how the connection string is structured:
Config > clientUpgrade.json
GYTPOL features an auto-update functionality for clients, allowing the updating of existing clients to the latest version once the updated version is made accessible on the server. To accomplish this, follow these steps as outlined:
Client Auto-Update Steps: Detailed steps for the auto-updating of GYTPOL clients are provided at:
The file managing parameters related to GYTPOL client auto-upgrades is the "clientUpgrade.json" file. This file plays a crucial role in managing parameters for the client auto-update process. Here are the fields within this file that you can modify:
"computers" Field: The "computers" field manages the list of computers that require updating. The default setting is "all," updating any client reporting to GYTPOL. To update only specific clients, list their names in JSON syntax. Example:
"computers": [
"pc01", "pc02", "srv01", "dc02"
],
"links" Field: The "links" field defines the URL from which clients download the new version. Provide the GYTPOL server's FQDN. For Remote Employees, add additional links from web-facing servers. Example:
"links": [
"https://<GYTPOL-SRV-FQDN>:9093/updates/gytpolClient_x64.msi",
"https://<customers-webserver.domain.com>/path-to-msi.msi"
],
"gytpolClient" Field: This field specifies the name of the client file as the end of the URL specified in the "links" section. Update this field accordingly. After the initial upgrade, leave it as is.
"version" Field: The "version" field signifies the client file version. You can verify the version by accessing the Details tab. To do this, right-click the client MSI file, select "Properties," and then navigate to the "Details" tab where you can find the version information in the "Subject" field.
By understanding and modifying these fields as necessary, you can effectively manage the auto-upgrade process for GYTPOL clients, ensuring that they are always up to date with the latest version and enhancements.
Config > SIEM.json
GYTPOL offers the capability to forward data regarding findings, alerts, and remediations to a SIEM (Security Information and Event Management) system using the syslog protocol. This data forwarding is managed through the "siem.json" file, and the process is outlined below:
"host" Field: This field should contain the hostname or IP address of your SIEM server that will receive the data sent by GYTPOL.
"port" Field: Specify a port number that is open and available for communication over TCP with your SIEM. Typically, port 514 is used for this purpose.
"protocol" Field: Set the protocol to "TCP". UDP is not supported for data forwarding in this context.
"gytpolServer" Field: Enter the GYTPOL server's fully qualified domain name (FQDN) to establish the connection between GYTPOL and the SIEM.
"isSiemIntegrationEnabled" Field: Change the value of this field to "true" to enable the SIEM integration.
Once you've made these changes in the "siem.json" file, it's essential to restart both the "gytpol Data Repository" service and the "gytpol Analyzer" service, as the latter is dependent on the former. This restart ensures that the updated configurations take effect and that the data forwarding to the SIEM is initiated properly.
By following these steps, you can seamlessly integrate GYTPOL with your SIEM system, enabling the transmission of pertinent data for analysis and monitoring purposes.
Config > options.json
If the GYTPOL support team requires more detailed logs to facilitate troubleshooting or to gain insights into the system's operational status, please follow these steps:
Adjust "minLogSeverity" Value: Change the value of "minLogSeverity" from the current setting of 5 to 0. This adjustment will increase the logging verbosity, capturing more detailed information in the log files.
Save the Configuration File: Save the changes made to the configuration file.
Restart "gytpol Analyzer" Service: To apply the modified logging settings, restart the "gytpol Analyzer" service. This ensures that the new logging configuration takes effect.
Review Additional Log Files: Once the service is restarted, additional log files will be generated in the "Analyzer > Config > logs" folder. These log files will contain more comprehensive information about the system's processes and operational status.
By following these instructions, you can generate more detailed logs to provide the GYTPOL support team with the necessary insights to assist in resolving any issues or enhancing the system's performance.
GPMCProxy
All the below files are located in c:\gytpol\data\GPMCProxy
Relevant service
If your architecture involves utilizing a localDB without an external SQL server, it's important to note that the only service that will make use of the "gytpolSVC" account (which was created during the server setup) is the GYTPOL GPMC Proxy service.
config > dcs.json
The mentioned file, which will be automatically populated during GYTPOL installation process, holds a crucial list of Domain Controllers to be utilized by the Policy Validator module and the dsRequester in GYTPOL. It plays a pivotal role in facilitating the operations of these components.
Here are the key points regarding this file:
Automatic Population: The file will be populated automatically based on the Domain Controllers in the same site as GYTPOL server.
Blank File Impact: An empty file will result in the Policy Validator module not functioning, causing the associated page to appear blank.
Modifications in JSON Format: If any changes are made to this JSON file, such as adding or removing Domain Controllers, it's essential to maintain the file's comma-delimited format as demonstrated in the provided example.
Restarting Services After Changes: Following any adjustments to the JSON file, ensure to restart the following GYTPOL services to enact the changes: "gytpol GPMCPROXY service," "gytpol Data Repository service," and "gytpol Validator service".
By adhering to these guidelines, you can effectively manage the Domain Controllers used by the Policy Validator module and the dsRequester within GYTPOL, ensuring that these components operate optimally and in accordance with your requirements.
RsopRepository
Relevant service and DBs
In the context of GYTPOL utilizing a localDB setup, the databases are stored within the "c:\gytpol\data\RsopRepository" folder. This folder contains two essential database files:
Data: The "gytpol_rsop_reports.mdf" file holds the core data of GYTPOL's RSoP (Resultant Set of Policy) reports.
Log: The "gytpol_rsop_reports_log.ldf" file is the log file accompanying the data file, tracking changes and maintaining data integrity.
Furthermore, it's crucial to note that whenever changes are made to any configuration files within the GYTPOL setup, restarting the relevant GYTPOL services is imperative. This restart ensures that the changes are applied, settings are updated, and the system operates seamlessly based on the modified configurations.
All the below files are located in c:\gytpol\data\RSOPRepository
appsettings.json
The file in question contains the database connection string and provides information about the SQL server name and the specific database name. This information is typically located within the file, specifically on line #7.
Below is an example of a default localDB database connection string. This example showcases how the connection string is structured:
Config > domains.json
The file will encompass a list of domain names that are permitted to undergo the Policy Validation module using the Group Policy Modeling Wizard. These domain names will be subject to a comparison against the actual policies applied to the respective devices or users. The Policy Validation page will then exclusively display devices that are associated with the domains specified within this JSON file.
In essence, this JSON file acts as a filter, ensuring that only devices linked to the approved domains are considered for the Policy Validation process. This targeted approach streamlines the process by narrowing down the focus to specific domains, enhancing the accuracy and relevance of the analysis performed by the Group Policy Modeling Wizard.
Config > options.json
Here are two important settings in GYTPOL's configuration that control reporting intervals and logging severity:
minMinutesBetweenReports: This parameter sets the minimum time interval between reports sent from the same device. The default value is 150 minutes (2 hours and 30 minutes). While this value can be modified for troubleshooting purposes, it's advised not to lower it significantly. Adjusting this parameter might be useful in situations where you need more frequent reports from specific devices for diagnostic purposes.
minLogSeverity: The "minLogSeverity" parameter dictates the level of detail in the logs generated by GYTPOL. By default, it's set to 5. However, if the GYTPOL support team requires more comprehensive logs to troubleshoot issues or gain insights into system operations, you can change this value to 0. This adjustment will increase the level of logging detail. To apply this change, you'll need to restart the "gytpol Data Repository Service" service.
As a result of this adjustment, additional log files will be generated in the "RsopRepository > Config > trace" folder. These logs will contain a higher level of information regarding the system's processes and operational status.
By understanding and adjusting these settings as needed, you can optimize GYTPOL's reporting intervals and logging detail for effective troubleshooting and monitoring.
Config > URLs.json.
Provided is a compilation of internal URLs designated for diverse system components. These URLs play the role of transmitting and receiving data internally among GYTPOL's microservices and databases. It's paramount that these ports remain insulated from external access, designed exclusively for local utilization.
We strongly advise against altering the configurations within the file. However, if your operations involve Nutanix hypervisors and port 5000 is engaged by Nutanix processes, we recommend reviewing the port 5000 modification procedure for guidance.
Config > vdiImages.json
The designated file serves as a controller for VDI Pool names within which the GYTPOL client is deployed. When GYTPOL client is installed on non-persistent VDI instances that undergo regular resets, such as weekly or nightly, the client's changes will be reversed, leading to the reemergence of alerts.
Upon adding a Pool name to the file, the VDI instances belonging to that Pool will be allocated a dedicated section within the UI. To enable this functionality, the file should contain the specific Pool name. Any VDI instance that aligns with the specified name will be allocated to the corresponding VDI section in the UI
It's important to note that GYTPOL will disregard any numerical values or hyphens ("-") that appear after the Pool name, including the last hyphen and numerical sequences. For instance, if the Pool name is "PA-R111-COMP," any VDI instances named "PA-R111-COMP-01," "PA-R111-COMP-02," or "PA-R111-COMP-03" will be associated with the "PA-R111-COMP" record in the file.
This mechanism ensures that VDI instances under the same Pool name are properly managed and categorized within GYTPOL's UI, irrespective of minor numerical or hyphen variations in their names.
Updates
This service is specifically designed for customers who utilize the Remote Employee (RE) feature and is not obligatory for all users. When the Remote Employee feature is not required or activated, this service can be disabled and stopped. For further insights into the Remote Employee feature, we recommend consulting the High-Level Design (HLD) document.
Relevant service
The designated service assumes the role of interfacing with the Cloud API, ensuring the retrieval of pending reports from external devices that are unable to transmit misconfiguration reports through the local URL. This mechanism serves as a fallback, enabling these devices to still report their misconfigurations via the Cloud API.
It's important to mention that if the feature is not enabled for the customer and the tenant hasn't been created, the corresponding service can be stopped and disabled. By default, the feature is disabled during the POC phase.
If you decide to enable this feature later, follow these steps:
Ask GYTPOL for support to create Remote Employees tenant in US/EU region.
Create an "updates" folder within the c:\gytpol\data\ directory.
Copy the appsettings.json file from the client archive to the newly created "updates" folder.
appsettings.json
"pollInterval": This parameter dictates the duration between consecutive interactions with the Cloud API, fetching any pending reports. The default interval is set at 60 minutes. Should the need arise, this interval can be modified, either reducing it for more frequent checks or extending it for less frequent ones.
"remoteURL": This configuration defines the URL for the Cloud API. This URL can be tailored to be either EU or US based (shown in “region” field), based on the specific requirements of the customer. It's a pivotal setting that directs communication to the designated Cloud API location.
"accessKeyID" and "SecretAccessKey": These entries involves the keys that provides secure access to the Cloud API URL exclusively from the server itself. It's a critical security measure ensuring that only authorized access is granted to the Cloud API.
When editing any of these parameters within the configuration files, it's essential to bear in mind that restarting the gytpol Updater service is imperative. This reboot guarantees that the modifications are integrated effectively, ensuring the smooth functioning of the service in alignment with the updated configurations.
For customers who do not utilize a Cloud API or operate within closed environments, the designated file will lack any entries for "access keys" values. In such cases, this parameter will remain absent from the configuration.
During the initial installation process, it's recommended to substitute this file with the version located within the client zip package provided by the GYTPOL team. This ensures that the file's contents are in alignment with GYTPOL's recommended configuration, tailored to the specific client's needs and circumstances.
Validator
Relevant service and DBs
For localDB, the DBs located in c:\gytpol\data\Validator folder:
Data: gytpol_joblog.mdf, gytpol_profiler.mdf, gytpol_validator.mdf
Log: gytpol_joblog_log.ldf, gytpol_profiler_log.ldf, gytpol_validator_log.ldf
If one of the settings in any config file is changed, please make sure to restart the service.
appsettings.json
The file will contain the database connection string, explicitly specifying the SQL server's name and the database's name. This information is located in line #3-#5 of the file.
Below is an illustration of the default localDB file as a sample reference. This example is intended to offer a clear understanding of the file's structure and content.
Please ensure to incorporate the appropriate SQL server name and database name in the actual file according to your configuration needs.
WebSrv
Relevant service
If one of the settings in any config file is changed, please make sure to restart the service.
Static > Updates folder
Within this folder, you are expected to store the client files (e.g., MSI, PKG) necessary for the automated update procedure, which was elaborated upon in the Analyzer section. The URL specified in the "clientUpgrade.json" file directs to the contents of this folder, facilitating the seamless auto-update process. This organized approach ensures that the correct client files are accessible for updates and contributes to the efficiency of the auto-update mechanism.
websrv_config.json
The default settings for the management ports are as follows:
HTTP Port: 9090
HTTPS Port: 9093
These ports serve as the default access points for GYTPOL's management interface. However, it's possible to modify these ports for more tailored accessibility. This can be accomplished by designating specific users or IP addresses permitted to access the user interface, facilitated through organizational firewalls.
If you opt to alter either of these ports, it's imperative to remember that both the HTTP and HTTPS ports need to be changed simultaneously. While you have the flexibility to select different port numbers, it's essential to avoid ports already in use by GYTPOL's internal processes, as indicated in the RsopRepository > URLs.json configuration. This ensures smooth communication while accommodating your specific port preferences.
"throttledUrls": This parameter signifies the limit of concurrent reports allowed per second. The default value is set at 50 reports per second. It's strongly recommended not to modify this number unless specifically requested by the GYTPOL team. Any adjustments in this regard should be carried out only under the guidance of GYTPOL's experts. If needed, further troubleshooting steps can be found in the provided resource.
"permissions": By default, access to the user interface (UI) is extended to Authenticated Users. The management of roles and permissions is conducted within the UI itself, accessible through the "Roles and Permissions" screen. Users within the designated group gain access to the UI, with their access level aligned to the roles assigned to them. Should no roles be granted, an error message will emerge. If necessary, it's possible to switch the group from Authenticated Users to any security group within the Active Directory. However, it's important to note that mere membership within a group is insufficient; actual access levels are established via the Roles screen. This setup ensures controlled and tailored access to GYTPOL's UI in line with your security requirements.
PEM Certificate
Additionally, the WebSRV folder is the designated location where the Node.js certificates are stored. These certificates are self-signed and are generated as part of the installation process. If you intend to replace the self-signed certificates with your own custom certificate, comprehensive instructions can be found in this document. This resource outlines the steps required to seamlessly transition to your preferred certificate setup.