Uploaded image for project: 'Directory ApacheDS'
  1. Directory ApacheDS
  2. DIRSERVER-2125

More than one value has been provided for the single-valued attribute: pwdAccountLockedTime

    Details

    • Type: Bug
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-M20
    • Fix Version/s: 2.0.0-M22
    • Component/s: None
    • Labels:
      None

      Description

      I have now encountered this issue a couple times. I am not quite sure how, but pwdAccountLockedTime is getting multiple values set to it. This seems not to be a problem immediately (the directory works with multiple values), but I take daily backups and when I try to restore, I get:

      processing failure: CONSTRAINT_VIOLATION: failed for MessageType : ADD_REQUEST
      Message ID : 6259
          Add Request :
      Entry
          dn[n]: uid=some.guy,ou=people,dc=example,dc=com
          objectClass: organizationalPerson
          objectClass: person
          objectClass: inetOrgPerson
          objectClass: portalPerson
          objectClass: top
          pwdAccountLockedTime: 20160131192519.758Z
          pwdAccountLockedTime: 20160131193013.986Z
          pwdAccountLockedTime: 20160131193020.941Z
          pwdAccountLockedTime: 20160131193026.911Z
          pwdAccountLockedTime: 20160131193036.580Z
          mail: some.guy@example.com
          pwdFailureTime: 20160131192059.579Z
          pwdFailureTime: 20160131192108.556Z
          pwdFailureTime: 20160131192129.709Z
          pwdFailureTime: 20160131192142.260Z
          pwdFailureTime: 20160131192448.419Z
          pwdFailureTime: 20160131192457.637Z
          pwdFailureTime: 20160131192504.937Z
          pwdFailureTime: 20160131192519.758Z
          pwdFailureTime: 20160131193013.986Z
          pwdFailureTime: 20160131193020.941Z
          pwdFailureTime: 20160131193026.911Z
          pwdFailureTime: 20160131193036.580Z
          timeZone: America/New_York
          active: true
          cn: Some Guy
          creatorsName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
          modifiersName: 0.9.2342.19200300.100.1.1=admin,2.5.4.11=system
          userPassword: ????
          pwdHistory: ????     
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          pwdHistory: ????
          uid: some.guy
          entryUUID: 33b6e17c-fe72-4d28-85ea-9f72e27143d3
          givenName: Some
          entryParentId: 96c37a0c-48b0-4960-b3e1-e01057bb742f
          createTimestamp: 20150422005642.549Z
          entryCSN: 20160131193036.581000Z#000000#001#000000
          sn: Guy
          modifyTimestamp: 20151020122447.179Z
          entryDN: uid=some.guy,ou=people,dc=example,dc=com
      : ERR_278 More than one value has been provided for the single-valued attribute: pwdAccountLockedTime
      

      My understanding is that the pwdAccountLockedTime SHOULD be single valued, and as such, the bug is in allowing it to get set multiple times.

      I do not currently have steps to reproduce, and for now my team works around it with our restore automation (read the incoming ldif and strip out all bu the latest copy of this attribute before adding it to the directory)...

        Activity

        Hide
        elecharny Emmanuel Lecharny added a comment -
        Show
        elecharny Emmanuel Lecharny added a comment - Should be fixed with http://svn.apache.org/viewvc?rev=1732290&view=rev
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Yes, that's it, we bypass all the checks :

                    processModifyAddPwdAttributes( entry, mods, pwdModDetails );
        
                    String csnVal = directoryService.getCSN().toString();
                    Modification csnMod = new DefaultModification( REPLACE_ATTRIBUTE, directoryService.getAtProvider()
                        .getEntryCSN(), csnVal );
                    mods.add( csnMod );
        
                    ModifyOperationContext internalModifyCtx = new ModifyOperationContext( adminSession );
                    internalModifyCtx.setPushToEvtInterceptor( true );
                    internalModifyCtx.setDn( modifyContext.getDn() );
                    internalModifyCtx.setEntry( entry );
                    internalModifyCtx.setModItems( mods );
        
                    // Directly update the database...
                    directoryService.getPartitionNexus().modify( internalModifyCtx );
        

        We can bypass the checks done by the SchemaInterceptor, but we must be sure we don't add a Single Value attribute twice. In other words, the AuthenticationInterceptor class should always control the attributeType presence before adding it.

        Show
        elecharny Emmanuel Lecharny added a comment - Yes, that's it, we bypass all the checks : processModifyAddPwdAttributes( entry, mods, pwdModDetails ); String csnVal = directoryService.getCSN().toString(); Modification csnMod = new DefaultModification( REPLACE_ATTRIBUTE, directoryService.getAtProvider() .getEntryCSN(), csnVal ); mods.add( csnMod ); ModifyOperationContext internalModifyCtx = new ModifyOperationContext( adminSession ); internalModifyCtx.setPushToEvtInterceptor( true ); internalModifyCtx.setDn( modifyContext.getDn() ); internalModifyCtx.setEntry( entry ); internalModifyCtx.setModItems( mods ); // Directly update the database... directoryService.getPartitionNexus().modify( internalModifyCtx ); We can bypass the checks done by the SchemaInterceptor , but we must be sure we don't add a Single Value attribute twice. In other words, the AuthenticationInterceptor class should always control the attributeType presence before adding it.
        Hide
        elecharny Emmanuel Lecharny added a comment -

        Clearly a bug, as this AttributeType is SINGLE VALUE :

        attributetype ( 1.3.6.1.4.1.42.2.27.8.1.17 
        	NAME 'pwdAccountLockedTime' 
        	DESC 'The time an user account was locked' 
        	EQUALITY generalizedTimeMatch 
        	ORDERING generalizedTimeOrderingMatch 
        	SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 
        	SINGLE-VALUE 
        	NO-USER-MODIFICATION 
         )
        

        I suspect the update is done internally by the PPolicy interceptor bypassing the schema checks - which could make sense, as this save a lot of CPU - but without removing beforehand the previous value.

        Should be easy to reproduce and fix.

        Show
        elecharny Emmanuel Lecharny added a comment - Clearly a bug, as this AttributeType is SINGLE VALUE : attributetype ( 1.3.6.1.4.1.42.2.27.8.1.17 NAME 'pwdAccountLockedTime' DESC 'The time an user account was locked' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION ) I suspect the update is done internally by the PPolicy interceptor bypassing the schema checks - which could make sense, as this save a lot of CPU - but without removing beforehand the previous value. Should be easy to reproduce and fix.

          People

          • Assignee:
            Unassigned
            Reporter:
            ltheisen@mitre.org lucas theisen
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development