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.
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.
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
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.
Volker, That should not be an issue. The assumptions our code makes is based on the values in the NegotiatedFlags.
(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.
Created attachment 3935 [details] implement netr_ServerAuthenticate3 patch Just in case we are going to implement ServerAuthenticate3, here is a patch.
(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).
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
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.
Jeremy, Samba4 just returns back the flags passed in. No Samba3 release ever did, as far as I can see.
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
"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.
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.
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).
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.
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.
Patchset like fine. Thanks for collecting that!
Jeremy, could you please add patches for 3.2? Thanks!
Created attachment 4141 [details] gzip'ed tarball of patches for v3-2-test
Added patchset for 3.2.x also. Jeremy.
Karolin, I think we are ready with this one. Re-assigning to you.
Patches will be included in 3.2.12 and 3.3.5. Closing out bug report. Thanks for reporting!
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
Reopening as requested.
Can you post your full debug level 10 log to the bug please ? Thanks, Jeremy.
Created attachment 4543 [details] Full gzipped Debug Level 10 Log
Volker is planning to test this with 3.4.1 code early next week. Jeremy.
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.
(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 ?
(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
(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).
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.
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
(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.
(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
(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 ?
(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).
Ok, thanks for the feedback. Glad to hear it is working now. Closing this one now again.