High Mgmt CPU due to nsaaad process
book
Article ID: CTX230883
calendar_today
Updated On:
Description
High management CPU
CPU spiked to 100% causing VIPs and LDAP server configuration on NS to go down
Issue may be intermittent.
Resolution
If you configure LDAP using TLS, aaad service will consume high cpu utilization, which cause high Management cpu.
To aviod this, please follow the below workaround:
It is because of the TLS configuration on the LDAP action that is causing the process spike.
Thus, please implement the configuration as below:
Option 1 - Configure PLAINTEXT LDAP on port 389 (instead of secure LDAP on port 636)
One could go with Option 1 when NetScaler is only used in integration of any VIP for authentication.
Option 2 - if secure LDAP (port 636) is required, the following workaround would help (by avoiding a blocking call from AAAD to LDAPS) :-
One could go with Option 2 when along with the authentication, NetScaler is catering service for resetting password of Active Directory users; as reset password strictly requires secure communication.
Step 1. Create SSL_TCP services for each secure(port 636) LDAP server.
Step 2. Create TCP LB Vserver for each such service (this would be port 389 or 636 based on the options explained above)
Step 3. Pass the LB vserver's IP as -ServerIP to ldapaction with -secType PLAINTEXT (in LDAP Action Port would be the same as your LB vServer confgiured 389 or 636)
In effect what this does is, AAAD talks plaintext LDAP to packet engine, while packet engine SSL-encrypts and passes it on to the LDAP server.
Sample config :-
add lb vserver LDAP-vsrv TCP 1.1.1.1 636
add service LDAP-vsvc 2.2.2.2 SSL_TCP 636
bind lb vserver LDAP-vsrv LDAP-vsvc
add authentication ldapAction LDAP-act -serverIP 1.1.1.1 -serverPort 636 -secType PLAINTEXT
For each LDAP server, create individual LDAP-Vservers for use in ldapActions.
Problem Cause
aaad service using high cpu utilization
Issue/Introduction
nsassd process is consuming lot of CPU cycles
Was this article helpful?
thumb_up
Yes
thumb_down
No