Set "force group = <somegroup>" together with "guest ok =
yes". Then try "smbclient //server/share -U%". Works. Then try to connect to
the same share from Windows 2003 using an anonymous connection. Breaks with

make_connection: connection to share denied due to security descriptor

although the share_info.tdb is empty. I've seen reports of this on the lists,
but I could never ever nail it until a customer gave me access to such a box.

What happens? With an empty share_info.tdb we create a security descriptor
allow everything to the world. The problem with the above parameter combination
is that S-1-1-0 (World) is lost in the token. When you look at the callers of
create_local_token, they are only called if the preceding check_ntlm_password
did not create server_info->ptok. Not so with the one in auth_ntlmssp.c. So, if
we get a NTLMSSP session setup with user="", domain="", pass="" we call
create_local_token even though check_guest_security() via
make_server_info_guest() has already correctly done so. In this case
create_local_token puts S-1-1-0 into user_sids[1], which is supposed to be the
primary group sid of the user logging in. "force group" then overwrites this ->
the world is gone -> "denied due to security descriptor".

Why don't you see it with smbclient -U% (anonymous connection)? smbclient does
not use ntlmssp for anon session setup.