Stupid Question #1

[Bill Castner]

An irregular series of questions that I am not sure the answers I have
are in fact true.

Q1. The Guest Account under XP Pro

I have seen two widely different claims in this NG in the last month:

.. Enabling the Guest account on the local machine is a question only
of whether a Guest can logon, not whether there is an ACL issue;
.. It does matter for remote connections.

MS KB does not help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;300489

I have always recommended the later course, (enable ForceGuest) when
Simple file sharing was enabled (or forced, as under XP Home).;
.. I have followed the MS KB article, as best I understand the
ForceGuest issue, even with Simple file sharing disabled in mixed OS
network settings. Hence the basis of the question: this should be
unnecessary.
.. Personally, I have done fine with any network I setup with
ForceGuest set to disabled; I synch the username and passwrords on
all machines;
.. As someone who answers 7,000 networking questions a year, I follow
the MS KB though out of safety and ease for the newsgroup end user.

Now the query: why should I have to enable the Guest Account with
Pro,; using nothing other than ACL authentication. Why the MS KB
warning?

Related thought: Al Jarvis had had a query abought the inability to
stop pings (ICMP traffic) under WinXP Service Pack 2. The MSFT answer
was that File and Printer Sharing would not work without free ICMP
traffic under a subnet. The more I think about it, the less credible
these seems as a claim. The relation between my MS KB article above,
and the ping blocking should be clear. I think there is a seriously
murky area in Workgroup networking.

Comments welcomed.

 

[Ron Lowe]

See inline....

An irregular series of questions that I am not sure the answers I have
are in fact true.

Q1. The Guest Account under XP Pro

I have seen two widely different claims in this NG in the last month:

. Enabling the Guest account on the local machine is a question only
of whether a Guest can logon, not whether there is an ACL issue;
. It does matter for remote connections.

Confusion on the definition of 'disabling'.
There are 2 different ways to 'disable' the account, only one of which
really is disabling it.

Using the control panel users applet, is it possible to 'turn the guest
account off'.
This is not 'Disabling the guest account'.
It simply sets it as 'Deny Local Logon'.
It simply prevents someone logging on at the console with the account.

The account is still enabled, and can be used for network logon.
Simple File Sharing, which depends on the Guest account, still functions
normally.

To truly DISABLE the account, you need to go to the 'real' users and groups
control.
Start | Run | enter "lusrmgr.msc" ;
Expand users folder;
Double-click 'Guest' account,
Check box for 'Account is disabled'.

[ When I talk about 'Disabling the Guest Acount'. THIS is what I mean.
Truly Disabling. Not 'Deny Local Logon'. ]

NOW the account is disabled.
NOW guest can't log on across the network.

Also, Simple File Sharing is now broken.
This is because SFS FORCES all incoming connections to authenticate as
Guest,
but the Guest account is now *really* disabled.
So you must disable Simple File Sharing and set up ACLs for real user
accounts.

MS KB does not help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;300489

I have always recommended the later course, (enable ForceGuest) when
Simple file sharing was enabled (or forced, as under XP Home).;

Simple File Sharing = ForceGuest.

. I have followed the MS KB article, as best I understand the
ForceGuest issue, even with Simple file sharing disabled in mixed OS
network settings. Hence the basis of the question: this should be
unnecessary.

The guest account is only enabled by default to permit SFS to work.
SFS forced all incoming connections to authenticate as guest.
If you DISABLE the guest account whilst SFS (ForceGuest ) is on, then
incoming connections will fail.
You will be met with a password prompt for PCname\Guest ( greyed out. )

Personally, I have done fine with any network I setup with
ForceGuest set to disabled; I synch the username and passwrords on
all machines;
. As someone who answers 7,000 networking questions a year, I follow
the MS KB though out of safety and ease for the newsgroup end user.

Now the query: why should I have to enable the Guest Account with
Pro,; using nothing other than ACL authentication. Why the MS KB
warning?

You dont have to.
I don't.

Disable it.
Use ACLs as normal.

Just don't have SFS ( ForceGuest ) enabled.
Becuase ForceGuest fails if Guest is disabled.


[snip SP2 stuff, not knowing. ]

 

[Steve Winograd [MVP]]

