| Author | Messages | |
bdesmond
Posts:366
 | | 10/17/2005 2:17 AM |
| 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
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 9:33 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Knowing when users were deleted.
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 servers....heck 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. Ώ]) the bar gets raised until we get to the diminishing
>return. Since we're targeting 80/20 out of the box ΐ] 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.
>
>
>
>Ώ] I'm not saying that the quality has kept up, only that the hardware is
>bigger, faster, stronger and cheaper.
>ΐ] I'm making that up, but it sounds reasonable
>
>
>
>
>-----Original Message-----
>From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
>Simon-Weidner
>Sent: Sunday, October 16, 2005 4:42 PM
>To: ActiveDir@xxxxxxxxxxxxxxxxxx
>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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura
>|E. Hunter
>|Sent: Sunday, October 16, 2005 10:28 PM
>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
>|Subject: Re: [ActiveDir] Knowing when users were deleted.
>|
>|Various thoughts from this thread:
>|
>|Ώ] I agree with Al and PaulΏ] 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.
>|
>|ΐ] Please finish the thought, Brett, I'm sure I'd find it
>|helpful/enlightening/informative even if it's only speaking in
>|hypotheticals.
>|
>|Α] It's Gil and Darren's turn to crack me up today, I guess
>|joe is taking a break.
>|
>|
>|Ώ] *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/
>
>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/ | | | |
| bdesmond
Posts:366
| | 10/17/2005 2:18 AM |
| 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
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 10:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Knowing when users were deleted.
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>> Bradley, CPA
>> aka Ebitz - SBS Rocks [MVP]
>> Sent: Sunday, October 16, 2005 8:33 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> Subject: Re: [ActiveDir] Knowing when users were deleted.
>>
>>
>>
>> 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
>> servers....heck 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. Ώ]) the bar gets raised until we get to the diminishing
>>> return. Since we're targeting 80/20 out of the box ΐ] 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.
>>>
>>>
>>> Ώ] I'm not saying that the quality has kept up, only that the
>>> hardware is
>>> bigger, faster, stronger and cheaper. ΐ] I'm making that up, but it
>>> sounds reasonable
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
>>> Simon-Weidner
>>> Sent: Sunday, October 16, 2005 4:42 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> |[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura |E.
>>> Hunter
>>> |Sent: Sunday, October 16, 2005 10:28 PM
>>> |To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> |Subject: Re: [ActiveDir] Knowing when users were deleted.
>>> |
>>> |Various thoughts from this thread:
>>> |
>>> |Ώ] I agree with Al and PaulΏ] 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.
>>> |
>>> |ΐ] Please finish the thought, Brett, I'm sure I'd find it
>>> |helpful/enlightening/informative even if it's only speaking in
>>> |hypotheticals.
>>> |
>>> |Α] It's Gil and Darren's turn to crack me up today, I guess
>>> |joe is taking a break.
>>> |
>>> |
>>> |Ώ] *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/
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/ | | | |
| rkingsla@xxxx.yyy
| | 10/17/2005 2:25 AM |
| 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.
Rick [msft]
--
Posting is provided "AS IS", and confers no rights or warranties ...
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 8:54 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley,
>CPA aka Ebitz - SBS Rocks [MVP]
>Sent: Sunday, October 16, 2005 8:33 PM
>To: ActiveDir@xxxxxxxxxxxxxxxxxx
>Subject: Re: [ActiveDir] Knowing when users were deleted.
>
>
>
>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 servers....heck 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. Ώ]) the bar gets raised until we get to
>>the diminishing return. Since we're targeting 80/20 out of the box
>>ΐ] 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.
>>
>>
>>
>>Ώ] I'm not saying that the quality has kept up, only that the
>>hardware is bigger, faster, stronger and cheaper.
>>ΐ] I'm making that up, but it sounds reasonable
>>
>>
>>
>>
>>-----Original Message-----
>>From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
>>Simon-Weidner
>>Sent: Sunday, October 16, 2005 4:42 PM
>>To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura E.
>>|Hunter
>>|Sent: Sunday, October 16, 2005 10:28 PM
>>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>|Subject: Re: [ActiveDir] Knowing when users were deleted.
>>|
>>|Various thoughts from this thread:
>>|
>>|Ώ] I agree with Al and PaulΏ] 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.
>>|
>>|ΐ] Please finish the thought, Brett, I'm sure I'd find it
>>|helpful/enlightening/informative even if it's only speaking in
>>|hypotheticals.
>>|
>>|Α] It's Gil and Darren's turn to crack me up today, I guess joe is
>>|taking a break.
>>|
>>|
>>|Ώ] *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/
>>
>>
>>
>>
>>
>
>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/ | | | |
| rkingsla@xxxx.yyy
| | 10/17/2005 2:27 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 9:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Knowing when users were deleted.
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
>> Bradley, CPA aka Ebitz - SBS Rocks [MVP]
>> Sent: Sunday, October 16, 2005 8:33 PM
>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>> Subject: Re: [ActiveDir] Knowing when users were deleted.
>>
>>
>>
>> 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 servers....heck 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. Ώ]) the bar gets raised until we get to the diminishing
>>> return. Since we're targeting 80/20 out of the box ΐ] 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.
>>>
>>>
>>> Ώ] I'm not saying that the quality has kept up, only that the
>>> hardware is
>>> bigger, faster, stronger and cheaper. ΐ] I'm making that up, but it
>>> sounds reasonable
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
>>> Simon-Weidner
>>> Sent: Sunday, October 16, 2005 4:42 PM
>>> To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
>>> |[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura |E.
>>> Hunter
>>> |Sent: Sunday, October 16, 2005 10:28 PM
>>> |To: ActiveDir@xxxxxxxxxxxxxxxxxx
>>> |Subject: Re: [ActiveDir] Knowing when users were deleted.
>>> |
>>> |Various thoughts from this thread:
>>> |
>>> |Ώ] I agree with Al and PaulΏ] 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.
>>> |
>>> |ΐ] Please finish the thought, Brett, I'm sure I'd find it
>>> |helpful/enlightening/informative even if it's only speaking in
>>> |hypotheticals.
>>> |
>>> |Α] It's Gil and Darren's turn to crack me up today, I guess
>>> |joe is taking a break.
>>> |
>>> |
>>> |Ώ] *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/
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/ | | | |
| sbradcpa
Posts:317
| | 10/17/2005 2:50 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 9:02 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Knowing when users were deleted.
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
Bradley, CPA aka Ebitz - SBS Rocks [MVP]
Sent: Sunday, October 16, 2005 8:33 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
Subject: Re: [ActiveDir] Knowing when users were deleted.
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 servers....heck 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. Ώ]) the bar gets raised until we get to the diminishing
return. Since we're targeting 80/20 out of the box ΐ] 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.
Ώ] I'm not saying that the quality has kept up, only that the
hardware is
bigger, faster, stronger and cheaper. ΐ] I'm making that up, but it
sounds reasonable
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-Weidner
Sent: Sunday, October 16, 2005 4:42 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura |E.
Hunter
|Sent: Sunday, October 16, 2005 10:28 PM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|Subject: Re: [ActiveDir] Knowing when users were deleted.
|
|Various thoughts from this thread:
|
|Ώ] I agree with Al and PaulΏ] 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.
|
|ΐ] Please finish the thought, Brett, I'm sure I'd find it
|helpful/enlightening/informative even if it's only speaking in
|hypotheticals.
|
|Α] It's Gil and Darren's turn to crack me up today, I guess
|joe is taking a break.
|
|
|Ώ] *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/
--
Letting your vendors set your risk analysis these days?
http://www.threatcode.com
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/ | | | |
| Ulf@xxxx.yyy
| | 10/17/2005 9:36 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Susan
|Bradley, CPA aka Ebitz - SBS Rocks [MVP]
|Sent: Monday, October 17, 2005 3:33 AM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|Subject: Re: [ActiveDir] Knowing when users were deleted.
|
|
|
|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 servers....heck 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. Ώ]) the bar gets raised until we get to the
|diminishing
|>return. Since we're targeting 80/20 out of the box ΐ] 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.
|>
|>
|>
|>Ώ] I'm not saying that the quality has kept up, only that
|the hardware is
|>bigger, faster, stronger and cheaper.
|>ΐ] I'm making that up, but it sounds reasonable
|>
|>
|>
|>
|>-----Original Message-----
|>From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|>[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
|>Simon-Weidner
|>Sent: Sunday, October 16, 2005 4:42 PM
|>To: ActiveDir@xxxxxxxxxxxxxxxxxx
|>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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura
|>|E. Hunter
|>|Sent: Sunday, October 16, 2005 10:28 PM
|>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|>|Subject: Re: [ActiveDir] Knowing when users were deleted.
|>|
|>|Various thoughts from this thread:
|>|
|>|Ώ] I agree with Al and PaulΏ] 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.
|>|
|>|ΐ] Please finish the thought, Brett, I'm sure I'd find it
|>|helpful/enlightening/informative even if it's only speaking in
|>|hypotheticals.
|>|
|>|Α] It's Gil and Darren's turn to crack me up today, I guess
|>|joe is taking a break.
|>|
|>|
|>|Ώ] *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/
|>
|>
|>
|
|--
|Letting your vendors set your risk analysis these days?
|http://www.threatcode.com
|
|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/ | | | |
| Ulf@xxxx.yyy
| | 10/17/2005 9:42 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
|Sent: Monday, October 17, 2005 3:10 AM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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. Ώ]) the bar gets raised until we get to the
|diminishing return. Since we're targeting 80/20 out of the
|box ΐ] 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.
|
|
|
|Ώ] I'm not saying that the quality has kept up, only that the
|hardware is bigger, faster, stronger and cheaper.
|ΐ] I'm making that up, but it sounds reasonable
|
|
|
|
|-----Original Message-----
|From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
|Simon-Weidner
|Sent: Sunday, October 16, 2005 4:42 PM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
||[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura E.
||Hunter
||Sent: Sunday, October 16, 2005 10:28 PM
||To: ActiveDir@xxxxxxxxxxxxxxxxxx
||Subject: Re: [ActiveDir] Knowing when users were deleted.
||
||Various thoughts from this thread:
||
||Ώ] I agree with Al and PaulΏ] 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.
||
||ΐ] Please finish the thought, Brett, I'm sure I'd find it
||helpful/enlightening/informative even if it's only speaking in
||hypotheticals.
||
||Α] It's Gil and Darren's turn to crack me up today, I guess joe is
||taking a break.
||
||
||Ώ] *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/ | | | |
| bdesmond
Posts:366
| | 10/17/2005 9:55 AM |
| ACS is now integrated into MOM3 which is coming I don't know when.
Thanks,
Brian Desmond
brian@xxxxxxxxxxxxxxxx
c - 312.731.3132
-----Original Message-----
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, October 17, 2005 5:37 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
|Sent: Monday, October 17, 2005 3:10 AM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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. Ώ]) the bar gets raised until we get to the
|diminishing return. Since we're targeting 80/20 out of the
|box ΐ] 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.
|
|
|
|Ώ] I'm not saying that the quality has kept up, only that the
|hardware is bigger, faster, stronger and cheaper.
|ΐ] I'm making that up, but it sounds reasonable
|
|
|
|
|-----Original Message-----
|From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
|Simon-Weidner
|Sent: Sunday, October 16, 2005 4:42 PM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
||[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura E.
||Hunter
||Sent: Sunday, October 16, 2005 10:28 PM
||To: ActiveDir@xxxxxxxxxxxxxxxxxx
||Subject: Re: [ActiveDir] Knowing when users were deleted.
||
||Various thoughts from this thread:
||
||Ώ] I agree with Al and PaulΏ] 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.
||
||ΐ] Please finish the thought, Brett, I'm sure I'd find it
||helpful/enlightening/informative even if it's only speaking in
||hypotheticals.
||
||Α] It's Gil and Darren's turn to crack me up today, I guess joe is
||taking a break.
||
||
||Ώ] *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/ | | | |
| rwf4
Posts:10
| | 10/17/2005 11:21 AM |
| >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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
Simon-Weidner
Sent: Monday, October 17, 2005 2:37 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxx
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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
|Sent: Monday, October 17, 2005 3:10 AM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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. Ώ]) the bar gets raised until we get to the
|diminishing return. Since we're targeting 80/20 out of the
|box ΐ] 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.
|
|
|
|Ώ] I'm not saying that the quality has kept up, only that the
|hardware is bigger, faster, stronger and cheaper.
|ΐ] I'm making that up, but it sounds reasonable
|
|
|
|
|-----Original Message-----
|From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
|Simon-Weidner
|Sent: Sunday, October 16, 2005 4:42 PM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
||[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura E.
||Hunter
||Sent: Sunday, October 16, 2005 10:28 PM
||To: ActiveDir@xxxxxxxxxxxxxxxxxx
||Subject: Re: [ActiveDir] Knowing when users were deleted.
||
||Various thoughts from this thread:
||
||Ώ] I agree with Al and PaulΏ] 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.
||
||ΐ] Please finish the thought, Brett, I'm sure I'd find it
||helpful/enlightening/informative even if it's only speaking in
||hypotheticals.
||
||Α] It's Gil and Darren's turn to crack me up today, I guess joe is
||taking a break.
||
||
||Ώ] *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/ | | | |
| activedirsmaporg
Posts:0
| | 10/18/2005 1:58 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> [mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Tomasz Onyszko
> Sent: Tuesday, October 18, 2005 10:17
> To: ActiveDir@xxxxxxxxxxxxxxxxxx
> 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/ | | | |
| activedirsmaporg
Posts:0
| | 10/18/2005 2:03 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> |[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
> |Sent: Tuesday, October 18, 2005 2:42 AM
> |To: ActiveDir@xxxxxxxxxxxxxxxxxx
> |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"
> |>Reply-To: ActiveDir@xxxxxxxxxxxxxxxxxx
> |>To:
> |>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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> |>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
> |>|Sent: Monday, October 17, 2005 3:10 AM
> |>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
> |>|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.
> |>|Ώ]) the bar gets raised until we get to the diminishing return.
> |>|Since we're targeting 80/20 out of the box ΐ] 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.
> |>|
> |>|
> |>|
> |>|Ώ] I'm not saying that the quality has kept up, only that the
> |>|hardware is bigger, faster, stronger and cheaper.
> |>|ΐ] I'm making that up, but it sounds reasonable
> |>|
> |>|
> |>|
> |>|
> |>|-----Original Message-----
> |>|From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> |>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
> |>|Simon-Weidner
> |>|Sent: Sunday, October 16, 2005 4:42 PM
> |>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
> |>|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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
> |>||[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Laura E.
> |>||Hunter
> |>||Sent: Sunday, October 16, 2005 10:28 PM
> |>||To: ActiveDir@xxxxxxxxxxxxxxxxxx
> |>||Subject: Re: [ActiveDir] Knowing when users were deleted.
> |>||
> |>||Various thoughts from this thread:
> |>||
> |>||Ώ] I agree with Al and PaulΏ] 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.
> |>||
> |>||ΐ] Please finish the thought, Brett, I'm sure I'd find it
> |>||helpful/enlightening/informative even if it's only speaking in
> |>||hypotheticals.
> |>||
> |>||Α] It's Gil and Darren's turn to crack me up today, I guess joe is
> |>||taking a break.
> |>||
> |>||
> |>||Ώ] *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/ | | | |
| Ulf@xxxx.yyy
| | 10/18/2005 5:37 AM |
| 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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Brett Shirley
|Sent: Tuesday, October 18, 2005 4:02 PM
|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|> |[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Al Mulnick
|> |Sent: Tuesday, October 18, 2005 2:42 AM
|> |To: ActiveDir@xxxxxxxxxxxxxxxxxx
|> |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"
|> |>Reply-To: ActiveDir@xxxxxxxxxxxxxxxxxx
|> |>To:
|> |>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: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|> |>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of
|Al Mulnick
|> |>|Sent: Monday, October 17, 2005 3:10 AM
|> |>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|> |>|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.
|> |>|Ώ]) the bar gets raised until we get to the diminishing return.
|> |>|Since we're targeting 80/20 out of the box ΐ] 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.
|> |>|
|> |>|
|> |>|
|> |>|Ώ] I'm not saying that the quality has kept up, only that the
|> |>|hardware is bigger, faster, stronger and cheaper.
|> |>|ΐ] I'm making that up, but it sounds reasonable
|> |>|
|> |>|
|> |>|
|> |>|
|> |>|-----Original Message-----
|> |>|From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx
|> |>|[mailto:ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Ulf B.
|> |>|Simon-Weidner
|> |>|Sent: Sunday, October 16, 2005 4:42 PM
|> |>|To: ActiveDir@xxxxxxxxxxxxxxxxxx
|> |>|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 |
|
|