|
Ah ok, I wondered if that was the one that was being
discussed, I didn't want to assume it was something that Iknew. That one does
work for sure in ADFIND I know. :o)
joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Thursday, October 28, 2004 7:14 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Trusting Domain SIDs trustedDomain.
The attribute is securityIdentifier – syntax is SID. There is another documented
attribute domainIdentifier. But it seems to be null on the 356 (give or take a
few) incoming NT4/W2k/W2k3 trusts I have. I ended up just sending an adfind
dump. It satisfied the requirement. --Brian 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. |
Title: RE: [ActiveDir] Trusting Domain SIDs
