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)
        Accesses                Unknown 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 exactly as clean as I had hoped, but it'll do.

Jason


_________________________________________________________________
List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
Web Interface:
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&;
lang=english
To unsubscribe:         mailto:[EMAIL PROTECTED]
Exchange List admin:    [EMAIL PROTECTED]



_________________________________________________________________
List posting FAQ:       http://www.swinc.com/resource/exch_faq.htm
Web Interface: 
http://intm-dl.sparklist.com/cgi-bin/lyris.pl?enter=exchange&text_mode=&lang=english
To unsubscribe:         mailto:[EMAIL PROTECTED]
Exchange List admin:    [EMAIL PROTECTED]

Reply via email to