chan_fookmun

Hi everyone, i refer to the post titled "URGENT: ADSI corrupt ADAM SID in ACE and fail to update ADAM ACLs" by Denis Gervalle in the www.ldaps.com forum 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: http://www.softec.st/~dge/post/sdtest.html 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: S-1-297827799-211... 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: S-1-297827591-211... 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, Denis As i am experiencing the same problem, i like to know if there is a proper way to solve it.Thanks

Hello everyone i like to know if there is a way to test the replication performance on my company LAN for example?Can it be done? Thanks a lot