exacqVision Edge Plus Archiving currently supports SMB archiving targets.
Edge Plus does not currently support Cloud Drive or Amazon S3 archiving.
<br>
exacqVision Edge Plus Archiving currently supports SMB archiving targets.
Edge Plus does not currently support Cloud Drive or Amazon S3 archiving.
<br>
After logging into your Illustra camera for the first time, accepting the End User License Agreement, and creating a Host ID, you will be asked to select a security mode.
Enhanced is selected by default. As the message indicates, Enhanced will automatically select several advanced security options, such as enabling additional authentication needs, like forcing the creation of a non-default username, and requiring HTTPS. Regardless of the selection chosen on initial setup, individual settings can always be changed later by navigating to Security Status, under the Security menu.
Selecting ‘Enhanced’ Security performs the following:
Changing any of the security settings only requires you to click the Edit link beside the listed option. Some settings offer the ability to change port numbers and some offer additional setting fields to configure.
Notice that Onvif Discovery may be individually disabled on this page as well. Clicking the Edit link for Onvif Discovery redirects to the Remote Access options page. This permits you to disable Onvif Discovery, or require Onvif User Authentication.
The Users configuration page permits additional user accounts to be created, in which a user role is assigned. Enabling Onvif User Authentication directs the camera to only accept commands from authenticated users.
<br>
This document will outline the process of creating a privacy zone on an Illustra camera.
When the camera is connected to exacqVision you will be able to create a privacy zone through the inbuilt options.
The inbuilt option is greyed out/disabled for Illustra cameras.
Create the privacy zone in the web client for the camera.
Cloudvue Mobile Access Control User Guide |
A hardening guide is a supplemental document that is provided alongside installation instructions with a product.
A hardening guide is a supplemental document that is provided alongside installation instructions with a product. This hardening guide will outline the minimal necessary steps to ensure a secure installation of the product in a customer environment. The document can vary in terms of length and technical detail at the discretion of the Product Management team and Security Architects for that line of business.
exacqVision Hardening Guides are available from the Johnson Controls Cyber Learning and Resource Center at https://www.johnsoncontrols.com/cyber-solutions/resources#Security
<br>
This document will guide you through step-by-step procedures for keyboard use and suggested button mappings.
For proper operation of the American Dynamics ADVCPTZKEY1 PTZ USB Keyboard, both the exacqVision Client and Server must be on version 22.03 or higher.
ADVCPTZKEY1 American Dynamics Surveillance Keyboard
<br>
<br>
In this example using Letsencrypt SSL certificates. The webservice is behind HAProxy and was not been able to successfully configure HAProxy to update Letsencrypt certificates over HTTP. Therefore, I manually updated the certificate.
/etc/webservice/tls/server.crt _> /etc/letsencrypt/live/site.com/cert.pem
/etc/webservice/tls/server.key -> /etc/letsencrypt/live/site.com/privkey.pem.
After updating the certificates, I linked the original to the new certificates in the Letencrypt folder:
When I try to connect to the webservice, I get this error message sent an invalid response. ERR_SSL_PROTOCOL_ERROR’.
The destination of his symlink, not the symlink itself, needs to be readable by the nvrweb user. In this example the directory that the symlink did not have permissions to allow the link to work correctly.
The best way to be sure would be to run terminal command
sudo -i
to root and then run
su nvrweb -s /bin/bash
and try to view the files (e.g., cat the paths listed in the config file).
This should give you an out put.
{
“service”: {
“name”: “Customer Name”,
“url”: “https://site.com”,
“loginTokenExpiration”: 30,
“discoverable”: true,
“inactivityTimeout”: 0,
“enableAutocomplete”: false,
“enableRelay”: false
},
“webserver”: {
“listen”: 80,
“tls”: {
“listen”: 443,
“cert”: “/etc/webservice/tls/server.crt”,
“key”: “/etc/webservice/tls/server.key”,
“type”: “external”
}
},
“log”: {
“duration”: 1,
“interval”: “W”,
“level”: “debug”,
“retain”: 1
},
“servers”: [
{
“host”: “site.com”,
“port”: 22609,
“passthrough”: {
“enabled”: false
},
“poweruser”: {
“enabled”: true,
“username”: “INFO”,
“password”: ” INFO”
}
}
],
“nvrg”: {
“port”: 22717,
“remote”: {
“enabled”: false,
“port”: 35111
}
},
“updates”: {
“fileInfo”: “https://www.exacq.com/downloads/evFileInfo.txt”,
“downloadTimeout”: 10
},
“auth”: {
“type”: “none”
We also need to make sure nvrweb can read the cert files
/etc/webservice/tls/server.crt and .key
The output will show the certs.
nvrweb@sunstone:/root$ cd /etc/webservice
nvrweb@sunstone:/etc/webservice$ cat tls/server.crt
—–BEGIN CERTIFICATE—–
Contents of cert will be displayed here.
—–END CERTIFICATE—–
nvrweb@sunstone:/etc/webservice$ cat tls/server.key
—–BEGIN PRIVATE KEY—–
Contents of Cert will be displayed here
—–END PRIVATE KEY—–
These certs were in the TLS directory and being linked to the Letsencrypt folder, which we found having permissions issues.
To check try the following:
Try the same thing with su to nvrweb and see if nvrweb can access the certs in the let’s encrypt folder, before changes WS config.
Important to note that it’s not just the permissions of the target file that matter, but all the directories in between. In this case the target file was fine but the directory was LetsEncrypt and that did not have permissions. Since we were pointing the link to another file, that file needs to be accessible to nvrweb.
ls -ld for each directory – /etc/letsencrypt, /etc/letsencrypt/live, /etc/letsencrypt/site.com
Without -d it will show the contents, if you want to look at the directory like /etc/letsencrypt it’s necessary to do ls -ld /etc/letsencrypt
The site.com directory is fine. We need to check the live or letsencrypt directories.
letsencrypt live directory’s permissions are rwx—- which means only root can enter or read the directory.
In the above photo we can see that the Permission is denied for the letsencrypt/live folder.
Configuration this way in not the normal process and it is possible the next time I run letsencrypt again to update certs it might error due to perms or reset them. The process might need to be done each time.