Hi,
> > In particular, the ntVer as part of the filter for the netlogon rpc is
> > not a string
>
> At least as I read RFC 2251, AttributeValues in LDAP filters aren't
> necessarily text strings; the type is OCTET STRING. As I remember, I've
> seen what appear to be GUIDs as LDAP attributes, and they're represented
> in binary, not text.
Yes, attribute values may be binary - the most common example is
certificate - where as string representation wouldn't cut it (as you
couldn't very the signature).
LDAP got itself into a bit of a mess with binary attributes though,
with the ";binary" annotation to attribute names, and it's still
unclear.
> RFC 2252 has a language for describing the syntax of attributes, and
> OpenLDAP has a bunch of files describing attribute syntaxes. Should the
> LDAP dissector read files of that sort and use them to figure out how to
> display attribute values? It says they should, wherever possible, be
> text, but says it shouldn't be assumed that they are:
I have exactly this problem with my X.500 dissectors, which is where
the LDAP issue comes from. Basically, attributes as "ANY defined-by
TYPE" - where ANY is an ASN.1 encoding (or syntax) and TYPE is an OID.
I introduced a "syntax" registration into packet_ber.c/asn2eth so that
a dissector could register a encoding under a given name, and then a
simple text file to associate a TYPE with a syntax. Thus a user can
dissect their own schema (set of types) by modifying the text file
(assuming all syntaxes are implemented).
As the simple text file also supplies a name for the OID, it is in
conflict with the MIB approach currently being discussed.
I did post these changes for syntax handling a while back, but they
were not accepted. Perhaps MIBs are the way to go as they do have a
(simple) syntax association.
Getting back to the original question, I would imagine there would
just be some MS specific syntaxes to implement.
Graeme