Bug 5257 - Allow password server to work under security = server
Allow password server to work under security = server
Status: NEW
Product: Samba 3.0
Classification: Unclassified
Component: File Services
All Linux
: P3 normal
: none
Assigned To: Samba Bugzilla Account
Samba QA Contact
Depends on:
  Show dependency treegraph
Reported: 2008-02-12 12:16 UTC by Claude Lefrancois
Modified: 2011-09-08 15:17 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Claude Lefrancois 2008-02-12 12:16:18 UTC

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:
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.



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 */
Comment 1 Gordon Lack 2008-09-24 07:32:08 UTC
I also had the same problem, but applied a simpler patch. 
  The client has already sent what it wants you to use, so just use it. 
  I can't see why you wouldn't want to do so.  You have already decided 
to trust a Windows authentication server, so why not send it the domain 
that the client has asked you to?  If the credentials as duff then the 
Windows server will say so.  To replace the domain name with one which 
has absolutely *nothing* to do with the client, and hence makes the 
authentication bound to fail, unless it happens to be the default domain 
of the DC, seems completely wrong to me.

This was what I used:

--- auth_util.c.orig    Wed May 28 13:41:11 2008
+++ auth_util.c Fri Jun  6 10:43:03 2008
@@ -173,7 +173,11 @@
            and let the "passdb backend" handle unknown users. */

         if ( !is_trusted_domain(domain) && !strequal(domain, get_global_sam_name()) )
+       {
+/* XXX - Leave alone if SEC_SERVER */
+               if ( lp_security() != SEC_SERVER )
                 domain = my_sam_name();
+       }

         /* we know that it is a trusted domain (and we are allowing 
them) or it is our domain */

However, there may be some other factors around that I am unaware of, but the ability to use the client-supplied domain in security == server mode is *essential* for this type of working.  So can we please get this in, even if it requires a further option to enable it?
Comment 2 Gordon Lack 2011-09-08 15:14:45 UTC
This is still an issue (with a similar fix) in 3.5.8 (at least).

Here's the patch for that version....

--- source3/auth/auth_util.c.orig       2011-03-06 18:48:05.000000000 +0000
+++ source3/auth/auth_util.c    2011-04-06 15:01:17.000000000 +0100
@@ -220,7 +220,15 @@
         * non-domain member box will also map to WORKSTATION\user.
         * This also deals with the client passing in a "" domain */

+ * GML - we don't want to do this is server mode, where we
+ * want the user-provided domain to obtain
        if (!is_trusted_domain(domain) &&
+ */
+       if (lp_security() != SEC_SERVER &&
+           !is_trusted_domain(domain) &&
            !strequal(domain, my_sam_name()))
                if (lp_map_untrusted_to_domain())
Comment 3 Gordon Lack 2011-09-08 15:17:07 UTC
(Note that I'm unable to update the Version this bug is logged against...)