Re: Kerberos machine authentication - apparent authentication fail

• Previous message: Tim: "Move CertServices to a new DC"
• 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"
• Reply: Tim: "Re: Kerberos machine authentication - apparent authentication fail"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Mon, 30 May 2005 22:16:48 -0500

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
>> > 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: Tim: "Move CertServices to a new DC"
• 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"
• Reply: Tim: "Re: Kerberos machine authentication - apparent authentication fail"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]