Re: Kerberos machine authentication - apparent authentication fail
From: Glenn LeCheminant (the.only(delete)_at_gmail)
Date: 06/06/05
- Next message: Jon: "Re: NT4 user account recovery"
- Previous message: Glenn LeCheminant: "Re: NT4 user account recovery"
- In reply to: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Reply: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sun, 5 Jun 2005 20:33:35 -0700
JCB,
I just wanted to let you know there is a known bug in netdiag that reports
this error.
http://support.microsoft.com/default.aspx?scid=kb;en-us;870692
Sorry if this has already been mentioned in this thread....too much info to
go through to find out :-)
-- Glenn LeCheminant CCNA, MCSE 2000/2003 + Security "JCB_MCSE_wannabe" <JCBMCSEwannabe@discussions.microsoft.com> wrote in message news:E863952E-26D3-4A5E-A989-AEFB3FE88E51@microsoft.com... > Steven: > > I installed the Resource Kit. I will explore the additional CMD line > tools > you mentioned. And thanks once again. You must REALLY enjoy what you do! > -- > 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. >> >> > >> >> > >> >> >> >> >> >> >> >> >>
- Next message: Jon: "Re: NT4 user account recovery"
- Previous message: Glenn LeCheminant: "Re: NT4 user account recovery"
- In reply to: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Next in thread: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Reply: JCB_MCSE_wannabe: "Re: Kerberos machine authentication - apparent authentication fail"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
