1. Welcome Guest! In order to create a new topic or reply to an existing one, you must register first. It is easy and free. Click here to sign up now!.
    Dismiss Notice

why network logon fallback to NTLM using anonymous account?

Discussion in 'Windows Home Server' started by strongline, Aug 27, 2009.

  1. strongline

    strongline Guest

    I have multiple w2k3 file servers, most of them are always working. A
    few of them, however, make me scratch my head. I will list what I
    observed in bulletpoints:

    + when issue occurs, "net use" against the problematic file server
    returns "the password is invalid" then access denied
    + It happens only when a client workstation's "local system" account
    is used to access the share. E.g., if I access the share as myself,
    there is never problem. However, if I open up a cmd.exe window using
    AT command, then access the same share, it (may) fail with above error
    message
    + On the server side, I found that whenever access is denied, the
    workstation computer account logs in as Anonymous/NTLM. On contrast,
    whenever access is sucessful, the workstation computer account logs in
    as itself/Kerberos (this info is obtained from event id 540). In
    other words, when client computer account is able to get a kerberos
    ticket, it succeeds, otherwise it logs in as anonymous and denied.
    + Frequency: 1 server(almost always), 2 servers (half of the time),
    the rest (never, or I didn't test enough time to observe any incident)
    + All servers have same security policy (or at least they supposed
    to) because they receive GPOs from domain - they are under same OU. I
    actually compare security settings between a good and the bad side by
    side

    Question:
    1. why would a logon request fallback to ntlm? the same computer
    account has other kerberos ticket from others resources/DC
    2. under what conditions will a network logon fallback?
    3. most importantly, why it's intermitent?
     
  2. Any takers? The title "why network logon came in as Anonymous" might
    have been more accurate...
     
  3. "future2Bunknown" <johnlan@gmail.com> wrote in message
    news:b5685d6e-02ea-4619-b3f0-a3a91f2b5566@b18g2000vbl.googlegroups.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
    > Any takers? The title "why network logon came in as Anonymous" might
    > have been more accurate...<!--colorc--><!--/colorc-->


    Not that I am a "taker" on this, but what I can say, and this is because
    you've only posted symptoms and no config info, therefore without knowing
    your AD infrastructure, how you've configured the server's DNS addresses,
    how your AD Sites are setup, what event log errors are on the DCs
    workstations, and clients (Kerberos, LSA or any of the logs ), how long the
    workstation's been logged on without a restart or logoff/logon, the
    security settings set in the GPO on the OU, firewall settings, if anything;s
    been denied in AD or curtailed (due to security precautions or
    restrictions), who's currently logged on to the workstation or the server
    (whether it is the built in administrator account or an admin account that's
    been delegated), and much more, it is difficult to tell.

    I can say that I've seen *similar* issues when there are restrictions in AD
    (no matter where), that when a user account has been logged on past the
    ticket refresh, that it can't renew the ticket, and turns into an anonymous
    request, hence an access denied. This is for all non-default administrator
    accounts. It doesn't happen with the defaul built-in administrator account.
    So even if you have been logged on with a delegated account, it may still
    not be able to renew the ticket, and resulting in LSA 49601 errors that will
    result in 1030 errors, and others. This also happens when a logged on
    delegated account is RDP'd into a server and simply disconnects where a week
    later we see these errors. What's the fix? If this is what's going on, not
    sure, but logging off the server and logging back in again, and making sure
    that any admins logoff and not disconnect, will alleviate the issue on the
    servers, but as far as workstations, if they remain logged on for any
    extended period of days, it will happen, and you will need to restart the
    machine. I worked at one installation as an Exchange engineer, however I did
    not have AD access. There were issues similar issues on the workstations,
    and we believed they were related to restrictions in AD, but we were not
    able to pinpoint the root cause. We simply had users restart their machines
    when they complained when they were getting

    I don't know if this was helpful or not, but I hope it gives you general
    things to look for.


    --
    Ace

    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Please reply back to the newsgroup or forum for collaboration benefit among
    responding engineers, and to help others benefit from your resolution.

    Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
    Microsoft Certified Trainer

    For urgent issues, please contact Microsoft PSS directly. Please check
    for regional support phone numbers.


    --
    Ace

    This posting is provided "AS-IS" with no warranties or guarantees and
    confers no rights.

    Please reply back to the newsgroup or forum for collaboration benefit among
    responding engineers, and to help others benefit from your resolution.

    Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
    Microsoft Certified Trainer

    For urgent issues, please contact Microsoft PSS directly. Please check
    for regional support phone numbers.
     

Share This Page