Related thought: Al Jarvis had had a query abought the inability to
stop pings (ICMP traffic) under WinXP Service Pack 2. The MSFT answer
was that File and Printer Sharing would not work without free ICMP
traffic under a subnet. The more I think about it, the less credible
these seems as a claim. The relation between my MS KB article above,
and the ping blocking should be clear. I think there is a seriously
murky area in Workgroup networking.

Hi, Bill. In SP2, ICMP Echo is automatically enabled through the
Windows Firewall if you enable TCP 445, which is used by direct-hosted
"NetBIOS-less" SMB traffic. File and Printer Sharing using NetBIOS
doesn't enable, and doesn't depend on, ICMP Echo. Does that help
resolve the issue?
--
Best Wishes,
Steve Winograd, MS-MVP (Windows Networking)

Please post any reply as a follow-up message in the news group
for everyone to see. I'm sorry, but I don't answer questions
addressed directly to me in E-mail or news groups.

Microsoft Most Valuable Professional Program
http://mvp.support.microsoft.com

 

[Bill Castner]

Ron ,

Thank yoiu. I believe we are exactly on the same page on the
'disabling' issue.

If you have the chance, comment on the MS KB article I quote.

Thanks,
Bill

See inline....

An irregular series of questions that I am not sure the answers I have
are in fact true.

Q1. The Guest Account under XP Pro

I have seen two widely different claims in this NG in the last month:

. Enabling the Guest account on the local machine is a question only
of whether a Guest can logon, not whether there is an ACL issue;
. It does matter for remote connections.

Confusion on the definition of 'disabling'.
There are 2 different ways to 'disable' the account, only one of which
really is disabling it.

Using the control panel users applet, is it possible to 'turn the guest
account off'.
This is not 'Disabling the guest account'.
It simply sets it as 'Deny Local Logon'.
It simply prevents someone logging on at the console with the account.

The account is still enabled, and can be used for network logon.
Simple File Sharing, which depends on the Guest account, still functions
normally.

To truly DISABLE the account, you need to go to the 'real' users and groups
control.
Start | Run | enter "lusrmgr.msc" ;
Expand users folder;
Double-click 'Guest' account,
Check box for 'Account is disabled'.

[ When I talk about 'Disabling the Guest Acount'. THIS is what I mean.
Truly Disabling. Not 'Deny Local Logon'. ]

NOW the account is disabled.
NOW guest can't log on across the network.

Also, Simple File Sharing is now broken.
This is because SFS FORCES all incoming connections to authenticate as
Guest,
but the Guest account is now *really* disabled.
So you must disable Simple File Sharing and set up ACLs for real user
accounts.

MS KB does not help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;300489

I have always recommended the later course, (enable ForceGuest) when
Simple file sharing was enabled (or forced, as under XP Home).;

Simple File Sharing = ForceGuest.

. I have followed the MS KB article, as best I understand the
ForceGuest issue, even with Simple file sharing disabled in mixed OS
network settings. Hence the basis of the question: this should be
unnecessary.

The guest account is only enabled by default to permit SFS to work.
SFS forced all incoming connections to authenticate as guest.
If you DISABLE the guest account whilst SFS (ForceGuest ) is on, then
incoming connections will fail.
You will be met with a password prompt for PCname\Guest ( greyed out. )

Personally, I have done fine with any network I setup with
ForceGuest set to disabled; I synch the username and passwrords on
all machines;
. As someone who answers 7,000 networking questions a year, I follow
the MS KB though out of safety and ease for the newsgroup end user.

Now the query: why should I have to enable the Guest Account with
Pro,; using nothing other than ACL authentication. Why the MS KB
warning?

You dont have to.
I don't.

Disable it.
Use ACLs as normal.

Just don't have SFS ( ForceGuest ) enabled.
Becuase ForceGuest fails if Guest is disabled.


[snip SP2 stuff, not knowing. ]

Comments welcomed.

 

[Bill Castner]

Steve,

I do not know if you have tested it, but if you disable all possible
ICMP traffic exception choices under SP2 firewall, a ping still
succeeds on your local LAN subnet.

