Re: Kerberos machine authentication - apparent authentication fail

From: JCB_MCSE_wannabe (JCBMCSEwannabe_at_discussions.microsoft.com)
Date: 06/01/05


Date: Tue, 31 May 2005 15:51:43 -0700

Steven:

I thought we proved the Linksys wireless switch/router/gateway was the
reason for my non-authentication with Kerberos (K) because I got a PASSING
Kerberos result when I hardwired a laptop to a switch port. However, today
the K failure is being reported for the HARDWIRED laptop.

Also, I started another laptop and logged on normally. The K error was
observed as anticipated. I then simply left the machine on while the wife
and I went out for dinner. Upon returing and running Netdiag, I was now
receiving a PASSING K result. This suggests that the machine continues to
authenticate with K after initial failures. (I DO have IPSec policies
assigned, if this matters), not unlike a NIC will call for a DHCP server
after initially receiving an APIPA address assignment (every 5 minutes, I
think)

So I guess there is now a twist to the problem - hardwired machines can fail
to authenticate with K on reboot AND authentication appears to take place
after an initial failure. Is there any MS documentation to support my
observations - i.e., is there a timed retry period for K authentication? AND
what might account for the subsequent K failure for the hardwired machine?

I'll try any labbing experiments you can think of to elucidate the cause of
this behavior.

-- 
JCB\1059
"Steven L Umbach" wrote:
> When you joined your computer to the domain your wireless network card was 
> initialized and working properly. However when you reboot your computer the 
> network card does not initialize fast enough in order to have the computer 
> authenticate to the domain. The computer does not necessarily need to 
> authenticate to the domain resources in order for a user to access domain 
> resources particularly if cached logons are enabled. With cached logons you 
> are logged with cached domain credentials to the local computer. When you 
> try to access domain shares while logged on with cached credentials you are 
> denied access until you can authenticate to a domain controller as a user. 
> By the time you attempt such your network card is probably initialized and 
> thus you can access the domain controller, be authenticated, and then access 
> a domain share. Another downside of not having the computer account 
> authenticated to the domain is that the computer configuration Group Policy 
> will not be applied/refreshed at startup.
> 
> You should have logging of account logon events enabled in Domain Controller 
> Security Policy which it is by default in Windows 2003 and also enable 
> auditing of logon events on your domain computers which may also provide 
> helpful information including if cached logons are being used. The set 
> command when run on a domain computer will also show the authenticating 
> computer/domain controller.
> 
> While kerberos is the default authentication protocol of choice, fallback 
> can be done to lm/ntlm/ntlmv2 in a Windows 2000/2003 domain. Kerberos 
> failure is not usually as problematic as is problems with the computer 
> account as shown by errors/failed test with trust/secure channel as shown 
> with netdiag. Kerberos authentication for the "computer" is however required 
> for domain negotiation ipsec policy using ESP/AH if using default 
> authentication for the ipsec policy. Also keep in mind that the netdiag 
> /debug switch may also give more detailed info on why a test failed.
> 
> I bet that if you hard wire one of your domain computers to the network that 
> you will not see the problem with kerberos anymore. Also since you are 
> interested in troubleshooting you will find packet sniffing very helpful for 
> a problem such as yours or many other problems. In your case monitoring 
> packet activity on the domain controller while a domain computer is booting 
> up will tell a lot, particularly if you have a capture of a successful 
> domain computer account logon to compare to. Windows 2003 Server has the 
> built in netmon though I personally much prefer Ethereal which is free. Also 
> dns configuration for the domain MUST be correct or all sorts of problems 
> will ensue. The first link below is a good quick read on dns for an Active 
> Directory domain and the second is on troubleshooting kerberos errors which 
> can be displayed in the security logs of domain controllers.  --- Steve
> 
> http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technologies/security/tkerberr.mspx
> 
> 
> "JCB_MCSE_wannabe" <JCBMCSEwannabe@discussions.microsoft.com> wrote in 
> message news:5EDF6C37-EDA1-4889-803F-AF8CB8FCB878@microsoft.com...
> > NOTE:  This post was incorrectly posted under "Access Security" 
> > previously.
> > I misinterpreted the topic as resource access, not MS Access database
> > product...oh well!....
> >
> >
> > I am new to networking.  I recently built a small AD-integrated DNS domain
> > network for labbing purposes using my TechNet Plus Server 2003 Ent. OS. 
> > The
> > single server is also running DNS and DHCP.  All of my clients (yeah, all 
> > SIX
> > of them - I did say SMALL!) are running XPsp2.  Hosts connect to the 
> > network
> > using wireless cards through a linksys NAT-enabled router/switch.  The 
> > server
> > is hard wired to one of the switch ports on the linksys.  I am using 
> > 128-bit
> > WEP encryption
> > and further control access using a MAC table of allowed hosts on the
> > wireless.  Three machines are workstations and three are laptop/portables.
> >
> > I successfully joined the client machines to the domain.  They receive
> > DHCP-assigned IP addresses.  However, when I run the Netdiag commmand, I
> > receive PASSING results for all tested parameters, EXCEPT the Kerberos 
> > test
> > which gives a:        " [FATAL] Kerberos does not have a ticket for
> > host/mymachinename.mydomainname"       result.
> >
> > The strange thing is that immediately after I joined the machines to the
> > domain and ran Netdiag, a PASSING Kerberos result is obtained.  HOWEVER, 
> > once
> > the machines are restarted, the Kerberos test yields a consistent FAILED
> > status.  With Server2003/XP, I thought Kerberos v.5 was the default
> > authentication protocol.  If my machine is not being authenticated, how 
> > come
> > I can still access domain resources?  Should my audit logs show a "logon"
> > event instead of an "account logon" event if my machine is not 
> > authenticated?
> >
> > Does anyone have an explanation?  I would prefer guidance on how to
> > efficiently troubleshoot this problem and not just a "here, do this"
> > solution.  The REAL problem is I don't yet have the troubleshooting skills
> > to effectively address the apparent Kerberos authentication failures.
> >
> > Any help would be appreciated.
> >
> > 
> 
> 
> 


Relevant Pages