Event ID 538 Logon Type 3 NT AUTHORITY/ANONYMOUS LOGON

G

Guest

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

Steven L Umbach

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
 
G

Guest

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
 
S

Steven L Umbach

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 said:
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 said:
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
 
G

Guest

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 said:
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 said:
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 said:
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

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

Steven L Umbach

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 said:
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 said:
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 said:
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

:

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

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

Guest

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 said:
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 said:
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 said:
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


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

:

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

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

Steven L Umbach

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 said:
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 said:
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 said:
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. ??

:

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


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

:

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

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

Guest

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 said:
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 said:
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 said:
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


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

:

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


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

:

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

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

Steven L Umbach

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 said:
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 said:
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 said:
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

:

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


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

:

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


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

:

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

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

Guest

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 said:
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 said:
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 said:
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


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

:

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


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

:

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


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

:

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

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

Steven L Umbach

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 said:
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 said:
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 said:
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


:

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


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

:

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


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

:

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


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

:

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

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

joescat

/.dz said:
*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.
*

Fascinating thread! Yes, it is from a long time ago, but still a great
read.

I have a related issue I'm trying to solve, which landed me here.

I have a Server 2003 member server (in an NT domain), for file and
printer sharing. I have auditing enabled for "logon events", I really
wish to capture logons _for users_. Which works fine, but I also get a
much greater load of event 540, NT AUTHORITY\ANONYMOUS LOGON events.
There is no user name, it's a "computer" logon, listing the computer
name, ip address, etc. I want to eliminate those, and keep the user
logons.

I've played a bit with the auditing settings, and it seems I get either
all or nothing.

I've also changed settings in local group policy, but again have not
achieved the desired effect.
For example, "Network Access: Do not allow anonymous enumeration of SAM
accounts and shares" is enabled. "Network Access: Do not allow anonymous
enumeration of SAM account" is enabled.
Yet, I'm not exactly sure why the "anonymous" success logon events are
occurring (they do not change to failure events).

Any help would be greatly appreciated. Maybe it's simply not possible
to achieve the settings I want, but I haven't given up yet.
 
S

Steven L Umbach

You can't be selective about which logon events to record as it is an all or
nothing deal. You can however use Event Comb or a program such as PsLogList
from SysInternals to help narrow your search of the security log. Often the
anonymous events are a result of activity relating to network browsing such
as accessing computers/shares in My Network Neighborhood. You say that you
are in an NT domain. If you mean NT4.0 then yes you may see a lot more
anonymous logons. Disabling netbios over tcp/ip on the server may make most
of those events go away but then the server will not appear in My Network
Places though users could still access via unc path or mapped drive. As an
experiment some time from a workstation in the domain try to access the
server in My Network Places and then see if corresponding anonymous logon
events are shown in the security log on the server at that time.
Master/backup browsers are also likely to see more anonymous logon events.
You can use nbtstat -n if you have not disabled netbios over tcp/ip to see
if the computer is a master or backup browser. If you disable the computer
browser service the computer can no longer be a master/backup browser and
by election some other computer on the network will have to take over that
role. --- Steve

http://www.sysinternals.com/Utilities/PsLogList.html --- PsLogList
 
J

joescat

Thanks, that confirms my thinking, and results trying to pare down my
security event log.

I'm doing exactly that now - using EventComb to capture a particular
person's logon and logoff's. Unfortunately, even though I've cranked
up the size of the security log, it still doesn't go back very far due
to all the excess "chatter" by the anonymous logon events. I guess
I'll just have to live with it.

It would be undesirable to disabled NetBIOS , as it is very useful on
occasion to browse to this particular resource server.

I will play around with stopping the Browser service, but so far I
haven't seen it become the master browser - the NT PDC grabs that role
of course, and the BDC's and such snatch up what's left.

Wondering, I am running a WINS server on a separate box from this one.
If everyting is registered properly (a static WINS entry perhaps), could
there be a way to configure that to allow browsing to the resource
server, yet leave NetBIOS disabled?
 
S

Steven L Umbach

Wins uses netbios name resolution so you could not disable NBT and have it
work anymore. I know it is a pain in some ways but that is the way it works
and it is pretty old technology. The links below explains more. What might
help is to configure the Local Security Policy local policies\security
options of the server for the security option for additional restrictions
for anonymous connections to be no access without explicit anonymous
permissions though enabling that setting can have ramifications in some
situations. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;323357
http://support.microsoft.com/?kbid=246261
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top