Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON
From: Steven L Umbach (n9rou_at_nospam-comcast.net)
Date: 03/25/05
- Next message: Steven L Umbach: "Re: How to export W2K Effective Policy Setting?"
- Previous message: GVB: "Security policies are propagated with warning"
- In reply to: /.dz: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 24 Mar 2005 21:31:37 -0600
Sounds good. I am often on the Windows server networking newsgroup. I think
you will find Ethereal pretty easy to use once you play around with it for a
while and there is a lot of info for it if you search Google for whatever
you are trying to do. Creating capture filters go from being easy to
extremely complex. To capture netbios traffic simply use the capture filter
"port 137 or port 138 or port 139" without the quotes . --- Steve
"/.dz" <dz@discussions.microsoft.com> wrote in message
news:E20E4512-F89D-40F4-A5C8-E6632E88493B@microsoft.com...
> Steve:
> Thanks very much for this entire dialog. I'm gonna take some time to read
> the references you provided -- which because of other priorities might
> take a
> while. In any case, I'm most appreciative for all the feedback. I won't
> promise that I'll let this thread die altogether -- but it's hard to say
> at
> the moment. You've given me more than enough to think on for a while and
> once I feel comfortable with the protocol dialogs, I might get back to the
> original 'security' concern.
>
> And, believe it or not, I had found Ethereal via another contact some
> months
> ago -- but it isn't something that I get an opportunity to use very often.
> And when I have 'dabbled', I've been a bit confused by the filtering
> mechanism, so I end up with a lot more traffic being captured than I'm
> able
> to comprehend.
>
> At some point in the future, I might even ask you about the filter
> settings
> you might employ to sniff NetBIOS traffic. In that regard, and since it
> could conceivably be of interest to audiences on newsgroups more
> 'network-centric', are you a regualr contributor on any other
> newsgroup(s) -
> one(s) that are in fact related to the networking?
> ./dz
>
> "Steven L Umbach" wrote:
>
>> No problem.
>>
>> Yes UDP is used to contact Wins servers and for broadcast netbios name
>> resolution if a Wins server is not used. Port 138 UDP is mostly used for
>> traffic that maintains the browse list that is what My Network Places
>> uses
>> for network browsing. Traffic such as browse announcements, requests for
>> browser master, and browser elections use that port. Port 139 TCP is used
>> a
>> lot for file and print sharing and is a port where the actual data
>> transfer
>> takes place. A real good way to learn all this is with a packet sniffer.
>> Netmon is built into server editions of Windows but I like Ethereal a lot
>> better and it is free. The link below contains some basics on NBT. ---
>> Steve
>>
>> http://www.keyfocus.net/kfsensor/help/AdminGuide/adm_NBT.php
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;832017 --- ports
>> used by Windows.
>>
>>
>> "/.dz" <dz@discussions.microsoft.com> wrote in message
>> news:64CF1392-1184-4248-AA5E-05C0EBD35316@microsoft.com...
>> > 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: Steven L Umbach: "Re: How to export W2K Effective Policy Setting?"
- Previous message: GVB: "Security policies are propagated with warning"
- In reply to: /.dz: "Re: Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
