Kerberos event 4/Target account name is incorrect/ troubleshooting

This error is reported whenever the service provider (e.g. file server) cannot decrypt a service ticket that was sent to it. This is caused by the fact that the ticket was encrypted by one machine then sent to a different machine. In this case, the second machine doesn't have the private key to decrypt the ticket.

Troubleshooting steps

- make sure there is not duplicate SPN for the service you are trying to get. For example, if you want to access \\serverName1\sharePath and get above error; or on a file server you see kerberos event 4, you want to check if there is duplicate SPN host\serverName*. In the past, it takes a little effort to find duplicate SPNs, but started Windows7/2008, you can run setspn -X to find all duplicated SPNs in your domain

- make sure you don't have duplicate DNS entries for same server to different IPs (unless the server does have multiple IP, and all DNS entries are correct).

- if access using FQDN works but not short name (e.g. \\server.FQDN.com\sharePath works but not \\server\sharePath), and you have WINS in your environment, make sure the target server register correct 20h record (File Server) in WINS

- If your target computer has multiple names (mostly added by command netdom computername), then you should make sure you add SPNs for all the alias you have. For example, if you have a server has both names as server1 and server2, you should below spn registered in AD:

• host/server1.fqdn.com
• host/server1
• host/server2.fqdn.com
• host/server2

- make sure you don't have hosts file entries that resolve to wrong IP

- Log into the system that actually owns wrong IP, make sure it's not registering wrong name. For DNS, check NIC TCP/IP stack; for WINS, check "netdom computername localhost /enum", as well as check HKLM\CCS\Services\lanmanserver\parameters\OptionalNames

Attributes used in ANR (Ambiguous Name Resolution)

• GivenName
• Surname
• displayName
• LegacyExchangeDN
• msExchMailNickname
• RDN
• physicalDeliveryOfficeName
• proxyAddress
• sAMAccountName

How to run an ANR search:

(anr=John Doe)

(anr=J D)

(anr=J Doe) etc....

Largest Delta? What is it?

[
Short version: typically you don't have to pay attention to this stat. As long as number of "fails" is zero, AD replication is healthy.
Note: When you have replication fails and subsequently remedy the problem, the number of "fails" in "replsummary" report is not going to change to zeros right away. The report of this command is a snapshot of history, so it takes a bit time for all fails to disappear.
]

Repadmin /replsummary result is simple, but yet somewhat confusing. A few notes:

• If you don't specify /bysrc or /bydest, it will list status for both directions. You want to pay attention to Destination DSA as AD replication is pull-based.
• Most critical column is "fails". If there is no fails, obviously you don't have much to worry about
• Most confusing column is "largest delta". It's common misunderstanding (on the Net at least) that value in this column should be less then 1hr. However, depending on how large your AD environment is, and how frequent changes happen in a particular Naming Context, value in this column could be very large (days)
• Microsoft's official interpretation for "largest delta": longest replication gap amongst all replication links for a particular DC", which is not really helpful. I personally had hard time to understand this interpretation itself.
• This value is for the particular DC, among all its replication partners, the longest time that it hasn't replicated anything against whatever NC. This value has to be read together with /showrepl command against that DC.

Read on for example:

How to troubleshoot account lockout issue

[Note] Event ID applicable to Windows 2003 DC only, but it shouldn't be too difficult to find related W2k8 event IDs.
[Edit Feb 14/2012] Full list of audit events in windows 2008 can be downloaded here, also KB947226
Please read the differences between "Account Logon/logoff" event and "Logon/Logoff" event first.

- First, using lockoutstatus to find out initial authenticating DC (more than often PDC is not the initial authenticating DC. It has same event IDs mentioned below merely because other DCs check with PDC for latest password.) and time of logon attempt

- Then go to authenticating DC, check security log. Pin-point the log entry using time identified by lockoutstatus

- We are looking for: event ID 675 (4771 in w2k8?), the client IP is the offending machine that sent bad pwds

- Failure code in event ID 675(This is corresponding kerberos error code, full list here)

• 0x18: original wrong password
• 0x12: this will be logged after the fact that account has already been locked

- Logon type in event ID 675 ( full list here)

• 2 being interactive
• 3 network
• 5 service
• 10 Remote interactive

Token Size vs. Paged Pool - draft

This is mostly a complete copy from microsoft.com

When users access a resource using Windows authentication and authorization (for example logging on to a workstation or accessing a file share), an “access token” is built to represent that user.
      The number of SIDs (representing group membership, etc) in that token largely determines how much kernel memory space (Paged Pool) is required to store each copy of the token.
      These allocations follow a “stair-step” pattern, as follows:
      At approximately 84 SIDs, allocation jumps from 4KB to 8KB.
      At approximately 177 SIDs, allocation jumps from 8KB to 12KB.
      At approximately 270 SIDs, allocation jumps from 12KB to 16KB.
      At approximately 363 SIDs, allocation jumps from 16KB to 20KB and so on.

Local Admin Account vs. account lockout

You can't really lock out an admin account - as long as you type in the correct password on *local console*, the system will unlock it automatically. This makes sense - legit users need a way to get into the system when all other credentials are failing - completely locking out all users surely won't make happy customers.

However this increases the risk of being cracked by brutalforce method. For companies who want to maximize the security and are willing to pay the cost of losing acceess due to lost passswords, there is a way to put admins under same lockout policy as ordinary users. MS has an old tool called passprop.exe that can enforce lockout policy, even against admins.

        passprop /adminlockout

This is no longer needed in Windows 2008. There are pre-define security polices in Windows 2008 will do the same.