|
That’s a good approach, especially
for those particular types. The problem is basically impossible to solve in
general, but you can make some good guesses in some cases. Do you try to parse the abstract schema
(CN=Aggregate,CN=Schema….) or read the individual attribute entries? Joe K. From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe > Hey Joe Richards, how does ADFind
know which binary attributes are SIDs? I know Dmitri has some > kind of hard-coded lookup table for
ldp.exe to handle special conversions of some numeric and binary data, > but it is hard to solve the problem
generally. He doesn’t have the securityIdentifier attribute for the
domainTrust > class in has table of binary
attributes that are SIDs either (at least on my build of ldp, which is higher
than the > one that shipped with ADAM).
This problem is actually kind of a hard one to solve for all those trying to do
AD > browsing, so I thought I’d
ask. It goes beyond schema into semantics and tends to end up requiring
lots of hard-coding > and/or a rules engine for trying
different things (like 16 byte binary is probably a guid, etc.). Hmm which class is that - domainTrust? Not
familiar with it. Does adfind work correctly with it? I used to hard code it but maintaining the
table was a pain in the arse, I fixed that in December 2002 (V1.09.00). Now I
pull part of the schema up front when adfind runs and pull out GUIDs, SIDs,
SDs, and other binary data so I can figure out how I want it displayed. You
should notice anything it can identify as a GUID displayed in the pretty
{xxx-xxx-xxx-xxx-xxx} format, SIDS should be displayed in their format
S-1-5-xx-xxxx-xxxxxxxxxx-xxx, SDs will get displayed as {Security Descriptor}
unless the option to display the SDDL is turned on, and binary should be
displayed as a hex dump broken up into 4 bytes (if I recall correctly) a
chunk. Anyway, I look at the attribute syntax
first. If it is 2.5.5.17, it is a SID. If it is 2.5.5.15 it is an SD. If
it is 2.5.5.10 and range upper and lower are 16 it probably a GUID. Don't tell anyone how I do it. It is an
ancient joeware trick that I busted my bum trying to figure out because it was
not well documented... We'll just keep it a secret between all of us. I figured
I would put it in a book some day. So consider this email copyrighted. :) Oh yeah, I realized that some times I wouldn't
want that overhead so the -dloid option is available that tells it not to load
the schema first and then it falls back to a small hardcoded list. joe Copyright 2004 joeware.net From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] No reference yet really, but here are a
couple of pointers: With S.DS, anything stored as octet
string in AD/ADAM is marshaled to .NET as a byte[]. This means, to get
the binary data, you would just do something like (from the results of a search
with DirectorySearcher): Byte[] binarySid = (byte[])
result.Properties(“securityIdentifier”)(0); I’m assuming you already know how
to use the DirectorySearcher to search for the trusts as I’m pretty sure
I remember you talking about doing some of this stuff before. If you need
more details, please respond. To convert to string SID, you basically
have to do a p/invoke to the API function (which is quite easy) unless you are
already on 2.0, which has a managed SID class (which I haven’t used yet,
but assume works fine). The p/invoke wiki has a nice
ConvertSidToStringSid sample (www.pinvoke.net)
or you can get a nice managed library for all Win32 security functions and such
here at GotDotNet: I’m not sure which method is going
to get you there faster, especially if you are already done using the adfind
method J, but I do agree with Joe that script simply isn’t suitable
for dealing with binary data in AD (or 8 byte integers for that matter). Hey Joe Richards, how does ADFind know
which binary attributes are SIDs? I know Dmitri has some kind of
hard-coded lookup table for ldp.exe to handle special conversions of some
numeric and binary data, but it is hard to solve the problem generally.
He doesn’t have the securityIdentifier attribute for the domainTrust class
in has table of binary attributes that are SIDs either (at least on my build of
ldp, which is higher than the one that shipped with ADAM). This problem
is actually kind of a hard one to solve for all those trying to do AD browsing,
so I thought I’d ask. It goes beyond schema into semantics and
tends to end up requiring lots of hard-coding and/or a rules engine for trying
different things (like 16 byte binary is probably a guid, etc.). Just curious… Joe K. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Brian Desmond I'm up for that ... I've never dealt with
this stuff in S.DS before. Do you ahve any pointers on SIDs w/ .net? I
actually got hte info I needed with adfind, but I still want to be able to
produce this dump in spreadsheet form. --Brian Desmond From:
[EMAIL PROTECTED] on behalf of [EMAIL PROTECTED] This would also be something that would
be easier to deal with in .NET than script as there is plenty of good support
for octet strings in S.DS and there are plenty of options for converting the
SID back to string SID. Of course, shelling out to adfind might
be easy, depending on the particulars of what you are up to. Joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond I thought Richard had something that did
this - I'll have to email me because I dcouldn't find a sample on his site. How's that csv support in adfind coming? ;) --Brian From:
[EMAIL PROTECTED] on behalf of joe To be
blunt, scripts suck for working with octetstrings which This
message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited. This
message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the email by you is prohibited. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. |
Title: RE: [ActiveDir] Trusting Domain SIDs
- RE: [ActiveDir] Trusting Domain SIDs joseph.e.kaplan
