NTP status displays “No association ID ” error message on Secondary NetScaler

On the Secondary NetScaler, ” No association ID error” gets displayed when “Show NTP Status command ” is executed

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

Done

Log Analysis:

==============

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:

—————————–

var/log/ns.log

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:

——————————–

var/log/ns.log

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

Related:

The following error occurred during an authentication attempt for user:domain.comabc with realm:

At the Storefront server open a command line and run the following command:

>set u

There would be two fields called USERDOMAIN and USERDNSDOMAIN

And these will be like this:

USERDNSDOMAIN=DOMAIN.COM

USERDOMAIN=DOMAIN

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.

Related:

Cisco NX-OS Software Authenticated Simple Network Management Protocol Denial of Service Vulnerability

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:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181017-nxos-snmp

Security Impact Rating: High

CVE: CVE-2018-0456

Related:

Cisco Adaptive Security Appliance TCP Syslog Denial of Service Vulnerability

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:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20181003-asa-syslog-dos

Security Impact Rating: Medium

CVE: CVE-2018-15399

Related:

DCA V2/V3: dcacheck shows [SNMP Status=>SNMP configuration issue on host, please validate IP address setting in SNMP configuration] [oid=>SNMP_CONFIG_ERROR]: lsi_mrdsnmp is missing when trying to reset SNMP services

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:

Example:
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:

Example:
[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:

  1. Check for the version ofsas-snmp running.

​Command:

# rpm -qa | grep sas-snmp
  1. Remove the current installed sas_snmp rpm.

Command:

# rpm -e sas_snmp-13.08-0401.x86_64 –noscripts
  1. Reinstall the correct SAS SNMP package:​

Command:

# yum install sas_snmp
  1. Restart snmpd and lsi_mrdsnmp services.

Command:

# /etc/init.d/snmpd restart

# /etc/init.d/lsi_mrdsnmp restart
Example:

[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 3.18.0.2 (Jan 21st, 2013) Started [ OK ] 

Related:

NetScaler GSLB Static Proximity Does Not Work After Upgrading to 11.0/11.1 Firmware

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/

root@NS-Cumulus1# ls

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

Related:

Apple mobile device registration for IOS Ver12

I do not need a solution (just sharing information)

Hi Community!!

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 

https://forums.developer.apple.com/thread/84508

https://support.symantec.com/en_US/article.INFO500…

0

Related: