| Author | Messages | |
ganeshen
Posts:0
 | | 10/10/2007 7:52 AM |
| .hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
Hello All,I came across ActiveDir.Org and have found it to be quite comprehensive on the subject.I have a concern which I wish to discuss here and seek your suggestions.I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes (mostly Windows XP, 2000). Initially, all members of the admin team were domain admins. All have had Domain Admin Account access. This was not a good security practice and made it difficult to keep a track of actions taken on the AD and the DC resources.To control this, the domain admin account password was reset and access given only to limited team members. To enable other team members perform the daily administrative tasks, I used Delegation of Control to define and assign specific permissions that they needed. This has controlled the extent of access and changes on AD.However, the other portion of the team still has domain admin account access as well as domain admin rights. This is required for administration and monitoring of DC/AD resources and other critical servers. In order to control & monitor access on AD by this group, they have been asked to log on to DC with their own domain id to perform any task. Apart from this, I wish to keep a track of changes on the DC and AD. Although the auditing is enabled on the AD, the logs are plenty and hence tracking of events becomes difficult.I wish to use Auditing on AD for the following events:1. To know and keep track of users (in this case the other group with domain admin access) who log on to the DCs either locally or through RDP, with timestamp and source IP (if possible).2. To know and keep track of users who make changes in AD objects (creating/modifying/deleting user accounts, exchange accounts, creating/modifying/deleting OUs/security groups, creating/modifying/deleting GPOs and tracking the specific policy attribute(s) that were altered, etc.)3. To keep a track of only specific set of users.If I missed out any information, please feel free to let me know.Your suggestions would be helpful.Thanks,GaneshenBoo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now! | | | |
| amulnick
Posts:143
| | 10/10/2007 1:07 AM |
| Of those that you mention, I only see the backups as an item that need to be done while logged on locally. I see none of those that require domain admin rights. Rather, lower level rights can be used to achieve the same administration and the users can load the MMC's locally on their machines vs. putting them on the servers.
The problem with the request is that you want to audit three things:
1) logons to the domain controller hopefully inclusive of source IP
2) changes made to dg's, security groups, users, etc. in the AD
3) only watching a specific set of users
Logons to the domain controller can be logged. But as you've seen it is difficult to tell from the rdp session and logon from a different ip address. That, and the amount of data is intense. There are some third party log collection utilities, MOM was mentioned, or you could roll your own solution to gather that information. There's also reskit utilities. But honestly, you'd be better off removing that right for all but domain admins any way. Only allow domain admins the log on locally right and remove everyone you can from domain admin. Just give them the rights they need and the tools they need (adminpak and exchange admin tools from the sounds of it) and do away with local logons to DC's.
The backups task is a little more difficult. Do your domain controllers act as file servers in the remote sites? Is that why they make bacukps of each domain controller?
Al
On 10/10/07, Ganeshen - wrote:
I agree, Al. This group has domain admin access and can furnish tasks through Remote connectivity (RDP). However, we use a third-party tool as well to connect to the machines and I think it is considered a local log-on. This needs to be tracked hence.
The following tasks are on concern:- administering AD users/groups/group memberships- administering group policies- creating shares and providing access on shares.- performing backups- administering exchange ids/distribution groups/etc.
Although there may be multiple robust administrative models for the same scenario, I must admit it would not be feasible to bring about a drastic change at this point in time, though it can be gradually implemented.
All I require is to keep a track on the below mentioned 3 points. I hope I am clear on the requirements now. I am open to suggestions, so please feel free to do so.Thanks,Ganeshen
Date: Wed, 10 Oct 2007 08:50:37 -0400From: amulnick@gmail.comTo:
ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Reg: Active Directory Auditing.
The first suggestion that comes to mind is to ask a question:
why do the users have to log on locally to the domain controllers? What tasks are they required to perform that they cannot from a remote machine and with lower privileges?
After that, I would suggest a different administrative model. There are very few reasons I can think of that would necessitate that a user logon to the domain controller only to perform a task.
If you don't you won't really be able to audit the actions.Many of the audit events will just say "domain admins" and you won't really be able to tell which domain admin it was.
Al
On 10/10/07, Ganeshen - wrote:
Hello All,I came across ActiveDir.Org and have found it to be quite comprehensive on the subject.I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes (mostly Windows XP, 2000). Initially, all members of the admin team were domain admins. All have had Domain Admin Account access. This was not a good security practice and made it difficult to keep a track of actions taken on the AD and the DC resources.
To control this, the domain admin account password was reset and access given only to limited team members. To enable other team members perform the daily administrative tasks, I used Delegation of Control to define and assign specific permissions that they needed. This has controlled the extent of access and changes on AD.
However, the other portion of the team still has domain admin account access as well as domain admin rights. This is required for administration and monitoring of DC/AD resources and other critical servers. In order to control & monitor access on AD by this group, they have been asked to log on to DC with their own domain id to perform any task. Apart from this, I wish to keep a track of changes on the DC and AD. Although the auditing is enabled on the AD, the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:1. To know and keep track of users (in this case the other group with domain admin access) who log on to the DCs either locally or through RDP, with timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects (creating/modifying/deleting user accounts, exchange accounts, creating/modifying/deleting OUs/security groups, creating/modifying/deleting GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.If I missed out any information, please feel free to let me know.Your suggestions would be helpful.Thanks,Ganeshen
Boo!Scare away worms, viruses and so much more! Try Windows Live OneCare!
Try now!
Help yourself to FREE treats served up daily at the Messenger Café.
Stop by today! | | | |
| amulnick
Posts:143
| | 10/10/2007 8:50 AM |
| The first suggestion that comes to mind is to ask a question:
why do the users have to log on locally to the domain controllers? What tasks are they required to perform that they cannot from a remote machine and with lower privileges?
After that, I would suggest a different administrative model. There are very few reasons I can think of that would necessitate that a user logon to the domain controller only to perform a task.
If you don't you won't really be able to audit the actions.Many of the audit events will just say "domain admins" and you won't really be able to tell which domain admin it was.
Al
On 10/10/07, Ganeshen - wrote:
Hello All,I came across ActiveDir.Org and have found it to be quite comprehensive on the subject.I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes (mostly Windows XP, 2000). Initially, all members of the admin team were domain admins. All have had Domain Admin Account access. This was not a good security practice and made it difficult to keep a track of actions taken on the AD and the DC resources.
To control this, the domain admin account password was reset and access given only to limited team members. To enable other team members perform the daily administrative tasks, I used Delegation of Control to define and assign specific permissions that they needed. This has controlled the extent of access and changes on AD.
However, the other portion of the team still has domain admin account access as well as domain admin rights. This is required for administration and monitoring of DC/AD resources and other critical servers. In order to control & monitor access on AD by this group, they have been asked to log on to DC with their own domain id to perform any task. Apart from this, I wish to keep a track of changes on the DC and AD. Although the auditing is enabled on the AD, the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:1. To know and keep track of users (in this case the other group with domain admin access) who log on to the DCs either locally or through RDP, with timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects (creating/modifying/deleting user accounts, exchange accounts, creating/modifying/deleting OUs/security groups, creating/modifying/deleting GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.If I missed out any information, please feel free to let me know.Your suggestions would be helpful.Thanks,Ganeshen
Boo!Scare away worms, viruses and so much more! Try Windows Live OneCare!
Try now! | | | |
| austin
Posts:33
| | 10/10/2007 9:40 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Hi Ganeshen,
“Comprehensive on the subject” is putting it mildly
(wait till JR wakes up and reads this! J )
Anyone who has console access or physical access to your DC can
cause you harm.
Anyone who has administrative privileges on your DC can cause
you harm.
You need to limit DA rights to only a few known individuals who
know AD if you want a secure environment. Equally, or more important, are members
of EA group. These need to be well controlled.
Delegate other rights as required. Even the rights required to
monitor things like replication can be delegated if you have specialized teams.
This is best supported by an AD administrative policy which is
signed off by management.
You can audit almost anything you want to audit in AD. The work
involved always, is sifting the noise that results from the data generated.
With the requirements you have, it might be quicker and easier
to get a COTS AD audit tool than it would be rolling your own.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ganeshen -
Sent: 10 October 2007 12:52
To: activedir@mail.activedir.org
Subject: [ActiveDir] Reg: Active Directory Auditing.
Hello
All,
I came across ActiveDir.Org and have found it to be quite comprehensive on the
subject.
I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes
(mostly Windows XP, 2000). Initially, all members of the admin team were domain
admins. All have had Domain Admin Account access. This was not a good security
practice and made it difficult to keep a track of actions taken on the AD and
the DC resources.
To control this, the domain admin account password was reset and access given
only to limited team members. To enable other team members perform the daily
administrative tasks, I used Delegation of Control to define and assign
specific permissions that they needed. This has controlled the extent of access
and changes on AD.
However, the other portion of the team still has domain admin account access as
well as domain admin rights. This is required for administration and monitoring
of DC/AD resources and other critical servers. In order to control & monitor
access on AD by this group, they have been asked to log on to DC with their own
domain id to perform any task. Apart from this, I wish to keep a track of
changes on the DC and AD. Although the auditing is enabled on the AD, the logs
are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:
1. To know and keep track of users (in this case the other group with domain
admin access) who log on to the DCs either locally or through RDP, with
timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects
(creating/modifying/deleting user accounts, exchange accounts,
creating/modifying/deleting OUs/security groups, creating/modifying/deleting
GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.
If I missed out any information, please feel free to let me know.
Your suggestions would be helpful.
Thanks,
Ganeshen
Boo!Scare
away worms, viruses and so much more! Try Windows Live OneCare! Try now!
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
| ganeshen
Posts:0
| | 10/10/2007 10:24 AM |
| .hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
I agree, Al. This group has domain admin access and can furnish tasks through Remote connectivity (RDP). However, we use a third-party tool as well to connect to the machines and I think it is considered a local log-on. This needs to be tracked hence. The following tasks are on concern:- administering AD users/groups/group memberships- administering group policies- creating shares and providing access on shares.- performing backups- administering exchange ids/distribution groups/etc.Although there may be multiple robust administrative models for the same scenario, I must admit it would not be feasible to bring about a drastic change at this point in time, though it can be gradually implemented.All I require is to keep a track on the below mentioned 3 points. I hope I am clear on the requirements now. I am open to suggestions, so please feel free to do so.Thanks,GaneshenDate: Wed, 10 Oct 2007 08:50:37 -0400From: amulnick@gmail.comTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Reg: Active Directory Auditing.The first suggestion that comes to mind is to ask a question:
why do the users have to log on locally to the domain controllers? What tasks are they required to perform that they cannot from a remote machine and with lower privileges?
After that, I would suggest a different administrative model. There are very few reasons I can think of that would necessitate that a user logon to the domain controller only to perform a task.
If you don't you won't really be able to audit the actions.Many of the audit events will just say "domain admins" and you won't really be able to tell which domain admin it was.
Al
On 10/10/07, Ganeshen - wrote:
Hello All,I came across ActiveDir.Org and have found it to be quite comprehensive on the subject.I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes (mostly Windows XP, 2000). Initially, all members of the admin team were domain admins. All have had Domain Admin Account access. This was not a good security practice and made it difficult to keep a track of actions taken on the AD and the DC resources.
To control this, the domain admin account password was reset and access given only to limited team members. To enable other team members perform the daily administrative tasks, I used Delegation of Control to define and assign specific permissions that they needed. This has controlled the extent of access and changes on AD.
However, the other portion of the team still has domain admin account access as well as domain admin rights. This is required for administration and monitoring of DC/AD resources and other critical servers. In order to control & monitor access on AD by this group, they have been asked to log on to DC with their own domain id to perform any task. Apart from this, I wish to keep a track of changes on the DC and AD. Although the auditing is enabled on the AD, the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:1. To know and keep track of users (in this case the other group with domain admin access) who log on to the DCs either locally or through RDP, with timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects (creating/modifying/deleting user accounts, exchange accounts, creating/modifying/deleting OUs/security groups, creating/modifying/deleting GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.If I missed out any information, please feel free to let me know.Your suggestions would be helpful.Thanks,Ganeshen
Boo!Scare away worms, viruses and so much more! Try Windows Live OneCare!
Try now!
Peek-a-boo FREE Tricks & Treats for You! Get 'em! | | | |
| ganeshen
Posts:0
| | 10/10/2007 10:24 AM |
| .hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
I agree, Al. This group has domain admin access and can furnish tasks through Remote connectivity (RDP). However, we use a third-party tool as well to connect to the machines and I think it is considered a local log-on. This needs to be tracked hence. The following tasks are on concern:- administering AD users/groups/group memberships- administering group policies- creating shares and providing access on shares.- performing backups- administering exchange ids/distribution groups/etc.Although there may be multiple robust administrative models for the same scenario, I must admit it would not be feasible to bring about a drastic change at this point in time, though it can be gradually implemented.All I require is to keep a track on the below mentioned 3 points. I hope I am clear on the requirements now. I am open to suggestions, so please feel free to do so.Thanks,GaneshenDate: Wed, 10 Oct 2007 08:50:37 -0400From: amulnick@gmail.comTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Reg: Active Directory Auditing.The first suggestion that comes to mind is to ask a question:
why do the users have to log on locally to the domain controllers? What tasks are they required to perform that they cannot from a remote machine and with lower privileges?
After that, I would suggest a different administrative model. There are very few reasons I can think of that would necessitate that a user logon to the domain controller only to perform a task.
If you don't you won't really be able to audit the actions.Many of the audit events will just say "domain admins" and you won't really be able to tell which domain admin it was.
Al
On 10/10/07, Ganeshen - wrote:
Hello All,I came across ActiveDir.Org and have found it to be quite comprehensive on the subject.I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes (mostly Windows XP, 2000). Initially, all members of the admin team were domain admins. All have had Domain Admin Account access. This was not a good security practice and made it difficult to keep a track of actions taken on the AD and the DC resources.
To control this, the domain admin account password was reset and access given only to limited team members. To enable other team members perform the daily administrative tasks, I used Delegation of Control to define and assign specific permissions that they needed. This has controlled the extent of access and changes on AD.
However, the other portion of the team still has domain admin account access as well as domain admin rights. This is required for administration and monitoring of DC/AD resources and other critical servers. In order to control & monitor access on AD by this group, they have been asked to log on to DC with their own domain id to perform any task. Apart from this, I wish to keep a track of changes on the DC and AD. Although the auditing is enabled on the AD, the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:1. To know and keep track of users (in this case the other group with domain admin access) who log on to the DCs either locally or through RDP, with timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects (creating/modifying/deleting user accounts, exchange accounts, creating/modifying/deleting OUs/security groups, creating/modifying/deleting GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.If I missed out any information, please feel free to let me know.Your suggestions would be helpful.Thanks,Ganeshen
Boo!Scare away worms, viruses and so much more! Try Windows Live OneCare!
Try now!
Help yourself to FREE treats served up daily at the Messenger Café. Stop by today! | | | |
| ganeshen
Posts:0
| | 10/10/2007 10:44 AM |
| .hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
Hi Austin,This is the first instance when I navigated through the site. So comprehensive seemed to be right word. I am sure JR will introduce me to a new vocab on this. :)It is true that access needs to be controlled strictly or else unwanted issues crop up. But ours is not an enterprise-level infrastructure. Although we are growing, but I see it's going to take some time when we get specialized team controlling individual aspects.Although commercial audit tools are available and provide good reporting, currently we only need to enable monitoring using the in-built AD features.Do let me know if your suggestions to initiate this.Thanks,GaneshenSubject: RE: [ActiveDir] Reg: Active Directory Auditing.Date: Wed, 10 Oct 2007 14:40:43 +0100From: austin@osuide.comTo: ActiveDir@mail.activedir.org
.ExternalClass .EC_shape
{;}
.ExternalClass EC_p.MsoNormal, .ExternalClass EC_li.MsoNormal, .ExternalClass EC_div.MsoNormal
{margin-bottom:.0001pt;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass a:link, .ExternalClass EC_span.MsoHyperlink
{color:blue;text-decoration:underline;}
.ExternalClass a:visited, .ExternalClass EC_span.MsoHyperlinkFollowed
{color:purple;text-decoration:underline;}
.ExternalClass p
{margin-right:0cm;margin-left:0cm;font-size:12.0pt;font-family:'Times New Roman','serif';}
.ExternalClass EC_span.EmailStyle18
{font-family:'Calibri','sans-serif';color:#1F497D;}
.ExternalClass .EC_MsoChpDefault
{font-size:10.0pt;}
@page Section1
{size:612.0pt 792.0pt;}
.ExternalClass EC_div.Section1
{page:Section1;}
Hi Ganeshen,
“Comprehensive on the subject” is putting it mildly
(wait till JR wakes up and reads this! J )
Anyone who has console access or physical access to your DC can
cause you harm.
Anyone who has administrative privileges on your DC can cause
you harm.
You need to limit DA rights to only a few known individuals who
know AD if you want a secure environment. Equally, or more important, are members
of EA group. These need to be well controlled.
Delegate other rights as required. Even the rights required to
monitor things like replication can be delegated if you have specialized teams.
This is best supported by an AD administrative policy which is
signed off by management.
You can audit almost anything you want to audit in AD. The work
involved always, is sifting the noise that results from the data generated.
With the requirements you have, it might be quicker and easier
to get a COTS AD audit tool than it would be rolling your own.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ganeshen -
Sent: 10 October 2007 12:52
To: activedir@mail.activedir.org
Subject: [ActiveDir] Reg: Active Directory Auditing.
Hello
All,
I came across ActiveDir.Org and have found it to be quite comprehensive on the
subject.
I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes
(mostly Windows XP, 2000). Initially, all members of the admin team were domain
admins. All have had Domain Admin Account access. This was not a good security
practice and made it difficult to keep a track of actions taken on the AD and
the DC resources.
To control this, the domain admin account password was reset and access given
only to limited team members. To enable other team members perform the daily
administrative tasks, I used Delegation of Control to define and assign
specific permissions that they needed. This has controlled the extent of access
and changes on AD.
However, the other portion of the team still has domain admin account access as
well as domain admin rights. This is required for administration and monitoring
of DC/AD resources and other critical servers. In order to control & monitor
access on AD by this group, they have been asked to log on to DC with their own
domain id to perform any task. Apart from this, I wish to keep a track of
changes on the DC and AD. Although the auditing is enabled on the AD, the logs
are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:
1. To know and keep track of users (in this case the other group with domain
admin access) who log on to the DCs either locally or through RDP, with
timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects
(creating/modifying/deleting user accounts, exchange accounts,
creating/modifying/deleting OUs/security groups, creating/modifying/deleting
GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.
If I missed out any information, please feel free to let me know.
Your suggestions would be helpful.
Thanks,
Ganeshen
Boo!Scare
away worms, viruses and so much more! Try Windows Live OneCare! Try now!
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version.
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try now! | | | |
| h2bear@msn.com
Posts:51
| | 10/10/2007 10:55 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
shape {behavior:url(#default#VML);}
Hi Ganeshen
First I will re-iterate the need to control
access to your domain admins groups. Look to use GPO to set and control this
access. Second in regards to your SELM auditing, you can look into tools such
as MOM to add in watching this and sending alerts to the proper team. For your
group administration, you can look into developing your own in house tools to
log the changes and prevent people from using native rights or look into tools out
there from a 3rd party vendor (there are several). Most backup tools
have a way to be integrated into MOM. Lastly if you have not already read it
there is a good MS article on delegation of AD rights and security regarding
this: http://www.microsoft.com/downloads/details.aspx?familyid=631747a3-79e1-48fa-9730-dae7c0a1d6d3
and
http://technet.microsoft.com/en-us/library/Bb727032.aspx
Hugh
From:
ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ganeshen -
Sent: Wednesday, October 10, 2007
7:24 AM
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Reg:
Active Directory Auditing.
I agree, Al. This group has domain admin access and can
furnish tasks through Remote connectivity (RDP). However, we use a third-party
tool as well to connect to the machines and I think it is considered a local
log-on. This needs to be tracked hence.
The following tasks are on concern:
- administering AD users/groups/group memberships
- administering group policies
- creating shares and providing access on shares.
- performing backups
- administering exchange ids/distribution groups/etc.
Although there may be multiple robust administrative models for the same
scenario, I must admit it would not be feasible to bring about a drastic change
at this point in time, though it can be gradually implemented.
All I require is to keep a track on the below mentioned 3 points. I hope I am
clear on the requirements now. I am open to suggestions, so please feel free to
do so.
Thanks,
Ganeshen
Date: Wed, 10 Oct 2007 08:50:37
-0400
From: amulnick@gmail.com
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Reg: Active Directory Auditing.
The first suggestion that comes to mind is to ask a
question:
why do the users have to log on locally to the domain
controllers? What tasks are they required to perform that they cannot
from a remote machine and with lower privileges?
After that, I would suggest a different administrative
model. There are very few reasons I can think of that would necessitate
that a user logon to the domain controller only to perform a task.
If you don't you won't really be able to audit the
actions.Many of the audit events will just say "domain admins"
and you won't really be able to tell which domain admin it was.
Al
On 10/10/07, Ganeshen - wrote:
Hello All,
I came across ActiveDir.Org and have found it to be quite comprehensive on the
subject.
I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes
(mostly Windows XP, 2000). Initially, all members of the admin team were domain
admins. All have had Domain Admin Account access. This was not a good security
practice and made it difficult to keep a track of actions taken on the AD and
the DC resources.
To control this, the domain admin account password was reset and access given
only to limited team members. To enable other team members perform the daily
administrative tasks, I used Delegation of Control to define and assign specific
permissions that they needed. This has controlled the extent of access and
changes on AD.
However, the other portion of the team still has domain admin account access as
well as domain admin rights. This is required for administration and monitoring
of DC/AD resources and other critical servers. In order to control &
monitor access on AD by this group, they have been asked to log on to DC with
their own domain id to perform any task. Apart from this, I wish to keep a
track of changes on the DC and AD. Although the auditing is enabled on the AD,
the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:
1. To know and keep track of users (in this case the other group with domain
admin access) who log on to the DCs either locally or through RDP, with
timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects
(creating/modifying/deleting user accounts, exchange accounts,
creating/modifying/deleting OUs/security groups, creating/modifying/deleting
GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.
If I missed out any information, please feel free to let me know.
Your suggestions would be helpful.
Thanks,
Ganeshen
Boo!Scare away worms, viruses and so much more! Try
Windows Live OneCare! Try now!
Help yourself to FREE treats served up daily at the
Messenger Café. Stop by today! | | | |
| austin
Posts:33
| | 10/10/2007 11:16 AM |
| v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Hi Ganeshen
Trolling the machine event logs with “self rolled”
scripts and presenting the results in a variety of formats is well
established art form in itself.
I’m sure a Google will give you more than enough hits.
A place to start to see what’s possible though might be here
and if you’re in the mood, have a read of the .Net Frameworks System.Diagnostic.EventLog
Class here.
If you can think it, usually, you can do it.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ganeshen -
Sent: 10 October 2007 15:45
To: activedir@mail.activedir.org
Subject: RE: [ActiveDir] Reg: Active Directory Auditing.
Hi
Austin,
This is the first instance when I navigated through the site. So comprehensive
seemed to be right word. I am sure JR will introduce me to a new vocab on this.
:)
It is true that access needs to be controlled strictly or else unwanted issues
crop up. But ours is not an enterprise-level infrastructure. Although we are
growing, but I see it's going to take some time when we get specialized team
controlling individual aspects.
Although commercial audit tools are available and provide good reporting,
currently we only need to enable monitoring using the in-built AD features.
Do let me know if your suggestions to initiate this.
Thanks,
Ganeshen
Subject: RE: [ActiveDir] Reg: Active
Directory Auditing.
Date: Wed, 10 Oct 2007 14:40:43 +0100
From: austin@osuide.com
To: ActiveDir@mail.activedir.org
Hi Ganeshen,
“Comprehensive on the subject” is putting it mildly
(wait till JR wakes up and reads this! J )
Anyone who has console access or physical access to your DC can
cause you harm.
Anyone who has administrative privileges on your DC can cause
you harm.
You need to limit DA rights to only a few known individuals who
know AD if you want a secure environment. Equally, or more important, are
members of EA group. These need to be well controlled.
Delegate other rights as required. Even the rights required to
monitor things like replication can be delegated if you have specialized teams.
This is best supported by an AD administrative policy which is
signed off by management.
You can audit almost anything you want to audit in AD. The work
involved always, is sifting the noise that results from the data generated.
With the requirements you have, it might be quicker and easier
to get a COTS AD audit tool than it would be rolling your own.
Regards,
Austin
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Ganeshen -
Sent: 10 October 2007 12:52
To: activedir@mail.activedir.org
Subject: [ActiveDir] Reg: Active Directory Auditing.
Hello
All,
I came across ActiveDir.Org and have found it to be quite comprehensive on the
subject.
I have a concern which I wish to discuss here and seek your suggestions.
I have an AD with 2 DCs on Windows Server 2003 and have around 1500 nodes
(mostly Windows XP, 2000). Initially, all members of the admin team were domain
admins. All have had Domain Admin Account access. This was not a good security
practice and made it difficult to keep a track of actions taken on the AD and
the DC resources.
To control this, the domain admin account password was reset and access given
only to limited team members. To enable other team members perform the daily
administrative tasks, I used Delegation of Control to define and assign
specific permissions that they needed. This has controlled the extent of access
and changes on AD.
However, the other portion of the team still has domain admin account access as
well as domain admin rights. This is required for administration and monitoring
of DC/AD resources and other critical servers. In order to control &
monitor access on AD by this group, they have been asked to log on to DC with
their own domain id to perform any task. Apart from this, I wish to keep a
track of changes on the DC and AD. Although the auditing is enabled on the AD,
the logs are plenty and hence tracking of events becomes difficult.
I wish to use Auditing on AD for the following events:
1. To know and keep track of users (in this case the other group with domain
admin access) who log on to the DCs either locally or through RDP, with
timestamp and source IP (if possible).
2. To know and keep track of users who make changes in AD objects
(creating/modifying/deleting user accounts, exchange accounts,
creating/modifying/deleting OUs/security groups, creating/modifying/deleting
GPOs and tracking the specific policy attribute(s) that were altered, etc.)
3. To keep a track of only specific set of users.
If I missed out any information, please feel free to let me know.
Your suggestions would be helpful.
Thanks,
Ganeshen
Boo!Scare
away worms, viruses and so much more! Try Windows Live OneCare! Try now!
This
message may contain confidential information and is intended only for the
individual named.
If you are not the named addressee you should not disseminate, distribute or
copy this e-mail.
Please notify the sender immediately by e-mail if you have received this e-mail
by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as
information could be intercepted, corrupted, lost, destroyed, arrive late or
incomplete, or contain viruses.
The sender therefore does not accept liability for any errors or omissions in
the contents of this message, which arise as a result of e-mail transmission.
If verification is required please request a digitally signed version.
Boo!Scare
away worms, viruses and so much more! Try Windows Live OneCare! Try now!
This message may contain confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a digitally signed version. | | | |
|
|