Re: Kerberos machine authentication - apparent authentication fail

From: JCB_MCSE_wannabe (JCBMCSEwannabe_at_discussions.microsoft.com)
Date: 05/31/05 

Date: Mon, 30 May 2005 20:55:01 -0700

Thanks once again. I will watch out for the IPSec conflicts you cautioned
about as well.

This dialog has been most helpful. 

-- 
JCB\1059
"Steven L Umbach" wrote:
> Reply in line.
> 
> "JCB_MCSE_wannabe" <JCBMCSEwannabe@discussions.microsoft.com> wrote in 
> message news:C0BEBF72-7A42-438D-801D-9F393ECDC17D@microsoft.com...
> > Steven:
> >
> > I was so close!  I surmised that the wireless was somehow the root cause 
> > of
> > the authentication failures, because I could watch the NIC calling for a 
> > DHCP
> > lease renewal AFTER I logged on.  I greatly appreciate you taking the time 
> > to
> > provide a thoroughly descriptive answer.  I don't know if you read my
> > profile, but I am new to networking and have gained experience with much 
> > of
> > the required skills needed to pass the MCSE certification exams. 
> > Thankfully,
> > I have the resources to build a labbing network to get much-needed 
> > hands-on
> > time with the Server product.
> >
> > But if you don't mind, let me address your replies on a point-by-point
> > basis, as you have stimulated further thought and need for clarification 
> > on
> > my part.
> >
> >
> > -- 
> > 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.
> >
> > This is absolutely correct.  However, isn't there a Group Policy setting 
> > (or
> > Local Policy, as the case may be) which will delay authentication until 
> > the
> > network is ready?
> 
> There is a Group Policy setting for fast network optimization for windows XP 
> Pro that usually [there are exceptions as stated in link below] causes a 
> user to be logged on with cached credentials, though it does not always seem 
> to work with wireless network cards that take a long time to access the 
> network. I have the same situation with my laptop and it's D-link wireless 
> card. I also have an Intel network adapter and WAP that does not have this 
> problem and even works well with 802.1X EAP-TLS for domain logon.
> 
> http://support.microsoft.com/default.aspx?scid=kb;en-us;305293&Product=winxp
> 
> >> 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.
> >
> > There is a tremendous amount of information you have provided above; let 
> > me
> > see if I fully understand the implications:
> >
> > - I understand what you mean about cached domain logons.  In fact, I have
> > just set the policy value to zero (from 10) for various reasons.  But what
> > you said next caught me off guard - that is, you are suggesting that even
> > though I am not INITIALLY authenticated, once the NIC is fully 
> > initialized, I
> > will SUBSEQUENTLY be initiated?  Is this correct?  If so, it would seem 
> > that
> > the problem I have observed would EVENTUALLY disappear upon subsequent
> > invocations of the Netdiag command - is this correct???  I CAN access net
> > shares via a UNC path on the machines that show the initial Kerberos 
> > error.
> > Hmmmm....
> >
> 
> In addition to disabling cached logons also disable fast logon optimization. 
> Another thing that could be happening is that the network connection is not 
> happening fast enough for computer authentication but it is ready for user 
> authentication which alsways happens after the attemp to authenticate the 
> computer account. If cached domain credentials are disabled and the computer 
> can not contact a domain controller when the user attempts to logon the 
> domain then the user authentication will fail and the users will get a 
> message that a domain controller can not be contataced or something to that 
> effect. Try logging onto the domain when the domain controller is either 
> shut down or disconnected from the network to see what happens. If cached 
> logons are allowed then yes the user can be authenticated to the domain 
> after a domain cached logon. Netdiag may still show kerberos errors because 
> the user has authenticated via lm/ntlm/ntlmv2 since kerberos authentication 
> failed or because the "computer account" does not have a kerberos ticket. In 
> most cases [ipsec a possible exception] kerberos authentication is not 
> needed to access domain resources as long as the client and server use a 
> common authentication method for  lm/ntlm/ntlmv2.
> 
> >
> >
> > 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.
> >
> > - Dammit!  I thought I was going crazy.  Now I understand why certain
> > (computer) policy changes I made were not applied...UNTIL normal GP 
> > refresh
> > had occured!
> >
> Group Policy is always applied or refreshed at startup for computers and 
> logon for users. Certain Group Policy elements such as Software Installation 
> can only be applied at startup/logon and redirection of folders can only be 
> done at logon.
> 
> >>
> >> 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.
> >
> > - A user logging on locally will generate a "Logon" event, while a user
> > logging on to the domain/network will be authenticated by a DC and 
> > generate
> > an "Account Logon" event.  BUT, what about the MACHINE account?  Will 
> > there
> > be an entry in the appropriate security logs indicating Logon vs. Account
> > Logon?  If so, will the log(s) first show a Logon event followed by an
> > Account Logon event, if my machine is SUBSEQUENTLY authenticated (as per 
> > my
> > comments above)
> 
> Computer account account logon events for a domain computer logon to the 
> domain will show only in the security log of a domain controller if you have 
> auditing of account logon events enabled which it is by default. I am not 
> sure offhand if a computer account will try to authenticate after failuer to 
> do so at the intitial startup. That is something you can look for in your 
> domain controller security log. It may happen if the computer tries to 
> engage in an ipsec negotiate connection which would require computer 
> authentication.
> 
> >> 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.
> >
> > - Now I understand the IPSec negotiation errors I have been seeing with
> > NetMonitor.
> 
> Be careful with ipsec policy. Most do not understand [too little 
> documentation] that domain computers and domain controllers can not 
> communicate with ipsec AH/ESP due to the fact that the domain controller is 
> also the kerberos distribution center. Domain controllers must be exempt 
> from ipsec policies for the domain that involve domain computers or all 
> sorts of problems can occur. Refer to the KB article below for more details 
> and to the Windows 2003 Deployment Kit chapter on ipsec which is a free 
> download at the second link.
> 
> http://support.microsoft.com/default.aspx?scid=kb;en-us;Q254949
> http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/DepKit/119050c9-7c4d-4cbf-8f38-97c45e4d01ef.mspx
> 
> >
> > 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.
> >
> > - You are correct!
> >
> > 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
> >>
> > - I have not experienced many DNS errors (probably because I chose an
> > AD-integrated DNS implemnentation - which seems to be quite simple).  One
> > annoying problem, confirmed by monitoring, was that after removing Root 
> > Hints
> > from the DNS server and disabling recursion for the domain (NOT the 
> > server),
> > my server was STILL resolving on the internet.  I had configured 
> > Forwarders
> > to my ISP's DNS servers for "all other domains", so as to hide my server 
> > (as
> > much as possible) and to put the work of resolution off on my ISP (or so I
> > thought).  But each time I would reboot the server (which I do a lot for
> > labbing, probably FAR more than would ever be done in a production
> > environment), the Root Hints table was persistently repopulated. 
> > Apparently,
> > this table cannot be void, so I entered my SOA server as a root hint. 
> > This
> > has fixed the problem, but was certainly NOT an intuitive solution! (at 
> > least
> > for a newbie like myself)
> >
> > Thanks for you spot-on technically accurate response.  If you have any
> > thoughts on the points I raised above, I'd love to learn more from you.
> 
> You can still have dns problems with an AD domain. The main issue is to 
> NEVER include an ISP dns server in the preferred server list in the tcp/ip 
> properties or DHCP scope of any domain computer or any computer you want to 
> join to the domain in which case your computers may be trying to locate the 
> domain _srv records on the ISP dns server and fail.  I would not worry about 
> the root hints table. If you have disabled recursion for the domain then 
> your dns server should be a slave to your ISP dns server and never use root 
> hints which will work fine as long as your ISP dns servers respond to dns 
> requests from your network. Even if your dns server does use root hints your 
> dns server should be at very little risk as long as your firewall is 
> blocking incoming destination port 53 udp/tcp to your dns server.
> 
> It looks like you are well on your way to learning material for the MCSE as 
> you want to learn "hands on" and have a thirst for knowledge which is a huge 
> plus.  --- Steve
> 
> 
> > Many thanks,  JCB
> >
> >
> >> 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

