LDAP abending with RC=0003 - Assertion failed
Article ID: 115929
Updated On:
Products
Top Secret
Top Secret - LDAP
Issue/Introduction
Running LDAP R15 and TSS R16. On Saturday evening we applied Top Secret R16 Hyper maintenance to our environment in addition to (1) IBM Security maintenance and (2) implementation of the OSPROTECT=1 security setting.
On Sunday and Monday morning at 07:10am, we have received errors in LDAP bringing the task down:
ETLDP04I CA LDAP Server r15 has terminated abnormally
IEF404I LDAP - ENDED - TIME=07.10.03
$HASP395 LDAP ENDED - RC=0003
We attempt a restart at 7:15'ish and it fails but then after waiting a while, another restart is successful.
In the stderr log, it says the following:
Assertion failed: ..............information............
CEE5207E The signal SIGABRT was received.
On Sunday and Monday morning at 07:10am, we have received errors in LDAP bringing the task down:
ETLDP04I CA LDAP Server r15 has terminated abnormally
IEF404I LDAP - ENDED - TIME=07.10.03
$HASP395 LDAP ENDED - RC=0003
We attempt a restart at 7:15'ish and it fails but then after waiting a while, another restart is successful.
In the stderr log, it says the following:
Assertion failed: ..............information............
CEE5207E The signal SIGABRT was received.
Environment
Release:
Component: TSSLDP
Component: TSSLDP
Resolution
We have seen these errors before when upgrading to r16.0.
In each case there was specific acids that caused the abend/error/message.
Here is some information from a case where the abend/error/messages occurred when issuing a list command:
1.) The bit in the User Record to reflect the MFA Administrative Attribute was re-used. This Attribute used
to represent a Top Secret PC Administrative Attribute that had been removed from the product over 20 years ago. But if a User was defined before the date this Attribute was retired, there's the potential that they had it assigned all this time but was not being used. That's why you'll only see the problem on a limited number of Users.
2.) Our recommendation is to manually remove the flag setting for DATA(MFA) for any affected User to clear up any false reporting of the MFA Administrative Attribute, which will correct the processing with LDAP r15.0.
You can manually switch off this flag via the following command:
TSS DEADMIN(acid) DATA(MFA)
Note: You can find the acids that have the MFA flag by issuing
TSS LIST(ACIDS) DATA(ADMIN) and looking to see which acids have MFA listed
In each case there was specific acids that caused the abend/error/message.
Here is some information from a case where the abend/error/messages occurred when issuing a list command:
1.) The bit in the User Record to reflect the MFA Administrative Attribute was re-used. This Attribute used
to represent a Top Secret PC Administrative Attribute that had been removed from the product over 20 years ago. But if a User was defined before the date this Attribute was retired, there's the potential that they had it assigned all this time but was not being used. That's why you'll only see the problem on a limited number of Users.
2.) Our recommendation is to manually remove the flag setting for DATA(MFA) for any affected User to clear up any false reporting of the MFA Administrative Attribute, which will correct the processing with LDAP r15.0.
You can manually switch off this flag via the following command:
TSS DEADMIN(acid) DATA(MFA)
Note: You can find the acids that have the MFA flag by issuing
TSS LIST(ACIDS) DATA(ADMIN) and looking to see which acids have MFA listed
Feedback
Yes
No
Powered by
