Bug 6099 - Samba returns incurrate capabilities list.
Samba returns incurrate capabilities list.
Status: RESOLVED FIXED
Product: Samba 3.4
Classification: Unclassified
Component: Domain Control
3.4.0
All Windows NT
: P3 regression
: ---
Assigned To: Jeremy Allison
Samba QA Contact
:
Depends on:
Blocks: 6247 6255
  Show dependency treegraph
 
Reported: 2009-02-10 17:47 UTC by Nick Meier
Modified: 2009-09-28 23:35 UTC (History)
6 users (show)

See Also:
gd: review+


Attachments
implement netr_ServerAuthenticate3 patch (5.90 KB, patch)
2009-02-12 18:38 UTC, Guenther Deschner
no flags Details
gzip'ed tarball of patches for v3-3-test (3.39 KB, application/octet-stream)
2009-05-07 15:24 UTC, Jeremy Allison
no flags Details
gzip'ed tarball of patches for v3-2-test (3.31 KB, application/octet-stream)
2009-05-11 13:21 UTC, Jeremy Allison
no flags Details
Full gzipped Debug Level 10 Log (157.58 KB, application/x-gzip)
2009-08-11 17:17 UTC, Ken Bass
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Meier 2009-02-10 17:47:17 UTC
The following issue was identified during a Samba/Microsoft conference call.

Microsoft Open Protocol Document MS-NRPC
    NetrServerAuthenticate3, section 3.5.4.3.2
    NetrServerAuthenticate2, section 3.5.4.3.3
The NegotiateFlags field in the message output needs to be set to
the intersection of what Samba supports and what the client supports
even when the call results in failure such as Access Denied.
The current behavior appears to just echo back what was received,
falsely advertising capabilities that Samba does not support.
Comment 1 Nick Meier 2009-02-12 15:00:00 UTC
We feel it is in Samba's interest to implement NetrServerAuthenticate3
in Samba version 3.  This will save a round trip to the server.
Section 1.7 of MS-NRPC discusses how NetrServerAuthenticate2 will
be tried if NetrServerAuthenticate3 fails.
Comment 2 Volker Lendecke 2009-02-12 15:03:42 UTC
The question here is -- will any version of Windows assume features that we don't provide when we start to do the ServerAuthenticate3, because it errnoeously figures out we must be AD?

Volker
Comment 3 Jeremy Allison 2009-02-12 16:57:49 UTC
Doesn't look to me like we're reflecting the client flags. The relevant code in _netr_ServerAuthenticate2 is :

        srv_flgs = 0x000001ff;

        if (lp_server_schannel() != false) {
                srv_flgs |= NETLOGON_NEG_SCHANNEL;
        }

        /* set up the LSA AUTH 2 response */
        memcpy(r->out.return_credentials->data, &srv_chal_out.data,
               sizeof(r->out.return_credentials->data));
        *r->out.negotiate_flags = srv_flgs;

So we're returning a static value of 0x000001ff (| NETLOGON_NEG_SCHANNEL) if schannel is configured on (which it is by default). In 3.3.x we use the correct symbolic names :

        /* 0x000001ff */
        srv_flgs = NETLOGON_NEG_ACCOUNT_LOCKOUT |
                   NETLOGON_NEG_PERSISTENT_SAMREPL |
                   NETLOGON_NEG_ARCFOUR |
                   NETLOGON_NEG_PROMOTION_COUNT |
                   NETLOGON_NEG_CHANGELOG_BDC |
                   NETLOGON_NEG_FULL_SYNC_REPL |
                   NETLOGON_NEG_MULTIPLE_SIDS |
                   NETLOGON_NEG_REDO |
                   NETLOGON_NEG_PASSWORD_CHANGE_REFUSAL;

which shows what we are returning here. I'll look into what we should be doing (checking the union of what we support with the client flags) but we're not just reflecting the client values here. Is this what you have seen in your testing ?

