RE: [ActiveDir] Knowing when users were deleted.
No no no. It was so appropriate and so funny. I have just been quickly scanning the last few days and that caught my attention and made me seriously laugh. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Wednesday, October 19, 2005 1:27 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Outch - Sorry Brett! |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells |Sent: Wednesday, October 19, 2005 5:20 AM |To: Send - AD mailing list |Subject: RE: [ActiveDir] Knowing when users were deleted. |Importance: Low | |Such beauty in a mere typo - | |Ulf |Hi Bratt |/Ulf | |... still laughing at the irony ;o) | |ah hahahahaha | |-- |Dean Wells |MSEtechnology |* Email: [EMAIL PROTECTED] |http://msetechnology.com | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Tuesday, October 18, 2005 10:34 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Hi Bratt, | |I knew, however assuming performance and size issues I'd prefer to get |a better solutions within the OS for auditing AD instead of bloating it |up for retrieving some information. | |But thanks to your prior post I'd vote for a auditing within AD as |well, if it's even decreasing the metadata and doesn't have a high |impact on performance (I know - reading less data is mostly better than |worrying about the time it takes to be decompressed, and depending how |you would implement this this might even be done distributed on the |requesting machine). |However - and I was impressed of your sharp brain at the summit ;-) - |the DCRs I've been involved with don't make me to confident - even if |it's you suggesting that - still a stony path to take until we might |see something like this. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley ||Sent: Tuesday, October 18, 2005 4:02 PM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || ||Ulf, what Al (well the suggestion on the plate) is suggesting is taht ||the something to centralize that info, _is_ AD replication. | Implying ||the data is in AD. || ||Cheers, ||-Brett || || ||On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote: || || | Wherever the information gets put, it should be a) done as the || |default yet configurable b) centrally viewable (I should ||NOT have to || |visit each DC in my forest to find the data) and || |c) be included in the base product. || || Exactly, that's what I ment. Enable that logging by default and || provide something to centralize that info. || || |-Original Message- || |From: [EMAIL PROTECTED] || |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick || |Sent: Tuesday, October 18, 2005 2:42 AM || |To: ActiveDir@mail.activedir.org || |Subject: RE: [ActiveDir] Knowing when users were deleted. || | || |Not sure that's going to fix the issue though, unless I'm missing || |something. || | Wherever the information gets put, it should be a) done as the || |default yet configurable b) centrally viewable (I should ||NOT have to || |visit each DC in my forest to find the data) and || |c) be included in the base product. I can see no valuable way to || |otherwise do this. Having to deploy yet another product ||doesn't fix || |the problem, it exacerbates it; it's even worse if it's a ||reskit item || |as those aren't supported nor as heavily tested. This is ||important || |enough that it should be and should meet those criteria above. || | || |We may just need to knock a few more edges off before ||submitting this || |FMR ;) || | || | || |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] || |Reply-To: ActiveDir@mail.activedir.org || |To: ActiveDir@mail.activedir.org || |Subject: RE: [ActiveDir] Knowing when users were deleted. || |Date: Mon, 17 Oct 2005 23:36:44 +0200 || | || |Another Hmm. || | || |I'd still like to see that better configured that putting it into || |the AD if the infos are already there (or configurable). We could || |request to make it default to log that kind of info. And |as far as || |we are talking about looking into every server: Where's ACS? And || |also SNMP would be an option to get notified on a single system || |instead of looking into every DC. || | || |Ulf || | || ||-Original Message- || ||From: [EMAIL PROTECTED] || ||[mailto:[EMAIL PROTECTED] On Behalf Of ||Al Mulnick || ||Sent: Monday, October 17, 2005 3:10 AM || ||To: ActiveDir@mail.activedir.org || ||Subject: RE: [ActiveDir] Knowing when users were deleted. || || || ||I'll see your Eurocents and add raise you two. :) || || || ||I fully understand where you're coming from Ulf. Adding this || ||information into the DIT when it is currently possible to get is || ||something that grates
RE: [ActiveDir] Knowing when users were deleted.
| Wherever the information gets put, it should be a) done as |the default yet configurable b) centrally viewable (I should |NOT have to visit each DC in my forest to find the data) and |c) be included in the base product. Exactly, that's what I ment. Enable that logging by default and provide something to centralize that info. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Tuesday, October 18, 2005 2:42 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Not sure that's going to fix the issue though, unless I'm |missing something. | Wherever the information gets put, it should be a) done as |the default yet configurable b) centrally viewable (I should |NOT have to visit each DC in my forest to find the data) and |c) be included in the base product. I can see no valuable way |to otherwise do this. Having to deploy yet another product |doesn't fix the problem, it exacerbates it; it's even worse if |it's a reskit item as those aren't supported nor as heavily |tested. This is important enough that it should be and should |meet those criteria above. | |We may just need to knock a few more edges off before |submitting this FMR ;) | | |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] |Reply-To: ActiveDir@mail.activedir.org |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. |Date: Mon, 17 Oct 2005 23:36:44 +0200 | |Another Hmm. | |I'd still like to see that better configured that putting it into the |AD if the infos are already there (or configurable). We could request |to make it default to log that kind of info. And as far as we are |talking about looking into every server: Where's ACS? And also SNMP |would be an option to get notified on a single system instead of |looking into every DC. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick ||Sent: Monday, October 17, 2005 3:10 AM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || ||I'll see your Eurocents and add raise you two. :) || ||I fully understand where you're coming from Ulf. Adding this ||information into the DIT when it is currently possible to get is ||something that grates against common sense and common engineering ||principles even if you subscribe to belts and braces methodologies. || ||However, I think two things make this a worthwhile request |with a big ||payoff. First to Laura's point about diminishing returns. I agree, ||at some point there will be diminishing returns. I also |believe that ||as hardware gets bigger (i.e. ||Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. ||[1]) the bar gets raised until we get to the diminishing return. ||Since we're targeting 80/20 out of the box [2] it seems reasonable ||that 80% of the deployments would benefit from such a change. The ||other 20 would be those that ||a) don't care or know about such things and b) those that can't ||tolerate the additional overhead and therefore wouldn't want |to deploy ||it. I say tough pickles to them. :) Seriously, this could be on by ||default but configurable (group ||policy?) to disable it as a performance issue etc. || ||Second, I think that the major benefit is the ability to |actually get ||usable information native to the product vs. ||having to invest in a third party product. Why? Because today in ||order to get that information I have to have something that scrapes ||the Security logs looking for such information. Is this a |good idea? ||I think it is. Is it something that could be native? I think it ||could and should be native if technically feasible. || ||Making us look in a particular DC's event logs is more |difficult than ||it should be without yet another product. ||That's fine for the really large companies that have deeper pockets, ||and larger needs. For the small to medium businesses, it should not ||be so difficult nor should it ||*require* SQL licensing or expertise. || || || ||[1] I'm not saying that the quality has kept up, only that the ||hardware is bigger, faster, stronger and cheaper. ||[2] I'm making that up, but it sounds reasonable || || || || ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. ||Simon-Weidner ||Sent: Sunday, October 16, 2005 4:42 PM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || || ||Hmm. || ||Do we really want to excuse prior failure of proper auditing by ||putting more data into AD? Wouldn't that lead into every request of ||non-configured auditing to requests for extending the AD? Do |it right ||the first way. || ||I completely agree that we should make the people more |auditing aware, ||and it would be great to have a centralized auditing together with ||some force
Re: [ActiveDir] Knowing when users were deleted.
joe wrote: 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. count me with this request -- Tomasz Onyszko http://www.w2k.pl 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/
RE: [ActiveDir] Knowing when users were deleted.
Hi, I'm not sure if I would want this in the AD DB as this would mean a larger DIT (as every change is stamped... - how many versions are kept as history?) and additional replication traffic. I would prefer a better central auditing solution instead of having to check each DC to see for who made a change and when. Jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko Sent: Tuesday, October 18, 2005 10:17 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. joe wrote: 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. count me with this request -- Tomasz Onyszko http://www.w2k.pl 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/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. 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/
RE: [ActiveDir] Knowing when users were deleted.
The proposal was no history, nor even a history of who modified it, merely who made the current state of the AD be the way it is. In order to do that, you must track the modifier (whether by backlink, GUID, SID, DN, samAccountName, whatever) at the replication conflict level, ergo for each attribute, and for DN values for each value. The ancillary question, was, would it be OK to just get the last modifier at the object level (i.e. aggregate it up to who last touched the object, any attribute of value). Obviously, this would lose who made the change at time whenChanged minus 1 (or more). The first probably will not bloat the DIT, (in fact it will probably shrink the DIT as I will show shortly, when I find an extra hour). In a twist of irony, the later even though significantly less data, would probably bloat the DIT (although obviously only very slightly). This is because to implement the first idea, you have enough of an impact on DIT size (10% or more), the team would consider strongly compressing the meta-data to make up for it. Where as the later, would be so insignificant, that no one would invest in any compression. At least that is my prediction of how it would play out. Cheers, -Brett On Tue, 18 Oct 2005, Almeida Pinto, Jorge de wrote: Hi, I'm not sure if I would want this in the AD DB as this would mean a larger DIT (as every change is stamped... - how many versions are kept as history?) and additional replication traffic. I would prefer a better central auditing solution instead of having to check each DC to see for who made a change and when. Jorge -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Onyszko Sent: Tuesday, October 18, 2005 10:17 To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. joe wrote: 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. count me with this request -- Tomasz Onyszko http://www.w2k.pl 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/ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. 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/
RE: [ActiveDir] Knowing when users were deleted.
Ulf, what Al (well the suggestion on the plate) is suggesting is taht the something to centralize that info, _is_ AD replication. Implying the data is in AD. Cheers, -Brett On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote: | Wherever the information gets put, it should be a) done as |the default yet configurable b) centrally viewable (I should |NOT have to visit each DC in my forest to find the data) and |c) be included in the base product. Exactly, that's what I ment. Enable that logging by default and provide something to centralize that info. |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Tuesday, October 18, 2005 2:42 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Not sure that's going to fix the issue though, unless I'm |missing something. | Wherever the information gets put, it should be a) done as |the default yet configurable b) centrally viewable (I should |NOT have to visit each DC in my forest to find the data) and |c) be included in the base product. I can see no valuable way |to otherwise do this. Having to deploy yet another product |doesn't fix the problem, it exacerbates it; it's even worse if |it's a reskit item as those aren't supported nor as heavily |tested. This is important enough that it should be and should |meet those criteria above. | |We may just need to knock a few more edges off before |submitting this FMR ;) | | |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] |Reply-To: ActiveDir@mail.activedir.org |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. |Date: Mon, 17 Oct 2005 23:36:44 +0200 | |Another Hmm. | |I'd still like to see that better configured that putting it into the |AD if the infos are already there (or configurable). We could request |to make it default to log that kind of info. And as far as we are |talking about looking into every server: Where's ACS? And also SNMP |would be an option to get notified on a single system instead of |looking into every DC. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick ||Sent: Monday, October 17, 2005 3:10 AM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || ||I'll see your Eurocents and add raise you two. :) || ||I fully understand where you're coming from Ulf. Adding this ||information into the DIT when it is currently possible to get is ||something that grates against common sense and common engineering ||principles even if you subscribe to belts and braces methodologies. || ||However, I think two things make this a worthwhile request |with a big ||payoff. First to Laura's point about diminishing returns. I agree, ||at some point there will be diminishing returns. I also |believe that ||as hardware gets bigger (i.e. ||Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. ||[1]) the bar gets raised until we get to the diminishing return. ||Since we're targeting 80/20 out of the box [2] it seems reasonable ||that 80% of the deployments would benefit from such a change. The ||other 20 would be those that ||a) don't care or know about such things and b) those that can't ||tolerate the additional overhead and therefore wouldn't want |to deploy ||it. I say tough pickles to them. :) Seriously, this could be on by ||default but configurable (group ||policy?) to disable it as a performance issue etc. || ||Second, I think that the major benefit is the ability to |actually get ||usable information native to the product vs. ||having to invest in a third party product. Why? Because today in ||order to get that information I have to have something that scrapes ||the Security logs looking for such information. Is this a |good idea? ||I think it is. Is it something that could be native? I think it ||could and should be native if technically feasible. || ||Making us look in a particular DC's event logs is more |difficult than ||it should be without yet another product. ||That's fine for the really large companies that have deeper pockets, ||and larger needs. For the small to medium businesses, it should not ||be so difficult nor should it ||*require* SQL licensing or expertise. || || || ||[1] I'm not saying that the quality has kept up, only that the ||hardware is bigger, faster, stronger and cheaper. ||[2] I'm making that up, but it sounds reasonable || || || || ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. ||Simon-Weidner ||Sent: Sunday, October 16, 2005 4:42 PM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || || ||Hmm. || ||Do we really want to excuse prior failure
RE: [ActiveDir] Knowing when users were deleted.
Hi Bratt, I knew, however assuming performance and size issues I'd prefer to get a better solutions within the OS for auditing AD instead of bloating it up for retrieving some information. But thanks to your prior post I'd vote for a auditing within AD as well, if it's even decreasing the metadata and doesn't have a high impact on performance (I know - reading less data is mostly better than worrying about the time it takes to be decompressed, and depending how you would implement this this might even be done distributed on the requesting machine). However - and I was impressed of your sharp brain at the summit ;-) - the DCRs I've been involved with don't make me to confident - even if it's you suggesting that - still a stony path to take until we might see something like this. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley |Sent: Tuesday, October 18, 2005 4:02 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Ulf, what Al (well the suggestion on the plate) is suggesting |is taht the something to centralize that info, _is_ AD |replication. Implying the data is in AD. | |Cheers, |-Brett | | |On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote: | | | Wherever the information gets put, it should be a) done as the | |default yet configurable b) centrally viewable (I should |NOT have to | |visit each DC in my forest to find the data) and | |c) be included in the base product. | | Exactly, that's what I ment. Enable that logging by default and | provide something to centralize that info. | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick | |Sent: Tuesday, October 18, 2005 2:42 AM | |To: ActiveDir@mail.activedir.org | |Subject: RE: [ActiveDir] Knowing when users were deleted. | | | |Not sure that's going to fix the issue though, unless I'm missing | |something. | | Wherever the information gets put, it should be a) done as the | |default yet configurable b) centrally viewable (I should |NOT have to | |visit each DC in my forest to find the data) and | |c) be included in the base product. I can see no valuable way to | |otherwise do this. Having to deploy yet another product |doesn't fix | |the problem, it exacerbates it; it's even worse if it's a |reskit item | |as those aren't supported nor as heavily tested. This is |important | |enough that it should be and should meet those criteria above. | | | |We may just need to knock a few more edges off before |submitting this | |FMR ;) | | | | | |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] | |Reply-To: ActiveDir@mail.activedir.org | |To: ActiveDir@mail.activedir.org | |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Date: Mon, 17 Oct 2005 23:36:44 +0200 | | | |Another Hmm. | | | |I'd still like to see that better configured that putting it into | |the AD if the infos are already there (or configurable). We could | |request to make it default to log that kind of info. And as far as | |we are talking about looking into every server: Where's ACS? And | |also SNMP would be an option to get notified on a single system | |instead of looking into every DC. | | | |Ulf | | | ||-Original Message- | ||From: [EMAIL PROTECTED] | ||[mailto:[EMAIL PROTECTED] On Behalf Of |Al Mulnick | ||Sent: Monday, October 17, 2005 3:10 AM | ||To: ActiveDir@mail.activedir.org | ||Subject: RE: [ActiveDir] Knowing when users were deleted. | || | ||I'll see your Eurocents and add raise you two. :) | || | ||I fully understand where you're coming from Ulf. Adding this | ||information into the DIT when it is currently possible to get is | ||something that grates against common sense and common engineering | ||principles even if you subscribe to belts and braces |methodologies. | || | ||However, I think two things make this a worthwhile request | |with a big | ||payoff. First to Laura's point about diminishing returns. I | ||agree, at some point there will be diminishing returns. I also | |believe that | ||as hardware gets bigger (i.e. | ||Standard 80 GB hard drives, 1 GB memory in workstation | |machines, etc. | ||[1]) the bar gets raised until we get to the diminishing return. | ||Since we're targeting 80/20 out of the box [2] it seems |reasonable | ||that 80% of the deployments would benefit from such a change. The | ||other 20 would be those that | ||a) don't care or know about such things and b) those that can't | ||tolerate the additional overhead and therefore wouldn't want | |to deploy | ||it. I say tough pickles to them. :) Seriously, this could be on | ||by default but configurable (group | ||policy?) to disable it as a performance issue etc. | || | ||Second, I think that the major benefit is the ability to | |actually get | ||usable information native to the product vs. | ||having to invest in a third party product. Why? Because today in | ||order
RE: [ActiveDir] Knowing when users were deleted.
Such beauty in a mere typo - Ulf Hi Bratt /Ulf ... still laughing at the irony ;o) ah hahahahaha -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Tuesday, October 18, 2005 10:34 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Hi Bratt, I knew, however assuming performance and size issues I'd prefer to get a better solutions within the OS for auditing AD instead of bloating it up for retrieving some information. But thanks to your prior post I'd vote for a auditing within AD as well, if it's even decreasing the metadata and doesn't have a high impact on performance (I know - reading less data is mostly better than worrying about the time it takes to be decompressed, and depending how you would implement this this might even be done distributed on the requesting machine). However - and I was impressed of your sharp brain at the summit ;-) - the DCRs I've been involved with don't make me to confident - even if it's you suggesting that - still a stony path to take until we might see something like this. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley |Sent: Tuesday, October 18, 2005 4:02 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Ulf, what Al (well the suggestion on the plate) is suggesting is taht |the something to centralize that info, _is_ AD replication. Implying |the data is in AD. | |Cheers, |-Brett | | |On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote: | | | Wherever the information gets put, it should be a) done as the | |default yet configurable b) centrally viewable (I should |NOT have to | |visit each DC in my forest to find the data) and | |c) be included in the base product. | | Exactly, that's what I ment. Enable that logging by default and | provide something to centralize that info. | | |-Original Message- | |From: [EMAIL PROTECTED] | |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick | |Sent: Tuesday, October 18, 2005 2:42 AM | |To: ActiveDir@mail.activedir.org | |Subject: RE: [ActiveDir] Knowing when users were deleted. | | | |Not sure that's going to fix the issue though, unless I'm missing | |something. | | Wherever the information gets put, it should be a) done as the | |default yet configurable b) centrally viewable (I should |NOT have to | |visit each DC in my forest to find the data) and | |c) be included in the base product. I can see no valuable way to | |otherwise do this. Having to deploy yet another product |doesn't fix | |the problem, it exacerbates it; it's even worse if it's a |reskit item | |as those aren't supported nor as heavily tested. This is |important | |enough that it should be and should meet those criteria above. | | | |We may just need to knock a few more edges off before |submitting this | |FMR ;) | | | | | |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] | |Reply-To: ActiveDir@mail.activedir.org | |To: ActiveDir@mail.activedir.org | |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Date: Mon, 17 Oct 2005 23:36:44 +0200 | | | |Another Hmm. | | | |I'd still like to see that better configured that putting it into | |the AD if the infos are already there (or configurable). We could | |request to make it default to log that kind of info. And as far as | |we are talking about looking into every server: Where's ACS? And | |also SNMP would be an option to get notified on a single system | |instead of looking into every DC. | | | |Ulf | | | ||-Original Message- | ||From: [EMAIL PROTECTED] | ||[mailto:[EMAIL PROTECTED] On Behalf Of |Al Mulnick | ||Sent: Monday, October 17, 2005 3:10 AM | ||To: ActiveDir@mail.activedir.org | ||Subject: RE: [ActiveDir] Knowing when users were deleted. | || | ||I'll see your Eurocents and add raise you two. :) | || | ||I fully understand where you're coming from Ulf. Adding this | ||information into the DIT when it is currently possible to get is | ||something that grates against common sense and common engineering | ||principles even if you subscribe to belts and braces |methodologies. | || | ||However, I think two things make this a worthwhile request | |with a big | ||payoff. First to Laura's point about diminishing returns. I | ||agree, at some point there will be diminishing returns. I also | |believe that | ||as hardware gets bigger (i.e. | ||Standard 80 GB hard drives, 1 GB memory in workstation | |machines, etc. | ||[1]) the bar gets raised until we get to the diminishing return. | ||Since we're targeting 80/20 out of the box [2] it seems |reasonable | ||that 80% of the deployments would benefit from such a change. The | ||other 20 would be those that | ||a) don't care or know about such things and b) those that can't | ||tolerate the additional overhead
RE: [ActiveDir] Knowing when users were deleted.
Outch - Sorry Brett! |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells |Sent: Wednesday, October 19, 2005 5:20 AM |To: Send - AD mailing list |Subject: RE: [ActiveDir] Knowing when users were deleted. |Importance: Low | |Such beauty in a mere typo - | |Ulf |Hi Bratt |/Ulf | |... still laughing at the irony ;o) | |ah hahahahaha | |-- |Dean Wells |MSEtechnology |* Email: [EMAIL PROTECTED] |http://msetechnology.com | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Tuesday, October 18, 2005 10:34 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |Hi Bratt, | |I knew, however assuming performance and size issues I'd |prefer to get a better solutions within the OS for auditing AD |instead of bloating it up for retrieving some information. | |But thanks to your prior post I'd vote for a auditing within |AD as well, if it's even decreasing the metadata and doesn't |have a high impact on performance (I know - reading less data |is mostly better than worrying about the time it takes to be |decompressed, and depending how you would implement this this |might even be done distributed on the requesting machine). |However - and I was impressed of your sharp brain at the |summit ;-) - the DCRs I've been involved with don't make me to |confident - even if it's you suggesting that - still a stony |path to take until we might see something like this. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley ||Sent: Tuesday, October 18, 2005 4:02 PM ||To: ActiveDir@mail.activedir.org ||Subject: RE: [ActiveDir] Knowing when users were deleted. || ||Ulf, what Al (well the suggestion on the plate) is suggesting is taht ||the something to centralize that info, _is_ AD replication. | Implying ||the data is in AD. || ||Cheers, ||-Brett || || ||On Tue, 18 Oct 2005, Ulf B. Simon-Weidner wrote: || || | Wherever the information gets put, it should be a) done as the || |default yet configurable b) centrally viewable (I should ||NOT have to || |visit each DC in my forest to find the data) and || |c) be included in the base product. || || Exactly, that's what I ment. Enable that logging by default and || provide something to centralize that info. || || |-Original Message- || |From: [EMAIL PROTECTED] || |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick || |Sent: Tuesday, October 18, 2005 2:42 AM || |To: ActiveDir@mail.activedir.org || |Subject: RE: [ActiveDir] Knowing when users were deleted. || | || |Not sure that's going to fix the issue though, unless I'm missing || |something. || | Wherever the information gets put, it should be a) done as the || |default yet configurable b) centrally viewable (I should ||NOT have to || |visit each DC in my forest to find the data) and || |c) be included in the base product. I can see no valuable way to || |otherwise do this. Having to deploy yet another product ||doesn't fix || |the problem, it exacerbates it; it's even worse if it's a ||reskit item || |as those aren't supported nor as heavily tested. This is ||important || |enough that it should be and should meet those criteria above. || | || |We may just need to knock a few more edges off before ||submitting this || |FMR ;) || | || | || |From: Ulf B. Simon-Weidner [EMAIL PROTECTED] || |Reply-To: ActiveDir@mail.activedir.org || |To: ActiveDir@mail.activedir.org || |Subject: RE: [ActiveDir] Knowing when users were deleted. || |Date: Mon, 17 Oct 2005 23:36:44 +0200 || | || |Another Hmm. || | || |I'd still like to see that better configured that putting it into || |the AD if the infos are already there (or configurable). We could || |request to make it default to log that kind of info. And |as far as || |we are talking about looking into every server: Where's ACS? And || |also SNMP would be an option to get notified on a single system || |instead of looking into every DC. || | || |Ulf || | || ||-Original Message- || ||From: [EMAIL PROTECTED] || ||[mailto:[EMAIL PROTECTED] On Behalf Of ||Al Mulnick || ||Sent: Monday, October 17, 2005 3:10 AM || ||To: ActiveDir@mail.activedir.org || ||Subject: RE: [ActiveDir] Knowing when users were deleted. || || || ||I'll see your Eurocents and add raise you two. :) || || || ||I fully understand where you're coming from Ulf. Adding this || ||information into the DIT when it is currently possible to get is || ||something that grates against common sense and common |engineering || ||principles even if you subscribe to belts and braces ||methodologies. || || || ||However, I think two things make this a worthwhile request || |with a big || ||payoff. First to Laura's point about diminishing returns. I || ||agree, at some point there will be diminishing returns. I also || |believe that || ||as hardware gets bigger (i.e
RE: [ActiveDir] Knowing when users were deleted.
I've discussed something like this recently: display a monitoring summary at every admin login, e.g. instead of the annoying configure your server thingie ;-) There are just to many admins not paying any attention to the event logs, so if they don't go into event logs bring the event logs to them :D Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Susan |Bradley, CPA aka Ebitz - SBS Rocks [MVP] |Sent: Monday, October 17, 2005 3:33 AM |To: ActiveDir@mail.activedir.org |Subject: Re: [ActiveDir] Knowing when users were deleted. | |here she goes again.. I know ... I'm terrible at lurking | |In SBSland we have a daily monitoring email [well ... I send |it daily anyway, but it's configurable] and it looks at the |event logs and tells daily health status of my server. | |Like today my email tells me my server has been running for 6 |hours [just rebooted it last night] and it gives me an |overview if auto services are not running, critical alerts and |critical errors in the event logs. | |It tells me memory/disk size, cpu use, top processes, if the |backup ran, and aggregates the alerts from all the log files. | |It's a health mon that dumps it's data into a msde database |and builds the email to be sent internally or externally. | |What it does now, is only pulls data from the one box, the SBS |box. but I can go into health mon and build my own monitors |and grab those event logs from other machines [need to so that |just haven't gotten around to it]. | |Right now if someone [usually me] fat fingers a password, for |example, it gives me an alert in the email of the last time it |occurred and how many occurrances. Basically it's tracking |the critical alerts in all the event logs and summarizing the |events along with the number of events in the email [and |showing the last time the event occurred so you can start your |investigation from that point back] | |For SBS it's in the box, it's a gui wizard that builds |this pretty little html email that my server builds and hits |me every morning at 6 a.m and says Hey here's how I'm |doing...how are you?. It's the mid market that doesn't have |this. [and yes, we've told Mothership Redmond they need to |steal this sucker and put it in the mid market server bundle] | |Does it make me more aware of events on my server? Oh you |betcha it does. Which is why this needs to be as you |say...native in small and medium serversheck I'd strongly |argue that no server should be shipped without some admin |somewhere getting an in your face report on that sucker. | |I'll go to Frys and buy bigger harddrives if I need to. But |give me a big fat audit log file and I'm a happy camper. | | |Al Mulnick wrote: | |I'll see your Eurocents and add raise you two. :) | |I fully understand where you're coming from Ulf. Adding this |information |into the DIT when it is currently possible to get is |something that grates |against common sense and common engineering principles even |if you subscribe |to belts and braces methodologies. | |However, I think two things make this a worthwhile request with a big |payoff. First to Laura's point about diminishing returns. I |agree, at some |point there will be diminishing returns. I also believe that |as hardware |gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in |workstation |machines, etc. [1]) the bar gets raised until we get to the |diminishing |return. Since we're targeting 80/20 out of the box [2] it |seems reasonable |that 80% of the deployments would benefit from such a change. |The other 20 |would be those that a) don't care or know about such things |and b) those |that can't tolerate the additional overhead and therefore |wouldn't want to |deploy it. I say tough pickles to them. :) Seriously, this |could be on by |default but configurable (group policy?) to disable it as a |performance |issue etc. | |Second, I think that the major benefit is the ability to |actually get usable |information native to the product vs. having to invest in a |third party |product. Why? Because today in order to get that information |I have to have |something that scrapes the Security logs looking for such |information. Is |this a good idea? I think it is. Is it something that could |be native? I |think it could and should be native if technically feasible. | |Making us look in a particular DC's event logs is more |difficult than it |should be without yet another product. That's fine for the |really large |companies that have deeper pockets, and larger needs. For |the small to |medium businesses, it should not be so difficult nor should |it *require* SQL |licensing or expertise. | | | |[1] I'm not saying that the quality has kept up, only that |the hardware is |bigger, faster, stronger and cheaper. |[2] I'm making that up, but it sounds reasonable | | | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto
RE: [ActiveDir] Knowing when users were deleted.
Another Hmm. I'd still like to see that better configured that putting it into the AD if the infos are already there (or configurable). We could request to make it default to log that kind of info. And as far as we are talking about looking into every server: Where's ACS? And also SNMP would be an option to get notified on a single system instead of looking into every DC. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Monday, October 17, 2005 3:10 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |I'll see your Eurocents and add raise you two. :) | |I fully understand where you're coming from Ulf. Adding this |information into the DIT when it is currently possible to get |is something that grates against common sense and common |engineering principles even if you subscribe to belts and |braces methodologies. | |However, I think two things make this a worthwhile request |with a big payoff. First to Laura's point about diminishing |returns. I agree, at some point there will be diminishing |returns. I also believe that as hardware gets bigger (i.e. |Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. [1]) the bar gets raised until we get to the |diminishing return. Since we're targeting 80/20 out of the |box [2] it seems reasonable that 80% of the deployments would |benefit from such a change. The other 20 would be those that |a) don't care or know about such things and b) those that |can't tolerate the additional overhead and therefore wouldn't |want to deploy it. I say tough pickles to them. :) |Seriously, this could be on by default but configurable (group |policy?) to disable it as a performance issue etc. | |Second, I think that the major benefit is the ability to |actually get usable information native to the product vs. |having to invest in a third party product. Why? Because today |in order to get that information I have to have something that |scrapes the Security logs looking for such information. Is |this a good idea? I think it is. Is it something that could |be native? I think it could and should be native if |technically feasible. | |Making us look in a particular DC's event logs is more |difficult than it should be without yet another product. |That's fine for the really large companies that have deeper |pockets, and larger needs. For the small to medium |businesses, it should not be so difficult nor should it |*require* SQL licensing or expertise. | | | |[1] I'm not saying that the quality has kept up, only that the |hardware is bigger, faster, stronger and cheaper. |[2] I'm making that up, but it sounds reasonable | | | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Sunday, October 16, 2005 4:42 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | | |Hmm. | |Do we really want to excuse prior failure of proper auditing |by putting more data into AD? Wouldn't that lead into every |request of non-configured auditing to requests for extending |the AD? Do it right the first way. | |I completely agree that we should make the people more |auditing aware, and it would be great to have a centralized |auditing together with some force of configuration instead of |the per server events and auditing which is rearly configured. | |However I'm not sure if I want this kind of data in the AD. | |Just my Eurocents. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Laura E. ||Hunter ||Sent: Sunday, October 16, 2005 10:28 PM ||To: ActiveDir@mail.activedir.org ||Subject: Re: [ActiveDir] Knowing when users were deleted. || ||Various thoughts from this thread: || ||[1] I agree with Al and Paul[1] on a desire for that sort of |metadata. ||I'm not as convinced of the trade-off value of bloating the DIT for ||full undelete information, particularly in monster big environments. ||For my teeny-tiny single domain it probably wouldn't be that bad of a ||hit, but I imagine that the laws of diminishing returns would quickly ||set in. || ||[2] Please finish the thought, Brett, I'm sure I'd find it ||helpful/enlightening/informative even if it's only speaking in ||hypotheticals. || ||[3] It's Gil and Darren's turn to crack me up today, I guess joe is ||taking a break. || || ||[1] *waves* Hi Paul! Glad to see you alive post-Summit. || ||- L ||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
RE: [ActiveDir] Knowing when users were deleted.
ACS is now integrated into MOM3 which is coming I don't know when. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, October 17, 2005 5:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Another Hmm. I'd still like to see that better configured that putting it into the AD if the infos are already there (or configurable). We could request to make it default to log that kind of info. And as far as we are talking about looking into every server: Where's ACS? And also SNMP would be an option to get notified on a single system instead of looking into every DC. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Monday, October 17, 2005 3:10 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |I'll see your Eurocents and add raise you two. :) | |I fully understand where you're coming from Ulf. Adding this |information into the DIT when it is currently possible to get |is something that grates against common sense and common |engineering principles even if you subscribe to belts and |braces methodologies. | |However, I think two things make this a worthwhile request |with a big payoff. First to Laura's point about diminishing |returns. I agree, at some point there will be diminishing |returns. I also believe that as hardware gets bigger (i.e. |Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. [1]) the bar gets raised until we get to the |diminishing return. Since we're targeting 80/20 out of the |box [2] it seems reasonable that 80% of the deployments would |benefit from such a change. The other 20 would be those that |a) don't care or know about such things and b) those that |can't tolerate the additional overhead and therefore wouldn't |want to deploy it. I say tough pickles to them. :) |Seriously, this could be on by default but configurable (group |policy?) to disable it as a performance issue etc. | |Second, I think that the major benefit is the ability to |actually get usable information native to the product vs. |having to invest in a third party product. Why? Because today |in order to get that information I have to have something that |scrapes the Security logs looking for such information. Is |this a good idea? I think it is. Is it something that could |be native? I think it could and should be native if |technically feasible. | |Making us look in a particular DC's event logs is more |difficult than it should be without yet another product. |That's fine for the really large companies that have deeper |pockets, and larger needs. For the small to medium |businesses, it should not be so difficult nor should it |*require* SQL licensing or expertise. | | | |[1] I'm not saying that the quality has kept up, only that the |hardware is bigger, faster, stronger and cheaper. |[2] I'm making that up, but it sounds reasonable | | | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Sunday, October 16, 2005 4:42 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | | |Hmm. | |Do we really want to excuse prior failure of proper auditing |by putting more data into AD? Wouldn't that lead into every |request of non-configured auditing to requests for extending |the AD? Do it right the first way. | |I completely agree that we should make the people more |auditing aware, and it would be great to have a centralized |auditing together with some force of configuration instead of |the per server events and auditing which is rearly configured. | |However I'm not sure if I want this kind of data in the AD. | |Just my Eurocents. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Laura E. ||Hunter ||Sent: Sunday, October 16, 2005 10:28 PM ||To: ActiveDir@mail.activedir.org ||Subject: Re: [ActiveDir] Knowing when users were deleted. || ||Various thoughts from this thread: || ||[1] I agree with Al and Paul[1] on a desire for that sort of |metadata. ||I'm not as convinced of the trade-off value of bloating the DIT for ||full undelete information, particularly in monster big environments. ||For my teeny-tiny single domain it probably wouldn't be that bad of a ||hit, but I imagine that the laws of diminishing returns would quickly ||set in. || ||[2] Please finish the thought, Brett, I'm sure I'd find it ||helpful/enlightening/informative even if it's only speaking in ||hypotheticals. || ||[3] It's Gil and Darren's turn to crack me up today, I guess joe is ||taking a break. || || ||[1] *waves* Hi Paul! Glad to see you alive post-Summit. || ||- L ||List info : http
RE: [ActiveDir] Knowing when users were deleted.
Where's ACS? As the beta came to a end, the last I was told the agent would be in R2 (free) and the collector would be a separate product (!free) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Monday, October 17, 2005 2:37 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Another Hmm. I'd still like to see that better configured that putting it into the AD if the infos are already there (or configurable). We could request to make it default to log that kind of info. And as far as we are talking about looking into every server: Where's ACS? And also SNMP would be an option to get notified on a single system instead of looking into every DC. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Monday, October 17, 2005 3:10 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |I'll see your Eurocents and add raise you two. :) | |I fully understand where you're coming from Ulf. Adding this |information into the DIT when it is currently possible to get |is something that grates against common sense and common |engineering principles even if you subscribe to belts and |braces methodologies. | |However, I think two things make this a worthwhile request |with a big payoff. First to Laura's point about diminishing |returns. I agree, at some point there will be diminishing |returns. I also believe that as hardware gets bigger (i.e. |Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. [1]) the bar gets raised until we get to the |diminishing return. Since we're targeting 80/20 out of the |box [2] it seems reasonable that 80% of the deployments would |benefit from such a change. The other 20 would be those that |a) don't care or know about such things and b) those that |can't tolerate the additional overhead and therefore wouldn't |want to deploy it. I say tough pickles to them. :) |Seriously, this could be on by default but configurable (group |policy?) to disable it as a performance issue etc. | |Second, I think that the major benefit is the ability to |actually get usable information native to the product vs. |having to invest in a third party product. Why? Because today |in order to get that information I have to have something that |scrapes the Security logs looking for such information. Is |this a good idea? I think it is. Is it something that could |be native? I think it could and should be native if |technically feasible. | |Making us look in a particular DC's event logs is more |difficult than it should be without yet another product. |That's fine for the really large companies that have deeper |pockets, and larger needs. For the small to medium |businesses, it should not be so difficult nor should it |*require* SQL licensing or expertise. | | | |[1] I'm not saying that the quality has kept up, only that the |hardware is bigger, faster, stronger and cheaper. |[2] I'm making that up, but it sounds reasonable | | | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Sunday, October 16, 2005 4:42 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | | |Hmm. | |Do we really want to excuse prior failure of proper auditing |by putting more data into AD? Wouldn't that lead into every |request of non-configured auditing to requests for extending |the AD? Do it right the first way. | |I completely agree that we should make the people more |auditing aware, and it would be great to have a centralized |auditing together with some force of configuration instead of |the per server events and auditing which is rearly configured. | |However I'm not sure if I want this kind of data in the AD. | |Just my Eurocents. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Laura E. ||Hunter ||Sent: Sunday, October 16, 2005 10:28 PM ||To: ActiveDir@mail.activedir.org ||Subject: Re: [ActiveDir] Knowing when users were deleted. || ||Various thoughts from this thread: || ||[1] I agree with Al and Paul[1] on a desire for that sort of |metadata. ||I'm not as convinced of the trade-off value of bloating the DIT for ||full undelete information, particularly in monster big environments. ||For my teeny-tiny single domain it probably wouldn't be that bad of a ||hit, but I imagine that the laws of diminishing returns would quickly ||set in. || ||[2] Please finish the thought, Brett, I'm sure I'd find it ||helpful/enlightening/informative even if it's only speaking in ||hypotheticals. || ||[3] It's Gil and Darren's turn to crack me up today, I guess joe is ||taking a break. || || ||[1] *waves* Hi Paul! Glad to see you alive post-Summit. || ||- L ||List info : http
RE: [ActiveDir] Knowing when users were deleted.
Not sure that's going to fix the issue though, unless I'm missing something. Wherever the information gets put, it should be a) done as the default yet configurable b) centrally viewable (I should NOT have to visit each DC in my forest to find the data) and c) be included in the base product. I can see no valuable way to otherwise do this. Having to deploy yet another product doesn't fix the problem, it exacerbates it; it's even worse if it's a reskit item as those aren't supported nor as heavily tested. This is important enough that it should be and should meet those criteria above. We may just need to knock a few more edges off before submitting this FMR ;) From: Ulf B. Simon-Weidner [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Date: Mon, 17 Oct 2005 23:36:44 +0200 Another Hmm. I'd still like to see that better configured that putting it into the AD if the infos are already there (or configurable). We could request to make it default to log that kind of info. And as far as we are talking about looking into every server: Where's ACS? And also SNMP would be an option to get notified on a single system instead of looking into every DC. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick |Sent: Monday, October 17, 2005 3:10 AM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | |I'll see your Eurocents and add raise you two. :) | |I fully understand where you're coming from Ulf. Adding this |information into the DIT when it is currently possible to get |is something that grates against common sense and common |engineering principles even if you subscribe to belts and |braces methodologies. | |However, I think two things make this a worthwhile request |with a big payoff. First to Laura's point about diminishing |returns. I agree, at some point there will be diminishing |returns. I also believe that as hardware gets bigger (i.e. |Standard 80 GB hard drives, 1 GB memory in workstation |machines, etc. [1]) the bar gets raised until we get to the |diminishing return. Since we're targeting 80/20 out of the |box [2] it seems reasonable that 80% of the deployments would |benefit from such a change. The other 20 would be those that |a) don't care or know about such things and b) those that |can't tolerate the additional overhead and therefore wouldn't |want to deploy it. I say tough pickles to them. :) |Seriously, this could be on by default but configurable (group |policy?) to disable it as a performance issue etc. | |Second, I think that the major benefit is the ability to |actually get usable information native to the product vs. |having to invest in a third party product. Why? Because today |in order to get that information I have to have something that |scrapes the Security logs looking for such information. Is |this a good idea? I think it is. Is it something that could |be native? I think it could and should be native if |technically feasible. | |Making us look in a particular DC's event logs is more |difficult than it should be without yet another product. |That's fine for the really large companies that have deeper |pockets, and larger needs. For the small to medium |businesses, it should not be so difficult nor should it |*require* SQL licensing or expertise. | | | |[1] I'm not saying that the quality has kept up, only that the |hardware is bigger, faster, stronger and cheaper. |[2] I'm making that up, but it sounds reasonable | | | | |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Sunday, October 16, 2005 4:42 PM |To: ActiveDir@mail.activedir.org |Subject: RE: [ActiveDir] Knowing when users were deleted. | | |Hmm. | |Do we really want to excuse prior failure of proper auditing |by putting more data into AD? Wouldn't that lead into every |request of non-configured auditing to requests for extending |the AD? Do it right the first way. | |I completely agree that we should make the people more |auditing aware, and it would be great to have a centralized |auditing together with some force of configuration instead of |the per server events and auditing which is rearly configured. | |However I'm not sure if I want this kind of data in the AD. | |Just my Eurocents. | |Ulf | ||-Original Message- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Laura E. ||Hunter ||Sent: Sunday, October 16, 2005 10:28 PM ||To: ActiveDir@mail.activedir.org ||Subject: Re: [ActiveDir] Knowing when users were deleted. || ||Various thoughts from this thread: || ||[1] I agree with Al and Paul[1] on a desire for that sort of |metadata. ||I'm not as convinced of the trade-off value of bloating the DIT for ||full undelete information, particularly in monster big environments. ||For my teeny-tiny single domain
Re: [ActiveDir] Knowing when users were deleted.
Is there a line? 'Cause if there's a line, I'd just like to know :) Regarding this thread. I have to say it's interesting to see the many sides differences based on experience and scale. But I think to bring this back a bit, I'm not sure that the SBS concept can work as well in the scaled up version. Here's what I mean: if I get an email from each DC, that's just as bad (almost) as if I went out and got the information manually. It's just that I pushed the information vs. pulled it. We blurred this a bit when we brought in the event logs for the audit information, but I think the concept we originally started to look at was surrounding the information regarding who deleted an object. That information is collected by the system and may be logged in the security log if the settings are so configured. The difference is whether we use a push or a pull model. A pull model is very inefficient, but push is pretty inefficient as well as we scale up. What makes more sense *so I thought before talking to bldg 7 Garage door opener* was that we could tag the deleted item with the sid or similar on the deleted object upon deletion. That allows it to replicate to all DC's and keeps the information with the relevant object. Having to deploy a third party product or reskit utility or ?? is not my idea of being able to keep this information where it should be. I also think putting the information on the object, could lead to additional products related to reanimation. I think so anyway. *just curious who's listening. I've heard he can close the door as well. From: Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] [EMAIL PROTECTED] Reply-To: ActiveDir@mail.activedir.org To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. Date: Sun, 16 Oct 2005 19:48:52 -0700 I give carte blanche to folks to wack me upside the head if I get too annoying. :-) Rick Kingslan wrote: Susan, Really - I know you too well. You're not going to lurk. Get in the game. It appears most folks want to hear what you have to say from the Small Business arena. And, if it broadens the message of managing and maintaining the systems - it's good for all. Just please - stop convincing yourself you're lurking You're aren't! You're too valuable to do so... :o) Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 9:02 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. sorry .. I know...I know...lurk..lurk The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily
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
RE: [ActiveDir] Knowing when users were deleted.
I'd be interested as well. BTW for the original request (don't have it here separatelly to reply) I've been told that there are some 3rd party tools which allow that kind of Audit. E.g. inTrust from Quest claims to plug in front of the LSASS and control which actions to log, which ones to apply and which ones to decline b/c they are in conflict with some buiness rules. Haven't head a chance to look into the app yet - just know the marketing ;-) Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of joe |Sent: Sunday, October 16, 2005 5:11 PM |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
RE: [ActiveDir] Knowing when users were deleted.
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
Re: [ActiveDir] Knowing when users were deleted.
Yep. Me too. - Original Message - From: Al Mulnick [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Sunday, October 16, 2005 6:38 PM Subject: RE: [ActiveDir] Knowing when users were deleted. 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
Re: [ActiveDir] Knowing when users were deleted.
Various thoughts from this thread: [1] I agree with Al and Paul[1] on a desire for that sort of metadata. I'm not as convinced of the trade-off value of bloating the DIT for full undelete information, particularly in monster big environments. For my teeny-tiny single domain it probably wouldn't be that bad of a hit, but I imagine that the laws of diminishing returns would quickly set in. [2] Please finish the thought, Brett, I'm sure I'd find it helpful/enlightening/informative even if it's only speaking in hypotheticals. [3] It's Gil and Darren's turn to crack me up today, I guess joe is taking a break. [1] *waves* Hi Paul! Glad to see you alive post-Summit. - L 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/
RE: [ActiveDir] Knowing when users were deleted.
Hmm. Do we really want to excuse prior failure of proper auditing by putting more data into AD? Wouldn't that lead into every request of non-configured auditing to requests for extending the AD? Do it right the first way. I completely agree that we should make the people more auditing aware, and it would be great to have a centralized auditing together with some force of configuration instead of the per server events and auditing which is rearly configured. However I'm not sure if I want this kind of data in the AD. Just my Eurocents. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Laura |E. Hunter |Sent: Sunday, October 16, 2005 10:28 PM |To: ActiveDir@mail.activedir.org |Subject: Re: [ActiveDir] Knowing when users were deleted. | |Various thoughts from this thread: | |[1] I agree with Al and Paul[1] on a desire for that sort of metadata. | I'm not as convinced of the trade-off value of bloating the |DIT for full undelete information, particularly in monster big |environments. |For my teeny-tiny single domain it probably wouldn't be that |bad of a hit, but I imagine that the laws of diminishing |returns would quickly set in. | |[2] Please finish the thought, Brett, I'm sure I'd find it |helpful/enlightening/informative even if it's only speaking in |hypotheticals. | |[3] It's Gil and Darren's turn to crack me up today, I guess |joe is taking a break. | | |[1] *waves* Hi Paul! Glad to see you alive post-Summit. | |- L |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/
RE: [ActiveDir] Knowing when users were deleted.
I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead and therefore wouldn't want to deploy it. I say tough pickles to them. :) Seriously, this could be on by default but configurable (group policy?) to disable it as a performance issue etc. Second, I think that the major benefit is the ability to actually get usable information native to the product vs. having to invest in a third party product. Why? Because today in order to get that information I have to have something that scrapes the Security logs looking for such information. Is this a good idea? I think it is. Is it something that could be native? I think it could and should be native if technically feasible. Making us look in a particular DC's event logs is more difficult than it should be without yet another product. That's fine for the really large companies that have deeper pockets, and larger needs. For the small to medium businesses, it should not be so difficult nor should it *require* SQL licensing or expertise. [1] I'm not saying that the quality has kept up, only that the hardware is bigger, faster, stronger and cheaper. [2] I'm making that up, but it sounds reasonable -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Sunday, October 16, 2005 4:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Hmm. Do we really want to excuse prior failure of proper auditing by putting more data into AD? Wouldn't that lead into every request of non-configured auditing to requests for extending the AD? Do it right the first way. I completely agree that we should make the people more auditing aware, and it would be great to have a centralized auditing together with some force of configuration instead of the per server events and auditing which is rearly configured. However I'm not sure if I want this kind of data in the AD. Just my Eurocents. Ulf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Laura |E. Hunter |Sent: Sunday, October 16, 2005 10:28 PM |To: ActiveDir@mail.activedir.org |Subject: Re: [ActiveDir] Knowing when users were deleted. | |Various thoughts from this thread: | |[1] I agree with Al and Paul[1] on a desire for that sort of metadata. |I'm not as convinced of the trade-off value of bloating the DIT for |full undelete information, particularly in monster big environments. |For my teeny-tiny single domain it probably wouldn't be that |bad of a hit, but I imagine that the laws of diminishing |returns would quickly set in. | |[2] Please finish the thought, Brett, I'm sure I'd find it |helpful/enlightening/informative even if it's only speaking in |hypotheticals. | |[3] It's Gil and Darren's turn to crack me up today, I guess |joe is taking a break. | | |[1] *waves* Hi Paul! Glad to see you alive post-Summit. | |- L |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/
Re: [ActiveDir] Knowing when users were deleted.
here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead and therefore wouldn't want to deploy it. I say tough pickles to them. :) Seriously, this could be on by default but configurable (group policy?) to disable it as a performance issue etc. Second, I think that the major benefit is the ability to actually get usable information native to the product vs. having to invest in a third party product. Why? Because today in order to get that information I have to have something that scrapes the Security logs looking for such information. Is this a good idea? I think it is. Is it something that could be native? I think it could and should be native if technically feasible. Making us look in a particular DC's event logs is more difficult than it should be without yet another product. That's fine for the really large companies that have deeper pockets, and larger needs. For the small to medium businesses, it should not be so difficult nor should it *require* SQL licensing or expertise. [1] I'm not saying that the quality has kept up, only that the hardware is bigger, faster, stronger and cheaper. [2] I'm making that up, but it sounds reasonable -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Sunday, October 16, 2005 4:42 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Hmm. Do we really want to excuse prior failure of proper auditing by putting more data into AD? Wouldn't that lead into every request of non-configured auditing to requests for extending the AD? Do it right the first way. I completely agree that we should make the people more auditing aware, and it would be great to have a centralized auditing together with some force of configuration instead of the per server events and auditing which is rearly configured. However I'm not sure if I want this kind of data in the AD
RE: [ActiveDir] Knowing when users were deleted.
And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead and therefore wouldn't want to deploy it. I say tough pickles to them. :) Seriously, this could be on by default but configurable (group policy?) to disable it as a performance issue etc. Second, I think that the major benefit is the ability to actually get usable information native to the product vs. having to invest in a third party product. Why? Because today in order to get that information I have to have something that scrapes the Security logs looking for such information. Is this a good idea? I think it is. Is it something that could be native? I think it could and should be native if technically feasible. Making us look in a particular DC's event logs is more difficult than it should be without yet another product. That's fine for the really large
Re: [ActiveDir] Knowing when users were deleted.
Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead and therefore wouldn't want to deploy it. I say tough pickles to them. :) Seriously, this could be on by default but configurable (group policy?) to disable it as a performance issue etc. Second, I think that the major benefit is the ability to actually get usable information native to the product vs. having to invest in a third party product. Why? Because today in order to get that information I have to have something that scrapes the Security logs looking for such information
Re: [ActiveDir] Knowing when users were deleted.
sorry .. I know...I know...lurk..lurk The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get
RE: [ActiveDir] Knowing when users were deleted.
I get these sorts of emails, at least the security audit aggregation stuff too. Just remember for me that I have a section of a very expensive SAN shelf allocated to my audit collection project, a pair of very well equipped servers clustered running SQL (expensive), a web frontend running SQL RS (cheap), and my time as a consultant maintaining it (very expensive). This stuff adds up. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 9:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead and therefore wouldn't want to deploy it. I say tough pickles to them. :) Seriously, this could be on by default but configurable (group policy?) to disable it as a performance issue etc. Second, I think that the major benefit is the ability to actually get usable information native to the product vs. having to invest in a third party product. Why? Because today in order to get that information I have to have something that scrapes the Security logs looking for such information. Is this a good idea? I think it is. Is it something that could be native? I think it could and should be native if technically feasible. Making us look in a particular DC's event logs is more difficult than it should be without yet another product. That's fine for the really large companies that have deeper pockets, and larger needs. For the small to medium businesses, it should not be so difficult nor should it *require* SQL licensing or expertise. [1] I'm not saying that the quality has kept up, only that the hardware is bigger, faster, stronger and cheaper. [2] I'm making that up, but it sounds reasonable -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL
RE: [ActiveDir] Knowing when users were deleted.
Mrtg (actually mrtg + rrdtool) and nagios are standard equipment in many an enterprise, mrtg in particular. You can get mrtg to graph damn near anything if you're good. Nagios in my opinion is better than MOM in certain respects, and it's free. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 10:02 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. sorry .. I know...I know...lurk..lurk The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two
RE: [ActiveDir] Knowing when users were deleted.
I suppose that this is why they pay folks who devise solutions to make this stuff work like it's supposed to the big bucks. shrug Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:54 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger harddrives if I need to. But give me a big fat audit log file and I'm a happy camper. Al Mulnick wrote: I'll see your Eurocents and add raise you two. :) I fully understand where you're coming from Ulf. Adding this information into the DIT when it is currently possible to get is something that grates against common sense and common engineering principles even if you subscribe to belts and braces methodologies. However, I think two things make this a worthwhile request with a big payoff. First to Laura's point about diminishing returns. I agree, at some point there will be diminishing returns. I also believe that as hardware gets bigger (i.e. Standard 80 GB hard drives, 1 GB memory in workstation machines, etc. [1]) the bar gets raised until we get to the diminishing return. Since we're targeting 80/20 out of the box [2] it seems reasonable that 80% of the deployments would benefit from such a change. The other 20 would be those that a) don't care or know about such things and b) those that can't tolerate the additional overhead
RE: [ActiveDir] Knowing when users were deleted.
Susan, Really - I know you too well. You're not going to lurk. Get in the game. It appears most folks want to hear what you have to say from the Small Business arena. And, if it broadens the message of managing and maintaining the systems - it's good for all. Just please - stop convincing yourself you're lurking You're aren't! You're too valuable to do so... :o) Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 9:02 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. sorry .. I know...I know...lurk..lurk The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face report on that sucker. I'll go to Frys and buy bigger
Re: [ActiveDir] Knowing when users were deleted.
I give carte blanche to folks to wack me upside the head if I get too annoying. :-) Rick Kingslan wrote: Susan, Really - I know you too well. You're not going to lurk. Get in the game. It appears most folks want to hear what you have to say from the Small Business arena. And, if it broadens the message of managing and maintaining the systems - it's good for all. Just please - stop convincing yourself you're lurking You're aren't! You're too valuable to do so... :o) Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 9:02 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. sorry .. I know...I know...lurk..lurk The consultant crowd who can't handle 300 SBS boxes hitting their inbox at 6 a.m have asked for a dashboard. I can handle a daily email they can't. At a NTuser group meeting I was at ...some of the dashboard tools in Linux were discussed. Nagios in particular was one they used for monitoring. Monitoring -- MRTG: The Multi Router Traffic Grapher: http://mrtg.hdl.com/mrtg.html Graphical console for Snort - Analysis Console for Intrusion Databases (ACID): http://acidlab.sourceforge.net/ Intrustion detection - Snort.org: http://www.snort.org/ Monitoring - Nagios: Home: http://www.nagios.org/ Traffic probe - ntop - network top: http://www.ntop.org/head.html Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] wrote: Yup information overload 'is' a problem. And then after the scale its... okay what the heck is the server trying to tell me? I'm still a fan of www.eventid.net over microsoft.com's click here. Rick Kingslan wrote: And, as you know that does work well in SBSland. However, when the scale grows, so do the requirements. IN the Medium to Enterprise space, the idea is more along the lines of a system or series of systems pumping this type of information into paging and making intelligent decisions based on the audit, event, alerts, services, etc. Which, is right where MOM 2005 drops into the picture. If it _IS_ the event aggregator, or if it's pushing up to a bigger overall item such as HP OpenView - that data is available. It's just that instead of getting an e-mail per server (most admins would just begin to create a rule to send these to DEV/NUL after a while...) MOM collects, enforces and reports this same type of information. Scale makes the problem much tougher, as I'm sure you can imagine Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA aka Ebitz - SBS Rocks [MVP] Sent: Sunday, October 16, 2005 8:33 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Knowing when users were deleted. here she goes again.. I know ... I'm terrible at lurking In SBSland we have a daily monitoring email [well ... I send it daily anyway, but it's configurable] and it looks at the event logs and tells daily health status of my server. Like today my email tells me my server has been running for 6 hours [just rebooted it last night] and it gives me an overview if auto services are not running, critical alerts and critical errors in the event logs. It tells me memory/disk size, cpu use, top processes, if the backup ran, and aggregates the alerts from all the log files. It's a health mon that dumps it's data into a msde database and builds the email to be sent internally or externally. What it does now, is only pulls data from the one box, the SBS box. but I can go into health mon and build my own monitors and grab those event logs from other machines [need to so that just haven't gotten around to it]. Right now if someone [usually me] fat fingers a password, for example, it gives me an alert in the email of the last time it occurred and how many occurrances. Basically it's tracking the critical alerts in all the event logs and summarizing the events along with the number of events in the email [and showing the last time the event occurred so you can start your investigation from that point back] For SBS it's in the box, it's a gui wizard that builds this pretty little html email that my server builds and hits me every morning at 6 a.m and says Hey here's how I'm doing...how are you?. It's the mid market that doesn't have this. [and yes, we've told Mothership Redmond they need to steal this sucker and put it in the mid market server bundle] Does it make me more aware of events on my server? Oh you betcha it does. Which is why this needs to be as you say...native in small and medium serversheck I'd strongly argue that no server should be shipped without some admin somewhere getting an in your face
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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Yann, There are some utilities you can purchase that will alert you when an object is deleted, added, modified... Dan Original Message Subject: [ActiveDir] Knowing when users were deleted. From: Yann [EMAIL PROTECTED] Date: Thu, October 13, 2005 11:56 pm To: ActiveDir@mail.activedir.org 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 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/
RE: [ActiveDir] Knowing when users were deleted.
Title: Message 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 joeSent: Friday, October 14, 2005 11:03 AMTo: ActiveDir@mail.activedir.orgSubject: 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 HARTONOSent: Friday, October 14, 2005 3:18 AMTo: ActiveDir@mail.activedir.orgSubject: 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Hi Freddy, The information you gave rocks ! Idid not thinkusing the Last modified date attributeand query it with the magic joe's tool : - "adfind -default -showdel -f isdeleted=TRUE" It saves my job ! :) The security audit isnow configured and on. Thanks for your help. YannFreddy HARTONO [EMAIL PROTECTED] a écrit : 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici ! Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
true. I was looking rather for free tools, and i found the free eventriggers tool form the 2k3 rktools that did the job. It alerts you in real time for a specific eventID. You can telleventriggers to do a particular actionsuch as using dumpel.exe to dump the 630 id (frecnh specific id i presume)that corresponds to a deleted object action. Notice that eventriggers.exe only works on w2k3/XP machine. Cheers, YannDaniel Gilbert [EMAIL PROTECTED] a écrit : Yann,There are some utilities you can purchase that will alert you when anobject is deleted, added, modified...Dan Original Message Subject: [ActiveDir] Knowing when users were deleted. From: Yann <[EMAIL PROTECTED]> Date: Thu, October 13, 2005 11:56 pm To: ActiveDir@mail.activedir.org 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 le ici ! List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Another possibility is the pure scripting way ... and leverage WMI with two event WQL queries: 1/ Select * From __InstanceDeletionEvent Within 60 Where TargetInstance ISA "ds_user" 2/ Select * From __InstanceCreationEvent Where TargetInstance ISA "Win32_NTLogEvent"And TargetInstance.Logfile = "Audit" You can use a logic similar to Sample 3.54 - GroupMonitor.wsf (at http://www.lissware.net, volume 2) but just need to adapt it to users. The same reasoning can be used to monitor FSMO role changes (Sample 3.55 and Sample 3.56 - FSMOMonitor.wsf). These two scripts send an email containing info about the modified object. Tweak them to meet your requirements with the WQL queries 1/ and 2/. You can download the script freely from my site. Enable object access auditing and you can eventually run the script as a Windows Service (yes) on the DC.Then you are all set! You can watch the web cast at http://go.microsoft.com/fwlink/?LinkId=39643where I explain how to run scripts as Windows service with the right security context. HTH. /Alain From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, October 14, 2005 8:18 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Hi Freddy, The information you gave rocks ! Idid not thinkusing the Last modified date attributeand query it with the magic joe's tool : - "adfind -default -showdel -f isdeleted=TRUE" It saves my job ! :) The security audit isnow configured and on. Thanks for your help. YannFreddy HARTONO [EMAIL PROTECTED] a écrit : 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici ! Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Eventtriggers tool uses WMI WQL query as described in my previous mail referring to the WMI scripting technique. Nothing different except that you don't have to deal with a script ... but if you have a script you master the logic better. /Alain From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, October 14, 2005 8:29 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. true. I was looking rather for free tools, and i found the free eventriggers tool form the 2k3 rktools that did the job. It alerts you in real time for a specific eventID. You can telleventriggers to do a particular actionsuch as using dumpel.exe to dump the 630 id (frecnh specific id i presume)that corresponds to a deleted object action. Notice that eventriggers.exe only works on w2k3/XP machine. Cheers, YannDaniel Gilbert [EMAIL PROTECTED] a écrit : Yann,There are some utilities you can purchase that will alert you when anobject is deleted, added, modified...Dan Original Message Subject: [ActiveDir] Knowing when users were deleted. From: Yann <[EMAIL PROTECTED]> Date: Thu, October 13, 2005 11:56 pm To: ActiveDir@mail.activedir.org 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 le ici ! List info : http://www.activedir.org/List.aspxList FAQ : http://www.activedir.org/ListFAQ.aspxList archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Thanks Alain, I will look throught your link right now. Cheers, YannAlain Lissoir [EMAIL PROTECTED] a écrit : Another possibility is the pure scripting way ... and leverage WMI with two event WQL queries: 1/ Select * From __InstanceDeletionEvent Within 60 Where TargetInstance ISA "ds_user" 2/ Select * From __InstanceCreationEvent Where TargetInstance ISA "Win32_NTLogEvent"And TargetInstance.Logfile = "Audit" You can use a logic similar to Sample 3.54 - GroupMonitor.wsf (at http://www.lissware.net, volume 2) but just need to adapt it to users. The same reasoning can be used to monitor FSMO role changes (Sample 3.55 and Sample 3.56 - FSMOMonitor.wsf). These two scripts send an email containing info about the modified object. Tweak them to meet your requirements with the WQL queries 1/ and 2/. You can download the script freely from my site. Enable object access auditing and you can eventually run the script as a Windows Service (yes) on the DC.Then you are all set! You can watch the web cast at http://go.microsoft.com/fwlink/?LinkId=39643where I explain how to run scripts as Windows service with the right security context. HTH. /Alain From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, October 14, 2005 8:18 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Hi Freddy, The information you gave rocks ! Idid not thinkusing the Last modified date attributeand query it with the magic joe's tool : - "adfind -default -showdel -f isdeleted=TRUE" It saves my job ! :) The security audit isnow configured and on. Thanks for your help. YannFreddy HARTONO [EMAIL PROTECTED] a écrit : 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici ! Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez le ici ! Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger Téléchargez le ici !
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.messenger 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/
RE: [ActiveDir] Knowing when users were deleted.
Is that a yes you'll add it? Or no, ..and no bananas for you. answer? Al -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.mes 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
RE: [ActiveDir] Knowing when users were deleted.
Well, first you should _never_ ever view anything _I_ am musing as a possible feature from the product group, I muse ALOT of stuff. PMs will be feature groups spokespeople, I am a dev. This feature (in various forms) has been under consideration before, specicfically Win2k, Win2k3, and Longhorn timeframes. Secondarily, features for any company, is always an optimization question of profit opportunity of feature A vs. feature B vs. cost vs. available resources ... would you give up the planned Longhorn RODC features for something like this? And finally ... you've dealt with the product group before ... they tell us (devs) the first time we goto a conference never promise the customer anything, as we are only supposed to set expectations in customers that will be delievered on ... IF you really want a commitment on adding it... how about this, I can commit to delivering my first blog post before giving you user modification tracking in metadata. ... have I now doomed the feature to never show up? So you asked was that a yes or no in that previous post ... I'd view this as nothing less than and nothing more than ... msft has smart people who think about this stuff ... and in that spirit, if it were done, you probably don't need to worry about DIT bloat (I'm much too smart to let that happen, frankly you insult me ;). Cheers, BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Fri, 14 Oct 2005, Al Mulnick wrote: Is that a yes you'll add it? Or no, ..and no bananas for you. answer? Al -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
RE: [ActiveDir] Knowing when users were deleted.
P.S. - You can't really insult me ... P.P.S - and if we were smart, we would've compressed the metadata from the get go ;) and we'd be trying to figure out how to stuff the SID in the metadata w/o bloating the DIT by 10% ... and instead we'd have to be really cunning (cunning is smarter than smart) to make it all work out, P.P.P.S. - or do survey's to see if the increase in DIT size is worth the feature to you guys (which is an interesting question in itself, just to see what people are willing to pay. ;) P.P.P.P.S. - Instead we're lucky. The line between lucky and cunning is very narrow. OK, I'm done. On Fri, 14 Oct 2005, Brett Shirley wrote: Well, first you should _never_ ever view anything _I_ am musing as a possible feature from the product group, I muse ALOT of stuff. PMs will be feature groups spokespeople, I am a dev. This feature (in various forms) has been under consideration before, specicfically Win2k, Win2k3, and Longhorn timeframes. Secondarily, features for any company, is always an optimization question of profit opportunity of feature A vs. feature B vs. cost vs. available resources ... would you give up the planned Longhorn RODC features for something like this? And finally ... you've dealt with the product group before ... they tell us (devs) the first time we goto a conference never promise the customer anything, as we are only supposed to set expectations in customers that will be delievered on ... IF you really want a commitment on adding it... how about this, I can commit to delivering my first blog post before giving you user modification tracking in metadata. ... have I now doomed the feature to never show up? So you asked was that a yes or no in that previous post ... I'd view this as nothing less than and nothing more than ... msft has smart people who think about this stuff ... and in that spirit, if it were done, you probably don't need to worry about DIT bloat (I'm much too smart to let that happen, frankly you insult me ;). Cheers, BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Fri, 14 Oct 2005, Al Mulnick wrote: Is that a yes you'll add it? Or no, ..and no bananas for you. answer? Al -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
RE: [ActiveDir] Knowing when users were deleted.
would you give up the planned Longhorn RODC features for something like this? I'd happily give up RODC in favor of this. But I appreciate the honest answer and wasn't looking for a commitment. I'll be more careful to word things more appropriately in the future and to eat my vegetables at every meal. I'd be very happy to see this as an option with some growth parameters that are documented (if you do x, expect this amount of storage per item increase over not doing it) sort of documentation. Now if only I could find that microsoft wish email address to send such a request to Al P.S. I can't insult you? Really? If I do, will you blog about it in your second blog post? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Friday, October 14, 2005 12:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. P.S. - You can't really insult me ... P.P.S - and if we were smart, we would've compressed the metadata from the get go ;) and we'd be trying to figure out how to stuff the SID in the metadata w/o bloating the DIT by 10% ... and instead we'd have to be really cunning (cunning is smarter than smart) to make it all work out, P.P.P.S. - or do survey's to see if the increase in DIT size is worth the feature to you guys (which is an interesting question in itself, just to see what people are willing to pay. ;) P.P.P.P.S. - Instead we're lucky. The line between lucky and cunning is very narrow. OK, I'm done. On Fri, 14 Oct 2005, Brett Shirley wrote: Well, first you should _never_ ever view anything _I_ am musing as a possible feature from the product group, I muse ALOT of stuff. PMs will be feature groups spokespeople, I am a dev. This feature (in various forms) has been under consideration before, specicfically Win2k, Win2k3, and Longhorn timeframes. Secondarily, features for any company, is always an optimization question of profit opportunity of feature A vs. feature B vs. cost vs. available resources ... would you give up the planned Longhorn RODC features for something like this? And finally ... you've dealt with the product group before ... they tell us (devs) the first time we goto a conference never promise the customer anything, as we are only supposed to set expectations in customers that will be delievered on ... IF you really want a commitment on adding it... how about this, I can commit to delivering my first blog post before giving you user modification tracking in metadata. ... have I now doomed the feature to never show up? So you asked was that a yes or no in that previous post ... I'd view this as nothing less than and nothing more than ... msft has smart people who think about this stuff ... and in that spirit, if it were done, you probably don't need to worry about DIT bloat (I'm much too smart to let that happen, frankly you insult me ;). Cheers, BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Fri, 14 Oct 2005, Al Mulnick wrote: Is that a yes you'll add it? Or no, ..and no bananas for you. answer? Al -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
RE: [ActiveDir] Knowing when users were deleted.
Now if only I could find that microsoft wish email address to send such a request to Try http://www.windowsserverfeedback.com/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick Sent: Friday, October 14, 2005 9:48 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. would you give up the planned Longhorn RODC features for something like this? I'd happily give up RODC in favor of this. But I appreciate the honest answer and wasn't looking for a commitment. I'll be more careful to word things more appropriately in the future and to eat my vegetables at every meal. I'd be very happy to see this as an option with some growth parameters that are documented (if you do x, expect this amount of storage per item increase over not doing it) sort of documentation. Now if only I could find that microsoft wish email address to send such a request to Al P.S. I can't insult you? Really? If I do, will you blog about it in your second blog post? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Friday, October 14, 2005 12:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. P.S. - You can't really insult me ... P.P.S - and if we were smart, we would've compressed the metadata from the get go ;) and we'd be trying to figure out how to stuff the SID in the metadata w/o bloating the DIT by 10% ... and instead we'd have to be really cunning (cunning is smarter than smart) to make it all work out, P.P.P.S. - or do survey's to see if the increase in DIT size is worth the feature to you guys (which is an interesting question in itself, just to see what people are willing to pay. ;) P.P.P.P.S. - Instead we're lucky. The line between lucky and cunning is very narrow. OK, I'm done. On Fri, 14 Oct 2005, Brett Shirley wrote: Well, first you should _never_ ever view anything _I_ am musing as a possible feature from the product group, I muse ALOT of stuff. PMs will be feature groups spokespeople, I am a dev. This feature (in various forms) has been under consideration before, specicfically Win2k, Win2k3, and Longhorn timeframes. Secondarily, features for any company, is always an optimization question of profit opportunity of feature A vs. feature B vs. cost vs. available resources ... would you give up the planned Longhorn RODC features for something like this? And finally ... you've dealt with the product group before ... they tell us (devs) the first time we goto a conference never promise the customer anything, as we are only supposed to set expectations in customers that will be delievered on ... IF you really want a commitment on adding it... how about this, I can commit to delivering my first blog post before giving you user modification tracking in metadata. ... have I now doomed the feature to never show up? So you asked was that a yes or no in that previous post ... I'd view this as nothing less than and nothing more than ... msft has smart people who think about this stuff ... and in that spirit, if it were done, you probably don't need to worry about DIT bloat (I'm much too smart to let that happen, frankly you insult me ;). Cheers, BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Fri, 14 Oct 2005, Al Mulnick wrote: Is that a yes you'll add it? Or no, ..and no bananas for you. answer? Al -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
RE: [ActiveDir] Knowing when users were deleted.
shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
*raises hand* sid of the last modify-er would be just nice for me. Usually we just want to know which admin is the culprit without analyzing 30gig of DC security log (one day log) 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: joe [mailto:[EMAIL PROTECTED] Sent: Friday, October 14, 2005 11:03 PMTo: ActiveDir@mail.activedir.orgSubject: 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 HARTONOSent: Friday, October 14, 2005 3:18 AMTo: ActiveDir@mail.activedir.orgSubject: 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Ok, now you've done it Gil :-) I guess this is the geek version of "dueling banjos" :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Friday, October 14, 2005 10:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
I get to be Burt Reynolds! :) -g From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Friday, October 14, 2005 10:33 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of "dueling banjos" :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Friday, October 14, 2005 10:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Gentlemen, "WHICH IS CHEAPER?" LOL RH __ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darren Mar-EliaSent: Friday, October 14, 2005 1:33 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of "dueling banjos" :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Friday, October 14, 2005 10:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Was going to ask that myself. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb Sent: Friday, October 14, 2005 2:54 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Gentlemen, WHICH IS CHEAPER? LOL RH __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darren Mar-Elia Sent: Friday, October 14, 2005 1:33 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of dueling banjos :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Friday, October 14, 2005 10:02 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Thursday, October 13, 2005 11: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 le ici !
RE: [ActiveDir] Knowing when users were deleted.
Come on...we're software companies. The price is directly related to the number of days left in a particular quarter. Its called "vendor management" :-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian DesmondSent: Friday, October 14, 2005 12:01 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Was going to ask that myself. Thanks,Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: Friday, October 14, 2005 2:54 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Gentlemen, "WHICH IS CHEAPER?" LOL RH __ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darren Mar-EliaSent: Friday, October 14, 2005 1:33 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of "dueling banjos" :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Friday, October 14, 2005 10:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
Whens the end of the Quest FY? Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Friday, October 14, 2005 3:35 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Come on...we're software companies. The price is directly related to the number of days left in a particular quarter. Its called vendor management :-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Friday, October 14, 2005 12:01 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Was going to ask that myself. Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb Sent: Friday, October 14, 2005 2:54 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Gentlemen, WHICH IS CHEAPER? LOL RH __ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darren Mar-Elia Sent: Friday, October 14, 2005 1:33 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of dueling banjos :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil Kirkpatrick Sent: Friday, October 14, 2005 10:02 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yann Sent: Thursday, October 13, 2005 11: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 le ici !
RE: [ActiveDir] Knowing when users were deleted.
Adfind saved your job? Hmmm that sounds like it is work 25% of your salary for the next year. ;o) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Friday, October 14, 2005 11:18 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Hi Freddy, The information you gave rocks ! Idid not thinkusing the Last modified date attributeand query it with the magic joe's tool : - "adfind -default -showdel -f isdeleted=TRUE" It saves my job ! :) The security audit isnow configured and on. Thanks for your help. YannFreddy HARTONO [EMAIL PROTECTED] a écrit : 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 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici ! Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! MessengerTéléchargez le ici !
RE: [ActiveDir] Knowing when users were deleted.
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.mes senger yahoo.com le ici ! List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org
RE: [ActiveDir] Knowing when users were deleted.
The Oracle sales model. :) There was a link a couple of days ago to Joel on Software describing thisprice model. The correct answer to this is probably closer to "Depends on who you talk to last..." From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Friday, October 14, 2005 3:35 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Come on...we're software companies. The price is directly related to the number of days left in a particular quarter. Its called "vendor management" :-) From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian DesmondSent: Friday, October 14, 2005 12:01 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Was going to ask that myself. Thanks,Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rocky HabeebSent: Friday, October 14, 2005 2:54 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Gentlemen, "WHICH IS CHEAPER?" LOL RH __ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Darren Mar-EliaSent: Friday, October 14, 2005 1:33 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. Ok, now you've done it Gil :-) I guess this is the geek version of "dueling banjos" :-) shameless plug2 Quest's InTrust for Active Directory provides detailed, real-time auditing and alerting of all changes to AD and Group Policy Objects (GPOs), including changes to AD configuration and GPO settings. It also provides all information behind important changes, including who made the change and the before and after values all without requiring native auditing. http://wm.quest.com/products/InTrustAD/ /shamelessplug2 From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gil KirkpatrickSent: Friday, October 14, 2005 10:02 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Knowing when users were deleted. shameless plug NetPro's ChangeAuditor for AD does this without requiring auditing. The change log includes what was changed, before and after values, when, where, and by whom. See http://www.netpro.com/products/changemanager/ /shameless plug From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of YannSent: Thursday, October 13, 2005 11:57 PMTo: ActiveDir@mail.activedir.orgSubject: [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! MessengerTéléchargez le ici !
