Re: Kerberos machine authentication - apparent authentication fail

• Previous message: Steven L Umbach: "Re: VPN and Windows 2003 Server"
• In reply to: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
• Next in thread: Glenn LeCheminant: "Re: Kerberos machine authentication - apparent authentication fail"
• Reply: Glenn LeCheminant: "Re: Kerberos machine authentication - apparent authentication fail"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Tue, 31 May 2005 19:15:22 -0700

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.
> >> >
> >> >
> >>
> >>
> >> 
> 
> 
> 

• Previous message: Steven L Umbach: "Re: VPN and Windows 2003 Server"
• In reply to: Steven L Umbach: "Re: Kerberos machine authentication - apparent authentication fail"
• Next in thread: Glenn LeCheminant: "Re: Kerberos machine authentication - apparent authentication fail"
• Reply: Glenn LeCheminant: "Re: Kerberos machine authentication - apparent authentication fail"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]