Primary NetScaler Appliance:
> show ntp status
remote refid st t when poll reach delay offset jitter
adljj.john.com .LOCL. 1 u 9 64 7 0.293 -212012 2.175
Secondary NetScaler Appliance:
> show ntp status
No association ID’s returned
1) From the logs, we found that, NTP was configured after upgrade and during that time secondary device interface was down.
2) We can see that interface was down in the time interval of10:01 – 11:18 A.M. In that interval, none of the command gets propagated. Because of that ntp config was missing from secondary.
3) As per current design, even if the Secondary comes UP and the NTP configurations are Synchronized through HA Synchronization, we have to manually restart the NTP Daemon to get the NTP status on Secondary. Which is a current limitation on NetScaler.
4) Hence, Enhancement request was raised to address this limitation. 5) The limitation was fixed in the following versions: 12.1 50.x 12.0 60.x 11.1 60.x
Logs from Primary:
ns.log.0:649:Apr 23 10:15:59 <local0.info> X.X.X.X 2018:01:15:59 GMT NetScaler-Internal-TDC-01 0-PPE-1 : default GUI CMD_EXECUTED 136 0 : User nsroot – Remote_ip X.X.X.20 – Command “add ntp server X.X.X.3 -minpoll 6 -maxpoll 10 -devno 32833536” – Status “Success”
ns.log.0:651:Apr 23 10:15:59 <local0.info> X.X.X.X 04/23/2018:01:15:59 GMT NetScaler-Internal-TDC-01 0-PPE-1 : default GUI CMD_EXECUTED 137 0 : User nsroot – Remote_ip X.X.X.20 – Command “unset ntp server X.X.X.3 -autokey” – Status “Success”
Logs from secondary:
Apr 23 10:00:34 <local0.info> X.X.X.25 04/23/2018:01:00:34 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default CLI CMD_EXECUTED 131 0 : User nsroot – Remote_ip 127.0.0.1 – Command “logout” – Status “Success”
Apr 23 10:01:13 <local0.notice> X.X.X.25 04/23/2018:01:01:13 GMT NetScaler-Internal-TDC-02 0-PPE-0 : default EVENT DEVICEDOWN 79 0 : Device “interface(0/1)” – State DOWN
Apr 23 10:01:13 <local0.notice> X.X.X.25 04/23/2018:01:01:13 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default EVENT DEVICEDOWN 132 0 : Device “interface(0/1)” – State DOWN
Apr 23 11:18:15 <local0.notice> X.X.X.25 04/23/2018:02:18:15 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default EVENT DEVICEUP 133 0 : Device “interface(0/1)” – State UP
Apr 23 11:18:15 <local0.notice> X.X.X.25 04/23/2018:02:18:15 GMT NetScaler-Internal-TDC-02 0-PPE-0 : default EVENT DEVICEUP 80 0 : Device “interface(0/1)” – State UP
Apr 23 11:18:29 <local0.info> X.X.X.25 04/23/2018:02:18:29 GMT NetScaler-Internal-TDC-02 0-PPE-1 : default AAA Message 134 0 : “rba authentication : user nsroot response_len-0 cmdPolicyLen-0, partitionLen-0 PromptLen-0 timeout 805307268 authPolicyLen-0 authActionLen-0 ssh_pubkey_len
There would be two fields called USERDOMAIN and USERDNSDOMAIN
And these will be like this:
Open Netscaler Gateway Virtual server session profile.
Go to Published applications tab and look for SSODomain field
As per the error it would be domain.com
We need to change it to domain, and save the configuration on Netscaler.
Also confirm that Storefront has either “Any” domain selected or has “domain.com” and “domain” added as trusted domain.
A vulnerability in the Simple Network Management Protocol (SNMP) input packet processor of Cisco NX-OS Software could allow an authenticated, remote attacker to cause the SNMP application of an affected device to restart unexpectedly.
The vulnerability is due to improper validation of SNMP protocol data units (PDUs) in SNMP packets. An attacker could exploit this vulnerability by sending a crafted SNMP packet to an affected device. A successful exploit could allow the attacker to cause the SNMP application to restart multiple times, leading to a system-level restart and a denial of service (DoS) condition.
Cisco has released software updates that address this vulnerability. There are no workarounds that address this vulnerability.
This advisory is available at the following link:
Security Impact Rating: High
A vulnerability in the TCP syslog module of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to exhaust the 1550-byte buffers on an affected device, resulting in a denial of service (DoS) condition.
The vulnerability is due to a missing boundary check in an internal function. An attacker could exploit this vulnerability by establishing a man-in-the-middle position between an affected device and its configured TCP syslog server and then maliciously modifying the TCP header in segments that are sent from the syslog server to the affected device. A successful exploit could allow the attacker to exhaust buffer on the affected device and cause all TCP-based features to stop functioning, resulting in a DoS condition. The affected TCP-based features include AnyConnect SSL VPN, clientless SSL VPN, and management connections such as Secure Shell (SSH), Telnet, and HTTPS.
There are no workarounds that address this vulnerability.
This advisory is available at the following link:
Security Impact Rating: Medium
|Article Number: 498281||Article Version: 3||Article Type: Break Fix|
Data Computing Appliance V3,Greenplum Data Computing Appliance V2
dcacheck showing SNMP issues on the cluster indicating a host configuration issue:
DCA_CHECK_ERROR host(sdw8.gphd.local): [Status=>error] [SNMP Status=>SNMP configuration issue on host, please validate IP address setting in SNMP configuration] [oid=>SNMP_CONFIG_ERROR]DCA_CHECK_ERROR host(sdw8.gphd.local): [Status=>error] [SNMP Status=>SNMP configuration issue on host, please validate IP address setting in SNMP configuration] [oid=>SNMP_CONFIG_ERROR]DCA_CHECK_ERROR host(sdw8.gphd.local): [Status=>error] [SNMP Status=>SNMP configuration issue on host, please validate IP address setting in SNMP configuration] [oid=>SNMP_CONFIG_ERROR]
Error showing when trying to restart the LSI SNMP agent:
[root@mdw ~]# /etc/init.d/lsi_mrdsnmpd restart-bash: /etc/init.d/lsi_mrdsnmpd: No such file or directory
To resolve do the fololwing steps:
- Check for the version ofsas-snmp running.
- Remove the current installed sas_snmp rpm.
- Reinstall the correct SAS SNMP package:
- Restart snmpd and lsi_mrdsnmp services.
# /etc/init.d/lsi_mrdsnmp restart
[root@mdw ~] # rpm -qa | grep sas-snmp[root@mdw ~] # rpm -e sas_snmp-13.08-0401.x86_64 --noscript[root@mdw ~] # yum install sas_snmpLoaded plugins: product-id, securitySetting up Install ProcessResolving Dependencies--> Running transaction check---> Package sas_snmp.x86_64 0:13.08-0401 will be installed--> Finished Dependency ResolutionDependencies Resolved====================================================================================================================== Package Arch Version Repository Size======================================================================================================================Installing: sas_snmp x86_64 13.08-0401 localRepo 556 kTransaction Summary======================================================================================================================Install 1 Package(s)Total download size: 556 kInstalled size: 2.1 MIs this ok [y/N]: y[root@mdw ~] # /etc/init.d/snmp restartStopping snmpd: [ OK ]Starting snmpd: [ OK ][root@mdw ~] # /etc/init.d/lsi_mrdsnmp restartRegistering Service lsi_mrdsnmpdStarting LSI SNMP AgentStarting LSI SNMP Agent:LSI MegaRAID SNMP Agent Ver 188.8.131.52 (Jan 21st, 2013) Started [ OK ]
To resolve this issue delete the nslocation.* files from the /var/netscaler/locdb/ directory and then re-run the configuration to add the location file.
root@NS-Cumulus1# cd /var/netscaler/locdb/
GeoIPCountryWhois.csv GeoLite2-City-Locations-en.csv IP2LOCATION-LITE-DB1.CSV nslocation.ck nslocation.db
root@NS-Cumulus1# rm nslocation.*
> add locationfile /var/netscaler/locdb/GeoIPCountryWhois.csv -format geoip-country
we have a client that seems unable to use Apple mobile device under WSS
gives a SCEP error when trying to enroll the new devices
apparently this is a well known issue thats been going on for years now
we have a workaround via MS intune to send the PAC file and SSL cert down to the apple clients does anyone else have this issue