Ubiquiti UniFi – Tuning the Network Application for a High Number of UniFi Devices

Updated on 4 mag 2023Print

This article only applies to advanced users running UniFi on their own Windows/macOS/Linux machine, to help diagnose and optimize self-hosted UniFi Network Servers running under a high load. We generally recommend using a UniFi OS Host for the best experience. Visit UI.com to learn more.

Notes & Requirements:

  • Ensure you are running the latest version of UniFi Network, found here.
  • This article describes advanced configuration options and should only be attempted by advanced users.
  • Create a backup prior to following the instructions in this article. See UniFi – Backups and Migration for more information.

Caution must be taken when self-hosting a UniFi Network Server if there are hundreds of UniFi devices connected across multiple sites. This increased system load may lead to performance degradation if certain things are not optimized.

Symptom: High CPU Usage

One of the most important metrics to monitor is the CPU usage of the UniFi Host. High CPU usage is the first indication that there is an issue. Unfortunately there is no easy solve for this, and merely increasing the CPU is not always the answer.

Allocating Additional Memory

Before increasing the RAM allocation on your machine, first try increasing the `XMX` and `XMS` options. By default, the UniFi Network application has these set to 1GB. The following lines set the xmx and xms to values to 2GB (2048MB):

unifi.xmx=2048
unifi.xms=2048

The changes above would increase the memory that the UniFi Network application is allowed to consume from 1 to 2GB. Before moving to a machine with more CPU resources, it is recommended to max out the available memory on that machine with the above settings to see if CPU usage decreases.

If 2GB is not sufficient, administrators may want to raise the limit to 4, 8, 16, or even 32GB depending on the scale. In this case it would simply be increasing the value above in increments of 1024, i.e. 4 GB= 4096.

Note: The jstat -gcutil Java command can be used to check whether the memory allocation is sufficient on your machine. See the Oracle documentation for more information.

Increase Mongo WiredTiger Engine Cache

If you already increased the UniFi Network application memory settings to at least 4GB (xmx), you may need to also change the default Mongo WiredTiger engine cache. By default the UniFi Network Application uses:

db.mongo.wt.cache_size=256

On UniFi Network version 6.5.13 and above you can change this setting or let Mongo pick the default value by using:

db.mongo.wt.cache_size_default=true

For more information please refer to Mongo documentation.

Enabling High Performance Java Garbage Collector

If increasing memory does not solve the problem, administrators may consider also adding this line to the system.properties file:

unifi.G1GC.enabled=true

This enables a new Java Garbage Collector that can help optimize performance. However, if after these changes high CPU usage does continue after memory increase, a larger machine with more CPU cores and more memory to handle the workload may be necessary.

Changing Mongo Version/Engine

In persistent cases, administrators may consider updating MongoDB version to 3.2+ with WiredTiger as storage engine, as a means of better scaling their UniFi Network deployment. See the following links for instructions:

Symptom: Heartbeat Missed or Slow to Provision

All devices work by communicating to UniFi Network. These regular inform messages are referred to as “heartbeats”. By default, the application can handle 200 simultaneous device connections so heartbeats shouldn’t be missed unless thousands of devices are being managed. The number of simultaneous inform messages that can be processed can be set in the system.properties file by adding the following lines and adjusting the values to best suit your needs. It does not matter where these lines are added in the file.

inform.num_thread=200
inform.max_keep_alive_requests=100

The default value is 200 and the max_keep_alive_requests value should always be lower than than num_thread. Try adjusting up from there. An increase in device stability should be seen, and by pushing the configuration out to other devices, become even more stable. 

Database Connection Tuning

When running a large UniFi installation, it may be desired to run an external Mongo cluster to be able to scale the database independently from the UniFi Network application. Discussion on that can be found here on our Community Beta forum. If high CPU usage is seen on the Mongo process, it can indicate the need of a bigger box or the need to separate the mongodb process as mentioned above. Once that is done, the following can be tuned to see if it results in better application performance: 

db.mongo.connections_per_host=100
db.mongo.threads_multiplier=5

This results in 500 threads that can be waiting for a Mongo connection. So keep in mind that more threads can mean higher CPU usage because the CPU has to context-switch between threads. It may allow for higher DB throughput, but only if the Mongo process is able to consume more CPU to serve requests faster. 

Source :
https://help.ui.com/hc/en-us/articles/115005159588-UniFi-Tuning-the-Network-Application-for-a-High-Number-of-UniFi-Devices

Ubiquiti UniFi – Repairing Database Issues on the UniFi Network Application

Updated on 1 mag 2023Print

Use this article to repair the database of malfunctioning UniFi Network applications. Please note this only applies to users self-hosting the UniFi Network Server on their own Windows/macOS/Linux machine, or those hosting UniFi Network on a legacy Cloud Key.

We generally recommend using a UniFi OS Host for the best experience. Visit UI.com to learn more. 

Symptoms

  • Statistics are only recorded for a few days and then are cut off or are only intermittently available.
  • Backups including statistics data cannot be generated.
  • Settings-only backups cannot complete, or are created but are unable to be restored due to corruption.
  • An error 400 is generated when trying to open UniFi Network.
  • The UniFi Network application service will not start due to database errors.

32-bit MongoDB Limitations

32-bit MongoDB collections are limited to a total size of 2GB. While running the MMAPv1 storage engine this can cause issues when trying to shrink the aggregate collection sizes. When running a compact command on the MongoDB, the database is rewritten and defragmented without error correction. This process does not return useable disk space to the UniFi Host when the storage engine is MMAPv1.

Getting back that valuable disk space on a 32-bit MongoDB instance will require a repair of the database. This repair may be needed for those who are suspecting invalid entries, corruption, or collection scaling issues. To be able to run a database repair, the Cloud Key will have to have enough free disk space equal to the size of the current data set plus 2 gigabytes. If the dataset has already grown too large to proceed with the db.repairDatabase() command there are instructions below to work around that.

Note: The Legacy Cloud Key (UC CK) utilizes the following:

  • 32-Bit architecture
  • MMAPv1
  • MongoDB Version 2.4.10

