Hi,

I have recently upgraded a group server to Fedora 8. The Samba version
3.0.28 did not work with my previous configuration from 3.0.10. All user
authentications failed with the messages below. The Samba server sends
authentication requests towards the password server using the SAM name
instead of the client domain. Samba indicates:

[2008/01/16 17:35:47, 1] auth/auth_server.c:check_smbserver_security(362)

  password server <servername> rejected the password:
NT_STATUS_LOGON_FAILURE
 
This is actually true but the wrong domain has been used. I tracked down the problem in the code.

It turns out the server role has changed from "domain member" to
"standalone server" when the "security = server" mode is used. I agree
with this statement.

However, by changing this server mode, the trusted domain functions are
affected. No more domains can be added to the list of trusted domains.
This fact also breaks the password server authentication function
because the "user_info->domain" is not set to the
"user_info->client_domain" during the user mapping process.

I assume that if a workgroup name is used with the intention to match a
domain on purpose, this definition should be taken as a trusted domain.
I mean some of us are dealing with Windows networks where the domain admins do
not want us to add our Samba servers to the domain. Most clients are
using Windows. In order to simplify the login procedures, it's really
handful to use the domain password server. I have seen such new
exciting code to me like winbindd and I am happy to see the cooperation
between Unix and Windows continues. However, some companies have
restrictions. Maybe some education is required.

Anyway, I am not a designer and not a very good coder. I am just a
happy user since a long time. But, I have written a small patch to
allow password server authentication to work again the way it was
before. There is for sure a better implementation but I believe I have
restored the old functionality. Maybe a fix in
"check_smbserver_security" is a better option. I did not test it but if "client_domain" is used instead of "domain" in the user_info array, it might work.

Please, consider some system administrators are in bad situations when
you will decide if this patch should go or not in the main tree. I know the "security = server" mode is deprecated but it would be great to keep the functionality for a while.

Thanks,

Claude.

diff -urN samba-3.0.28.orig/source/auth/auth_util.c samba-3.0.28/source/auth/auth_util.c
--- samba-3.0.28.orig/source/auth/auth_util.c   2007-12-10 08:55:21.000000000 -0500
+++ samba-3.0.28/source/auth/auth_util.c        2008-02-05 18:57:07.000000000 -0500
@@ -172,9 +172,13 @@
        /* do what win2k does.  Always map unknown domains to our own
           and let the "passdb backend" handle unknown users. */

-       if ( !is_trusted_domain(domain) && !strequal(domain, get_global_sam_name()) )
-               domain = my_sam_name();
-
+       if ( !is_trusted_domain(domain) && !strequal(domain, get_global_sam_name()) ) {
+               if ( lp_security() == SEC_SERVER )
+                       domain = lp_workgroup();
+               else
+                       domain = my_sam_name();
+       }
+
        /* we know that it is a trusted domain (and we are allowing them) or it
is our domain */

        result = make_user_info(user_info, smb_name, internal_username,
@@ -2196,9 +2200,9 @@
        DOM_SID trustdom_sid;
        BOOL ret;

-       /* no trusted domains for a standalone server */
+       /* no trusted domains for a standalone server but allow for security = server */

-       if ( lp_server_role() == ROLE_STANDALONE )
+       if ( lp_server_role() == ROLE_STANDALONE && lp_security() != SEC_SERVER
)
                return False;

        /* if we are a DC, then check for a direct trust relationships */