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: [email protected] > |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: [email protected] > |>To: <[email protected]> > |>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: [email protected] > |>|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: [email protected] > |>|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: [email protected] > |>||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/ > |>| > |> > |> > |>List info : http://www.activedir.org/List.aspx > |>List FAQ : http://www.activedir.org/ListFAQ.aspx > |>List archive: > |>http://www.mail-archive.com/activedir%40mail.activedir.org/ > | > | > |List info : http://www.activedir.org/List.aspx > |List FAQ : http://www.activedir.org/ListFAQ.aspx > |List archive: > |http://www.mail-archive.com/activedir%40mail.activedir.org/ > | > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
