Please Read: Significant Update Planned, Migrating Forum Software This Month

See more
See less

problem writing the security descriptor in ADAM

  • Filter
  • Time
  • Show
Clear All
new posts

  • problem writing the security descriptor in ADAM

    Hi everyone,
    When i try to set the security descriptor of an object in ADAM, i receive the following error:

    Unhandled Exception: System.Runtime.InteropServices.COMException (0x80072035): T
    he server is unwilling to process the request.
    at System.DirectoryServices.Interop.IAds.SetInfo()
    at System.DirectoryServices.DirectoryEntry.CommitChan ges()
    at ConsoleApplication1.Class1.Main(String[] args) in c:\test\consoleapplicati
    on1\consoleapplication1\class1.cs:line 402

    The source of the problem can be found at the following url:

    Does anyone has any suggestion on how to tackle the problem in a proper way?

    Thanks a lot

  • #2
    The link seams to be broken. Can you please copy&paste the details ?

    0x80072035 is "Unwilling to perform", but the code could help...
    Guy Teverovsky
    "Smith & Wesson - the original point and click interface"


    • #3
      To make things simple,
      i decided to extract the entire post titled "URGENT: ADSI corrupt ADAM SID in ACE and fail to update ADAM ACLs" by Denis Gervalle as follows:

      Hi all,

      Sorry to be so in hurry now, but I am investigating this problem since several days now and I really need a workaround or fix as soon as possible. I have finally manage to reduce the code to its minimal form to demonstrate the problem and related symptoms.
      I am currently using a WinXP Pro SP2 box with VS2003 and ADSI trought COM interop in .NET.

      For your convenience highlighted code, source download and snapshot of its runs are available here:
      The sample contains additionnal code enabled by defines to further show my research on that problem, up to a working but not acceptable workaround.

      The problem relate to the update of an ACLs on an directory entry in an ADAM. A new ACE is created for an ADAM user and added to the ACL of an existing entry. The user SID as been retrieved from the objectSID attribute of the user entry:
      01 05 00 00 11 C0 7D D7 C3 CD ....
      and converted to string using Win32 API:
      It is hardcoded in the sample code for limiting complexity.

      When committing the change of ACLs to the ADAM instance the server reply with a:
      System.Runtime.InteropServices.COMException (0x80072035): The server is unwilling to process the request.

      After many hours of research, I have added some code (#define MakeBinaryRoundTrip in the sample) to convert the SecurityDescriptor into an SDDL string, which require first to convert the IID SD into a RAW structure self-relative descriptor using an IADsSecurityUtility object.
      As the sample shows, when making the conversion of the IID SD into a RAW SD and back into a IID SD, the SID of the newly created ACL change ! It became:
      notice the 591 in place of 799. Note that the corruption is already present in the RAW form as shown by the convertion of the RAW SD to SDDL string:
      01 05 00 00 11 C0 7D 07 C3 CD ....
      notice the 4 most significant bit of the 8th byte has been cleared (07 in place of D7). Which means that either the SD converted is wrong or that the conversion from IID to RAW does
      not perform correctly.

      Moreover, if I corrupt these 4bits in the user SID (#define CorruptSid to have E7 (...815...) in place of D7 (...799...)), the SID received back from the IID => RAW => IID convertion is the same again. This confirm that these bits are effectively ignored and dropped during the conversion. More tests has shown that this only happen when the SID has been created or change using put_Trustee from the IADsAccessControlEntry interface. If I keep the same SID in an ACE created with the dsacl tool, and just change the AccessMask for example, the ADAM update the ACE correctly.

      My final test was to patch the SID in its RAW form (#define PatchSid and undefine #CorruptSid no more needed). So before converting back the RAW SD into IID, I replace the
      8th byte of the SID in the ACE by D7, fixing the wrong 07. The converted back IID SD now correctly report the SID 799, and is the same than the original SD. Using this patched SD, ADAM accept the change and update the ACL correctly.

      My conclusion is that during the transfert of the SD to the ADAM directory, a convertion to RAW form is made and that conversion fails the same way mine fail. The ADAM server obviously refuse to update its ACLs with an unknown SID and is therefore unwilling to process.

      Does anybody experience or reproduce the same problem ? Have I missed something ?
      Is this a know bug and is there a appropriate fix ?
      Waiting for your answers, I am installing a Windows2003 server to see if the same problem appears.

      Thank in advance,



      • #4
        Well, I ran some tests and it appears that the only SIDs I can add using the code are those that my workstation can actually resolve. Any unresolvable SID will result in the exception you are getting.

        Though, ADAM's dsacls does get the job done.

        (XP SP1 with ADAM, computer is part of AD).

        I am far from being an authority on this subject, but I can only speculate that ActiveDs is trying to resolve/validate the SID, and as it's not aware of ADAM's instance, it bails out miserably with SID corruption (the corruption part should not happen though - smells like a bug)
        (If you use a valid Active Directory account's SID, the code runs fine).

        I wrote some code which involved parsing SDDL not long ago (mostly ripped from MSDN) and my bet is that ActiveDs relies on LookupAccountSID function which is not capable to resolve the SID.
        Useful link:
        Guy Teverovsky
        "Smith & Wesson - the original point and click interface"


        • #5
          Thanks for the link.However i have some queries in mind and like to consult you.

          Firstly, the writing of the security descriptor on an ADAM instance in windows server 2003 works fine.Does it mean to say the OS is the problem?

          Secondly, i did the testing on my windows xp SP2 and found that the 8th byte needs to be replaced by D8 instead of D7 as specified by Denis Gervalle.Do you think the error is machine dependent?I like to know the conclusion of your testing in relation to the value of the 8th byte?

          Thanks a lot


          • #6
            Up front: I am not a programmer - just a sysadmin type of guy who once in a while takes someone else's code and tweaks it to suite his needs

            Your SID is rejected by ADAM because it is not valid as one of the following is not true:
            - the SID is well known security principal
            - the SID is local to computer (local account)
            - the SID is from a trusted AD domain
            - the SID is from ADAM's instance

            The part we are interested in is "the SID is not from ADAM's instance".
            The SID has several parts:
            - The first part is Sub-Authority which specifies the SID type (everyone, local, creator/owner, etc..). More details here:

            - If this is NT_AUTHORITY and is not well known sec princ, it must begin with the SID of the domain and end up with RID (issued by DC):

            In your case, the SID corruption causes the change of the DOMAIN part of the SID, hence the ADAM says:
            hey ! I have no idea where this SID comes from ! There is no chance this SID is mine ! go away !

            The abstract way to look at SID would be:
            S-1-5-5-<Domain SID>-<Account RID>

            RID - Relative ID

            C:\Documents and Settings\antid0t>adfind -default -f "objectclass=*" -s base objectsid
            AdFind V01.12.00cpp Joe Richards ([email protected]) May 2003
            Using server:
            Base DN: DC=antid0t,DC=net
            >objectSid: S-1-5-21-1177238915-413027322-515967899
            1 Objects returned
            C:\Documents and Settings\antid0t>adfind -default -f "samaccountname=antid0t" objectsid
            AdFind V01.12.00cpp Joe Richards ([email protected]) May 2003
            Using server:
            Base DN: DC=antid0t,DC=net
            >objectSid: S-1-5-21-1177238915-413027322-515967899-1106
            1 Objects returned
            As you can see, my account is constructed from domain's SID + RID
            Guy Teverovsky
            "Smith & Wesson - the original point and click interface"