Repairing a Cloud Key Database

  1. Establish an SSH connection with the Cloud Key.
  2. Download the mongo pruning script. As written, the script will only keep entries from the past 7 days. It will not remove entries that are required for UniFi administration. Do so by running the following command:
    cd /tmp/ wget https://help.ui.com/hc/en-us/article_attachments/360008640574/CK_repair.js
  3. Stop the UniFi service:
    service unifi stop
  4. The UniFi service will shut down the mongo process. Make sure that the UniFi service has been completely shut down. Repair the database to compact the data entries and free unused disk space field that is included in the query criteria.
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –repair
    1. NOTE: Steps 5-8 are optional if you need to prune back the database to conserve disk space.
  5. Restart mongo using:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –journal –fork
    1. NOTE: Journaling may not be have been enabled in your mongo database. If so, then remove the –journal option in the above command.
  6. Execute the script to prune the stat collections that are causing the problem:
    mongo < /tmp/CK_repair.js
  7. Shut down the mongo server with this command:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –shutdown
    1. Note: The last command in the CK_repair.js script is “db.repairDatabase()”. It may result in an error if the stats collections have already grown too large to be repaired while the mongo server is running. If you see such an error running the script then you will need to repair the database from the command line once again by running the command in step 3.
  8. Finally, restart the UniFi service:
    service unifi start

The Cloud Key should now be able to run the Network application. If you still have database issues, please upgrade to the latest Cloud Key Gen2 Plus which does not experience this problem.

Repairing a Debian-based Linux Database

  1. Stop the UniFi service
    service unifi stop
  2. In some cases, where the journal is corrupted, it will be helpful to run the following command before repairing the database, to move it to another location:
    mv -vi /usr/lib/unifi/data/db/journal /usr/lib/unifi/data/db/journal-$(date -I)
  3. Repair the database with this command:
    mongod –dbpath /usr/lib/unifi/data/db –smallfiles –logpath /usr/lib/unifi/logs/server.log –repair
  4. Finally, restart the UniFi service:
    service unifi start
    1. Note: If this process was performed as root the file ownership may have changed. This can be changed with:
      chown -R unifi:unifi /usr/lib/unifi/data/db/
      chown -R unifi:unifi /usr/lib/unifi/logs/server.log

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

Repairing a macOS Database

  1. Create a temporary working directory. For repair purposes, we will call this directory /repair. In terminal:
    mkdir ~/repair
  2. Visit the MongoDB official download website, and download the .tgz release that corresponds to your server’s CPU architecture.
    1. You can also download 2.4.14 here directly: 2.4.14.tgz
  3. Move the downloaded package to your working directory, and extract it by double-clicking it or using the application of your choice.
  4. Locate the bin/mongo binary file, and copy it to your working directory.  At this point, the downloaded .tgz package and any extra extracted files can be deleted as we only need the mongo binary.
  5. Open Terminal and move to your working directory:
    cd ~/repair
  6. Close or stop UniFi.
  7. Repair the database with this command:
    mongod –dbpath ~/Library/Application\ Support/UniFi/data/db –smallfiles –logpath ~/Library/Application\ Support/UniFi/logs/server.log –repair
  8. Open the UniFi application from Finder:
    open -n /Applications/UniFi.app

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

Repairing a Windows Database

  1. Visit the MongoDB official download website, and download the .zip release that corresponds to your CPU architecture.
    1. Note: The recommended MongoDB version is 3.4.x. You can download 3.4.23 directly here: 3.4.23.zip.
  2. Extract \bin\mongod.exe to a working directory of your choice.  In this example, we will use C:\repair\ You may ignore all other files included in the .zip.
  3. Close or stop UniFi.
  4. Open the command prompt by pressing WINDOWS + R.  In the popup, type cmd, and press ENTER.
  5. Enter Working Directory:
    cd C:\repair\
  6. Repair the database with this command:
    mongod.exe –dbpath “%userprofile%\Ubiquiti UniFi\data\db” –smallfiles –logpath “%programfiles%\Ubiquiti UniFi\logs\server.log” –repair
  7. Open the UniFi application.

If you still have suspected database issues please migrate to a Cloud Key Gen2 Plus or Dream Machine Pro. These UniFi OS Hosts do not experience this type of database corruption.

How to Migrate from MMAPv1 to WiredTiger

Attention: This section does not apply to 32-bit architecture hosts including the UC-CK G1.

After UniFi Network is functional again, a user may wish to migrate it to the WiredTiger storage engine.

To verify how much space is used, run the following command:

