Ronnie Sahlberg <sahlberg@xxxxxxxxxxxxxxxx> writes:
> I cant specify a link since www.dcerpc.net seems to have died.
>
> attached are the two files.
>
> lsa-muddle-orig.idl is what i assume are muddle generated.
>
> I think it is TYPE_8 that is the security descriptor.
> I think TYPE_8 is generated by muddle but am not sure. If it is generated by
> muddle then there
> exists an NDR encoding for the security descriptor.
Ah, see below.
> If one chooses the UNIQUE pointers carefully
> (they are unique so they could have any arbitrary value for non-NULL)
> as the offset inside the packet for where the struvture is, as SMB uses
> these fields,
> then NDR and SMB could have the identical wire representation of the SD
> structure.
You _can_ use NDR to marshall SDs, and if you went out of your way to
do it, you could make them be in a format that's considered valid by
the non-NDR stuff that uses them. However, that's not the way things
are actually done. What's going on in the muddle file is this: TYPE_8
is the definition of a security descriptor, as you surmised. But it's
only used in the process of defining TYPE_6. TYPE_6 is really the
OBJECT_ATTRIBUTES structure, and that is used by the LsaOpenPolicy
call. So, the SD definition is only there incidentally; I've never
seen an LsaOpenPolicy call that included an SD as part of the
OBJECT_ATTRIBUTES. (If there were one, it would probably be
marshalled "normally", i.e. without the special handling needed to
make it look valid to non-NDR users.)
The functions that query and set SDs in the LSA are 3 and 4 (0 based).
They both use TYPE_4, which is pretty much what I described in the
last email:
typedef struct {
long element_15;
[size_is(element_15)] [unique] char *element_16;
} TYPE_4;
Hope that makes sense. Come to think of it, netmon includes an lsarpc
parser. It was pretty buggy, but it might be able to verify that.
> lsarpc.idl is what i belive is their handtuned idl file. it contains many
> calls not implemented in ethereal yet
> but implementing them would be very easy.
> The parameters for these calls differs in their representation though from
> what the muddle file has.
> I dont know which of the idl files to trust to be correct.
I took a quick glace at the hand-tuned one, and it looked right to me,
but that's not saying a lot. If you point out discrepancies, I'll
clarify the ones I can. (They have a number of calls defined that I'm
not sure of.)
Todd