Relevant Pages

  • Re: Kerberos machine authentication - apparent authentication fail
    ... >> When you joined your computer to the domain your wireless network card ... as the case may be) which will delay authentication until ... In addition to disabling cached logons also disable fast logon optimization. ... NEVER include an ISP dns server in the preferred server list in the tcp/ip ...
    (microsoft.public.windows.server.security)
  • Re: Kerberos machine authentication - apparent authentication fail
    ... > until logon), the wireless connection can kick off when it is ready. ... > was confirmed in the server event logs with IAS (i set that up as the radius ... > as an ordinary user kicks in and takes over from the machine authentication. ... > while the network sorts itself out and a double click on a network link of ...
    (microsoft.public.windows.server.security)
  • Re: MSFT Bans insecure hashes - was"Passwords with Lan Manager (LM) under Windows"
    ... After I pointed out that "IPsec based auth" is not a basic netlogon ... authentication protocol like Kerberos, LM, NTLM and NTLMv2, you said I was ... based auth" to authenticate the request as opposed to LM, NTLM, or NTLMv2. ... Up to 75% of cyber attacks are launched on shopping carts, forms, ...
    (Pen-Test)
  • RE: Passwords with Lan Manager (LM) under Windows
    ... A device's security associations are contained in its Security Association Database ... Internet Protocol Security (IPSec) provides application-transparent encryption services for IP network traffic as well as other network access protections for the Windows 2000 operating system. ... As for "article you reference does indeed use the phrase "IPSec Authentication," but as any who reads it ...
    (Pen-Test)
  • Re: Logon 529 Errors
    ... Authentication in SMTP virtual server. ... These are almost surely SMTP logon attempts, ... Caller User Name: DELLSERVER$ ...
    (microsoft.public.windows.server.sbs)