One of the most common questions that I get about Windows Auditing is, how come you guys were so @#%! stupid that you put in two logon categories?

The answer is actually pretty simple- we're bad at choosing names.  "Account Logon" isn't really about logon, it's about credential validation.

Here's the low down on what is the difference between Logon/Logoff and Account Logon events, and how to decipher Account Logon events.

Audit Logon/Logoff generates events for the creation and destruction of logon sessions.  These events occur on the machine which was accessed.  In the case of an interactive logon, these would be generated on the machine which was logged on to.  In the case of network logon, for example, accessing a share, these events would be generated on the machine hosting the resource that was accessed.

Audit Account Logon generates events for credential validation. These events occur on the machine which is authoritative for the credentials.  For domain accounts, the domain controller is authoritative. For local accounts, the local machine is authoritative.  Since domain accounts are used much more frequently in enterprise environments than local accounts, most of the Account Logon events in a domain environment occur on the domain controllers which are authoriative for the domain accounts.  However, these events can occur on any machine, and may occur in conjunction with or on separate machines from logon/logoff events.

Logging on interactively to a workstation, using a domain account, can cause more activity than you might expect on the DC.  An interactive logon is pretty complex and involves multiple steps.  Typically, from the time you turn on your workstation until the time you are viewing your desktop, the following things happen:

User logs on: Kerberos AS request (DC, 672), Kerberos TGS request for AD (DC, 673), Logon session created (workstation, 528, 576)

• User gets policy: Kerberos TGS request for DC\Netlogon [logon scripts, group policy] (DC, 673), Network logon (DC, 540, 538, usually 2-3 rounds)

In Account Logon failures for Kerberos, the KDC has to generate an AS reply with an RFC 1510 error. Since RFC 1510 error codes don't contemplate Windows-specific errors, and we have to return Kerberos-specific errors in Kerberos AS request failure replies, we had to map Windows error conditions to kerberos error codes. The error code mappings are described in the Kerberos Troubleshooting document that is available on Microsoft.com: http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx

Here are some questions that you might have about Account Logon events:

Q: Why do you only have the IP address in the Account Logon event, and not the computer name?
A: There are three reasons:

1. There is no secure method for the KDC to get the remote machine's name at the current time.  If the client provides the name (as in NTLM), then it's not trustworthy and can be spoofed.  There are Unix-based hacking tools which spoof workstation name in NTLM auth requests.
2. DNS and NetBIOS reverse lookup are not secure and are not reliable- if we tried this, we'd have a high incidence of incorrect or missing information, and hurt performance.
3. Even if we chose to do add the name anyway, when we could, there's no field for us to use to carry it in Kerberos AS REQ & TGS REQ messages- we'd have to overload some other field, and run a high risk of loss of compatibility with MIT's reference implementation.

Q: How do I correlate the Account Logon event on a DC with the Logon/Logoff event on the machine which was accessed?
A: Easy!  The Account Logon event and the Logon/Logoff event both contain a field called a Logon GUID, starting in Windows Server 2003.  Just compare the GUIDs- if they match, it's the same Kerberos ticket.  Unfortunately this only works for Kerberos; other Logon events contain a GUID that is all zeroes.

