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

"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" </***@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.
> >
>
>
>

"/.dz" <d*@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" </***@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.
>> >
>>
>>
>>

"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" <d*@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" </***@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.
> >> >
> >>
> >>
> >>
>
>
>

"/.dz" <d*@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" <d*@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" </***@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.
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>

"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" <d*@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" <d*@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" </***@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.
> >> >> >
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

"/.dz" <d*@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" <d*@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" <d*@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" </***@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.
>> >> >> >
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

"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" <d*@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" <d*@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" <d*@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" </***@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.
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

"/.dz" <d*@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" <d*@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" <d*@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" <d*@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
>> >> >> >>
>> >> >> >>