security=share vs user

[Gerald Carter]

Volker Lendecke wrote:

> I remember that Andrew once wrote a VERY long posting that discussed
> the issues of guest access to a samba server in great detail. I
> searched the archives but could not find it. If anybody remembers that
> posting and still has it available, could you please forward a copy of
> that to me? Thanks a lot!

I think this is the one you want Volker.




jerry

========================================================
I'm starting a new thread for this as I think the thread it came from
is getting just a tad overloaded.

For those who have been just deleting the other thread the background
is that I made the claim that virtual servers are needed to properly
support guest and non-guest shares on the same machine. In other
words, user level security does not allow guest shares to work
properly.

First some background for those of you not totally familiar with how
SMB security levels work.

When a SMB client connects to a server the server tells the client in
the negprot response what "security level" is supported by the
server. The server must choose "share level security" or "user level
security" (the "server level security" in Samba is just user level
security in disguise. It is identical to user level security from the
clients point of view).

The difference that this choice makes at the protocol level is how the
client attempts to authenticate with the server and what assumptions
the client makes about the servers response.

If the server selects share level security then the client expects
that it will need to separately authenticate each share that it wants
to access and that the only authentication token it will need to do
that authentication is a password. The client may, or may not, send a
username in a session setup request. With Windows clients, whether it
does send a username in a session setup seems to depend on whether it
already has an established "anonymous" session that it has used for
browsing. The Microsoft programmers may be able to reveal more details
about this aspect of the clients behaviour.

It is the lack of a username in share level security that makes it
unsuitable for many installations. SMB vendors and the SMB spec
sensibly recommend that new installations use user level security.

In user level security the client expects to authenticate itself via a
session setup request containing a username and a password. This is
done before the client tells the server what resource they are going
to access.

By convention current servers (at least the ones I know of) accept a
NULL username and password in a user level session setup request as
meaning that they wish to make a anonymous connection. This is used
for the parts of the browsing protocol that involve the transfer of
large number of host names. The special IPC$ share is used for this
purpose. It does not seem possible to get current Windows clients to
send anonymous session setup requests when attaching to file or
printer shares (they insist that the username not be blank). Astute
readers will note that this "anonymous login" opens a door to attack
user level security servers without knowing a password (and indeed the
./ attack worked over a anonymous IPC$ connection).

In responding to the session setup request a user level server has a
small number of choices.

1) reject the session setup and set one of a small range of error
   codes.

2) accept the supplied username/password. A integer VUID is returned
   to the client. The client is required to offer this VUID in future
   packets that require the security context of the supplied
   username/password.

3) accept the session setup but set the "guest" bit in the reply. It
   is unclear how Windows clients change their behaviour when they get
   a guest response. Maybe a Microsoft programmer could comment?

Assuming that option 2 or 3 is chosen by the server the client will
then proceed to request access to particular shares using a "tree
connect". The client will not supply a password with the tree
connect.

Ok, so enough background, now to some specific problems.

The first problem I'd like to point out is what happens if a Win95
clients needs access to two different shares that need different
authentication on the same user level server. This isn't the main
guest access problem that this email is all about but it is related.

For example, I might set a share "foo" as only accessible by user
"fred" and another share "bar" as only accessible by "staff". Once the
Windows95 client has successfully established a connection to "foo" it
is not possible for it to authenticate itself differently for
"bar". If you try and access "bar" and the server gives an error then
the client will deceptively pop up a dialog box asking for a password
for "bar". No matter what password you enter you will not succeed and
you will get a dialog saying "The password is incorrect. Try
again". If you look at this with a sniffer then you find that the
client is not sending the entered password over the link at all but is
just sending a blank password with each tree connect attempt. Users
sometimes sit for ages trying to guess what the password is, little
knowing that the client is silently sending a blank password in every
attempt then telling them to "try again". NT does this as well in a
slightly different situation. It is very frustrating.

The above problem rules out "known password" guest shares on user
level security servers. These are the sort of shares where someone
writes the password up on a whiteboard for everyone to see and the
admin wants users to only connect as the guest user rather than
themselves, but to connect to home directories as themselves.

There are other (more common) sorts of guest shares. The most commonly
asked for is a share where the admin wants anyone to be able to
connect without knowing a password. This is often used for public
resources (cdroms are commonly shared like this) or printers.

Lets think about what happens when a client tries to access such a
share on a user level server. The client does not have an account on
the server so it will need to send a username/password that the server
cannot validate. The client does still send a username/password in a
session setup, however, as Windows clients are not able to send
anonymous session setup requests for printer and file shares.

When the server receives the session setup it has to decide whether
to accept it or not. If the server has any guest shares at all then
rejecting the session setup is not an option as the client might be
trying to access a guest share. At the time of the session setup the
server has no way of telling.

But what if the username sent by the client is valid on the server but
the password is wrong? The user has no control over what username is
sent to the server by Windows. (Windows clients always send the
username that the user used to login locally). The server does not
know whether to send a "ERRbadpw" error response or a positive
session setup reply with the guest bit set. The server has no way to
distinguish between a mistyped password and a user that doesn't have
an account on the server.

Whichever choice the server makes you are sunk. You can configure
Samba either way, which really just lets administrators choose the
flavour of poison that they like.

Say you choose to reject the session setup if the username exists but
the password is invalid. You better hope that local "windows"
usernames are unique across your organisation or you will end up
rejecting access to guest shares for users that happen to have a
username that matches one on the server. We have 13k machines within
ANU. We do not control what local usernames people choose on their
desktop boxes. We do offer guest shares on central Samba servers.

Say you choose the other route. You accept the session setup and maybe
mark it as "guest" for good measure. You then discover that the client
does a "tree connect" to a non-guest share. The tree connect does not
contain a password. The server has no choice but to reject the tree
connect. The client pops up a dialog box and asks for the password for
share. The user enters the correct password this time. The client does
not send it over the wire, instead it sends a blank password then pops
up a "The password is incorrect. Try again" message. Refer to my
earlier comments on the frustrating time that eventually leads to the
user pressing the big red reset switch.

There are other potential solutions that people have offered over the
years to solve the "user level securuty + guest shares" dilemma. We
have tried them all. None worked. I am very happy to listen to other
suggestions and if you come up with something that actually works then
I'll be very happy!

The only solution we have been able to offer users is virtual
servers. The guest shares are configured on a share level security
virtual server. The non-guest shares are on the user level security
server.

I hope this explains why I'd be unhappy to see the current session
request mechanism disappear without a suitable replacement.

Andrew "more coffee! quick!"

----------------------------------------------------------------
Users Guide http://www.microsoft.com/sitebuilder/resource/mailfaq.asp
contains important info including how to unsubscribe.  Save time, search
the archives at http://discuss.microsoft.com/archives/index.html

========================================================



________________________________________________________________________
                            Gerald ( Jerry ) Carter	
Engineering Network Services                           Auburn University 
jerry at eng.auburn.edu             http://www.eng.auburn.edu/users/cartegw

       "...a hundred billion castaways looking for a home."
                                  - Sting "Message in a Bottle" ( 1979 )