Windows 2003 Kerberos Failure Audits - Event ID 673

I am having failure audits happen every 5 - 10 minutes on both 2003 DC's in Native mode.  There does not appear to be any problems on the network, although it is not running at 100% yet.  I'm still in implementation/development/testing stage.  I have 5 servers, 2 DC's all running Server 2003 Standard and there is only 2 windows 2000 computers joined to the domain.

The errors are comming from the same member servers.  The DC that has the error will also include an error for itself on  Some member servers have errors more frequently then others.

I think it's a glitch in 2003... but I am not 100% sure.


Event Type:      Failure Audit
Event Source:      Security
Event Category:      Account Logon
Event ID:      673
Date:            23/10/2003
Time:            11:43:13 AM
User:            NT AUTHORITY\SYSTEM
Computer:      <DC>
Service Ticket Request:
       User Name:            
       User Domain:            <My Domain>
       Service Name:            host/<Domain Member>
       Service ID:            -
       Ticket Options:            0x40830000
       Ticket Encryption Type:      -
       Client Address:            <IP Address>
       Failure Code:            0xD
       Logon GUID:            -
       Transited Services:      -

For more information, see Help and Support Center at
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

crazycanuck42Author Commented:
Thanks Sunray...

All those links show Event 673 as a success.  I am getting event 673 as a failure.  No success audits.  I've added success logging of Logon Events and the 673 turned into a success on only 1 of the 2 DC's.  The DC with the problem is also now, not loading the GPO.  Event 1030 and 1058.  Changing the settings in the GPO fixed it on one DC not the other.... hmmm...

Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9}
(Access is denied. ). Group Policy processing aborted.


I've fixed this once, now it's returned.
I have seen this creep up occasionally.  Here are my past postings on the subject on :

Last night I repeated it twice in a row and avoided it the third time around and noticed a strong indicator of whats going on. I have been playing with AD since the 2K RC's, but I make no "guruesque" claims. Because, I don't care how much you know DNS is complex and is one of the most unforgiving.

Both times when this corruption happned, config and setup were the same, cept the second time I was paying even more close attention. The first time I configured the NICs in setup and the second after setup.

Setup problems. Setup HW, enviromental/performace best practices. Then DDNS (FWD and REV), WINS, all were answering queries, DDNS and DHCP cooperating enterprise wide. Setup service start delays for Netlogon and DNScache, the first time and on the second included Lanmanworkstation and Server. With event logs clear, services behaving...time for dcpromo. Nothing unusual, intergrated DNS into AD. Everything seems OK....but you get a Security Fail Audit (see ex.1 below) every 15 minutes from DC boot and every 15 from the previous error. This behavior propigates as well. When that failure occurs using a TDImon, LOTS of DNS activity during that 1/4 second, didn't have time to investigate deeper. Sometimes with new directories and DCs, it takes a little bit for the dust to settle.

Everything seemed OK except that fail audit. So I start digging for info on the error. Not whole lot of help on the KB or other sources. I then go to netdiag and see minor issues, but definatly WAY less than you would see when Netlogons fails to update DNS or anything indicative of this serious problem. Next I looked at DCdiag. The domain appeared to "realize" its not there all of a sudden and then dies a HORRIBLE PAINFUL death. My RDP session locked and I could only locally logon. But from then on, more errors than if you setup AD without DNS. Being he first time around, just went back to start. However, the second time, digging through event logs after the directory disappeard as befor, I see one "Alert" (ex.2 below) and only one, after DNS gets enumerated, from way befor AD creation. It seems that a connections primary DNS suffix does not get updated during DNS or AD setup. Through DDNS this "update" of a corrupted DNS structure and AD referances spreads (as designed); if you intergrate WINS thats gets corrupted as well. And you have a big mess. Now in an established enviroment, you aren't just gonna scrap it, but it would be a huge headache. Especially since the only prelude is that one secuirty failure.

NOTE: "<xxx.yyy.zzz>" = the contexual format, just names were changed to protect the innocent.
("" was not changed, that is how it was reported)

Failiure Audit ID: 673
Service Ticket Request:
User Domain: "<your.domain>"
Service Name: "<host/yourDCs.seemingly.FQDN>"
Service ID: -
Ticket Options: 0x40830000
Ticket Encryption Type: -
Client Address:
Failure Code: 0xD
Logon GUID: -
Transited Services: -

Event Type: Warning
Event Source: DNS
Event Category: None
Event ID: 414
Date: 10/15/2003
Time: 12:52:34 AM
User: N/A
Computer: "<HOSTNAME>"
The DNS server machine currently has no DNS domain name. Its DNS name is a single label hostname with no domain (example: "host" rather than "").

You might have forgotten to configure a primary DNS domain for the server computer. For more information, see either "DNS server log reference" or "To configure the primary DNS suffix for a client computer" in the online Help.