du -shc /usr/lib/unifi/data/db/ace* /usr/lib/unifi/data/db/journal/* /usr/lib/unifi/data/db/local* | grep total

To verify which MongoDB version is being used, run the following:

mongod --version | grep "db version"

To verify what storage engine version is being used, run the following two commands:

mongo localhost:27117
db.serverStatus().storageEngine.name

How to Migrate to WiredTiger

  1. Create a backup under Settings > Maintenance > Backup with the desired retention settings.
  2. Uninstall UniFi from Windows or macOS. Purge UniFi from Debian-based Linux with the command:
    sudo dpkg -P unifi
  3. Reinstall UniFi on Windows or macOS. Reinstall UniFi on Debian-based Linux with the commands:
    cd /tmp/
    wget <https link to download>
    sudo dpkg -i unifi_sysvinit_all.deb
  4. In the UniFi Setup Wizard restore the backup from step 1.

Source :
https://help.ui.com/hc/en-us/articles/360006634094-UniFi-Repairing-Database-Issues-on-the-UniFi-Network-Application

Ubiquiti Self-Hosting a UniFi Network Server

Updated on 5 mag 2023Print

Self-hosting a UniFi Network Server should only be done by experienced network administrators. For the best and most streamlined experience, we recommend running UniFi Network on a UniFi OS Console or other UniFi OS Host, such as a Cloud Key. This will eliminate compatibility risks associated with third-party software and hardware.* Other benefits of UniFi OS Hosts include:

  • Optimized hosting and management performance
  • Automatic scheduling of backups and updates
  • Seamless email and mobile push notifications for important system activity

*UniFi also offers the Cloud Key Enterprise (on-premise) and a native Cloud Hosting subscription for scaleable deployments managing hundreds of UniFi APs.

If you choose to continue, see below for instructions to install the UniFi Network Application on your device.

Instructions

Windows

Linux

macOS

  1. Download the latest version of the UniFi Network application (UniFi-installer.exe) from the Download page.
    1. The latest versions of the UniFi Network Application (7.3) require Java 11.
    2. Previous versions (7.2) use Java 8.
    3. Install only the x64 Java release and only one version of Java.
  2. You will be prompted to install Java 11. Select the following options and download the x64 .msi file for Windows:
    1. Package Type: JRE
    2. Version: 11
  3. Install Java, and set the Set JAVA_HOME variable to Will be installed on local hard drive.
image.png
  1. After installing Java, continue the UniFi Network application installation and start it.
  2. Ensure that any anti-virus/spyware programs and the Windows firewall are not blocking the application.
  3. Open a browser, navigate to https://localhost:8443 and proceed when seeing the security warning.
  4. Proceed with the setup wizard.
  5. Adopt your first UniFi device.

Frequently Asked Questions

1. Does the UniFi Network application have to run at all times?

If the UniFi Network application is turned off, adopted UniFi devices (access points, switches) will keep functioning. 

However, it is highly recommended to keep the UniFi Network application running at at all times. This enables you gather accurate statistics and make configuration changes whenever needed. 

If you are not able to keep the Self-Hosting Network Server running continuously, then we recommend to upgrade to a UniFi OS Console, which is optimized to run UniFi Network and other applications.

2. Can I manage UniFi Devices that are adopted by another UniFi Network application?

No. The UniFi Network application installed on Windows/macOS/Linux is not a viewer for other UniFi Network applications (running on UniFi OS Consoles or other hosts).

3. The UniFi Network application is running slow.

Verify if the Self-Hosted Network Server is capable of running the UniFi Network application. The more UniFi and client devices that are connected, the more resources that will be needed.

Please be aware that self-hosting the UniFi Network application is an advanced setup for those familiar with network administration. If you are experiencing poor performance, we recommend upgrading to a UniFi OS Console, which is optimized to run UniFi Network and other applications.

4. The UniFi Network application is not able to start.

Verify if the Self-Hosted Network Server is capable of running the UniFi Network application and that the correct version of Java is installed. 

If you continue to experience issues, try installing the application on a different host machine.

Please be aware that self-hosting the UniFi Network application is an advanced setup for those familiar with network administration. If you are unable to get the UniFi Network application running on your host machine, we recommend upgrading to a UniFi OS Console, which is optimized to run UniFi Network and other applications. 

5. The UniFi Network application starts up, but I do not see any nearby UniFi devices.

Make sure that the firewall on the host machine is allowing the ports needed by UniFi and that the UniFi Network application is not blocked by any anti-virus/spyware programs.

Also make sure that the UniFi devices and the application are on the same network. If not, then remote adoption is required.

6. I get a “Your connection is not private” warning when accessing via my browser.

This can be safely ignored. Proceed to the next page.

7. What are the UniFi Network application system requirements?

At a bare minimum, we recommend the following system requirements (make sure to read the Release Notes for more details about a particular version):

  • Operating system:
    • Linux: Ubuntu Desktop / Server 22.04; Debian 11 “Bullseye”
    • Windows: Windows 10; Windows Server 2016
    • macOS: Mavericks 10.9, 10.10 Yosemite, 10.11 El Capitan, 10.12 Sierra, 10.13 High Sierra, 10.14 Mojave, 10.15 Catalina.
  • CPU: x86-64 Processor (Intel / AMD x64 Processors)
  • RAM: 2GB
  • Network: 100Mbps Wired Ethernet
  • HDD: Minimum 10GB free (20GB or more preferred)
  • Java: Java Runtime Environment (JRE) 11
  • Web Browser: Google Chrome
  • MongoDB: version 3.2 or later. Mongo is offered bundled: default is 2.4.14 (for macOS and Windows only).

Note: You will need to continually increase your system specs as you begin to adopt and manage more devices.

Source :
https://help.ui.com/hc/en-us/articles/360012282453-Self-Hosting-a-UniFi-Network-Server

Ubiquiti UniFi – Advanced Updating Techniques

Updated on 5 mag 2023Print

Use advanced techniques as a last resort to update UniFi devices and UniFi software when it is not possible to do so via the user interface. 

We highly recommend that most users enable automatic updates, or trigger updates through the user interface. See How to Update UniFi to learn more.

Update UniFi Devices via Web Application

Updating via the Device Property Panel

Use Case: You want to try Early Access firmware releases for specific devices, or you want to return to an official release after trying an EA release.

1. Copy the firmware release link from a post on community.ui.com/releases.

image1.png

2. Paste the link in the address bar found in the Settings tab of the device’s properties panel.

image2.png

Updating via Your Network Cache

Use Case: You prefer to download and store updates in your Network application so they can be used by other devices, as opposed to downloading multiple, device-specific files from the internet. This is an ideal solution for reducing bandwidth within high-volume networks that host a large number of similar UniFi devices. It is also suitable for the advanced users who disable internet access on their UniFi device’s management network.

Device updates can be cached in your Network application’s System Settings. Once an update is cached, you can open to your UniFi Devices page and click Update Available.

Note: The Cache link will appear when you hover your cursor over an update.image3.png

Updating via SSH

Please note that SSH updating is not an officially supported process and may prevent your UniFi OS console from functioning. Only do this at the request of UI Support. It is only prescribed to work around specific scenarios, such as when:

  • Prior, traditional, update attempts have failed, likely due to an incorrect network configuration. For more details, see How to Update UniFi.
  • Your UniFi Network device is not being discovered or cannot be adopted because it has been preloaded with outdated firmware.
  • Your UniFI OS Console cannot be set up because it has been preloaded with an outdated version of UniFi OS.

UAP/USW (Internet) 

  1. Copy the update link from community.ui.com/releases.
  2. SSH into your device.
  3. Run the following command:upgrade paste_download_link_here Example:upgrade https://dl.ui.com/unifi/firmware/UAL6/5.60.1.12923/BZ.mt7621_5.60.1+12923.210416.1641.bin

UAP/USW (No Internet) 

  1. Download the desired firmware update from community.ui.com/releases.
  2. Use the following SCP command to copy the file into the /tmp folder of your device from your workstation. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExample:
    scp /Users/alexpro/Desktop/BZ.mt7621_5.60.1+12923.210416.1641.bin Alex@192.168.1.219:/tmp/fwupdate.bin 
  3. Enter your SSH password when prompted.
  4. SSH into your device.
  5. Run the following command:syswrapper.sh upgrade2 &

UDM, UDM Pro, UDM SE, UDR, UDW, UCK G2, UCK G2 Plus, UNVR, UNVR Pro, UXG Pro (Internet)

  1. Copy the update link from community.ui.com/releases.
  2. SSH into your device.
  3. Run the following command:
ubnt-systool fwupdate paste_download_link_here 

Example:

ubnt-systool fwupdate https://fw-download.ubnt.com/data/unifi-dream/dd49-UDR-2.4.10-cd3afa000ebf4a4fb15374481539961c.bin

If your UDM, UDM Pro or UXG-Pro runs version 1.x, then please use the ubnt-upgrade command.

Example:

ubnt-upgrade https://fw-download.ubnt.com/data/udm/1adc-udmpro-1.12.38-ca8a490ac2b04247abb3f7d3e3eae01a.bin

UDM, UDM Pro, UDM SE, UDR, UDW, UCK G2, UCK G2 Plus, UNVR, UNVR Pro, UXG Pro (No Internet)

  1. Download the desired firmware update from community.ui.com/releases.
  2. Use the following SCP command to copy the file into the /tmp (/mnt/data for version 1.12 and below) folder of your device from your workstation. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExample:
    scp /Users/alexpro/Desktop/UDR-2.4.10.bin root@192.168.1.1:/tmp/fwupdate.binIf you are running Version 1.12 and below, use the following command:
    scp /folder_path/firmwarefile.bin <user>@<IP of device>:/mnt/data/fwupdate.binExample:
    scp /Users/alexpro/Desktop/UDR-2.4.10.bin root@192.168.1.1:/mnt/data/fwupdate.bin
  3. Enter your SSH password when prompted.
  4. SSH into your device.
  5. Run the following command:ubnt-systool fwupdate /tmp/fwupdate.binVersion 1.12 and below:
    ubnt-upgrade /mnt/data/fwupdate.bin

USG (Internet) 

  1. Copy the update link from community.ui.com/releases.
  2. SSH into your device.
  3. Run the following command:upgrade <paste_download_link_here> Example:
    upgrade https://dl.ui.com/unifi/firmware/UGW3/4.4.56.5449062/UGW3.v4.4.56.5449062.tar

USG (No Internet) 

  1. Download the desired firmware update from community.ui.com/releases.
  2. Rename the file: upgrade.tar
  3. Use the following SCP command to copy the file into the /home/<user> folder of your USG from your workstation. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/upgrade.tar <user>@<IP of device>:/home/<user>/upgrade.tarExample:
    scp /Users/alexpro/Desktop/upgrade.tar Alex@192.168.1.1:/home/Alex/upgrade.tar
  4. Enter your SSH password when prompted.
  5. SSH into your device.
  6. Run the following command:sudo syswrapper.sh upgrade upgrade.tar

Manually Update the Network Application

  1. Download the desired application update from community.ui.com/releases.
  2. SSH into your device.
  3. Run the following command (UDM/UDM Pro if still running UniFi OS 1.x):unifi-os shell
  4. Remove previously installed files:rm /tmp/unifi_sysvinit_all.deb &> /dev/null
  5. Store the new application version on your device using the download link:curl -o “/tmp/unifi_sysvinit_all.deb” <network application link.deb>Example:
    curl -o “/tmp/unifi_sysvinit_all.deb” https://dl.ui.com/unifi/6.2.26-a79cb15f05/unifi_sysvinit_all.deb
  6. Once downloaded, install the new version:apt-get install -y /tmp/unifi_sysvinit_all.deb
  7. Following installation, remove the downloaded file:rm /tmp/unifi_sysvinit_all.deb

Updating Devices in a Broken State

In rare occurrences, a device may stop functioning. UniFi APs may be updated using our TFTP Recovery. This should only be used if your AP completely stops functioning as a last resort prior to submitting an RMA. UniFi OS Consoles and gateways my be updated using Recovery Mode. This should only be used if prompted on your device’s LCM screen.

Source :
https://help.ui.com/hc/en-us/articles/204910064-UniFi-Advanced-Updating-Techniques

Ubiquiti UniFi – Storage Requirements and Compatibility

Updated on 5 mag 2023Print

Hard disks (HDD) enable the storage of recordings from Protect and Access, as well as voicemails from Talk. The Cloud Key Gen2 Plus requires an HDD, and comes with a 1TB disk pre-installed for your convenience.

Recommendations

Storage TypeApplicable UniFi HostsRecommended StorageGeneral Requirements
3.5″ HDDDream Machine Pro, Dream Machine SE, Network Video Recorders8TB UniFi HDDCMR drive with 7200RPM read/write speeds
2.5″ HDDCloud Key Gen2 PlusIncluded HDD, or Toshiba 2.5″ MQ01ABD100VCMR drive with 5400RPM read/write speeds
MicroSD CardDream Router, Dream WallMinimum capacity of 128GB

You can find instructions for replacing your current storage devices here.

Incompatible Storage

3.5” Disks

VendorSeriesModelCapacityNotes
SeagateSkyHawkST10000VX000410TBDoes not fit the drive tray.
SeagateUltrathinST500LT032500GBDoes not have bottom screws.
Western DigitalUltraSlimWD5000MPCK500GBDoes not have bottom screws and connectors do not fit the tray.
AnyAnySMR DrivesAnyDrives fit the tray but cause issues.

2.5” Disks

  VendorSeriesModelCapacityNotes
SeagateIronwolfZA960NM10001960GBDoes not meet the Power requirements*
SeagateIronwolfZA1920NM100011.92TBDoes not meet the Power requirements*
SeagateIronwolfZA3840NM100013.84TBDoes not meet the Power requirements*

*The Cloud Key Gen2 Plus does not support hard drives that require a 12V supply in addition to the default 5V supply.

MicroSD Cards

VendorSeriesModelCapacityNotes
SamsungEVO PlusAnyAnyCompatible with the Dream Router, not the Dream Wall
AnyAnyAny<128GBSD Cards must have at least 128GB of storage capacity

Source :
https://help.ui.com/hc/en-us/articles/360037340954

Ubiquiti UniFi – Backups and Migration

Types of Backups

There are UniFi OS backups and also application-specific backups. We strongly recommend using a UniFi OS backup for UniFi OS Hosts (i.e., Dream products, Cloud Key Gen2 Plus, and Network Video Recorders) because they capture backups for UniFi applications as well.

UniFi OS Backups

UniFi OS backups contain your entire system configuration, including settings for your UniFi OS Console, users, and applications. If Remote Access is enabled, UniFi OS Cloud backups are created weekly by default. You can also create additional Cloud backups or download localized backups at any time. 

UniFi OS backups are useful when:

  • Restoring a prior system configuration after making network changes.
  • Migrating all applications to a new UniFi OS Console that is the same model as the original.

Note: Backups do not include data stored on an HDD, such as recorded Protect camera footage.

Application Backups

Each UniFi application allows you to back up and export its configuration. Application backups contain settings and device configurations specific to the that application.

Application backups are useful when:

  • You want to restore a prior application configuration without affecting your other applications.
  • You want to migrate a Self-Hosted Network Server application to a UniFi OS Console.
  • You want to migrate your devices between two different UniFi OS Console models.
  • You need to back up a self-hosted Network application.

Note: Backups do not include data stored on an HDD, such as recorded Protect camera footage.

UniFi OS Console Migration

UniFi OS backups also allow you to restore your system configuration should you ever need to replace your console with one of the same model.

To do so:

  1. Create a Cloud backup or download a local backup. This can be done in your UniFi OS Settings.
  2. Replace your old UniFi OS Console with the new one. All other network connections should remain unchanged.
  3. Restore your system configuration on the new UniFi OS Console using the backup file. This can be done either during the initial setup or afterwards in your UniFi OS settings.

Note: Currently, UniFi OS backups cannot be used to perform cross-console migrations, but this capability will be added in a future update.

If you are migrating between two different console models, you will need to restore each application’s configuration with their individual backups. These file application backups will not include UniFi OS users or settings. 

See below for more information on using the configuration backups during migrations.

Migrating UniFi Network

Before migrating, we recommend reviewing your Device Authentication Credentials found in your Network application’s System Settings. These can be used to recover adopted device(s) if the migration is unsuccessful. 

Standard Migration

This is used when all devices are on the same Layer 2 network (i.e., all devices are on the same network/VLAN as the management application’s host device). 

Note: If you are a home user managing devices in a single location and have not used the set-inform command or other advanced Layer 3 adoption methods, this is most likely the method for you.

  1. Download the desired backup file (*.unf) from your original Network application’s System Settings
  2. Ensure that your new Network application is up to date. Backups cannot be used to restore older application versions.
  3. Replace your old UniFi OS Console with the new one. All other network connections should remain unchanged.
  4. Restore the backup file in the Network application’s System Settings.
  5. Ensure that all devices appear as online in the new application. If they do not, you can try Layer 3 adoption, or factory-reset and readopt your device(s) to the new Network application.

If a device appears as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host device) to perform an Advanced Adoption.

Migrating Applications That Manage Layer 3 Devices

This method is for users that have performed Layer 3 device adoption (e.g., devices are on a different network/VLAN than the application’s host device). This may also be useful when migrating to a Network application host that is not also a gateway.

  1. Download the desired backup file (*.unf) from your original Network application’s System Settings
  2. Enable the Override Inform Host field on the original Network application’s host device, then enter the IP address of the new host device. This will tell your devices where they should establish a connection in order to be managed. Once entered, all devices in the old application should appear as Managed by Other.
    • When migrating to a Cloud Console, you can copy the Inform URL from the Cloud Console’s dashboard. You will need to remove the initial http:// and the ending :8080/inform
  3. Ensure that your new Network application is up to date. Backups cannot be used to restore older application versions.
  4. Restore the backup file in the Network application’s System Settings.
  5. Ensure that all devices appear as online in the new application. If they do not, you can try Layer 3 adoption, or factory reset and readopt your device(s) to the new application.

If a device appears as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host) to perform an Advanced Adoption.

Exporting Individual Sites from a Multi-Site Host

Certain Network application hosts (e.g., Cloud Key, Cloud Console, self-hosted Network Server) can manage multiple sites. Site exportation allows you to migrate specific sites from one multi-site host to another. To do so:

  1. Click Export Site in your Network application’s System Settings to begin the guided walkthrough.
  2. Select the device(s) you wish to migrate to your new Network application.
  3. Enter the Inform URL of your new host. This will tell your devices where they should establish a connection in order to be managed. Once entered, all devices in the old application should appear as Managed by Other in the new one.
    • When migrating to a Cloud Console, you can copy the Inform URL from the Cloud Console’s dashboard. You will need to remove the initial http:// and the ending :8080/inform.
  4. Go to your new Network application and select Import Site from the site switcher located in the upper-left corner of your dashboard.
    • Note: You may need to enable Multi-Site Management in your System Settings.
  5. Ensure that all devices appear as online in the new application. If they do not, you try Layer 3 adoption, or factory reset and readopt your device(s) to the new application.

If a device appears as Managed by Other, click on it to open its properties panel, then use its Device Authentication Credentials (from the original Network application’s host) to perform an Advanced Adoption.

Migrating UniFi Protect

We recommend saving your footage with the Export Clips function before migrating. Although we provide HDD migration instructions, it is not an officially supported procedure due to nuances in the RAID array architecture. 

Standard Migration

  1. Download the desired backup file (*.zip) from the original Protect application’s settings. 
  2. Ensure that your new Protect application is up to date. Backups cannot be used to restore older application firmware.
  3. Replace your old UniFi OS Console with the new one. All other camera connections should remain unchanged.
  4. Restore the backup file in the Protect application’s settings.

HDD Migration

Full HDD migration is not officially supported; however, some users have been able to perform successful migrations by ensuring consistent ordering when ejecting and reinstalling drives into their new console to preserve RAID arrays.

Note: This is only possible if both UniFi OS Consoles are the same model.

  1. Remove the HDDs from the old console. Record which bay each one was installed in, but do not install them in the new console yet.
  2. Turn on the new console and complete the initial setup wizard. Do not restore a Protect application or Cloud backup during initial setup.
  3. Upgrade the new console and its Protect application to a version that is either the same or newer than the original console.
  4. Shut down the new console, and then install the HDDs in the same bays as the original console.
  5. Turn on the new console again. The Protect application should start with its current configuration intact, and all exported footage should be accessible.


Source :
https://help.ui.com/hc/en-us/articles/360008976393

Ubiquiti UniFi – Storage Replacement (HDD/SSD/SD Cards)

You may need to replace a storage disk when upgrading to a larger storage capacity, or if your current disk has naturally degraded over time, as discussed in our article on Disk Health. UniFi OS makes this process incredibly simple.

Before Replacing a Disk

  1. Back up your UniFi OS Host.
  2. Obtain a compatible disk.
  3. Export any recordings you want to keep (all recordings on the disk will be lost).

How to Replace a Disk

All UniFi Hosts with removable disks can be opened and the disks swapped with ease.

  • Hosts with HDDs and SSDs (i.e., Dream Machines & Video Recorders): Simply press the disk tray to open it. Then take out and replace the disk in the same orientation.
  • Hosts with microSD cards (i.e., Dream Router & Dream Wall): Carefully pull the tray out of its slot, then replace the card in the same orientation.

Cloud Key Gen2 Plus and Devices “Managed by Other”

The Cloud Key Gen2 Plus is unique, because it operates entirely off its external storage. Replacing this disk will result in a new database. Any connected devices (i.e., Cameras & Access Points) will still be associated with the old database, and will appear as “Managed by Other.”

In this case, restoring from a backup will resync the devices with your Cloud Key. If you did not make a backup before replacing the storage, you will need to factory reset and readopt your device(s).

Ensure the following when replacing a disk in your CK G2 Plus:

  • No security devices are connected to the security slot on the side.
  • Your Cloud Key has been shut down from UniFi OS > Console Settings and is unplugged.
    • The HDD should not be removed or installed while the CK is powered on.

Replacing a Disk in an Array

The Network Video Recorder and Network Video Recorder Pro can maximize data protection by creating storage arrays across multiple disks. For more information, see Storage Protect and Data Redundancy

Remember:

  • Always replace a failed disk first before replacing an at-risk disk.
  • Replace one disk at a time, allowing storage to fully repair before replacing the next disk.
  • Repairing a disk takes significant work, and will impact overall performance.

Source :
https://help.ui.com/hc/en-us/articles/12257010646679-UniFi-Storage-Replacement-HDD-SSD-SD-Cards-

NIST Password Guidelines

Joe Dibley

Published: November 14, 2022

Updated: March 17, 2023

What are NIST Password Guidelines?

Since 2014, the National Institute of Standards and Technology (NIST), a U.S. federal agency, has issued  guidelines for managing digital identities via Special Publication 800-63B. The latest revision (rev. 3) was released in 2017, and has been updated as recently as 2019. Revision 4 was made available for comment and review; however, revision 3 is still the standard as of the time of this blog post.

Section 5.1.1 – Memorized Secrets provides recommendations for requirements around how users may create new passwords or make password changes, including guidelines around issues such as password strength. Special Publication 800-63B also covers verifiers (software, websites, network directory services, etc.) that validate and handle passwords during authentication and other processes.

Handpicked related content:

Not all organizations must adhere to NIST guidelines. However, many follow NIST password policy recommendations even if it’s not required because they provide a good foundation for sound digital identity management. Indeed, strong password security helps companies block many cybersecurity attacks, including  hackers, brute force attacks like credential stuffing and dictionary attacks. In addition, mitigating identity-related security risks helps organizations ensure compliance with a wide range of regulations, such as HIPAA, FISMA and SOX.

Quick List of NIST Password Guidelines

This blog explain many NIST password guidelines in detail, but here’s a quick list:

  • User-generated passwords should be at least 8 characters in length.
  • Machine-generated passwords should be at least 6 characters in length.
  • Users should be able to create passwords at least 64 characters in length.
  • All ASCII/Unicode characters should be allowed, including emojis and spaces.
  • Stored passwords should be hashed and salted, and never truncated.
  • Prospective passwords should be compared against password breach databases and rejected if there’s a match.
  • Passwords should not expire.
  • Users should be prevented from using sequential characters (e.g., “1234”) or repeated characters (e.g., “aaaa”).
  • Two-factor authentication (2FA) should not use SMS for codes.
  • Knowledge-based authentication (KBA), such as “What was the name of your first pet?”, should not be used.
  • Users should be allowed 10 failed password attempts before being locked out of a system or service.
  • Passwords should not have hints.
  • Complexity requirements — like requiring special characters, numbers or uppercase letters — should not be used.
  • Context-specific words, such as the name of the service or the individual’s username, should not be permitted.

You probably notice that some of these recommendations represent a departure from previous assumptions and standards. For example, NIST has removed complexity requirements like special characters in passwords; this change was made in part because users find ways to circumvent stringent complexity requirements. Instead of struggling to remember complex passwords and risking getting locked out, they may write their passwords down and leave them near physical computers or servers. Or they simply recycle old passwords based on dictionary words by making minimal changes during password creation, such as incrementing a number at the end.

NIST Guidelines

Now let’s explore the NIST guidelines in more detail.

Password length & processing

Length has long been considered a crucial factor for password security. NIST now recommends a password policy that requires all user-created passwords to be at least 8 characters in length, and all machine-generated passwords to be at least 6 characters in length. Additionally, it’s recommended to allow passwords to be at least 64 characters as a maximum length.

Verifiers should no longer truncate any passwords during processing. Passwords should be hashed and salted, with the full password hash stored.

Also the recommended NIST account lockout policy is to allow users at least 10 attempts at entering their password before being locked out.

Accepted characters

All ASCII characters, including the space character, should be supported in passwords. NIST specifies that Unicode characters, such as emojis, should be accepted as well.

Users should be prevented from using sequential characters (e.g., “1234”), repeated characters (e.g., “aaaa”) and simple dictionary words.

Commonly used & breached passwords

Passwords that are known to be commonly used or compromised should not be permitted. For example, you should disallow passwords in lists from breaches (such as the Have I Been Pwned? database, which contains 570+ million passwords from breaches), previously used passwords, well-known commonly used passwords, and context-specific passwords (e.g., the name of the service).

When a user attempts to use a password that fails this check, a message should be displayed asking them for a different password and providing an explanation for why their previous entry was rejected.

Reduced complexity & password expiration

As explained earlier in the blog, previous password complexity requirements have led to less secure human behavior, instead of the intended effect of tightening security. With that in mind, NIST recommends reduced complexity requirements, which includes removing requirements for special characters, numbers, uppercase characters, etc.

A related recommendation for reducing insecure human behavior is to eliminate password expiration.

No more hints or knowledge-based authentication (KBA)

Although password hints were intended to help users to create more complex passwords, users often choose hints that practically give away their passwords. Accordingly, NIST recommends not allowing password hints.

NIST also recommends not using knowledge-based authentication (KBA), such as questions like “What was the name of your first pet?”

Password managers & two-factor authentication (2FA)

To account for the growing popularity of password managers, users should be able to paste passwords.

SMS is no longer considered a secure option for 2FA. Instead, one-time code provider, such as Google Authenticator or Okta Verify, should be used.

How Netwrix Can Help

Netwrix offers several solutions specifically designed to streamline and strengthen access and password management:

  • Netwrix Password Policy Enforcer makes it easy to create strong yet flexible password policies that enhance security and compliance without hurting user productivity or burdening helpdesk and IT teams.
  • Netwrix Password Reset enables users to safely unlock their own accounts and reset or change their own passwords, right from their web browser. This self-service functionality dramatically reduces user frustration and productivity losses while slashing helpdesk call volume.

FAQ

What is NIST Special Publication 800-63B?

NIST’s Digital Identity Guidelines (Special Publication 800-63B) provides reliable recommendations for identity and access management, including effective password policies.

Why does NIST recommend reducing password complexity requirements?

While requiring complex passwords makes them more difficult for attackers to crack, it also makes passwords harder for users to remember. To avoid frustrating lockouts, users tend to respond with behaviors like writing down their credentials on a sticky note by their desk or choosing to periodically reuse the same (or nearly the same) password — which increase security risks. Accordingly, NIST now recommends less stringent complexity requirements.

Source :
https://blog.netwrix.com/2022/11/14/nist-password-guidelines/

Top Strategies to Harden Your Active Directory Infrastructure

Joe Dibley

Published: April 28, 2023

Microsoft Active Directory (AD) is the central credential store for 90% of organizations worldwide. As the gatekeeper to business applications and data, it’s not just everywhere, it’s everything! Managing AD is a never-ending task, and securing it is even harder. At Netwrix, we talk to a lot of customers who are using our tools to manage and secure AD, and over the years, key strategies for tightening security and hardening AD to resist attacks have emerged. Here are 10 Active Directory security hardening tips that you can use in your environment:

Handpicked related content:

Tip #1: Clean up stale objects.

Active Directory includes thousands of items and many moving elements to safeguard. A core method for increasing security is to decrease clutter by removing unused users, groups and machines. Stale AD objects may be abused by attackers, so deleting them reduces your attack surface.

You may also find seldom-used items. Use HR data and work with business stakeholders to determine their status; for example, for user accounts, determine the user’s manager. While this takes time, you’ll appreciate having it done during your next audit or compliance review.

Tip #2: Make it easy for users to choose secure passwords.

To prevent adversaries from compromising user credentials to enter your network and move laterally, passwords need to be hard to crack. But users simply cannot remember and manage multiple complex passwords on their own, so they resort to practices that weaken security, such as writing their passwords on sticky notes or simply incrementing a number at the end when they need to change them. That led security experts to weaken their recommendations concerning password complexity and resets.

However, with an enterprise password management solution, you can make it easy for users to create unique and highly secure passwords and manage them effectively, so you do not have to compromise on strong password requirements. A user needs to memorize just one strong password, and the tool manages all the others for them.

Tip #3: Don’t let employees have admin privileges on their workstations.

If an attacker gains control of a user account (which we all know happens quite a bit), their next step is often to install hacking software on the user’s workstation to help them move laterally and take over other accounts. If the compromised account has local admin rights, that task is easy.

But most business users do not actually need to install software or change settings very often, so you can reduce your risk by not giving them admin permissions. If they do need an additional application, they can ask the helpdesk to install it. Don’t forget to use Microsoft LAPS ensure all remaining local admin accounts have strong passwords and change them on a regular schedule.

Tip #4: Lock down service accounts.

Service accounts are used by applications to authenticate to AD. They are frequently targeted by attackers because they are rarely monitored, have elevated privileges and typically have passwords with no expirations. Accordingly, take a good look at your service accounts and restrict their permissions as much as possible. Sometimes service accounts are members of the Domain Admin’s group, but typically don’t need all of that access to function — you may need to check with the application vendor to find out the exact privileges needed.

It’s also important to change service account passwords periodically to make it even more difficult for attackers to exploit them. Doing this manually is difficult, so consider using the group managed service account (gMSA) feature, introduced in Windows Server 2016. When you use gMSAs, the operating system will automatically handle the password management of service accounts for you.

Tip #5: Eliminate permanent membership in security groups.

The Enterprise Admin, Schema Admin and Domain Admin security groups are the crown jewels of Active Directory, and attackers will do everything they can to get membership in them. If your admins have permanent membership in these groups, an attacker who compromises one of their accounts will have permanent elevated access in your domain.

To reduce this risk, strictly limit membership in all of these highly privileged group and, furthermore, make membership temporary. The Enterprise Admin and Schema Admin groups are not frequently used, so for these, this won’t be an issue. Domain Admin is needed much more, so a system for granting temporary membership will have to be set up.

Tip #6: Eliminate elevated permissions wherever possible.

There are three fairly common permissions that attackers need to execute attacks against AD: Reset Password, Change Group Membership and Replication. These permissions are harder to secure since they are so frequently used in daily operations.

Accordingly, you should monitor all changes to security group permissions or membership that would grant these rights to additional users. Even better, implement a privileged access management (PAM) solution that enables just-in-time temporary provisioning of these privileges.

Tip #7: Implement multifactor authentication (MFA)

MFA adds an extra layer of security by requiring users to verify their identity by providing at least two of the following types of authentication factors:

  • Something they know, such as a password, PIN or answer to a security question
  • Something they have, such as a code from a physical token or a smart card
  • Something they are, which means biometrics like a fingerprint, iris or face scan

Tip #8: Closely audit your Active Directory.

It is important to audit Active Directory for both non-secure settings and suspicious activity. In particular, you should perform regular risk assessment to mitigate security gaps, monitor for anomalous user activity, and promptly identify configuration drift in critical system files. It’s ideal to invest in tools that will automatically alert you to suspicious events and even respond automatically to block threats.

Tip #9: Secure DNS.

Securing DNS can help you to block a variety of attacks, including as domain hijacking and DNS spoofing. Steps to take include implementing DNSSEC, using a secure DNS server and regularly reviewing DNS settings.

Tip #10: Regularly back up Active Directory.

Having a recent backup of your Active Directory is crucial for recovery from cyber incidents, including ransomware attacks and natural disasters. Backups should be stored securely, tested regularly and be readily accessible to ensure your critical AD settings are recoverable in the event of a disaster.

Conclusion

Active Directory is an amazing system for controlling access. However, it’s only secure when it’s clean, understood, properly configured, closely monitored and tightly controlled. These tips are practical ways that you can tighten security and harden your Active Directory.

Frequently Asked Questions

What is hardening in Active Directory?

Hardening in Active Directory is the process of securing and strengthening the directory service to reduce the risk of data breaches and downtime. It involves controlling access to sensitive data, removing unnecessary objects, enforcing password policies and monitoring for suspicious activity.

What is domain controller hardening?

Domain controller hardening is the process of strengthening the servers that run Active Directory to reduce the risk of unauthorized access, data breaches and service disruption. It includes deactivating superfluous services, deploying security patches and updates, establishing firewall rules, and enforcing strong password practices.

What happens if a domain controller is compromised?

An adversary who compromises a domain controller can do significant damage, from accessing sensitive data to creating, modifying and deleting user accounts and other critical AD objects.

How do I secure Active Directory?

Securing Active Directory is an ongoing process that involves multiple layers of security controls. In particular, organizations need to  implement strong password policies, limit user access, monitor for suspicious activity, keep machines patched and updated, secure domain controllers, use multifactor authentication (MFA) to add extra security, and educate employees on cybersecurity best practices and potential threats.

Source :
https://blog.netwrix.com/2023/04/28/harden-active-directory/

Active Directory Security Groups Best Practices

Kevin Joyce

Published: May 4, 2023

Active Directory security groups are used to grant users permissions to IT resources. Each security group is assigned a set of access rights, and then users are made members of the appropriate groups. Done right, this approach enables an accurate, role-based approach to user management and reduces IT workload.

Why should Security Groups Stay Secure?

Security groups should always be protected with clear security protocols because they govern user and computer access to resources that could be highly confidential, sensitive, and critical to the organization. Any oversight may result in security breaches and data theft with lasting consequences. Hence, you need to establish some best practices for using and managing security groups.

Key Best Practices

The following best practices can help you use security groups effectively.

  • Use Group Nesting to Simplify Access Management
  • Give each security group a unique, descriptive name
  • Limit each group’s permissions to the bare minimum
  • Make each user a member of only the required groups
  • Track group activity and changes to security groups
  • Pay attention to service accounts
  • Have group owners review their groups regularly, and remove groups that are no longer needed
  • Use privileged accounts only when required
  • Always create a recovery plan

Use Group Nesting to Simplify Access Management.

When we talk about group nesting, we refer to making an AD group a member of another group. This strategy enables us to give permissions across domains through universal groups. It works this way:

Use Group Nesting to Simplify Access Management.

Give each security group a unique, descriptive name.

When security groups have unclear names, or multiple groups have similar names, such as ‘Sales Group 1’ and ‘Sales Group 2’, it’s difficult to ensure that they have the correct permissions and membership. To reduce risk, establish group naming standards that ensure consistency and uniqueness.

Limit each group’s permissions to the bare minimum.

The least privilege principle is the cornerstone of security. Make sure each security group is assigned only the permissions that its members need to complete their tasks. Granting excessive permissions to a group enables any group member — or an adversary who compromises their account — to abuse those rights.

Make each user a member of only the required groups.

Never add users to groups they do not need to be a part of. Moreover, remove them promptly from groups they no longer need to belong to, such as when they change roles within the organization. For example, when users change departments, remove them from the previous department’s groups and add them to the new department’s groups. That way, each user has access only to the resources they need, which reduces your organization’s attack surface area.

Track group activity and changes to security groups.

Any improper change to the permissions or membership of a security group puts the organization at increased risk of security incidents and business disruptions. Be especially vigilant about monitoring changes to highly privileged groups like Domain Admins and Enterprise Admins.

Look out for the following to detect suspicious behavior:

  • Unauthorized permission and membership changes
  • Unnecessary or unusual use of admin accounts
  • Failed password attempts
  • Locked out accounts
  • Disabled or removed antivirus software

At a minimum, log the events and regularly run reports to spot suspicious activity. Even better, use a tool that will alert you in real time to changes to critical security groups, or block those changes from happening in the first place.

Pay attention to service accounts.

A service account is a special user account created to run a particular application or service. Best practices for service accounts include the following:

  • Set secure passwords.
  • Do not make service accounts members of built-in privileged groups like Domain Admins.
  • Enforce least privilege by granting each service account the minimum access required to accomplish its tasks.

Have group owners review their groups regularly, and remove groups that are no longer needed.

Security groups are usually set up to provide access to resources for a particular project team— but when the project is over, the group is often not deleted. By requiring group owners to regularly review their groups, you can improve security by removing groups that are no longer needed.

As a best practice, disable or delete dormant accounts after about 45 days of inactivity. Set up a system to distinguish inactive accounts from active accounts, which would help in removing inactive accounts from security groups. Hackers can easily target unused accounts since no one keeps track of the account’s activities. And if that unused account is a member of multiple security groups, the implications could be devastating.

Use privileged accounts only when required.

Accounts that are members of privileged groups should be used only for performing administrative tasks that require elevated rights. For all other tasks, admins should use their regular user accounts. This strategy reduces the risk of attackers gaining control of an account that is a member of security groups with access to sensitive systems and data.

Always create a recovery plan.

Despite keeping security intact, data breaches may happen at times due to an error. As a proactive measure, have a recovery plan in place with due attention to recovering security groups. IT teams must be trained to handle such a situation with quick and intelligent decision-making.

Simplifying Security Group Management

Netwrix GroupID can help you effectively manage your Active Directory security groups. Here are some of the ways it can help you implement the best practices described above.

  • Establish and enforce standards for naming groups
  • Ensure the membership of security groups is accurate
  • Establish an attestation process for security groups
  • Set security groups to expire automatically
  • Set a default group approver

Establish and enforce standards for naming groups.

Netwrix GroupID helps you implement consistency and convention in group names with the following features:

  • Group name prefixes
  • Regular expressions
  • Templates for naming nested groups
  • Lists of blocked words

Ensure the membership of security groups is accurate.

Netwrix GroupID enables you to manage group membership with LDAP queries as an alternative to manually adding and removing users, thus ensuring that membership is always up to date.

Establish an attestation process for security groups.

Netwrix GroupID makes it easy for group owners to regularly review the attributes, membership, and permissions of their security groups, as well as whether the groups are still needed. This process helps maintain a check on groups.

Set security groups to expire automatically.

You can set an expiry date for a security group, such as a group created for a specific project. Netwrix GroupID sends an email notification to a group’s owner 30 days, 7 days and 1 day before the expiration date. If the group is not renewed, it is automatically deleted. Expired groups that have been deleted can be quickly restored if necessary.

You can easily exempt any security group from expiration, including the default security groups in Active Directory.

Set a default group approver.

You can designate a default approver for groups, who will receive expiry notifications for groups without owners.

Conclusion

Properly managing your Active Directory security groups is vital to protecting your IT systems and data. A solution like Netwrix GroupID can make it easy to implement the best practices detailed here.

Source :
https://blog.netwrix.com/2023/05/04/active-directory-security-groups/