Kerberos machine authentication - apparent authentication failures

Discussion in 'Server Security' started by JCB_MCSE_wannabe, May 30, 2005.

  1. 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.
    JCB_MCSE_wannabe, May 30, 2005
    1. Advertisements

  2. 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;en-us;291382

    Steven L Umbach, May 30, 2005
    1. Advertisements

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


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

    Another downside of not having the computer account
    - 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!
    - 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)
    - Now I understand the IPSec negotiation errors I have been seeing with

    Also keep in mind that the netdiag
    - You are correct!

    Also since you are
    - 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.

    Many thanks, JCB

    JCB_MCSE_wannabe, May 31, 2005
  4. Reply in line.

    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.;en-us;305293&Product=winxp
    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.
    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.
    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
    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.;en-us;Q254949
    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

    Steven L Umbach, May 31, 2005
  5. Thanks once again. I will watch out for the IPSec conflicts you cautioned
    about as well.

    This dialog has been most helpful.


    JCB_MCSE_wannabe, May 31, 2005
  6. JCB_MCSE_wannabe

    Tim Guest

    Dear folks,

    One thing I noticed is that the start setting for Wireless device driver
    tends to be "3" which is something like User Logon. I changed mine to 2
    (something like ~= as a service) with no adverse effects (dynalink and intel
    2200bg with a d-link WAP) and setup 802.1x. With 802.1x and Windows Wireless
    zero config (IE not a 3rd party user world application that does not start
    until logon), the wireless connection can kick off when it is ready. This
    was confirmed in the server event logs with IAS (i set that up as the radius
    server for the WAP) reporting that the machine is authenticating prior to
    logon and the errors you are discussing disappeared - almost totally I
    think. If I logon too quickly after say the laptop boots then I think errors
    can still occur as the machine is too busy to get all the above done prior
    to me interfering with what it is doing by logging on. So, may be a few
    tweaks on service dependancies and so on and it can go 100%.

    The thing that now happens is a slightly slowed down equivalent of LAN
    machine authentication - I suspect there may be one warning left in the
    event log. When I as a user logs on the default option of re-authenticating
    as an ordinary user kicks in and takes over from the machine authentication.
    With the Intel 2200BG this has been totally reliable, the dynalink has
    settled down now too I think (tinkered with firmware, drivers and "things").

    Previously it was as you are describing / experiencing - a pregant pause
    while the network sorts itself out and a double click on a network link of
    any sort will turn into a tedious wait while the wireless things would do
    their stuff.

    - Tim

    Tim, May 31, 2005
  7. Tim:

    Many thanks. Can you tell me where I can view/configure my wireless NIC
    "start-up settings" you described?

    Might this entire problem have been avoided if I had used Windows' wireless
    configuration utility instead of the Linksys software? After all, the
    Linksys components I am using were probably intended for workgroup/home
    networks, not an AD-domain deployment as I have.

    JCB_MCSE_wannabe, May 31, 2005
  8. 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

    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_MCSE_wannabe, May 31, 2005
  9. 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

    E:\Program Files\Windows Resource Kits\Tools>klist tickets

    Cached Tickets: (5)

    Server: krbtgt/
    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/
    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/
    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/[email protected]
    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/
    KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
    End Time: 6/1/2005 6:52:39
    Renew Time: 6/7/2005 20:52:39

    Steven L Umbach, Jun 1, 2005
  10. 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_MCSE_wannabe, Jun 1, 2005
  11. JCB_MCSE_wannabe

    Tim Guest

    You have to go into the registry. If you are not conversant with the
    registry, device driver settings, and so on then I would suggest you be
    prepared to do a restore / resinstall if you utterly stuff up the process.
    You could render your windows system unbootable. (Don't forget there is the
    boot option available by F8 called Last Known Good if you make a small

    To locate the device name:

    Start, Settings, Control Panel, System, Hardware, Device Manager.

    Locate your wireless device - typically under Network Adapters.

    Double click on it, Click the Driver tab.
    Click the Driver Details button.

    More than one file may be listed. The file of interest is typically .sys and
    listed at the top.

    EG for mine it is rt2500usb.sys

    So, the device driver is likely called rt2500usb.

    Start, run, regedit



    locate the service entry for your wireless device driver & click on it.

    If you can't find the device driver entry, bail out and give up. Do some

    To play it safe, before you make any changes with regedit, you can *right*
    click on the Key (rt2500usb in this case) and click *Export* to take a
    backup of the registry key you are about to change. Save the file somewhere
    safe - if you double click on it, it will restore the OLD settings.

    On the right hand side you should see something like this:

    DisplayName = RT2500 USB Wireless LAN Driver
    ErrorControl = 1
    ImagePath = system32\drivers\rt2500usb.sys
    Start = 3
    Tag = 13
    Type = 1

    Change Start from 3 to 2. DO NOT CHANGE ANYTHING ELSE!
    If for example you changed error control to a different value, one of the
    values means crash close windows if this driver does not start (a stop code
    will appear on a BSOD).

    You will need Wireless zero config for this to help.

    - Tim

    Tim, Jun 1, 2005
  12. JCB,

    I just wanted to let you know there is a known bug in netdiag that reports
    this error.;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

    Glenn LeCheminant, Jun 6, 2005
  13. 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.


    JCB_MCSE_wannabe, Jun 6, 2005
  14. Steven:

    Okay, I'm back from traveling and have had the opportunity to revisit this
    issue. Hopefully, you still have this thread set to notify you of

    Bottom line - you were correct in the first place. Due to some hasty
    initial testing on my part I drew some false conclusions. However, when I
    lab on my home office network, I take explicit notes of my actions as a
    go-back and to be able to reproduce suspect results for further study.

    I can now absolutely tell you that the reason for the authentication
    failures is due to the laptop wireless adapter not initialiazing fully
    (Linksys WPC54G, version 2.0) until a user logon event. When a user logs on,
    then and only then does the adapter call for it's DHCP address and scope
    options, as evidenced by Ipconfig and the little tray icon that indicates the
    adapter is acquiring an address. The user is authenticated at this point.
    However, the Netdiag utility will show the Kerberos error in this scenario
    because the network isn't available when the machine boots.

    BUT TAKE NOTE - this behavior is adapter/driver-dependent. On my
    workstation machines, I am using a Linksys WMP54G, version 4.0 adapter/driver
    (with the obvious antenna sticking out of the tower!). On these machines I
    see the same start-up/logon sequence as with a hard-wired workstation -
    namely, "Please wait....Preparing Network Connections...." followed by
    "Applying Computer settings" and/or "Applying Security policy" after which
    the ctrl +alt +delete screen appears. Upon using my domain login creds, then
    I see "Applying User settings". Once I observed differences in boot/login
    behavior, I knew the laptops COULD NOT be authenticated by Kerberos because
    you don't see the "Preparing network connections" screen on them. Clearly,
    the workstation adapters are fully initialized before a user CAN logon and by
    that time the machine is already authenticated. When I logon to a
    workstation I have an immediate result with Ipconfig - further evidence that
    the NIC is fully initialized by the time I logon, rather than acquiring DHCP
    settings after supplying user credentials. I will contact Cisco/Linksys to
    see if an alternate driver is available for the laptop NICs.

    All of my Event logs and NetMonitor captures support this conclusion
    exactly. In fact, I was tearing my hair out trying to figure out why I was
    experiencing apparent inconsistent application of Group Policy. The ultimate
    reason is also because the laptops are not authenticated before a user logs
    on and thus do not receive the "Computer settings" from GPOs until a Gpupdate
    command or normal refresh.

    I have learned quite a lot about the logon process in a domain environment
    as a result of this and indirectly a lot about GPO linking and process
    ordering (thanks to Gpresult.exe and RSOP.msc).

    Steven, thank you for setting me on the right path to my own troubleshooting
    solution and VERIFICATION. Through this problem (opportunity?) I gained
    quite a bit of skill using the informnation from my logs and especially the
    NetMon utility all of which would not have been possible had you not offered
    me a plausible starting point to solve my Kerberos authentication problem.
    By the way I did download Ethereal as you suggested but have not yet had time
    to fool with it.

    JCB_MCSE_wannabe, Jun 15, 2005
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.