Re: Kerberos machine authentication - apparent authentication fail

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

Date: Mon, 30 May 2005 17:22:02 -0700

Steven:

I was so close! I surmised that the wireless was somehow the root cause of
the authentication failures, because I could watch the NIC calling for a DHCP
lease renewal AFTER I logged on. I greatly appreciate you taking the time to
provide a thoroughly descriptive answer. I don't know if you read my
profile, but I am new to networking and have gained experience with much of
the required skills needed to pass the MCSE certification exams. Thankfully,
I have the resources to build a labbing network to get much-needed hands-on
time with the Server product.

But if you don't mind, let me address your replies on a point-by-point
basis, as you have stimulated further thought and need for clarification on
my part. 

-- 
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.
This is absolutely correct.  However, isn't there a Group Policy setting (or 
Local Policy, as the case may be) which will delay authentication until the 
network is ready?
> 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.
There is a tremendous amount of information you have provided above; let me 
see if I fully understand the implications:
- I understand what you mean about cached domain logons.  In fact, I have 
just set the policy value to zero (from 10) for various reasons.  But what 
you said next caught me off guard - that is, you are suggesting that even 
though I am not INITIALLY authenticated, once the NIC is fully initialized, I 
will SUBSEQUENTLY be initiated?  Is this correct?  If so, it would seem that 
the problem I have observed would EVENTUALLY disappear upon subsequent 
invocations of the Netdiag command - is this correct???  I CAN access net 
shares via a UNC path on the machines that show the initial Kerberos error.  
Hmmmm....
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.
- Dammit!  I thought I was going crazy.  Now I understand why certain 
(computer) policy changes I made were not applied...UNTIL normal GP refresh 
had occured!  
> 
> 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.
- A user logging on locally will generate a "Logon" event, while a user 
logging on to the domain/network will be authenticated by a DC and generate 
an "Account Logon" event.  BUT, what about the MACHINE account?  Will there 
be an entry in the appropriate security logs indicating Logon vs. Account 
Logon?  If so, will the log(s) first show a Logon event followed by an 
Account Logon event, if my machine is SUBSEQUENTLY authenticated (as per my 
comments above)
> 
> 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.
- Now I understand the IPSec negotiation errors I have been seeing with 
NetMonitor.
 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.
- You are correct!
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
>
 - I have not experienced many DNS errors (probably because I chose an 
AD-integrated DNS implemnentation - which seems to be quite simple).  One 
annoying problem, confirmed by monitoring, was that after removing Root Hints 
from the DNS server and disabling recursion for the domain (NOT the server), 
my server was STILL resolving on the internet.  I had configured Forwarders 
to my ISP's DNS servers for "all other domains", so as to hide my server (as 
much as possible) and to put the work of resolution off on my ISP (or so I 
thought).  But each time I would reboot the server (which I do a lot for 
labbing, probably FAR more than would ever be done in a production 
environment), the Root Hints table was persistently repopulated.  Apparently, 
this table cannot be void, so I entered my SOA server as a root hint.  This 
has fixed the problem, but was certainly NOT an intuitive solution! (at least 
for a newbie like myself)
Thanks for you spot-on technically accurate response.  If you have any 
thoughts on the points I raised above, I'd love to learn more from you.
Many thanks,  JCB
 
> 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

  • Re: Kerberos machine authentication - apparent authentication fail
    ... > until logon), the wireless connection can kick off when it is ready. ... > was confirmed in the server event logs with IAS (i set that up as the radius ... > as an ordinary user kicks in and takes over from the machine authentication. ... > while the network sorts itself out and a double click on a network link of ...
    (microsoft.public.windows.server.security)
  • Re: Kerberos logon to Terminal Server prevents folder redirection
    ... Pass-through refers to the client browser passing through credentials to the Web Interface server; so you can still use Pass-through without enabling the option "Use Kerberos authentication to connect to servers". ...
    (microsoft.public.windows.server.security)
  • Re: Kerberos machine authentication - apparent authentication fail
    ... Subsequent Netdiag attempts after a reboot show the failed Kerberos ... >>> mean that kerberos authentication is not being used. ... >>> computer for logon events and the domain controller for account logon ...
    (microsoft.public.windows.server.security)
  • Re: Integrated Authentication with SQL
    ... On the IIS level there is no trouble authenticating with kerberos. ... problem is in when I try to flow those credentials over to the SQL server. ... Successful Network Logon: ... Authentication Package: Kerberos ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Kerberos machine authentication - apparent authentication fail
    ... Kerberos result when I hardwired a laptop to a switch port. ... to authenticate with K on reboot AND authentication appears to take place ... > denied access until you can authenticate to a domain controller as a user. ... > You should have logging of account logon events enabled in Domain Controller ...
    (microsoft.public.windows.server.security)