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

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

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

Exchange2007RTM和Exchange2003 SP2支持Windows 2008域控的环境安装
不能直接从安装Exchange 2007 RTM或SP1的系统升级到Windows Server 2008, 因此想在Windows Server 2008上安装Exchange的方法是：安装一台新的Windows Server 2008 然后安装Exchange 2007 SP1

Windows 2008针对Exchange的改进提高

 支持多网段冗余群集

更快的日志文件传送：CCR和SCR使用Server Message Block（SMB）协议来复制日志文件，Windows 2008使用SMB V2，提高了30-40%的传送性能

减少了硬件维护的当机时间：Windows Server 2008 支持核心硬件的热插拔

修复NTFS故障，当机时间接近零：在Windows 2003和以前的版本，修复NTFS故障需要使服务器离线，然后运行Chkdsk工具。Windows 2008包括一个新的功能 Self-healing NTFS.

提高了Outlook AnyWhere服务的性能：Windows 2008包含下一代Tcp/ip堆栈，移除了以前版本RPC proxy 服务的TCP连接限制，现在支持单IP连接限制。在Windows 2003里面支持最大65535个连接，在windows 2008里面支持每个IP地址最多65535个连接。

更简单部署：Windows 2008包括MMC3.0, Powershell， .net Framework

支持IPv6:

一些变化

Windows 2008不包括支持Exchange API接口的备份工具，Windows Server Backup不能备份Exchange 2007 (即将发行的SBS2008, 将支持Exchange备份)

Exchange 2007不会使用只读域控和只读GC

Exchange 2007不能安装在Server Core上面：Server Core上面即不能安装Powershell也不能安装.Net Fremawork

摘自：MSExchangeTeam Blog

Acctinfo.dll
Acctinfo.dll是一个动态链接库文件，注册这个动态链接库文件之后，管理员可以通过使用“Active Directory用户和计算机”管理控制台查看用户属性的时候，增加一个“Additional Account Info”选项卡。这个选项卡可以让管理员查看Active Directory中的一些高级信息，例如：用户上次修改密码时间、用户帐户上次登录时间等。使用“Additional Account Info”选项卡查看信息，主要是出于以下两个方面的需求。在某些情况下，部分信息没有被存储在Active Directory中，而是被存储在本地。

例如：某用户帐户上次登录时间和上次注销时间仅仅被存储每个域控制器本地，并没有复制到域中的其他域控制器中。Acctinfo.dll可以帮助管理员检查某台域控制器上用户上次登录和注销的具体时间。如果你在域中有多个域控制器，管理员可能需要在每个域控制器上都安装Acctinfo.dll以检查某一个用户帐户在每台域控制器上的登录、注销时间。

此外，使用Acctinfo.dll还可以更加方便的修改用户帐户密码，锁定或解除锁定用户帐户。Acctinfo.dll解除用户帐户的锁定状态的具体步骤如下：
1.在使用Acctinfo.dll之前，需要安装注册Acctinfo.dll文件。
2.将Acctinfo.dll文件复制到“%windir%\system32”文件夹中。在Windows Server 2003中，通常这个文件夹为“C:Windows\System32”；在Windows 2000中，这个文件夹通常为“C:Winnt\System32”。
3.打开命令行窗口，假设“%windir%\system32”文件夹为“C:Windows\System32”，键入以下内容：regsvr32 c:windows\system32\acctinfo.dll
4.如果命令执行成功，将会出现一个成功注册Acctinfo.dll的对话框。
5.点击“开始”－>“运行”－>输入“DSA.MSC”－>“Active Directory用户和计算机” －>选择被锁定的用户－>右键点击“属性”
6.在“Additional Account Info”选项卡中，单击“Set PW On Site DC”按钮。在新出现的对话框中,修改用户帐户的密码。这种密码修改方式是直接连接到用户所在站点的域控制器上执行操作，所以执行速度更快。同时在这个对话框中，也可以解除用户帐户的锁定状态。希望我的回复对您有所帮助。

Tom Zhang 张一平
在线技术支持工程师
微软全球技术支持中心