Unable to join a domain with windows 7 beta1

[Jim Pinkerton]

Well, to quote the trailer in an email that Jeremy and I sent out for the SNIA SMB/CIFS interop

event back in September:



   (... and yes, pigs can fly!... :-)



... and now can actually post to external reflectors! What a concept.



As we slooowly, but surely break down the accumulated walls that have built up over the years, today is a bit of a unique day in my experience - we (well, really Nick Meier, representing Microsoft's interop lab) filed bugs against Samba to help get over the interop issues we've seen with Windows 7 (and yep, we have bugs on our end as well (sigh)...).



The bugs are:

      Samba 4 - Function NetrLogonDummyRoutine1 needs to return STATUS_NOT_IMPLEMENTED (bug 6109)

      Samba 4 - NetrServerAuthenticate[2,3] returns inaccurate capabilities (bug 6108)



      Samba 3.2 - Function NetrLogonDummyRoutine1 needs to return STATUS_NOT_IMPLEMENTED (bug 6100)

      Samba 3.2 - NetrServerAuthenticate[2,3] returns inaccurate capabilities. (bug 6099)





Just so hopefully we all know what's going on, lemme attempt to explain what the heck happened (and no, to the best of my knowledge we're not trying to hose small business' as was theorized on this thread :-)). First, we've dropped support for NT Domains - thus it is no longer included in our test matrix. And as programmers often do, old things break as you introduce new things (like AES support, better diagnostics).  Also, the crypto community pretty strongly deprecates 40 and 56 bit crypto, so the default minimum crypto required is 128 bit (overridden with a reg-key, if you don't need enterprise class security or interop is more important). That said though, the goal is interop. Period. But interop is never a constant target, as we both continue to put new features in our code bases.



So the beta interop issue was pretty much what betas are for - we've tested it enough in our labs, time to put it out in the big-bad real world. And of course we found a few holes in our test plan... interop testing with Samba was minimal (we've fixed this going forward). We scurried around internally to figure out how bad it was, and then sent out an email with full status, plus had a sanity-check con-call with a few Samba folks (I'm going to botch it if I try to say everyone that was on, but a few of the usual suspects, like Tridge, Volker, Andrew, James Peach...). On our end were devs from the AD team, netlogon team, and the SMB team. This resulted in the above bugs being filed.



So in short, we have a plan. Fix the above bugs on your end, we'll fix a few on our end, and we'll meet in the Microsoft Cambridge Interop lab (well, virtually meet) with privates ASAP to verify there aren't any other hidden issues (hopefully before we ship the next Windows 7 beta update). Below is the gory details, sent out by Keith Hageman before the con-call, including thoughts around interop matrices (i.e. what will work by default, what won't but has defaults that can be over-ridden, etc).



Hope this helps. A bit long winded, but hopefully worthwhile.





Jim





-----------



Following is our current understanding of the issue you have reported to us including additional

testing that was recently completed. We welcome your input here and would like to start an

active dialog to resolve these issues.



Summary:

-  We have done quite a bit of testing with Samba 3.2.7. Spotty on other versions (help appreciated.)

-  Have found issues with AD, crypto, and netlogon, due to non-testing of NT interop and

   upgrading of security requirements. Going forward (post win7) strongly encourage Samba team

   to move off the NT Domain, since we stopped supporting it a while back (and thus aren't

   testing it as thoroughly as we used to).

    o  We're up for fixing the issues on our side to interoperate with Samba, however

       a couple of the issues we're recommending be fixed in the Samba code, because to

       fix it on our end opens us to man-in-the-middle attacks.



Summary of outstanding technical issues:

-  We think there are two bugs in Samba (which we'll file bug reports for):

    o  [MS-NRPC]NetrServerAuthenticate[2,3] Message output, NegotiateFlags field - need

       to set negotiated flag to the intersection of what they support and what the client

       supports (currently it appears to just be echoed back, falsely advertising capabilities

       that Samba doesn't support).

    o  [MS-NRPC]NetrLogonDummyRoutine1 (for win7 this is renamed NetrLogonGetCapabilities) - i.e. opnum 21.

          § Function call to test for a man-in-the-middle attack - first implemented in win2k.

          § If Samba supported the end-point, but not the method, and returned "status not

            implemented", then the response is secure and we would downgrade to prior behavior.

          § Approach that would open us up to man-in-the-middle attacks - If "RPC procnum out

            of range" error was returned. This is because it is not signed, thus it opens us

            up to man-in-the middle attacks.



Here is the proposal for the interop matrix with Windows 7 (after all changes have been done

for Windows 7 and for Samba):

-  Samba as a domain joined file server

    o  With current Samba and the proposed modifications to Windows 7, full interop.

    o  Downlevel interop may require setting of registry keys on Windows 7.

         - Note: this means that a Win7 client must substantially degrade it's

           security configuration to achieve this functionality.

           (See below for Win7 Client registry settings information)

-  Samba as a domain joined SMB client

    o  Would interoperate

-  Samba as a DC

    o  would require installation of security patches as defined above.

       If they are not installed, then Windows 7 would not interoperate.

-  Samba in non-domain joined environments (i.e. SMB server or client)

    o  Would interoperate



Configuration changes potentially required on Win7 client to interoperate with

downlevel Samba DC (unknown yet which versions of Samba require which

settings - arguably just set them all):



*  WS08/Win7 clients perform DNS name resolution validations to enable detection

of misconfigured environments early. This must be disabled via client registry

policy for NT4 domains as they don't have DNS names.

      o HKLM\System\CCS\Services\LanManWorkstation\Parameters DWORD DNSNameResolutionRequired = 0



*  NT4 does support NTLM v2, Win7 client's require it by default:

      o Gpedit.msc / Computer Configuration / Windows Settings / Security Settings /

        Local Policies / Security Policies - "Network security: LAN Manager authentication

        level" needs to be relaxed to one of the levels that accepts LM & NTLM but doesn't

        require NTLM v2 otherwise NTLM auth fails with errors like 1326 ERROR_LOGON_FAILURE.



*  Two Win7 client registry policies that must be disabled as NT4 does not support them.

      o HKLM\System\CCS\Services\Netlogon\Parameters  DWORD RequireSignOrSeal and RequireStrongKey = 0



*  Win7 requires NTLM 128bit:

      o Gpedit.msc / Computer Configuration / Windows Settings / Security Settings /

        Local Policies / Security Policies - Network security: Minimum session security

        for NTLM SSP based (including secure RPC) clients

           § Uncheck: Require 128-bit encryption.



Stuff left to examine:

- Unsecure domain join (using a pre-created computer account in the domain). This does

not work against an NT 4 machine, but we haven't yet tested against Samba. Since Samba

supports 128 bit crypto,  this may work - but need to validate.





Next steps:

-  We both do code changes.

-  We would like to test interoperability with Samba  ASAP (i.e. not wait for the next major

   release) in the Windows Interop lab in Cambridge to validate all the above (both for uplevel

   (i.e. bug fixed) Samba DC and for the other scenarios).