RE: Tracking and auditing Exchange administrators
I know that an admin can't read someone elses email by default. But they
*can* if they want to, and we simply want a way to audit this. Like I
said, this is a law firm and they are very particular about stuff like
this.
Jason
-Original Message-
From: Hurst, Paul [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 5:24 AM
To: Exchange Discussions
Jason,
By default the Exchange admin cannot read Emails (same as
GroupWise), only if he has implemented the Q article on how
to get round this security. I would say to set it back so
they cannot go into emails.
Cheers
Paul
Standards are like toothbrushes,
everyone wants one but not yours
-Original Message-
From: Clishe, Jason [mailto:[EMAIL PROTECTED]
Sent: 03 June 2003 19:58
To: Exchange Discussions
Subject: Tracking and auditing Exchange administrators
I have a client that is in the middle of a Groupwise to
Exchange 2000 migration. They were a bit unsettled at the
discovery that an Exchange admin can grant himself permission
to read anyone's mail (something that is completely
impossible in Groupwise, short of changing the users'
password). They want to know how they can audit whether an
admin has modified the ACL on a mailbox store to grant
himself access to anyones mailbox. I know, I know, you should
be able to trust your administrators, but this is a law firm
and it's important that there's a paper trail.
I've done some testing and come up with the following
results. I wanted to run this by the group to see if anyone
can confirm or deny that I'm using the most appropriate
method to perform the auditing.
I've set the local policy on the Exchange server to audit
process tracking and privelege use. I then went into ESM and
gave an account full access to a mailbox store, including
send as and receive as rights.
I checked the security logs and found the following 3 events
(I actually found more than 3 events that appeared to be
generated when I modified the permissions, but these 3 seemed
most relevant):
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
--
--
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
-
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 565
Date: 6/3/2003
Time: 11:08:25 AM
User: DOMAIN\User
Computer: SERVER
Description:
Object Open:
Object Server: Microsoft Exchange
Object Type:Microsoft Exchange Database
Object Name:/o=ORG/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB
New Handle ID: 0
Operation ID: {0,227067}
Process ID: 1636
Primary User Name: SERVER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: User
Client Domain: DOMAIN
Client Logon ID:(0x0,0x29E68)
AccessesUnknown specific access (bit 8)
Privileges -
Properties:
Unknown specific access (bit 8)
%{d0780592-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8762-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8774-2289-11d3-aa62-00c04f8eedd8}
%{cf899a6a-afe6-11d2-aa04-00c04f8eedd8}
%{cffe6da4-afe6-11d2-aa04-00c04f8eedd8}
%{cfc7978e-afe6-11d2-aa04-00c04f8eedd8}
%{d03a086e-afe6-11d2-aa04-00c04f8eedd8}
%{d74a875e-22b9-11d3-aa62-00c04f8eedd8}
%{cf4b9d46-afe6-11d2-aa04-00c04f8eedd8}
%{cf0b3dc8-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8766-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8769-22b9-11d3-aa62-00c04f8eedd8}
RE: Tracking and auditing Exchange administrators
You can look at the security log and it will tell you. But if that person
is smart they will also remove entries in the log too
From: Clishe, Jason [EMAIL PROTECTED]
Reply-To: Exchange Discussions [EMAIL PROTECTED]
To: Exchange Discussions [EMAIL PROTECTED]
Subject: RE: Tracking and auditing Exchange administrators
Date: Wed, 4 Jun 2003 11:21:25 -0400
I know that an admin can't read someone elses email by default. But they
*can* if they want to, and we simply want a way to audit this. Like I
said, this is a law firm and they are very particular about stuff like
this.
Jason
-Original Message-
From: Hurst, Paul [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2003 5:24 AM
To: Exchange Discussions
Jason,
By default the Exchange admin cannot read Emails (same as
GroupWise), only if he has implemented the Q article on how
to get round this security. I would say to set it back so
they cannot go into emails.
Cheers
Paul
Standards are like toothbrushes,
everyone wants one but not yours
-Original Message-
From: Clishe, Jason [mailto:[EMAIL PROTECTED]
Sent: 03 June 2003 19:58
To: Exchange Discussions
Subject: Tracking and auditing Exchange administrators
I have a client that is in the middle of a Groupwise to
Exchange 2000 migration. They were a bit unsettled at the
discovery that an Exchange admin can grant himself permission
to read anyone's mail (something that is completely
impossible in Groupwise, short of changing the users'
password). They want to know how they can audit whether an
admin has modified the ACL on a mailbox store to grant
himself access to anyones mailbox. I know, I know, you should
be able to trust your administrators, but this is a law firm
and it's important that there's a paper trail.
I've done some testing and come up with the following
results. I wanted to run this by the group to see if anyone
can confirm or deny that I'm using the most appropriate
method to perform the auditing.
I've set the local policy on the Exchange server to audit
process tracking and privelege use. I then went into ESM and
gave an account full access to a mailbox store, including
send as and receive as rights.
I checked the security logs and found the following 3 events
(I actually found more than 3 events that appeared to be
generated when I modified the permissions, but these 3 seemed
most relevant):
Event Type:Success Audit
Event Source: Security
Event Category:Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
--
--
Event Type:Success Audit
Event Source: Security
Event Category:Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
-
Event Type:Success Audit
Event Source: Security
Event Category:Object Access
Event ID: 565
Date: 6/3/2003
Time: 11:08:25 AM
User: DOMAIN\User
Computer: SERVER
Description:
Object Open:
Object Server: Microsoft Exchange
Object Type:Microsoft Exchange Database
Object Name:/o=ORG/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB
New Handle ID: 0
Operation ID: {0,227067}
Process ID: 1636
Primary User Name: SERVER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: User
Client Domain: DOMAIN
Client Logon ID:(0x0,0x29E68)
AccessesUnknown specific access (bit 8)
Privileges -
Properties:
Unknown specific access (bit 8)
%{d0780592-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8762-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8774-2289-11d3-aa62-00c04f8eedd8}
%{cf899a6a-afe6-11d2-aa04-00c04f8eedd8}
%{cffe6da4-afe6-11d2-aa04-00c04f8eedd8}
%{cfc7978e-afe6-11d2-aa04-00c04f8eedd8}
%{d03a086e-afe6-11d2-aa04-00c04f8eedd8}
%{d74a875e-22b9-11d3-aa62-00c04f8eedd8
RE: Tracking and auditing Exchange administrators
Not sure if this is relevant to you, but I found that anyone who has
administrative permissions to exchange can bring up anyone's email via
OWA without having any specific permission. I have found this an
advantage for me in certain circumstances but if security is an issue
with the administrators.
Todd
-Original Message-
From: Clishe, Jason [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 2:58 PM
To: Exchange Discussions
Subject: Tracking and auditing Exchange administrators
I have a client that is in the middle of a Groupwise to Exchange 2000
migration. They were a bit unsettled at the discovery that an Exchange
admin can grant himself permission to read anyone's mail (something that
is completely impossible in Groupwise, short of changing the users'
password). They want to know how they can audit whether an admin has
modified the ACL on a mailbox store to grant himself access to anyones
mailbox. I know, I know, you should be able to trust your
administrators, but this is a law firm and it's important that there's a
paper trail.
I've done some testing and come up with the following results. I wanted
to run this by the group to see if anyone can confirm or deny that I'm
using the most appropriate method to perform the auditing.
I've set the local policy on the Exchange server to audit process
tracking and privelege use. I then went into ESM and gave an account
full access to a mailbox store, including send as and receive as rights.
I checked the security logs and found the following 3 events (I actually
found more than 3 events that appeared to be generated when I modified
the permissions, but these 3 seemed most relevant):
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
-
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 565
Date: 6/3/2003
Time: 11:08:25 AM
User: DOMAIN\User
Computer: SERVER
Description:
Object Open:
Object Server: Microsoft Exchange
Object Type:Microsoft Exchange Database
Object Name:/o=ORG/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB
New Handle ID: 0
Operation ID: {0,227067}
Process ID: 1636
Primary User Name: SERVER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: User
Client Domain: DOMAIN
Client Logon ID:(0x0,0x29E68)
AccessesUnknown specific access (bit 8)
Privileges -
Properties:
Unknown specific access (bit 8)
%{d0780592-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8762-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8774-2289-11d3-aa62-00c04f8eedd8}
%{cf899a6a-afe6-11d2-aa04-00c04f8eedd8}
%{cffe6da4-afe6-11d2-aa04-00c04f8eedd8}
%{cfc7978e-afe6-11d2-aa04-00c04f8eedd8}
%{d03a086e-afe6-11d2-aa04-00c04f8eedd8}
%{d74a875e-22b9-11d3-aa62-00c04f8eedd8}
%{cf4b9d46-afe6-11d2-aa04-00c04f8eedd8}
%{cf0b3dc8-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8766-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8769-22b9-11d3-aa62-00c04f8eedd8}
%{d74a876f-22b9-11d3-aa62-00c04f8eedd8}
-
Does this behavior seem correct? It appears that there's multiple
entries that need to be tracked in order to tell the whole story: Event
ID 577 signifies that privileges have been modified, and then event ID
565 lists the objects that were accessed at the time the
RE: Tracking and auditing Exchange administrators
Jason,
By default the Exchange admin cannot read Emails (same as GroupWise), only
if he has implemented the Q article on how to get round this security. I
would say to set it back so they cannot go into emails.
Cheers
Paul
Standards are like toothbrushes,
everyone wants one but not yours
-Original Message-
From: Clishe, Jason [mailto:[EMAIL PROTECTED]
Sent: 03 June 2003 19:58
To: Exchange Discussions
Subject: Tracking and auditing Exchange administrators
I have a client that is in the middle of a Groupwise to Exchange 2000
migration. They were a bit unsettled at the discovery that an Exchange
admin can grant himself permission to read anyone's mail (something that
is completely impossible in Groupwise, short of changing the users'
password). They want to know how they can audit whether an admin has
modified the ACL on a mailbox store to grant himself access to anyones
mailbox. I know, I know, you should be able to trust your
administrators, but this is a law firm and it's important that there's a
paper trail.
I've done some testing and come up with the following results. I wanted
to run this by the group to see if anyone can confirm or deny that I'm
using the most appropriate method to perform the auditing.
I've set the local policy on the Exchange server to audit process
tracking and privelege use. I then went into ESM and gave an account
full access to a mailbox store, including send as and receive as rights.
I checked the security logs and found the following 3 events (I actually
found more than 3 events that appeared to be generated when I modified
the permissions, but these 3 seemed most relevant):
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
Event Type: Success Audit
Event Source: Security
Event Category: Privilege Use
Event ID: 577
Date: 6/3/2003
Time: 11:08:06 AM
User: DOMAIN\User
Computer: SERVER
Description:
Privileged Service Called:
Server: Security
Service:-
Primary User Name: User
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x29E68)
Client User Name: -
Client Domain: -
Client Logon ID:-
Privileges: SeIncreaseBasePriorityPrivilege
-
Event Type: Success Audit
Event Source: Security
Event Category: Object Access
Event ID: 565
Date: 6/3/2003
Time: 11:08:25 AM
User: DOMAIN\User
Computer: SERVER
Description:
Object Open:
Object Server: Microsoft Exchange
Object Type:Microsoft Exchange Database
Object Name:/o=ORG/ou=First Administrative
Group/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB
New Handle ID: 0
Operation ID: {0,227067}
Process ID: 1636
Primary User Name: SERVER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: User
Client Domain: DOMAIN
Client Logon ID:(0x0,0x29E68)
AccessesUnknown specific access (bit 8)
Privileges -
Properties:
Unknown specific access (bit 8)
%{d0780592-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8762-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8774-2289-11d3-aa62-00c04f8eedd8}
%{cf899a6a-afe6-11d2-aa04-00c04f8eedd8}
%{cffe6da4-afe6-11d2-aa04-00c04f8eedd8}
%{cfc7978e-afe6-11d2-aa04-00c04f8eedd8}
%{d03a086e-afe6-11d2-aa04-00c04f8eedd8}
%{d74a875e-22b9-11d3-aa62-00c04f8eedd8}
%{cf4b9d46-afe6-11d2-aa04-00c04f8eedd8}
%{cf0b3dc8-afe6-11d2-aa04-00c04f8eedd8}
%{d74a8766-22b9-11d3-aa62-00c04f8eedd8}
%{d74a8769-22b9-11d3-aa62-00c04f8eedd8}
%{d74a876f-22b9-11d3-aa62-00c04f8eedd8}
-
Does this behavior seem correct? It appears that there's multiple
entries that need to be tracked in order to tell the whole story: Event
ID 577 signifies that privileges have been modified, and then event ID
565 lists the objects that were accessed at the time the privileges were
modified. Not