I like your explanation quite a bit. But I was under the impression
that a ping was essentially "port independent." A ping was a type of
TCP traffic to the remote IP address, it would not either from the
source or remote site scan ports until it found an open port to
respond with.

The explanation given "Sooner Al" was that SP2 firewall would always
except subnet traffic because the File and Printer Sharing services
APIs would not work otherwise.

I think you could deny ICMP traffic on port 445 (or the other TCP and
UDP ports used by F&S) without compromising existing XP F&P Services;
I just viewed the response upon relfecltion for SP2 as being
unsatisfactory.

The notion that their are about 5 ports one needs to have open for
file and printer I do not doubt, but what that has to do with ping I
remain baffled.

Thank yoiu very much for the response,
Bill

 

[Bill Castner]

I should be clearer here about my concern.

As you said: "Using the control panel users applet, is it possible to
'turn the guest account off'.
This is not 'Disabling the guest account'.
It simply sets it as 'Deny Local Logon'.
It simply prevents someone logging on at the console with the account.

The account is still enabled, and can be used for network logon.
Simple File Sharing, which depends on the Guest account, still
functions normally."

And this has been my understanding and experience.

But the MS KB article suggests otherwise, or implies at the least that
without an active Guest user account, that authentication by a remote
user can be troublesome.

Unless I suppose the ACL reflects Group Guest as part of Group
Everyone and not Guest as user to authenticate.

I am less confused about this in practice than I am in trying to sort
such notions as that under XP the 'Authenticated User' group is not
automaticly part of Group Everyone. That make sense to me as well,
but I still find the MS KB comment about user Guest difficult to
reconcile in the whole schema.

Your comments appreciated.

Ron ,

Thank yoiu. I believe we are exactly on the same page on the
'disabling' issue.

If you have the chance, comment on the MS KB article I quote.

Thanks,
Bill

See inline....

An irregular series of questions that I am not sure the answers I have
are in fact true.

Q1. The Guest Account under XP Pro

I have seen two widely different claims in this NG in the last month:

. Enabling the Guest account on the local machine is a question only
of whether a Guest can logon, not whether there is an ACL issue;
. It does matter for remote connections.

Confusion on the definition of 'disabling'.
There are 2 different ways to 'disable' the account, only one of which
really is disabling it.

Using the control panel users applet, is it possible to 'turn the guest
account off'.
This is not 'Disabling the guest account'.
It simply sets it as 'Deny Local Logon'.
It simply prevents someone logging on at the console with the account.

The account is still enabled, and can be used for network logon.
Simple File Sharing, which depends on the Guest account, still functions
normally.

To truly DISABLE the account, you need to go to the 'real' users and groups
control.
Start | Run | enter "lusrmgr.msc" ;
Expand users folder;
Double-click 'Guest' account,
Check box for 'Account is disabled'.

[ When I talk about 'Disabling the Guest Acount'. THIS is what I mean.
Truly Disabling. Not 'Deny Local Logon'. ]

NOW the account is disabled.
NOW guest can't log on across the network.

Also, Simple File Sharing is now broken.
This is because SFS FORCES all incoming connections to authenticate as
Guest,
but the Guest account is now *really* disabled.
So you must disable Simple File Sharing and set up ACLs for real user
accounts.

MS KB does not help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;300489

I have always recommended the later course, (enable ForceGuest) when
Simple file sharing was enabled (or forced, as under XP Home).;

Simple File Sharing = ForceGuest.

. I have followed the MS KB article, as best I understand the
ForceGuest issue, even with Simple file sharing disabled in mixed OS
network settings. Hence the basis of the question: this should be
unnecessary.

The guest account is only enabled by default to permit SFS to work.
SFS forced all incoming connections to authenticate as guest.
If you DISABLE the guest account whilst SFS (ForceGuest ) is on, then
incoming connections will fail.
You will be met with a password prompt for PCname\Guest ( greyed out. )

Personally, I have done fine with any network I setup with
ForceGuest set to disabled; I synch the username and passwrords on
all machines;
. As someone who answers 7,000 networking questions a year, I follow
the MS KB though out of safety and ease for the newsgroup end user.

Now the query: why should I have to enable the Guest Account with
Pro,; using nothing other than ACL authentication. Why the MS KB
warning?