While the DNS server has only a single label name, all zones created will have default records (SOA and NS) created using only this single label name for the server's hostname. This can lead to incorrect and failed referrals when clients and other DNS servers use these records to locate this server by name.

To correct this problem:
1) open Control Panel
2) open System applet
3) select Computer Name tab
4) click the "Change" button and join the computer to a domain or workgroup; this name will be used as your DNS domain name
5) reboot to initialize with new domain name

After reboot, the DNS server will attempt to fix up default records, substituting new DNS name of this server, for old single label name. However, you should review to make sure zone's SOA and NS records now properly use correct domain name of this server.

For more information, see Help and Support Center at

Try it out if you want headache...
;) On the first time around, after DCdiag (without fix) locked user mode...MY mouse worked, but the cordinate responses were not being returned in the frozen RDP session, it then became. Link light was on at least. But that was on my first one. The second time around,...not as dead, but not more alive.

Solutionwise....depends on how deep in "fantasy" the directory and DNS install, quicker to redeploy. And I would feel better, structuraly thinking. In an pre-existing enviroment see if a DC is either not or the least affected. Perhaps the one accoss the leased-56 that you forgout about. I may be your best friend. Since the DDNS is screwed, the AD gets screwed, WINS, etc. You have to stage it out, at least with the name servers.

Mantra: ipconfig/flushdns nbtstat -R/RR

Anyways, just my insights and LOSIS induced thoughts.

Post Scriptum, If any one of you worked with Novell's eDirectory Corp Edition for NT 4.0, this propigation and the effect is definitely similar. Recoverable, but who the hell wants too......I prolly would in an established enviroment, then again thats why they are still in my lab.

It seems I can fix it without doing ADR or ASR or any of that nonsense.

I know it will not seem like a DNS issue. But anytime you get a resolution "host/" it IS a name resolution error. It isn't resolving your hostname. And unless you are logging everything and it only shows up ONCE in the event as a warning, not even an error. You may not see it and I think other conditions can cause this. For example, NEVER EVER EVER EVER EVER rely on the AD wizard to create DNS. But if you do not have it set up before AD enumeration and for some reason netlogon is running or doesn't get started (maybe disabled), the domain and the DC will not get registered properly and it has the potential to get super screwed. I for one do not like relying on replication or DDNS to fix this or add it, as I have seen by this "Dynamically Update Pri. DNS Suffix" unreliability. Because even after dcpromo for some reason the DC's host dame wan't properlyly registered with DNS. By manually populating that field befor DNS installation and AD creation, it seems to resolve the problem. But I was able to confim that hostnames weren't registered properly, y cross-referanceing to the WINS database. The fix (at least in my case) isn't too bad and very similar to the methods for correcting AD name registration issues (i.e. no DNS for AD). This seemed to completely resolve it for me, as I have squeaky clean event logs (minus the w32 time, cause I am too lazy to configure filters on my ISA server ;) ). Typically if you are having issues with Kerberos or AD, even GPO's, it can be traced to name resolution configuration errors. At least 80% of the time in my experience. But this sort of problems, get more complex as they replicate and "poison the well" so to speak. So this is what I did to resolve the problem. Of course, on production/mission critical machines, BACKUP BACKUP BACKUP. Hell image the *uckers. You will want to do this for all DCs, if one is located over a WAN link, and you cannot image, do a backup/shadow copy. I demoted all subordinate DCs (maybe keep one off the network, as is as a CYA) and configured all WINS servers for pull replication. For DNS server, you will want to do same, as outlined below, to all DNS servers. I didn't try setting them up just to receive zone transfers, which may work too. All of this is done on the "Master/Primary" DC. This is on the assumption of one namespace and used for internal and forwarding DNS services.

1.Backup, rdisk, image, whatever
2. IF DHCP is used for Dynamic Update of DHCP clients, verify that a user account has been created to facilitate this and configured with in DNS and has appropriate rights and permissions
3. Isolate DC on vacant segment (VLAN, physical separation, etc.)
4. Backup all GP's
5a.Verify that the host has a Primary DNS suffix (it should be the domain root), if not you are going to have enter it and restart, then go to the next step (4b)
5b.Make sure that the following services depend on DNS to start:
6. Stop or pause unnecessary services (write down what services are stopped)

1. WINS part I
NOTE: Make sure Remote Registry service is running or you will not be able to manage WINS
-Purge all WINS registrations
-Stop WINS
-nbtstat -R <all for good measure>

2. DNS part I
-Delete the forward and reverse DNS zones
-Clear DNS cache
-Stop DNS and if the above services do not also stop, manually stop those services as well (other dependant services will stop) NOTE: Write down what services are stopped
-ipconfig /flushdns <all for good measure>
-delete <%windir%>\system32\dns\cache.dns
-rename <%windir%>\system32\dns\*.log *<%date%>.000
-rename <%windir%>\system32\driver\lmhosts lmhst<%date%>.000
-rename <%windir%>\system32\driver\hosts hst<%date%>.000
3.Uninstall DNS and WINS
4.Reinstall DNS (have your install disk handy)

