why network logon fallback to NTLM using anonymous account?

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?

 

Any takers? The title "why network logon came in as Anonymous" might
have been more accurate...

 

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