IZ33974: AD LDAP RSPI_SERVER_DOWN CONDITION NOT RELEASING THE LDAP HANDLE

APAR status

• Closed as user error.

Error description

• ENVIRONMENT
  
  User Clients
  Windows XP Pro, Norwegian
  Internet Explorer: v. 6.0.2900.2180.xpsp_sp2
  .
  Registry Server:
  Microsoft Active Driectory, Windows Server 2003 SP2
  Single Domain.
  
  Policy Server: TAM Policy Server on Windows Server 2003
  
  TAM WebSEAL 6.1 is running on Redhat Enterprise Linux version
  5.0
  
  
  PROBLEM:
  
  .
  Sometimes, when accessing the resources after an external
  authentication
  is done, I get the following error from my Windows Internet
  Explorer
  client:
  https://webseal1server/eailogin/login/error.jsp?ERROR_CODE=0x132
  12072&E
  ROR_TEXT=HPDIA0114E+++Could+not+acquire+a+client+credential.&TAM
  _OP=err
  r&USERNAME=unauthenticated
  .
  Error 0x13212072
  Message HPDIA0114E Could not acquire a client credential
  .
  When I try to access the web-resource again, with the external
  authentication, it then works
  
  I know the user is always located in the TAM registry, but
  sometimes this WebSeal lookup ( after that EAI application has
  validated username/password) fails.
  So, for me it looks like this error is inconsistent. I
  experience the same with other users. The user credentials are
  in the header data, but TAM lookup fails.
  
  
  
  TRACE:
  
  URAF_TRACE reports:
  
  2008-09-19-09:44:40.734+02:00I----- thread(101)
  trace.pd.mgr.uraf:6
  /project/am610/build/am610/src/uraf/ad_ldap/urafinternal.cpp:980
  : SYNC: ldap_search_s failed for filter
  (&(objectCategory=URAF-User)(objectClass=URAF-User)) and base
  cn=100034693,cn=users,cn=Default,cn=Tivoli PD
  Domains,dc=sfaa,dc=norsk-tipping,dc=no (81) -> Can't contact
  LDAP server (4793:
  /project/am610/build/am610/src/uraf/ad_ldap/urafuser.cpp) ->
  errstr -> hr1 =0
  2008-09-19-09:44:40.735+02:00I----- thread(101)
  trace.pd.mgr.uraf:6
  /project/am610/build/am610/src/uraf/ad_ldap/urafinternal.cpp:244
  : LDAP error code (81) was converted to (50) RSPI_SERVER_DOWN
  2008-09-19-09:44:40.736+02:00I----- thread(101)
  trace.pd.mgr.uraf:1
  /project/am610/build/am610/src/uraf/ad_ldap/urafuser.cpp:4865:
  status: 0x00000032
  
  
  
  
  TCP-IP trace reports:
  
  173 42.539626 09:44:38.774888 172.16.40.180 172.16.40.29 LDAP
  59915 > ldap [PSH, ACK] Seq=6279 Ack=4626 Win=21312 Len=523
  TSV=3722882948 TSER=69690235| searchRequest(22)
  "cn=100034693,cn=users,cn=Default,cn=Tivoli PD
  Domains,dc=sfaa,dc=norsk-tipping,dc=no" baseObject
  174 0.000114 09:44:38.775002 172.16.40.29 172.16.40.180 TCP ldap
  > 59915 [RST, ACK] Seq=4626 Ack=6802 Win=0 Len=0
  175 0.000365 09:44:38.775367 172.16.40.180 172.16.40.29 TCP
  59916 > ldap [FIN, ACK] Seq=167 Ack=24 Win=5888 Len=0
  TSV=3722882954 TSER=69689358
  176 0.000034 09:44:38.775401 172.16.40.29 172.16.40.180 TCP ldap
  > 59916 [RST] Seq=24 Win=0 Len=0
  177 0.000038 09:44:38.775439 172.16.40.180 172.16.40.29 TCP
  59917 > ldap [FIN, ACK] Seq=167 Ack=24 Win=5888 Len=0
  TSV=3722882955 TSER=69689634
  178 0.000018 09:44:38.775457 172.16.40.29 172.16.40.180 TCP ldap
  > 59917 [ACK] Seq=24 Ack=168 Win=64074 Len=0 TSV=69690661
  TSER=3722882955
  179 0.000194 09:44:38.775651 172.16.40.180 172.16.40.29 TCP
  59918 > ldap [FIN, ACK] Seq=167 Ack=24 Win=5888 Len=0
  TSV=3722882955 TSER=69689335
  180 0.000015 09:44:38.775666 172.16.40.29 172.16.40.180 TCP ldap
  > 59918 [RST] Seq=24 Win=0 Len=0
  

Local fix

• WORKAROUND:
  
  edit the activedir_ldap.conf and add a second entry for the same
  DC
  that is from :
  
  primary-domain = dc=myco,dc=com|adprim.myco.com
  
  
  change to :
  
  
  primary-domain = dc=myco,dc=com|adprim.myco.com|adprim.myco.com
  
  
  
  With this workaround WebSeal after verified that old connection
  are all gone is able to bind to the fake replica ( the same DC )
  and the authentication succeed.
  

Problem summary

Problem conclusion

Temporary fix

Comments

• The customer is experiencing network connectivity fail
  ures.  The customer may gain increased reliability by adding one
   more server name entry to their activedir_lda.conf file; this w
  ill only suffice if the server connectivity is successful at the
   second retry.
  

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels