During an eTrust Admin Global User password change, some child accounts are changed, and others are not. Why is this happening?

Document ID : KB000055704
Last Modified Date : 14/02/2018
Show Technical Document Details

For eTrust Directory 8.0 releases which are embedded within eTrust Admin, there have been reports of intermittent problems in updating account passwords.

Scenario

1 Parent Admin Domain
1 Child Admin Domain

A Global User password is updated in Parent eTrust Admin domain. This is successful, but when the linked accounts are updated in child domain (multiple child accounts), 1 child account is updated successfully and the remaining account is not.

Analysis

The following is occurring:

  • The router DSA on the Parent Admin server which is responsible for sending updates to the eTrust Admin "child" slapd instance receives two binds in quick succession.

  • The first bind is handled correctly.

  • The second bind is handled incorrectly.

The logic of a bind going over a DXLINK connection is that eTrust Directory will NOT perform 'compares' on the password attribute, as 'compares' are not supported by LDAP directories. So eTrust Directory normally do not send compares over DXLINK connections, because eTrust is not going to get a valid response back. In this case, if eTrust Directory receives multiple binds in quick succession for the same DN, then the first one gets handled correctly, while each subsequent one actually generates a compare request.

This is a known issue in 8.0 builds of eTrust Directory. To resolve this issue, upgrade to eTrust Directory version 8.1 build 883 (or higher).

Example trace that illustrates this condition is listed below:

We have the first bind coming in:

<-- (SSL) LDAP MESSAGE messageID 1

> BindRequest 
> version: 3 
> name: eTGlobalUserName=eds,eTGlobalUserContainerName=
Global Users,eTNamespaceName=CommonObjects,dc=verke01-iam80,dc=eta
> authentication: 
> simple: (masked) 

This is then sent to the Child Admin Servers SLAPD directory as per normal

> --> (SSL) LDAP MESSAGE messageID 1
> BindRequest 
> version: 3 
> name: eTGlobalUserName=eds,eTGlobalUserContainerName=Global 
Users,eTNamespaceName=CommonObjects,dc=verke01-iam80,dc=eta
> authentication:
> simple: (masked) 
> 
> 

But straight away we have another bind for the same account come in

> <-- (SSL) LDAP MESSAGE messageID 1
> BindRequest
> version: 3
> name: eTGlobalUserName=eds,eTGlobalUserContainerName=Global 
Users,eTNamespaceName=CommonObjects,dc=verke01-iam80,dc=eta
> authentication: 
> simple: (masked)
>   

Bind response from Child Admin Servers slapd is received by the Router DSA

> (Remote) <- #1 (SSL) [admin_server_child] DXLINK BIND-CONFIRM 
>        invoke-id = 1   credit = 24 
> ! Remote: bind-response accepted without credentials
! returnSpecialCompareResult 
! ----------RemoteEvent (001/000)---------------20060829.2254.39
! 
> 
> (Remote) <- #1 (SSL) [admin_server_child] DXLINK COMPARE-CONFIRM 
>        invoke-id = 0   credit = 1
>        flags = IDU_FLAGS_IGNORE_COMPARE 
>   

After the first bind confirmation is processed, we see this Router DSA sending a compare request over the DXLINK connection to the Child Admin Servers slapd directory.

> (Remote) -> #1 (SSL) [admin_server_child] DXLINK COMPARE-REQ 
>        invoke-id = 1   credit = 1 
>     Entry:
>         <cosineDomainComponent "eta"> 
>         <cosineDomainComponent "verke01-iam80">
>         <eTNamespaceName "CommonObjects"> 
>         <eTGlobalUserContainerName "Global Users"> 
>         <eTGlobalUserName "eds">
>     Assertion = userPassword (masked)
>     Service controls: 
        Options: No chaining 
>     Chaining Arguments:
>        Originator:
>             <cosineDomainComponent "eta">
>             <cosineDomainComponent "verke01-iam80">
>             <eTNamespaceName "CommonObjects">
>             <eTGlobalUserContainerName "Global Users"> 
>             <eTGlobalUserName "eds"> 
>        Trace Information: 
>            DSA: 
>                 <cosineDomainComponent "eta"> 
>                 <commonName "admin_router_child">
>             Operation Progress: Name Resolution Phase:  Not Started
>        Auth Level:  simple
>        flags = IDU_FLAGS_NO_AC
>        flags = IDU_FLAGS_BIND_COMPARE 
>        flags = IDU_FLAGS_IGNORE_COMPARE 

Then the directory attempts to process the compare response that is received.

> <-- (SSL) LDAP MESSAGE messageID 1
> CompareResponse 
>  resultCode: success
>  matchedDN:
>  errorMessage: 
> 
! ----------RemoteEvent (001/001)---------------20060829.2254.41 
! 

eTrust Directory generates a failure when it processes the Compare.

>
> (Remote) <- #1 (SSL) [admin_server_child] DXLINK COMPARE-REFUSE 
>        invoke-id = 1   credit = 25 
>    Attribute Error:
>        Entry:  <>
>        Attribute: dxErrorReason 
>        Value: "0:"
>        Problem: (unknown 0) 
>    Controls: 
>        tunnel-ldap-error 
>             errorMessage: "0:"