You dont have to.
I don't.

Disable it.
Use ACLs as normal.

Just don't have SFS ( ForceGuest ) enabled.
Becuase ForceGuest fails if Guest is disabled.


[snip SP2 stuff, not knowing. ]

Comments welcomed.

 

[Steve Winograd [MVP]]

Steve,

I do not know if you have tested it, but if you disable all possible
ICMP traffic exception choices under SP2 firewall, a ping still
succeeds on your local LAN subnet.

I like your explanation quite a bit. But I was under the impression
that a ping was essentially "port independent." A ping was a type of
TCP traffic to the remote IP address, it would not either from the
source or remote site scan ports until it found an open port to
respond with.

The explanation given "Sooner Al" was that SP2 firewall would always
except subnet traffic because the File and Printer Sharing services
APIs would not work otherwise.

I think you could deny ICMP traffic on port 445 (or the other TCP and
UDP ports used by F&S) without compromising existing XP F&P Services;
I just viewed the response upon relfecltion for SP2 as being
unsatisfactory.

The notion that their are about 5 ports one needs to have open for
file and printer I do not doubt, but what that has to do with ping I
remain baffled.

Thank yoiu very much for the response,
Bill

You're welcome, Bill. I've run a few tests on SP2, and all seems to
be well. When I disable all ICMP choices (which is only possible when
TCP 445 is removed from the list of exceptions), a ping on the local
subnet fails, as we would hope and expect. When I enable ICMP Echo,
the ping succeeds.

You have to disable ICMP in two places in the Windows Firewall's
Advanced tab: the Settings button under the ICMP heading, and the
Settings button under "Network Connection Settings".

I think that it would be good to move this discussion to the SP2
private or beta newsgroups. There are people in them who know more
than I do about SP2 and its intricacies.
--
Best Wishes,
Steve Winograd, MS-MVP (Windows Networking)

Please post any reply as a follow-up message in the news group
for everyone to see. I'm sorry, but I don't answer questions
addressed directly to me in E-mail or news groups.

Microsoft Most Valuable Professional Program
http://mvp.support.microsoft.com

 

[Ron Lowe]

But the MS KB article suggests otherwise, or implies at the least that

without an active Guest user account, that authentication by a remote
user can be troublesome.

Not true.
Disabling ( in the true sense ) the guest account will only cause
authentication trouble if SFS is in force.

Unless I suppose the ACL reflects Group Guest as part of Group
Everyone and not Guest as user to authenticate.

I am less confused about this in practice than I am in trying to sort
such notions as that under XP the 'Authenticated User' group is not
automaticly part of Group Everyone. That make sense to me as well,
but I still find the MS KB comment about user Guest difficult to
reconcile in the whole schema.

IMHO the article is grossly oversimplistic to the point of being wrong.

Your comments appreciated.

The everyone group includes just that - everyone.
It includes the group 'Guests', which in turn includes the user 'Guest'.

The group 'Everyone is the default share permission.

So for SFS, all users authenticate as Guest ( as long as the Guest account
has not been disabled ), and the default permissions for the share will
contain Everyone which in turn will include guest, and access is granted.

If you are not using SFS, then go ahead and:

0) Disable the Guest account.
1) Create user accounts;
2) Create groups for them if you wish;
3) Add them to the share ACL;
4) Remove 'Everyone' form the ACL, unless you want all users ( except the
disabled guest, obviously ) to access the share.

Re: use of Everyone group:
You may want to use the Everyone group in your share permissions, even with
Guest disabled.
As an example, I have a share on a server which I use for staff to make
files available to anyone on the network.
All the saff accounts belong to a group called 'Staff'.
So I have the share permissions set to
Staff: Change permission ( read/write )
Everyone: Read permission only.

( The guest account is disabled. )

Now, all users can read the files, but only the staff can change them.

 

[Bill Castner]

Ron,

Thanks a lot. What you wrote above jibes perfectly with my
understanding of the Guest account, and generally the notion of ACLs.
I appreciate the details provided by your answer.

I have been cleaning my office (always a mistake) and found a printout
of the MS KB article above with a big question mark I had penciled on
the top of it earlier this year, and decided to pose the question.