Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON
From: /.dz (dz_at_discussions.microsoft.com)
Date: 03/22/05
- Next message: Herb Martin: "Re: Disable Exe and Other File Types from being run/viewed"
- Previous message: Arkane: "Re: Disable Exe and Other File Types from being run/viewed"
- In reply to: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Next in thread: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Reply: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Tue, 22 Mar 2005 12:01:04 -0800
Steve:
I did not lose interest -- but I did have other things to attend to. This
particular thread has become almost a hobby with me -- so you are forewarned;
I will probably keep going until you tire of my questions; and of course, I
appreciate all the information you've already provided regardless of whether
you continue or not.
But if you elected to continue ...
When I read the last response, this is what I 'hear', right or wrong. UDP
137 is used by the client to contact a WINS server for name resolution. UDP
138 I don't understand, unless it's a port simply to listen for responses to
requests issued via UDP 137 and/or broadcasts. TCP 139 I think I understand
-- using NETSTAT I can 'see' a couple of workstations have ESTABLISHED
connections to TCP 139 on my server and recognize the 'foreign' IP address as
valid users of the system.
[By the way, if you happen to know of a relatively concise article that
describes the NetBIOS protocol, perhaps replete with dialog examples, I'd be
interested ....]
./dz
"Steven L Umbach" wrote:
> First off disabling netbios over tcp/ip will not stop null sessions but it
> may reduce them. Netbios over tcp/ip is legacy [W98/NT4.0, etc] file and
> print sharing that uses ports 137UDP/138UDP/139TCP for netbios naming,
> transport, and session services. It will use broadcasts only, if a wins
> server is not available. NBT [net bios over tcp/ip] uses port 137 UDP for
> naming for client to contact wins server, 138 UDP for browse list
> maintenance, and 139 TCP for actual file sharing. Legacy clients can only
> use NBT and if disabled will not be able to do any name resolution,
> browsing, or file sharing.
>
> Windows 2000/XP/2003 can use either NBT or CIFS [port 445TCP] and also DNS
> for name resolution of course. If NBT is disabled then Windows 2000/XP/2003
> will use DNS and port 445TCP for file and print sharing. A Windows 2000/XP
> Pro/2003 domain computer will always use dns name resolution first for any
> name resolution request. It will append parent domain suffix [or whatever
> you configure] to a non FQDN request. Windows 2000/XP/2003 in a workgroup
> however will use NBT first for name resolution for a non FQDN if it is
> enabled.
>
> Care should be taken before disabling NBT to make sure no computers or
> applications need to use it to refer to computers by name. If it is disabled
> then for 2000/XP/2003 you can still use names to refer to file shares. DNS
> FQDN will work and "flat" computer names may work if your dns can resolve
> the names by appending suffixes for domain computers. For non domain
> computers you are best using only FQDN when referring to computer names if
> NBT is disabled. While NBT is legacy technology it still is widely used in
> most of today's networks and still is required in some cases such as for
> certain configurations with Exchange and clusters I believe. --- Steve
>
>
> "/.dz" <dz@discussions.microsoft.com> wrote in message
> news:1AC558F8-332E-4CEB-BEC5-2564EB1FFB00@microsoft.com...
> > Steve:
> > As before, thank you for the explanation of the relationship between the
> > 'null sessions' and the Computer Browser service -- one less source of
> > ambiguity for me to deal with. Unfortunately, for reasons related to 'job
> > security', I am not able to investigate the 'restrict anonymous access'
> > option at this time. However, if at some point in the near future I am
> > able
> > to, I will add my experience to this dialog.
> >
> > That having been said, and if you are still willing, I'd like to return to
> > the original response you provided and ask in detail about one of the
> > other
> > points -- disabling NETBIOS over tcp/ip. I'm fairly certain that I
> > understand the premise of 'name resolution' and you've indicated that as
> > long
> > as the file-share users reference the share with either a FQDN (or
> > equivalently, the workstation TCP/IP Advanced Properties DNS settings has
> > an
> > appropriate suffix in the list that results in a FQDN), name resolution
> > should proceed OK. Question: Does this imply that NETBIOS - from the
> > standpoint of file sharing - is only needed for name resolution? There's
> > no
> > other aspect to file sharing that is dependent upon NETBIOS?
> > ./dz
> >
> > "Steven L Umbach" wrote:
> >
> >> The browser service is just one and the most common use of null sessions.
> >> However disabling the browser service simply prevents the computer from
> >> becoming a master browser or backup browser. If you can change the
> >> security
> >> option for additional restrictions for anonymous access to be no access
> >> without explicit anonymous permissions you will prevent null connections
> >> though apparently you may still see anonymous logon events in the
> >> security
> >> log as I experienced. The KB article below explains more on how to do
> >> this
> >> but be sure to read the consequences first. --- Steve
> >>
> >> http://support.microsoft.com/?kbid=246261
> >>
> >> The following tasks are restricted when the RestrictAnonymous registry
> >> value
> >> is set to 2 on a Windows 2000-based domain controller: . Down-level
> >> member
> >> workstations or servers are not able to set up a netlogon secure channel.
> >> . Down-level domain controllers in trusting domains are not be able
> >> to
> >> set up a netlogon secure channel.
> >> . Microsoft Windows NT users are not able to change their passwords
> >> after they expire. Also, Macintosh users are not able to change their
> >> passwords at all.
> >> . The Browser service is not able to retrieve domain lists or
> >> server
> >> lists from backup browsers, master browsers or domain master browsers
> >> that
> >> are running on computers with the RestrictAnonymous registry value set to
> >> 2.
> >> Because of this, any program that relies on the Browser service does not
> >> function properly
> >>
> >>
> >> "/.dz" <dz@discussions.microsoft.com> wrote in message
> >> news:6D02852B-4580-422D-A4F1-81D7CC52C8FA@microsoft.com...
> >> > Again, thanks. Here's what I know now that I didn't prior to your
> >> > response --
> >> > Your version of the 'null session' command has two less ""s in it. And
> >> > that
> >> > makes it work! So now I can indeed verify that I am able to establish
> >> > a
> >> > null
> >> > session with my server; and 'yes' it apparently does log a 538 upon
> >> > session
> >> > termination. But allow me a further quesiton: Since I have the
> >> > 'Computer
> >> > Browser' service disabled on the server, why are 'null sessions' still
> >> > allowed? I was under the impression that null sessions only existed to
> >> > facilitate the 'enumeration' of resouces that the browsing capability
> >> > supports; and therefore by disabling the Computer Browser service I
> >> > would
> >> > effectively prevent 'null sessions' from occurring. ??
> >> >
> >> > "Steven L Umbach" wrote:
> >> >
> >> >> I am experiencing something different than you are [ as shown below].
> >> >> As
> >> >> long as the security option for additional restrictions for anonymous
> >> >> access
> >> >> is NOT set to no access without explicit anonymous permissions I am
> >> >> able
> >> >> to
> >> >> create a null session. When I do have no access without explicit
> >> >> anonymous
> >> >> permissions enabled I can not create a null session and I simply get a
> >> >> system error 5 has occurred - access is denied. Even when access was
> >> >> denied
> >> >> to my null session an Event ID 538 is recorded in the security log of
> >> >> my
> >> >> server for successful anonymous logoff which indicates that these
> >> >> events
> >> >> may
> >> >> be recorded even if a null session is denied. You might want to see if
> >> >> you
> >> >> have any current sessons to your server before you try null session
> >> >> with
> >> >> "
> >> >> net use " command and delete them if there are any and try again. I
> >> >> doubt
> >> >> Client for Microsoft Networks enabled on your server is causing the
> >> >> null
> >> >> sessions to be created to your server. If your server does not need to
> >> >> logon
> >> >> to a domain or access shares/resources on other computers then you
> >> >> should
> >> >> be
> >> >> able to diable it with no ill effect. A dedicated web server for
> >> >> instance
> >> >> would not need to use Client for Microsoft Networks. --- Steve
> >> >>
> >> >> D:\Documents and Settings\Steve>net use \\192.168.1.105\ipc$ "" /u:""
> >> >> The command completed successfully.
> >> >>
> >> >>
> >> >> D:\Documents and Settings\Steve>net use \\192.168.1.105\ipc$ "" /u:""
> >> >> System error 5 has occurred.
> >> >>
> >> >> Access is denied.
> >> >>
> >> >> Event Type: Success Audit
> >> >> Event Source: Security
> >> >> Event Category: Logon/Logoff
> >> >> Event ID: 538
> >> >> Date: 3/16/2005
> >> >> Time: 11:56:16 PM
> >> >> User: NT AUTHORITY\ANONYMOUS LOGON
> >> >> Computer: SERVER1-2000
> >> >> Description:
> >> >> User Logoff:
> >> >> User Name: ANONYMOUS LOGON
> >> >> Domain: NT AUTHORITY
> >> >> Logon ID: (0x0,0x2CFBA3)
> >> >> Logon Type: 3
> >> >>
> >> >>
> >> >> "/.dz" <dz@discussions.microsoft.com> wrote in message
> >> >> news:1D63D35D-431D-4A78-83BD-AE4A2E8EE0D1@microsoft.com...
> >> >> > Steve:
> >> >> > First thanks very much for the response. I've noticed that your
> >> >> > name
> >> >> > is
> >> >> > on
> >> >> > a lot of the responses in this forum and I appreciate the help as
> >> >> > much
> >> >> > as
> >> >> > I'm
> >> >> > sure the other people do as well.
> >> >> >
> >> >> > So anytime you get tired of this thread, it will probably die -- but
> >> >> > I
> >> >> > will
> >> >> > continue to ask questions as long as you continue to respond.
> >> >> >
> >> >> > In your response, you mentioned 'null sessions'. In other articles
> >> >> > I've
> >> >> > read, there is a reference to using the statement [net use
> >> >> > \\servername\ipc$
> >> >> > """" /u:""] to check if null sessions are able to be created. When
> >> >> > I
> >> >> > attempted this statement from my workstation, targetting the
> >> >> > 'servername'
> >> >> > being discussed in this posting, I received the "Logon failure:
> >> >> > unknown
> >> >> > user
> >> >> > name or bad password" message at the workstation, and the server
> >> >> > logged
> >> >> > an
> >> >> > event 529 Logon failure, explicitly indicating my userid,
> >> >> > workstation,
> >> >> > and
> >> >> > domain. From this info, I'm assuming that the 'null sessions'
> >> >> > discussion
> >> >> > does not apply to my situation. Is that a valid conclusion? Also,
> >> >> > the
> >> >> > Computer Browser service is disabled (and has been since
> >> >> > installation)
> >> >> > on
> >> >> > the
> >> >> > server. Am I also 'on-track' here in that these two items are
> >> >> > directly
> >> >> > related? (That is, 'null sessions' are enabled - i.e., required -
> >> >> > for
> >> >> > the
> >> >> > Computer Browser service to function)
> >> >> >
> >> >> > I want to ask about the other items in your response as well, but to
> >> >> > keep
> >> >> > the dialog within reasonable bounds, I'm electing to go through it
> >> >> > one
> >> >> > item
> >> >> > at a time --- starting (I think) with the most clearcut.
> >> >> >
> >> >> > Also in this thread, I need to about the 'Client for Microsoft
> >> >> > Networks' .
> >> >> > The server has this protocol enabled. Two further questions: a)
> >> >> > This
> >> >> > client
> >> >> > is only necessary if the computer (the server in this case) wants to
> >> >> > access
> >> >> > other NETBIOS resources on the net; it is not required for other
> >> >> > computers
> >> >> > on
> >> >> > the net to reach its (the server's) resources. Is this correct? b)
> >> >> > the
> >> >> > 'Client for Microsoft Networks' is not responsible for the 538
> >> >> > logout
> >> >> > events
> >> >> > mentioned in the original post?
> >> >> >
> >> >> > Any further dialog is greatly appreciated.
> >> >> > ./dz
> >> >> >
> >> >> > "Steven L Umbach" wrote:
> >> >> >
> >> >> >> It is common to see those Events on computers using Windows
> >> >> >> networking
> >> >> >> and
> >> >> >> that have file and print sharing and Client for Microsoft networks
> >> >> >> enabled.
> >> >> >> Those often are null sessions used by the computer browser service.
> >> >> >> While
> >> >> >> null sessions can be used to enumerate users, groups, and shares
> >> >> >> you
> >> >> >> can
> >> >> >> mitigate the risk by using a firewall to prevent internet access to
> >> >> >> null
> >> >> >> sessions, enforcing strong passwords on your network, and making
> >> >> >> sure
> >> >> >> your
> >> >> >> share/folder permissions only allow authorized users access.
> >> >> >>
> >> >> >> There are things you can do to reduce there occurrence as ling as
> >> >> >> the
> >> >> >> changes do not interfere with your network access for users. For
> >> >> >> instance
> >> >> >> disabling netbios over tcp/ip, disabling the computer browser
> >> >> >> service,
> >> >> >> and
> >> >> >> configuring the security option for "additional restrictions for
> >> >> >> anonymous
> >> >> >> access" to be " no access without explicit anonymous permissions".
> >> >> >> If
> >> >> >> you
> >> >> >> disable netbios over tcp/ip on a computer it will no longer show in
> >> >> >> or
> >> >> >> be
> >> >> >> able to use My Network Places but access to shares can still be
> >> >> >> done
> >> >> >> via
> >> >> >> fully qualified domain name or possibly even netbios name as long
> >> >> >> as
> >> >> >> dns
> >> >> >> can
> >> >> >> resolve the non FQDN by appending parent suffix to the request. The
> >> >> >> link
> >> >> >> below explains anonymous access more and the security option to
> >> >> >> restrict
> >> >> >> it
> >> >> >> along with possible consequences of doing such. --- Steve
> >> >> >>
> >> >> >> http://support.microsoft.com/?kbid=246261
> >> >> >>
> >> >> >> "/.dz" </.dz@discussions.microsoft.com> wrote in message
> >> >> >> news:480AE832-9FE3-4740-A265-6F6CA5A898FD@microsoft.com...
> >> >> >> > The security event log on our W2K, SP4 server has hundreds of the
> >> >> >> > above
> >> >> >> > messages in it. There are no associated 'logon' events, just the
> >> >> >> > 'logoff'
> >> >> >> > events.
> >> >> >> >
> >> >> >> > File and Print sharing is enabled on this server.
> >> >> >> >
> >> >> >> > There are several published file shares (all hidden); and there
> >> >> >> > are
> >> >> >> > individuals who are authorized to use those shares. The security
> >> >> >> > log
> >> >> >> > does
> >> >> >> > contain 540/538 'pairs' that reflect the credentials of these
> >> >> >> > known
> >> >> >> > users
> >> >> >> > (user/domain). (These are also 'Logon Type 3') But the number of
> >> >> >> > 538
> >> >> >> > NT
> >> >> >> > AUTHORITY/ANONYMOUS LOGON events absolutely dwarfs the number of
> >> >> >> > "known
> >> >> >> > user"
> >> >> >> > logon/logoff events.
> >> >> >> >
> >> >> >> > The server itself is not a domain controller. It was until
> >> >> >> > recently
> >> >> >> > a
> >> >> >> > member of a NT domain, and now is under AD (I don't know how to
> >> >> >> > state
> >> >> >> > that
> >> >> >> > with any accuracy). 'Known user' logon/logoff events are
> >> >> >> > present
> >> >> >> > for
> >> >> >> > both
> >> >> >> > the 'older' NT domain, and the newer 'AD' whatever).
> >> >> >> >
> >> >> >> > I've scoured newsgroups and the MS web site without any luck
> >> >> >> > whatsoever.
> >> >> >> > Any feedback would be greatly appreciated.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>
- Next message: Herb Martin: "Re: Disable Exe and Other File Types from being run/viewed"
- Previous message: Arkane: "Re: Disable Exe and Other File Types from being run/viewed"
- In reply to: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Next in thread: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Reply: Steven L Umbach: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