NOTE: any step marked with a "<G*>" is ONLY FOR SBS users or Multi-Homed *WITH* ISA and or NAT (i.e. internet access/gateway/proxy/firewall/edge/bastion servers) with AD and DNS on the same host (excluding SBS, don't ask, cause I don't know either)
1.Make sure you TCP/IP DNS settings are correct
-point to itself as the DNS server
-register with DNS
-append parent DNS suffix
-Disable and enable adapter

-The above interface config applies to the internal interface
External Interface:
-Use the internal adapter address as the primary DNS server
-DO NOT USE CONNECTION SPECIFIC SUFFIX IN REGISTRATION, in fact do not register this interface at all, depending on your configuration, more than likely no need to register with your ISPs (if they care or if they CAN) DNS
-Do NOT append parent suffix (no need to dissect queries on the external interface)
-Disable and enable adapter

IV.DNS part II
1a.Specify Interfaces for DNS to listen on
<G*>1b. Should only be your internal adapter
2.Leave forwarders alone for now
3.Make sure the DHCP dynamic update account or parent group of that account has appropriate permissions
4.Create a Reverse Lookup Zone
-Use the default zone name
-Primary Zone
-Store in AD
-Replicate as needed, typically all DNS server in the AD domain your.domain
-Dynamic Updates, SECURE ONLY (ESPECIALLY IMPORTANT for multihomed, internet accessible servers)
-For now, Name Servers should list your FQDN and IP (without asterisk) ONLY
-WINS-R, enable but do not replicate this record, use the root domain and increase the cache timeout in respect to your DHCP lease time
-Allow Zone X-fers only to servers on the NS list (it should be this HOST on that list)
5.Create Forward Lookup Zone
-Use the domain root
-Primary Zone
-Store in AD
-Replicate as needed, typically all DNS server in the AD domain your.domain
-Dynamic Updates, SECURE ONLY (ESPECIALLY IMPORTANT for multihomed, internet accessible servers)
-For now, Name Servers should list your FQDN and IP (without asterisk) ONLY
-Forward WINS, use but do not replicate this record, use host IP (<G*> internal) to point to your WINS server, again, increase the cache time-out logically based on DHCP lease time
-Allow Zone X-fers only to servers on the NS list (it should be this HOST on the list)
6.Check the zone you just created it should show at least:
<%hostname%> A x.x.x.x (your IP or <G*> internal IP, delete the external, if shown)
(Same as Parent) WINS Lookup [x.x.x.x]
(Same as Parent) NS <%FQDN%>
-If not, create them
-go ahead and double click on the you’re a record and click create PTR and do the same for WINS
7.If used, add your forwarders at this time and select disable recursion if forwarding to ISP DNS for internet resolution (no need to devolve those queries)
8.Restart DNS
<G*>9.On the internal adapter TCP/IP properties, leave Specify DNS servers selected but delete the entry, (it will notify you that it will use itself since DNS server services are installed), disable and enable adapter

V.WINS part II
1.Install WINS, configure to auto-update stats, and backup
2.Preventatitve measure, verify the database periodically
3.Restat WINS

VII. AD DNS registrations
1.Start LanManWorkstation, LanManServer, Browser, DFS, DNScache, WINS, NetLogon
2a.ipconfig /registerdns
2b.nbtstat -RR
3.netdiag /dcaccountenum
4.netdiag /fix
5.dcdiag /fix
6.acldiag /chkdeleg /fixdeleg
8.restart computer (brevity)
9.test and make sure netlogon updated DNS and the domain controller and AD are happy
10.If all is good; push WINS to all partners from THIS server and replicate the DNS zone to all secondary/subordinate DNS server and DCs
11.If this doesn’t help, I can only think of doing a AD Recover…

DISCLAIMER: This is by no means complete and considering I only “play” late at night, in my exhaustion I may have missed some steps, although largely it is complete. Use common sense when doing this; I do not know your environment and/or configuration. USE AT YOUR OWN RISK. This is just a process that worked for me. If I missed something please, email me and I will comment the article and reference your name and contact info (if you wish) for accreditation. This is free for anyone to use at home, school or work. You may copy the text for distribution as you see fit and archive it for personal reference. YOU MAY NOT PUBLISH, SELL OR PLAGERIZE this document or content herein without written explicit permission from both the author and contributors (if/when others contribute and/or comment). However your may reference it for research providing disclosure of sources is included. In other words don't plagerize.
©2003 Copyright Eric A. Pelton

Out of curiousity, if this happens again to anyone, check WINS and both DNS zones for a record resolving to

There has beed added comments on the link posed above.
Close this topic or reply!


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.