Jeremy.
Comment 4 Nick Meier 2009-02-12 17:04:39 UTC
Volker,

That should not be an issue.  The assumptions our code makes is based on the values in the NegotiatedFlags.
Comment 5 Jeremy Allison 2009-02-12 17:10:19 UTC
(It's Jeremy by the way, not Volker :-). I'm not sure what you mean by "That should not be an issue." - I'm assuming that your client makes assumptions based on the values we're returning here, which are currently hardcoded at 0x000001ff | NETLOGON_NEG_SCHANNEL (0x40000000). Which of these values cause the client to decide not to continue with the negotiation to NT4 style PDC ?

Now we have the full info on what these bits mean I will be able to select out the correct set, but knowing the basic values you require would help a lot in getting this code right the first time.

Thanks,

Jeremy.
Comment 6 Guenther Deschner 2009-02-12 18:38:11 UTC
Created attachment 3935 [details]
implement netr_ServerAuthenticate3 patch

Just in case we are going to implement ServerAuthenticate3, here is a patch.
Comment 7 Guenther Deschner 2009-02-12 18:52:08 UTC
(In reply to comment #6)
> Created an attachment (id=3935) [edit]
> implement netr_ServerAuthenticate3 patch
> 
> Just in case we are going to implement ServerAuthenticate3, here is a patch.

This has been pushed to master now (other branches will follow tomorrow if we all agree).


Comment 8 Nick Meier 2009-02-12 18:55:53 UTC
Hi Jeremy,

Because of recent changes, the bit that caused the compatibility issue has changed.  Referencing it now may cause more confusion.  The hard coded values you listed are fine.  The problem is when the API returns an error, Samba appears to return the capabilities the client sent, not the hard coded list.  If Samba returned the hard coded list, it would have worked.

Nick Meier
Program Manager, Microsoft Protocol Team
Comment 9 Jeremy Allison 2009-02-12 19:10:25 UTC
Nick, you are driving me nuts here :-). Please be clear. Be *extremely* clear. 

"Samba appears to return the capabilities the client sent, not the hard coded list,"

Under what exact circumstances does this happen ? Please be explicit as to what code branch you are testing. Every branch I have looked at only sets the hard coded flags in the reply struct for NetrServerAuthenticate2 to 0x000001ff | NETLOGON_NEG_SCHANNEL (0x40000000) just before returning NT_STATUS_OK in the NetrServerAuthenticate2 reply. In what code branch do you see the incoming flags being mirrored ?

If the API NetrServerAuthenticate2 returns an error, why does the client look at the returned flags. Anything in the return is invalid in this case except the status code.

Jeremy.
Comment 10 Guenther Deschner 2009-02-12 19:12:54 UTC
Jeremy, Samba4 just returns back the flags passed in. No Samba3 release ever did, as far as I can see.
Comment 11 Nick Meier 2009-02-15 18:20:37 UTC
Jeremy,

We tested against Samba version 3.2.27.

The bit used in the Win 7 beta release was:
     #define NETLOGON_SUPPORTS_AES_SHA           0x00400000
This is the W bit in the NegotiatedFlags field  - http://msdn.microsoft.com/en-us/library/cc237128(PROT.13).aspx
In the next Win 7 beta, the bit will change to:
      #define NETLOGON_SUPPORTS_AES               0x01000000 
We will make sure the documents match the new definition.

Our code uses the value of the NegotiatedFlags field, even on error returns.  This simplifies our client side state machine and saves us round trips on the network.

The actual bug to be addressed is Samba needs to return its flags, even on Access Denied.  For now, simply ANDing the samba capabilities using the existing bit definition should work, since we are not yet trying to interoperate with the new functionality.

We will look at adding a comment to the server side documentation to make it clear the flags should be returned even when the function returns Access Denied.
     http://msdn.microsoft.com/en-us/library/cc237240(PROT.13).aspx

 Iā€™m very sorry for the confusion, and hope this answers your questions.

Nick Meier
Comment 12 Jeremy Allison 2009-02-15 18:45:26 UTC
"We tested against Samba version 3.2.27."

I take it that you mean 3.2.7 ?

"The actual bug to be addressed is Samba needs to return its flags, even on
Access Denied."

Ok, that we can fix, even though I think your client is broken and should be fixed if it's looking at values returned in ACCESS_DENIED error returns. I'll look at this asap. Thanks for the clarification.

Jeremy.
Comment 13 Jeremy Allison 2009-02-15 20:26:33 UTC
Ok, I've applied the fix to all active branches (master, v3-3-test, v3-2-test) and the maintenance branch (v3-0-test) so always set the returned flags field even on error return on the auth2 (and auth3 in master) calls. Please either test the build or look at the code to confirm this will work ok with future versions of Windows7.

Thanks !

Jeremy.
Comment 14 Nick Meier 2009-03-05 15:27:28 UTC
With this change and 6100, Win 7 can successfully join the Samba 3 domain (6099 changes) and log on using Samba domain credentials (6100 changes).
Comment 15 Jeremy Allison 2009-05-07 15:20:00 UTC
Ok, master and 3.4 currently seem to work correctly as a PDC for Win7. I'm going to attach a tarball of patches for v333-test and v3-2-test.
Jeremy.
Comment 16 Jeremy Allison 2009-05-07 15:24:34 UTC
Created attachment 4128 [details]
gzip'ed tarball of patches for v3-3-test

Ok, here is a gzip'ed tarball of 4 patches that will apply with git-am to v3-3-test to fix the credentials chaining and the interactive netlogon calculations. Guenther please review.
Jeremy.
Comment 17 Guenther Deschner 2009-05-07 18:11:19 UTC
Patchset like fine. Thanks for collecting that!
Comment 18 Karolin Seeger 2009-05-11 05:37:58 UTC
Jeremy, could you please add patches for 3.2?
Thanks!
Comment 19 Jeremy Allison 2009-05-11 13:21:33 UTC
Created attachment 4141 [details]
gzip'ed tarball of patches for v3-2-test
Comment 20 Jeremy Allison 2009-05-11 13:21:53 UTC
Added patchset for 3.2.x also.
Jeremy.
Comment 21 Guenther Deschner 2009-05-19 03:17:21 UTC
Karolin, I think we are ready with this one. Re-assigning to you.
Comment 22 Karolin Seeger 2009-05-19 03:56:46 UTC
Patches will be included in 3.2.12 and 3.3.5.
Closing out bug report.

Thanks for reporting!
Comment 23 Ken Bass 2009-08-11 10:10:25 UTC
Please reopen. 

With Windows 7 Release to Manufacturing (RTM), is appears this bug fix broke login. Login works with Samba 3.3.4, but is broken with 3.3.5, 3.3.6, 3.3.7. There is confirmation by two other people on the mailing list. According to the last comment this patch was rolled into 3.3.5.

After searching the archives I modified the required registry settings listed in other emails. I upgraded my Samba from the stock Centos 5.3 version to 3.3.7. Joining the domain worked, but I was unable to log in. I would get a 'Trust relationship denied' type error when trying to log in as a user of the domain. Everything works with XP/Vista.

I downgraded to 3.3.4 and it worked. I do not know if bug 6099 which says it was rolled into version 3.3.5 and  relates to Microsoft/Samba interoperability actually broke stuff with the RTM or what.

The error message from 3.3.7 I noticed with debug logging was:

[2009/08/07 19:05:40,  0] rpc_server/srv_netlog_nt.c:_netr_ServerAuthenticate2(555)
 _netr_ServerAuthenticate2: netlogon_creds_server_check failed. Rejecting auth request from client XX-PC machine account XX-PC$
     netr_ServerAuthenticate2: struct netr_ServerAuthenticate2
         out: struct netr_ServerAuthenticate2
             return_credentials       : *
                 return_credentials: struct netr_Credential
                     data                     : 0000000000000000
             negotiate_flags          : *
                 negotiate_flags          : 0x400041ff (1073758719)
                        1: NETLOGON_NEG_ACCOUNT_LOCKOUT
                        1: NETLOGON_NEG_PERSISTENT_SAMREPL
                        1: NETLOGON_NEG_ARCFOUR                           1: NETLOGON_NEG_PROMOTION_COUNT
                        1: NETLOGON_NEG_CHANGELOG_BDC
                        1: NETLOGON_NEG_FULL_SYNC_REPL
                        1: NETLOGON_NEG_MULTIPLE_SIDS
                        1: NETLOGON_NEG_REDO
                        1: NETLOGON_NEG_PASSWORD_CHANGE_REFUSAL
                        0: NETLOGON_NEG_SEND_PASSWORD_INFO_PDC
                        0: NETLOGON_NEG_GENERIC_PASSTHROUGH
                        0: NETLOGON_NEG_CONCURRENT_RPC
                        0: NETLOGON_NEG_AVOID_ACCOUNT_DB_REPL
                        0: NETLOGON_NEG_AVOID_SECURITYAUTH_DB_REPL
                        1: NETLOGON_NEG_128BIT                            0: NETLOGON_NEG_TRANSITIVE_TRUSTS
                        0: NETLOGON_NEG_DNS_DOMAIN_TRUSTS
                        0: NETLOGON_NEG_PASSWORD_SET2
                        0: NETLOGON_NEG_GETDOMAININFO
                        0: NETLOGON_NEG_CROSS_FOREST_TRUSTS
                        0: NETLOGON_NEG_NEUTRALIZE_NT4_EMULATION
                        0: NETLOGON_NEG_RODC_PASSTHROUGH
                        0: NETLOGON_NEG_AUTHENTICATED_RPC_LSASS
                        1: NETLOGON_NEG_SCHANNEL               result                   : NT_STATUS_ACCESS_DENIED 
Comment 24 Karolin Seeger 2009-08-11 10:15:23 UTC
Reopening as requested.
Comment 25 Jeremy Allison 2009-08-11 13:32:19 UTC
Can you post your full debug level 10 log to the bug please ?
Thanks,
Jeremy.
Comment 26 Ken Bass 2009-08-11 17:17:44 UTC
Created attachment 4543 [details]
Full gzipped Debug Level 10 Log
Comment 27 Jeremy Allison 2009-08-14 18:12:18 UTC
Volker is planning to test this with 3.4.1 code early next week.
Jeremy.
Comment 28 Jeremy Allison 2009-08-17 16:01:21 UTC
Making this a blocker for 3.4.1. I think we need to make sure all domain control facilities work for Win7. Please feel free to override this if you disagree.
Jeremy.
Comment 29 Guenther Deschner 2009-08-19 16:48:11 UTC
(In reply to comment #23)
> Please reopen. 
> 
> With Windows 7 Release to Manufacturing (RTM), is appears this bug fix broke
> login. Login works with Samba 3.3.4, but is broken with 3.3.5, 3.3.6, 3.3.7.
> There is confirmation by two other people on the mailing list. According to the
> last comment this patch was rolled into 3.3.5.
> 
> After searching the archives I modified the required registry settings listed
> in other emails.

Ok, what were these registry keys please ? There are only two keys required to modify atm: 

        HKLM\System\CCS\Services\LanmanWorkstation\Parameters
                DWORD  DomainCompatibilityMode = 1
                DWORD  DNSNameResolutionRequired = 0

Have you modified your registry w.r.t. Netlogon settings ?
Comment 30 Ken Bass 2009-08-19 20:21:32 UTC
(In reply to comment #29)
> Have you modified your registry w.r.t. Netlogon settings ?

 I tried all permutations of the following which all work with 3.3.4, but not 3.3.5 and later. At first I tried just the first two, but then after it did not work, I found the additional two entries on various mailing lists/blogs in relation to Win 7 RC.

    HKLM\System\CCS\Services\LanmanWorkstation\Parameters
            DWORD  DomainCompatibilityMode = 1
            DWORD  DNSNameResolutionRequired = 0

        HKLM\System\CCS\Services\Netlogon\Parameters
            DWORD  RequireSignOnSeal = 0
            DWORD  RequireStrongKey = 0
Comment 31 Sven Strickroth 2009-08-27 18:32:40 UTC
(In reply to comment #30)
> work, I found the additional two entries on various mailing lists/blogs in
> relation to Win 7 RC.
> 
>     HKLM\System\CCS\Services\LanmanWorkstation\Parameters
>             DWORD  DomainCompatibilityMode = 1
>             DWORD  DNSNameResolutionRequired = 0
> 
>         HKLM\System\CCS\Services\Netlogon\Parameters
>             DWORD  RequireSignOnSeal = 0
>             DWORD  RequireStrongKey = 0
> 

I tested those with samba 3.3.7 pdc and Windows 7 (x86 German) RTM workstation and got the same output on the log (after joining the domain and after restarting windows 7 and trying to login as domain user) as described in comment #23 (and bug #6247).
Comment 32 Guenther Deschner 2009-08-28 07:00:26 UTC
Ok, just please do *NOT* modify the two NETLOGON registry keys. turn them both back to their default settings (1 instead of 0) and domain logon will work for all current 3.3 and 3.4 releases.
Comment 33 Guenther Deschner 2009-08-28 07:10:24 UTC
Jeremy: some background: once RequireStrongKeys has been set to 0, win7/w2k8r2 will compute a 64bit session key although it does not indicate that in the negotiate flags in the netr_ServerAuthenticate2/3 calls. This means that the Samba NETLOGON server will try to verify the credential chain using a 128bit session key and fail of course. I think we have two options in that case:
* either workaround this by trying both 64 and 128bit in the credential chain verification or
* do nothing while assuming that this is just a buggy behavior based on possibly misconfigured security settings on windows
Comment 34 Sven Strickroth 2009-08-28 07:12:52 UTC
(In reply to comment #32)
> Ok, just please do *NOT* modify the two NETLOGON registry keys. turn them both
> back to their default settings (1 instead of 0) and domain logon will work for
> all current 3.3 and 3.4 releases.

But without those settings I'm unable to join the domain with Windows 7.
Comment 35 Sven Strickroth 2009-08-28 08:08:53 UTC
(In reply to comment #34)
> But without those settings I'm unable to join the domain with Windows 7.

I opened a separate bugreport for it, because I found nothing similar on the bugzilla and dunno if it is related to this issue: bug #6671
Comment 36 Guenther Deschner 2009-08-28 08:30:44 UTC
(In reply to comment #34)
> (In reply to comment #32)
> > Ok, just please do *NOT* modify the two NETLOGON registry keys. turn them both
> > back to their default settings (1 instead of 0) and domain logon will work for
> > all current 3.3 and 3.4 releases.
> 
> But without those settings I'm unable to join the domain with Windows 7.

Ok, I took a fresh install of win7 ultimate, added the two LanManWorkstation registry keys, rebooted win7, joined a samba domain on a samba 3.3.7 pdc, rebooted win7 and sucessfully logged into the samba domain.

Which means I could not reproduce it, is there anything else required to reproduce ?
Comment 37 Sven Strickroth 2009-08-28 08:44:17 UTC
(In reply to comment #36)
> Which means I could not reproduce it, is there anything else required to
> reproduce ?

Strange: I did a reinstall and it works now (reproducible, with just these two settings).
Comment 38 Guenther Deschner 2009-09-02 05:16:16 UTC
Ok, thanks for the feedback. Glad to hear it is working now. Closing this one now again.