Table of Contents
NetYCE 8.1.0 Build_20220920
LDAP account aging
A Setting has been added that allows NetYCE administrators to automatically remove Ldap-based user accounts that have been idle for a defined period. The 'Ldap_idle_account_age' Tweak variable can be set to the number of days that an Ldap account is considered idle. If the last-login date of an account was before this age, the account is removed. This will be performed daily as part of the nightly maintenance tasks.
By default this setting has the value '0', which will skip Ldap account aging completely. This setting applies only to 'ldap'-type user accounts, 'local' users are not affected.
New 'Backups' form
The existing 'Backups' tools have been replaced with a new form offering a cleaner and clearer overview of the backups status and its management. Previously the backups page used four different tools, now a dashboard is presented with poll statuses and grouped root causes for poll failures.
This dashboard includes sections on failure causes, graphical pie-chart of statuses, the current poller queue and a gid with individual device statuses linking to polling details and the polled configurations. Option links into the 'Polling groups' and 'Config search' tools complement this first phase of the 'Backups' tooling.
Opening the node 'Details' offer a few additional options and a summary of its Nccm statuses and timing. It also includes the last polling log in full detail.
Also see the Wiki article on Backups Dashboard
Support for the authentication method SAML ('Security Assertion Markup Language') has been added to NetYCE. This functionality allows to delegate the authorization and authentication of NetYCE users to a SAML Identity Provider.
This functionality is currently available as a beta release, mostly due to the wide variations in implementation offered by the various Identity Providers and the limited compatibility testing completed.
Also see the Wiki article on Setting up SAML
Country and State
To properly support Site country and state information, some changes were made to the Site form. The Country field allows selection of pre-defined values from the 'Country' class of the settings. When the country value is selected, the State field will then allow for the selection of the pre-defined states of this country. Both country and state fields support a 'type-ahead' which narrows the menu items as more characters are typed.
An initial list of 14 countries and 208 states can be created if desired. The Country and State lists are customizable using the “Admin → Setup → General settings” tool.
This release includes an initial *alpha* version of a new RESTful API, named 'XchRest', which is intended to supersede the existing xml-based 'Xch' API. This API uses a built-in OAuth server to manage the authorization tokens needed to access the API.
The XchRest API will use port 8880 by default which can be customized on setup. The build-in documentation can be consulted using the URL “https://<server-fqdn>:8880/schema”. Use 'http' when the system is not configured for SSL.
Also see the Introduction section of the Wiki article XchRest API.
The current functionality is severely limited and as this stage not suitable for integrations as we will quickly extend and modify the endpoints.
Several minor issue have been located in the Backup process that resulted in some nodes being polled where that was not intended, or nodes only being polled after the NCCM process restart or making a change to a node-group. In another scenario, nodes that were removed from the polling-group would be polled every five minutes.
These issues have been corrected, resulting in a more timely and consistent behaviour of the backup processes.
Customers using Zscaler as a security platform will find that some pages in the NetYCE GUI are not accessible. The authentication verification of these pages included the validation of the source IP-address being the same address to which the session cookie was issued.
When using the Zscaler platform this source IP-address will not be fixed resulting in a mismatch of the session validation. To resolve the issue, the GUI pages that uses this validation mechanism have been modified to allow for changing IP-addresses during the session.
This change no longer allows the NetYCE session cookies to be validated across different NetYCE environments. Where previously a session could be started on the Production environment, the session would be accepted when accessing a NetYCE server in the Test environment provided the user account exists on both environments.
This single-sign-on function across environments is no longer available with this change. To access a NetYCE server in a different environment the user will need to re-authenticate himself.
Edit INI configs
After editing the YCE Nccm syslog patterns the new configuration failed the validation test.
The validation of INI-formatted file uses lines with the format
var = value. However,
it did not accept another '=' in the value.
This has been corrected.
The Apache http server that NetYCE deploys provided access to directories that were either unintended or have over time become obsolete. For security reasons the directory listings and some server locations are no longer accessible for the browser. There is no change to the accessibility that the GUI already provided.
A problem was found with preliminary releases of version 8.1. The NetYCE server configuration file,
yce_setup.conf would be defaulted to a single-server environment with only ip-based http access. This default configuration would manifest itself on server restart or software update, resulting in a broken replication and no login access.
The issue is now resolved, but to correct its symptoms will require additional manual action.
Those installations that installed the preliminary 8.1 release will find that after installing THIS update, their configuration was defaulted. The system admin must therefore before or after this update is installed, re-run the NetYCE setup script: “yce_setup.pl”. This could therefore entail adding the redundant server and its details as well as defining the https and replication settings for all servers. The process should be repeated on any additional servers too.