Q: Is there such a thing as an Account Logoff event?
A: No. The DC is only aware of logons, not logoffs (there's no possible way to force a machine to contact a DC when logging off- consider crashes, etc.)

Q: I just want to monitor my DC's logs.  Is that good enough?
A: Well, the DC has a distorted view of logon as mentioned above.  Also, the DC only knows where the logon request came from most recently.  Consider using IIS- the logon request originates at a browser somewhere on the internet.  IIS receives the request and then sends a logon request to the DC.  From the DC's point of view, the source of the logon is IIS.  If you only collect the DC's logs, you'll miss the detail of where the request came from.  This is true for any network service- RPC, file sharing, remote desktop, etc.  Also, the DC doesn't have enough information to answer "how long was the user logged on".  However there is one really interesting piece of information in DC logs.  In event 673 (Kerberos Service Ticket granted), the service name is listed.  This is the most detail that the DC can provide, on what the user was logging on for.

Eric

How to verify the Intelligent Message Filter SCL rating in Outlook 2003

On This Page

SUMMARY

MORE INFORMATION

How to install the SCL Extension Form in Outlook 2003

How to add the SCL rating field into the column header of Outlook folders

REFERENCES

[Description]
            MessageClass=IPM.Note
            CLSID={00020D31-0000-0000-C000-000000000046}
            DisplayName=SCL Extension Form
            Category=Standard
            Subcategory=Form
            Comment=This forms allows the SCL to be viewed as a column
            LargeIcon=IPML.ico
            SmallIcon=IPMS.ico
            Version=1.0
            Locale=enu
            Hidden=1
            Owner=Microsoft Corporation
            Contact=Your Name
            [Platforms]
            Platform1=Win16
            Platform2=NTx86
            Platform9=Win95
            [Platform.Win16]
            CPU=ix86
            OSVersion=Win3.1
            [Platform.NTx86]
            CPU=ix86
            OSVersion=WinNT3.5
            [Platform.Win95]
            CPU=ix86
            OSVersion=Win95
            [Properties]
            Property01=SCL
            [Property.SCL]
            Type=3
            NmidInteger=0x4076
            DisplayName=SCL
            [Verbs]
            Verb1=1
            [Verb.1]
            DisplayName=&Open
            Code=0
            Flags=0
            Attribs=2
            [Extensions]
            Extensions1=1
            [Extension.1]
            Type=30
            NmidPropset={00020D0C-0000-0000-C000-000000000046}
            NmidInteger=1
            Value=1000000000000000

Dcgpofix 如果以下两个默认 GPO 中的一个出现了问题，则可以使用该工具：默认域策略和默认域控制器策略。如果其中一个或全部两个 GPO 损坏，程度严重到仅靠配置方式已经无法修复，或者存在一些其他未知问题，则可以使用 dcgpofix 工具将其还原为默认状态。此工具包含在 Windows Server® 2003 中。不应在 Windows 2000 域控制器上运行此工具；可使用 Recreatedefpol 来代替。请记住，使用此工具后会丢失所有自定义设置。

Recreatedefpol 该工具类似于 Dcgpofix，但只用于 Windows 2000 服务器。可将两个默认的 GPO 返回到其刚安装的状态。此工具应仅用于灾难恢复，不可用于 GPO 的日常维护。单击此处下载该工具。

Gpotool 由于 GPO 是从域控制器（最初先在此域控制器中进行更改，然后扩展到所有其他域控制器）复制的，因此可能会出现复制失败或聚合无效的现象。结果可能是对各目标计算机所适合应用的更改不一致或失败。像 Gpresult 和 RSOP 这样的工具可以帮助确定应用了哪些 GPO，而 Gpotool 工具则可以帮助确定每个域控制器上的 GPO 是否一致。此工具是 Windows Server 2003 Resource Kit 的一部分，其网址为 go.microsoft.com/fwlink/?LinkId=77613。

在Exchange 2007中的郵件傳送與接收大小的限制有下列幾個檢查點

http://technet.microsoft.com/en-us/library/bb124345.aspx

• Origanizational Limit
• Global Limit
• Connector Limit
• Server Limit
• User Limit

在沒有Edge的情況下，Organizational以及User的收及發都是未設限，亦即Unlimited

假設整個ORG中你只有一台Hub Transport，以及只有一條Send Connector的話

那麼預設使用者寄出去及收進來都只有10MB．

因為預設Hub Transport上的Send & Receive Connector的最大message size都是10MB

你可以利用Set-SendConnector -MaxMessageSize以及Set-ReceiveConnector -MaxMessageSize cmdlet來改變預設的郵件傳送及接收大小

至於OWA預設在選取要加入的附件檔案的大小是30000 KB，你可以依照下面的作法做適當的修改

http://technet.microsoft.com/en-us/library/aa996835.aspx

要注意的是，即使OWA預設可上傳的附件檔大小為30000KB,不代表使用者就可以真的將30000KB大小的附件檔寄出

因為還是會受限於Send Connector預設10MB大小的限制

 

解決方法：使用ADSI EDIT設定

Configuration-->CN=Service-->CN=Microsoft Exchange-->CN=<Exchange ORG. Name>-->CN=Global Settings-->CN=Message Delivery-->滑鼠右鍵-->內容

delivContLength：<10240>                       (0~2097151KB)  　預設值為10MB，最大可以設為2097151KB (2GB)
  submissionContLenght：<10240>             (0~2097151KB)     同上
  msExchReciplimit：<5000>                      (0~2147483647)   不用改

Exchange 2007傳送大小，使用MAPI時會受限於Global limits、Organizational limits、使用者信箱傳送大小的限制、Pickup大小的限制、集線傳輸規則的附件檔大小限制、Connector limits、OWA 2007 (Web.config file)的上傳下載大小限制。

    傳送大小的限制原則是：使用者的傳送大小或接收大小取決於使用者信箱的傳送大小限制之設定，若保持預設(沒有特別指定)，再由Global及ORG.兩者的傳送大小限制來決定，但預設上，Global是限制10MB，而ORG是沒有限制，因此Global與ORG之間再取最小值，所以若使用者信箱沒有特別設定傳送大小限制，預設值會被限制在10MB。

 以上為純Exchange 2007安裝時的情況,若是由Exchange 2003或Exchange 2000升級上來的,則Global會保留原有設定, 一般人比較容易疏忽的是Global設定,因為這是舊版本Exchange的設定,只能由Exchange 2000或2003的管理介面去檢視或設定,若是純Exchange 2007的安裝,並沒有直接的管理介面或指令去指定,必須透過ADSI工具至AD的Configuration中設定。

Best regards.

Frank Hsieh

Categorizer

分类进程从递交队列中提取邮件，在递交队列中总是更早的邮件被优先提取。

在边缘服务器，分类进程仅仅处理收件人地址是否符合这一条件，然后邮件直接传递到传输队列。通过传输队列，邮件路由到中心传输服务器。

在中心传输服务器上，分类进程执行下列的任务：

1.       判断和检查收件人

2.       多收件人邮件进行分叉

3.       判断路由路径

4.       转换内容格式

5.       应用组织邮件策略

单个AD站点中邮件的传递流向工作

1．  当一份邮件递交到邮箱服务器邮箱存储上时，邮件流开始。如果客户端是office outlook客户端，邮件通过MAPI提交，邮件直接写在用户outbox中。

2．  当Microsoft Exchange Mail Submission service检测到邮件可用(在outbox中)，它选择一台可用的中心传输服务器角色，递交一个邮件通知给Store Driver

3．  Store Driver(中心传输服务器的传输服务组件)使用MAPI连接到用户的outbox,收集所有需要发送的邮件。将邮件递交到递交队列，然后将邮件从outbox移动到已发送邮箱。

4．  当邮件目的是同一个AD站点的邮箱服务器，邮件被提交到Local Delivery Queue，然后store driver 通过MAPI传递邮件到邮箱服务器角色。

5．  当邮件目的是另一个AD站点的邮件服务器，中心传输服务器使用AD站点链接信息来判断到目的站点的路由，当路径确定后，中心传输服务器会直接连接到远程站点的服务器。如果在目的站点没有中心传输服务器可用，邮件将被路由到离目的站点最近的中心传输服务器。

6．  当邮件目的是Internet，中心传输服务器提交邮件到边缘服务器。

The "Perform Reverse DNS Lookup for Incoming Messages" Option Is for Host Name Resolution

最近有客户反映使用RBL后，一些不在列表里面的服务器也会被阻止，又是电信干的好事。
google了一下，有篇不错的技术分析文章。

作者：wxy 2008-06-10 12:35:00