I'd be interested to see that argument as well, Brett.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, October 16, 2005 11:11 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Knowing when users were deleted.
I would be curious just from the standpoint that I will probably learn
something about the internals. If you don't feel the list would be
interested, send to me offline. I have removed your email address from the
kill file. ;o)
Now I have to go get ready to see a noon showing of Serenity[1].
joe
[1] We're deep in space, corner of No and Where.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Sunday, October 16, 2005 10:27 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Knowing when users were deleted.
You then change the representation from an external one to an internal
one,
which is a significant design decision ... I wrote up about a page filling
out the argument against using a backlink scheme ... then figured there
probably isn't interest, as we're talking a hypothetical feature.
Let me know if you want me to finish off and send my argument against
backlinks ...
Cheers,
BrettSh [msft]
On Fri, 14 Oct 2005, joe wrote:
Can you do some sort of backlink type of magic where you use some
smaller sized value to represent the real value via indirection or
something?
I expect most companies would be willing to take the hit on DIT size
to get this kind of capability. ESE can handle it right?
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Friday, October 14, 2005 11:50 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Knowing when users were deleted.
Ignoring the 16 bytes at the beginning of the metadata for version and
attr count info, and garbage wasted space ... the metadata for a
single attribute is 48 bytes, adding the SID (28 bytes) would be an
expansion of 57% on the _raw_ per attribute metadata size.
A sampling of a corporate DB showed the raw metadata size to be 15% of
the DIT size, which would lead me to believe the DIT would expand by
~10% for a trivial implementation against this paticular corporate
DIT.[1]
However, if you look at the /showobjmeta for _any_ object, you will
realize that is a data structure that is over ripe (like banannas you
wouldn't even use for a bananna cake) for being compressed. I think I
could add a SID,
(custom) compress it, and shrink the DIT in size.
While you might think a GUID is better, because If you add a GUID, it
is only 16 bytes, but that's a very uncompressible 16 bytes,
"effectively a random hash". The SID is more likely to compress
properly.
[1] I expect that corporate DITs vary what % is meta-data by how many
certs and big blobs they stick in thier AD. I imagine most corporate
DITs are worse (as in higher % is metadata) than the one I checked out.
Not that I've been thought of it ...
Cheers,
-BrettSh [msft]
This posting is provided "AS IS" with no warranties, and confers no
rights.
On Fri, 14 Oct 2005, Al Mulnick wrote:
> <raises hand>
> GUID or SID of the user account that made the delete request. Last
> mod my not be enough in case some process gets hold of that data in
> the deleted items, even if unlikely. I want the id of the identity
> that put caused the object to be there in the first place.
>
> Having the data for a full undelete option wouldn't seem too
> terrible either, although that might significantly increase the storage
in the DIT.
> In the past I've had to write apps to keep that information out of
> band in order to put back items mistakenly removed. But I can't see
> why I should have to trip through all the DC's Audit logs to find
> the information about who deleted something given how common this
> type of question is. It should be recorded same as the audit log
> (we have the information, why not stamp it on the object at time of
> deletion?)
>
> Al
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of joe
> Sent: Friday, October 14, 2005 11:03 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Knowing when users were deleted.
>
>
> Correct, you can currenlty only get the when and the where (DC Where
> not Client Where).
>
> Which raises the question. How many people would like a metadata
> stamp with the GUID or SID of the userid that made the modification
> for a given attribute (or value if appropriate)? Or would it be ok
> to just have who made the last change to the object? Either way,
> none of the "administrators group" nonsense, it points to a specific
> security
principal.
>
>
>
> _____
>
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Freddy
> HARTONO
> Sent: Friday, October 14, 2005 3:18 AM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Knowing when users were deleted.
>
>
> Hi Yann,
>
> You can find at the deletedobject folder via adfind -showdel and see
> the Last modified date - that would be when the object is deleted.
>
> But as for who deleted - I dont think you can find it without the
auditing.
>
>
>
> Thank you and have a splendid day!
>
> Kind Regards,
>
> Freddy Hartono
> Group Support Engineer
> InternationalSOS Pte Ltd
> mail: [EMAIL PROTECTED]
> phone: (+65) 6330-9740 - temp
>
>
>
> _____
>
> From: Yann [mailto:[EMAIL PROTECTED]
> Sent: Friday, October 14, 2005 2:57 PM
> To: ActiveDir@mail.activedir.org
> Subject: [ActiveDir] Knowing when users were deleted.
>
>
> Hi there,
>
> I wonder if there is a way to know when a user has been deleted from
> AD other than using security audt, because at the time of the
> deletion, i forgot to activate the audit :(
>
> So my boss urge me to find the guilty user AND the time of deletion.
> I looked for attributes in adsi and found that there is the
> whencreated, whenmodified attribute but not whendeletedtimestamp
> one.
>
> Any idea ?
>
>
>
> _____
>
> Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo!
> Messenger Téléchargez
> <http://us.rd.yahoo.com/messenger/mail_taglines/default/*http://fr.m
> es
> senger
> yahoo.com> le ici !
>
>
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
