|
Posted by JCB MCSE wannabe on June 6, 2005, 7:22 am
Please log in for more thread options Gelnn:
Thanks. The article describes a situation different than mine, but I have
since seen documentation that says the Netdiag utility does not work with XP!
I have used it on both my Windows 2003 DC and XP hosts. I get identical
results for both; the server gives consistent passing results for all
parameters while the hosts give passing results only after joining to the
domain. Subsequent Netdiag attempts after a reboot show the failed Kerberos
result for the hosts machines.
The Windows Support tools Netdiag utility that comes with Server 2003 is
different than the one on the XP CD, but I had no luck with either.
--
JCB59
"Glenn LeCheminant" wrote:
> 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
>
> > 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!
> > --
> > JCB59
> >
> >
> > "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
> >>
> >> > 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.
> >> > --
> >> > JCB59
> >> >
> >> >
> >> > "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
> >> >>
> >> >>
> >> >> > 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.
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
| 
XML Sitemap