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...<span style="color:blue">

> Any takers? The title "why network logon came in as Anonymous" might

> have been more accurate...</span>

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

http://support.microsoft.com 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

http://support.microsoft.com for regional support phone numbers.