security=share vs user

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 )