Re: Kerberos machine authentication - apparent authentication fail
From: JCB_MCSE_wannabe (JCBMCSEwannabe_at_discussions.microsoft.com)
Date: 06/15/05
- Previous message: Joe Richards [MVP]: "Re: Win2003 SP1 remotely restart service"
- In reply to: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: Tim: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Wed, 15 Jun 2005 08:01:11 -0700
Steven:
Okay, I'm back from traveling and have had the opportunity to revisit this
issue. Hopefully, you still have this thread set to notify you of
replies.....
Bottom line - you were correct in the first place. Due to some hasty
initial testing on my part I drew some false conclusions. However, when I
lab on my home office network, I take explicit notes of my actions as a
go-back and to be able to reproduce suspect results for further study.
I can now absolutely tell you that the reason for the authentication
failures is due to the laptop wireless adapter not initialiazing fully
(Linksys WPC54G, version 2.0) until a user logon event. When a user logs on,
then and only then does the adapter call for it's DHCP address and scope
options, as evidenced by Ipconfig and the little tray icon that indicates the
adapter is acquiring an address. The user is authenticated at this point.
However, the Netdiag utility will show the Kerberos error in this scenario
because the network isn't available when the machine boots.
BUT TAKE NOTE - this behavior is adapter/driver-dependent. On my
workstation machines, I am using a Linksys WMP54G, version 4.0 adapter/driver
(with the obvious antenna sticking out of the tower!). On these machines I
see the same start-up/logon sequence as with a hard-wired workstation -
namely, "Please wait....Preparing Network Connections...." followed by
"Applying Computer settings" and/or "Applying Security policy" after which
the ctrl +alt +delete screen appears. Upon using my domain login creds, then
I see "Applying User settings". Once I observed differences in boot/login
behavior, I knew the laptops COULD NOT be authenticated by Kerberos because
you don't see the "Preparing network connections" screen on them. Clearly,
the workstation adapters are fully initialized before a user CAN logon and by
that time the machine is already authenticated. When I logon to a
workstation I have an immediate result with Ipconfig - further evidence that
the NIC is fully initialized by the time I logon, rather than acquiring DHCP
settings after supplying user credentials. I will contact Cisco/Linksys to
see if an alternate driver is available for the laptop NICs.
All of my Event logs and NetMonitor captures support this conclusion
exactly. In fact, I was tearing my hair out trying to figure out why I was
experiencing apparent inconsistent application of Group Policy. The ultimate
reason is also because the laptops are not authenticated before a user logs
on and thus do not receive the "Computer settings" from GPOs until a Gpupdate
command or normal refresh.
I have learned quite a lot about the logon process in a domain environment
as a result of this and indirectly a lot about GPO linking and process
ordering (thanks to Gpresult.exe and RSOP.msc).
Steven, thank you for setting me on the right path to my own troubleshooting
solution and VERIFICATION. Through this problem (opportunity?) I gained
quite a bit of skill using the informnation from my logs and especially the
NetMon utility all of which would not have been possible had you not offered
me a plausible starting point to solve my Kerberos authentication problem.
By the way I did download Ethereal as you suggested but have not yet had time
to fool with it.
-- JCB\1059 "Steven L Umbach" wrote: > From what I can tell the kerberos failure shown in netdiag does not always > mean that kerberos authentication is not being used. I have seen the same > thing as you mention in the past but the failure always relates to a > kerberos ticket for host\domain name as not being found. I am not a kerberos > expert and am not quite sure of the significance of the host\domain ticket > for a domain member. I have seen that error yet my logs on the domain > computer for logon events and the domain controller for account logon events > do show that the computer/user is using kerberos. The next time you see that > error run the command netdiag /test:kerberos /debug to see if any kerberos > tickets are shown. If kerberos is being used you should probably see three > or more tickets for krbtgt, cifs, and ldap for instance. The RK tools klist > and kerbtray are also very helpful in seeing exactly what kerberos tickets > are being used if any. They are available at the link below and work on > Windows 2003 and XP Pro. Below is an example of klist output from a server > of mine.--- Steve > > http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en > > E:\Program Files\Windows Resource Kits\Tools>klist tickets > > Cached Tickets: (5) > > Server: krbtgt/UMBACH3.COM@UMBACH3.COM > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) > End Time: 6/1/2005 6:52:39 > Renew Time: 6/7/2005 20:52:39 > > > Server: krbtgt/UMBACH3.COM@UMBACH3.COM > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) > End Time: 6/1/2005 6:52:39 > Renew Time: 6/7/2005 20:52:39 > > > Server: cifs/server1-2003.umbach3.com@UMBACH3.COM > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) > End Time: 6/1/2005 6:52:39 > Renew Time: 6/7/2005 20:52:39 > > > Server: ldap/server1-2003.Umbach3.com/Umbach3.com@UMBACH3. > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) > End Time: 6/1/2005 6:52:39 > Renew Time: 6/7/2005 20:52:39 > > > Server: host/server1-2003.umbach3.com@UMBACH3.COM > KerbTicket Encryption Type: RSADSI RC4-HMAC(NT) > End Time: 6/1/2005 6:52:39 > Renew Time: 6/7/2005 20:52:39 > > "JCB_MCSE_wannabe" <JCBMCSEwannabe@discussions.microsoft.com> wrote in > message news:900B2CA8-A4F2-48C7-8738-7390D9DC5B95@microsoft.com... > > 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. > >> > > >> > > >> > >> > >> > > >
- Previous message: Joe Richards [MVP]: "Re: Win2003 SP1 remotely restart service"
- In reply to: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: Tim: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
|
