Re: Kerberos machine authentication - apparent authentication fail
From: JCB_MCSE_wannabe (JCBMCSEwannabe_at_discussions.microsoft.com)
Date: 06/01/05
- Next message: BarbS: "Script"
- Previous message: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Maybe in reply to: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Reply: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
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. > > > > > > >
- Next message: BarbS: "Script"
- Previous message: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Maybe in reply to: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Reply: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|