Hi, Did you get a chance to test it with 3.4.0? I have 3.3.7 installed - Windows 7 RTM joins the domain (with the primary dns suffix error) but cannot log in to as I get the trust error (output in the log.smbd is the same as everyone elses). The regkeys mentioned are all applied btw. I would rather go upwards than downgrade to get this working. I haven't seen anything official from the Samba folks on the issue or when Windows 7 will work? Thanks, P. SkyBeam wrote:> > > kmorning wrote: >> >> I installed windows 7 RC and was able to join my samba 3.3.6 domain and >> just as with server 2008r2 I ran into the "trust relationship" issue when >> trying to log into the domain. At this point I became a little >> frustrated since it seems everyone else here has had success with this. >> >> Finally, as a last ditch effort, I decided to downgrade to 3.3.4 since >> I've seen no mention of anyone using 3.3.6 in this scenario. Lo and >> behold, my domain logins now work in both win7 and win2008r2. >> >> Now this would lead me to believe something in 3.3.6 has broken this >> functionality, but I don't want to say this with absolute certainty. >> Perhaps in my process of uninstalling 3.3.6 and installing 3.3.4 I fixed >> something unbeknownst to me. >> >> I'm using a gentoo distro, and the reason for me initially installing >> 3.3.6 was because it was the the only ebuild for a 3.3.x flavour in the >> portage tree (which I had to unmask since it is still hard masked). >> After unemerging 3.3.6 I created a portage overlay for 3.3.4 and emerged >> it. >> >> Can someone confirm (or deny) my findings with 3.3.6? >> > > I can confirm this findings. > > I am running Gentoo Linux and my Samba was on latest 3.0 release. Changing > the registry keys in LanmanWorkstation parameters to enable domain > compatibility helped to join the domain. However the error about changing > the primary DNS domain remained. > I don't know if this is relevant at all or just annoying. The DNS suffix > for the connection is published by the DHCP server here. But maybe the > message is about something else. > > Anyway I immediately faced the problem that the trust relationship between > the workstation and the machine failed when I try to log in: "The trust > relationship between this workstation and the primary domain failed." > > So I followed this thread and first upgraded to the latest Samba release > available for my distribution (Gentoo) which was 3.3.6. Still no go. > Following your suggestion I've created a local overlay and some Samba > 3.3.4 overlays. Surprisingly you're right and Samba 3.3.4 works great. So > something has been broken (or enhanced in a Win-7 incompatible way) in > Samba 3.3.6. > If I find some time I will try to use Samba 3.4 too but this might be more > difficult than my 3.3.4 overlays... > > (Running Windows 7 Professional RTM, no Beta/RC) >-- View this message in context: http://www.nabble.com/Windows-7-RC-tp23405949p25241642.html Sent from the Samba - General mailing list archive at Nabble.com.
kmorning wrote:> > I installed windows 7 RC and was able to join my samba 3.3.6 domain and > just as with server 2008r2 I ran into the "trust relationship" issue when > trying to log into the domain. At this point I became a little frustrated > since it seems everyone else here has had success with this. > > Finally, as a last ditch effort, I decided to downgrade to 3.3.4 since > I've seen no mention of anyone using 3.3.6 in this scenario. Lo and > behold, my domain logins now work in both win7 and win2008r2. > > Now this would lead me to believe something in 3.3.6 has broken this > functionality, but I don't want to say this with absolute certainty. > Perhaps in my process of uninstalling 3.3.6 and installing 3.3.4 I fixed > something unbeknownst to me. > > I'm using a gentoo distro, and the reason for me initially installing > 3.3.6 was because it was the the only ebuild for a 3.3.x flavour in the > portage tree (which I had to unmask since it is still hard masked). After > unemerging 3.3.6 I created a portage overlay for 3.3.4 and emerged it. > > Can someone confirm (or deny) my findings with 3.3.6? >I can confirm this findings. I am running Gentoo Linux and my Samba was on latest 3.0 release. Changing the registry keys in LanmanWorkstation parameters to enable domain compatibility helped to join the domain. However the error about changing the primary DNS domain remained. I don't know if this is relevant at all or just annoying. The DNS suffix for the connection is published by the DHCP server here. But maybe the message is about something else. Anyway I immediately faced the problem that the trust relationship between the workstation and the machine failed when I try to log in: "The trust relationship between this workstation and the primary domain failed." So I followed this thread and first upgraded to the latest Samba release available for my distribution (Gentoo) which was 3.3.6. Still no go. Following your suggestion I've created a local overlay and some Samba 3.3.4 overlays. Surprisingly you're right and Samba 3.3.4 works great. So something has been broken (or enhanced in a Win-7 incompatible way) in Samba 3.3.6. If I find some time I will try to use Samba 3.4 too but this might be more difficult than my 3.3.4 overlays... (Running Windows 7 Professional RTM, no Beta/RC) -- View this message in context: http://www.nabble.com/Windows-7-RC-tp23405949p24982658.html Sent from the Samba - General mailing list archive at Nabble.com.
SkyBeam wrote:> > However the error about changing the primary DNS domain remained. > I don't know if this is relevant at all or just annoying. The DNS suffix > for the connection is published by the DHCP server here. But maybe the > message is about something else. >I just discovered that this message is indeed about the primary DNS suffix. The 'ipconfig /all' command now lists multiple suffixed: ... DNS Suffix Search List. . . . . . : DOMAIN domain.local Where "domain.local" seems to be pushed by DHCP but the first entry (DOMAIN) seems to be pushed by domain join. Unfortunately it takes priority. Therefore access to hostnames without appended DNS domain name fail here. E.g. ping server Windows 7 tries to resolve 'server.DOMAIN' which fails due to the fact that there is no DNS response for this hostname. Pinging "server.domain.local" works as expected. Unfortunately this breaks services/scripts/applications which were just using the hostname and relying on the DNS suffix. Actually I tried to work-around this issue as follows: Go to tystem properties and open the Computer Name tab and click on the "Change..." button (exactly as you would to change domain membership). Now in the "Computer Name/Domain Changes" window click on the "More..." button and uncheck the "Change primary DNS suffix when domain membership changes" checkbox. Then click OK and switch to Domain membership. Now join the domain as usual. Unfortunately Windows 7 seems to ignore my settings. It still tries to change the DNS suffix and pops up the same error message. However the checkbox remains unchecked but the DNS suffix for this computer is still inserted as "DOMAIN". When I try to change it later on using the "DNS Suffix and NetBIOS Computer Name" dialog box the "The specified domain either does not exist or could not be contacted" continues to pop up. It looks to me like Windows contacts the domain controller but Samba does not answer - or answers with unexpected value. The work-around I am using now is that I renamed my domain using smb.conf from "DOMAIN" to "domain.local" (equal to the DNS suffix). Samba automatically created a new sambaDomainName entry in LDAP which uses the same domain SID. Surprisingly even my vista machine which was joined to the DOMAIN NT-Domain did not even complain about the disappeared "DOMAIN" and seems to be able to connect to the "domain.local" NT-Domain without any change (while in system properties it still claims to be member of the "DOMAIN" NT-Domain). -- View this message in context: http://www.nabble.com/Windows-7-RC-tp23405949p24983475.html Sent from the Samba - General mailing list archive at Nabble.com.
SkyBeam wrote:> > The work-around I am using now is that I renamed my domain using smb.conf > from "DOMAIN" to "domain.local" (equal to the DNS suffix). Samba > automatically created a new sambaDomainName entry in LDAP which uses the > same domain SID. Surprisingly even my vista machine which was joined to > the DOMAIN NT-Domain did not even complain about the disappeared "DOMAIN" > and seems to be able to connect to the "domain.local" NT-Domain without > any change (while in system properties it still claims to be member of the > "DOMAIN" NT-Domain). >I found another work-around which does not require changing your Samba configuration (which might have other side-effects too). You can use group policy to enforce the DNS suffix. To do so open the group policy editor (e.g. run "gpedit.msc") and go to Administrative Templates => Network => DNS Client. Here you can set the "Primary DNS Suffix" policy to match your DNS domain. Alternatively you might set the following registry REG_SZ value: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient\NV PrimaryDnsSuffix Set the value to the desired domain sufix (e.g. "domain.local"). Then reboot the machine and see 'ipconfig /all' printing your custom primary DNS suffix. However within the system properties you will still see your "DOMAIN" listed but it's overridden by the policy value. You can do this change before or after joining the domain. Note that the error shown by Windows about the failure to change the primary DNS suffix on domain join is still there. This change only allows you to fix an invalid primary DNS suffix which you're otherwise unable to change after domain join. So here's a reg file which works for me: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters] ; Enable NT-Domain compatibility mode ; Default: ; [value not present] ; "DomainCompatibilityMode"=- "DomainCompatibilityMode"=dword:00000001 ; Disable required DNS name resolution ; Default: ; [value not present] ; "DNSNameResolutionRequired"=- "DNSNameResolutionRequired"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters] ; Disable requirement of signed communication ; My Samba works with signed communication enabled, so no need to disable it. ; Default: ; "RequireSignOrSeal"=dword:00000001 ; Disable the usage of strong keys ; Default: ; "RequireStrongKey"=dword:00000001 "RequireStrongKey"=dword:00000000 [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient] ; Enforce DNS suffix "NV PrimaryDnsSuffix"="domain.local" With these settings I can join the domain and logon works. However I've noticed that samba still logs the following message: [2009/08/15 14:14:41, 0] rpc_server/srv_netlog_nt.c:_netr_ServerAuthenticate2(546) _netr_ServerAuthenticate2: netlogon_creds_server_check failed. Rejecting auth request from client WIN7TEST machine account WIN7TEST$ [2009/08/15 14:15:18, 0] smbd/service.c:make_connection_snum(740) create_connection_server_info failed: NT_STATUS_ACCESS_DENIED [2009/08/15 14:15:30, 0] smbd/nttrans.c:call_nt_transact_ioctl(1989) call_nt_transact_ioctl(0x1401c4): Currently not implemented. Probably it's a bug of Samba 3.3.4 which still permitts logon even if machine authentication fails. The NT_STATUS_ACCESS_DENNIED is repeated many times. -- View this message in context: http://www.nabble.com/Windows-7-RC-tp23405949p24984174.html Sent from the Samba - General mailing list archive at Nabble.com.
SkyBeam wrote:> > Alternatively you might set the following registry REG_SZ value: > HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient\NV > PrimaryDnsSuffix > Set the value to the desired domain sufix (e.g. "domain.local"). Then > reboot the machine and see 'ipconfig /all' printing your custom primary > DNS suffix. However within the system properties you will still see your > "DOMAIN" listed but it's overridden by the policy value. >I found that this solution does not fully work sometimes Windows still tries to look up "<host>.DOMAIN" instead of "<host>.domain.local". So I was looking for the place within the registry which stores the domain name (which fails to propagate on domain-join) and found it within the TCP/IP service at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters. Changing the "NV Domain" to the right local domain makes the domain appear within the domain join dialog too. So my modification reg-file looks as follows now: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters] ; Enable NT-Domain compatibility mode ; Default: ; [value not present] ; "DomainCompatibilityMode"=- "DomainCompatibilityMode"=dword:00000001 ; Disable required DNS name resolution ; Default: ; [value not present] ; "DNSNameResolutionRequired"=- "DNSNameResolutionRequired"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters] ; Disable requirement of signed communication ; My Samba (3.0.33) works with signed communication enabled, so no need to disable it. ; Default: ; "RequireSignOrSeal"=dword:00000001 ; Disable the usage of strong keys ; Default: ; "RequireStrongKey"=dword:00000001 "RequireStrongKey"=dword:00000000 ; [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient] ; Enforce DNS suffix ; It seems this is not necessary - see below ; "NV PrimaryDnsSuffix"="domain.local" [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters] ; Overwrite DNS domain. Usually the domain is supposed to be propagated automatically ; when joining the domain. But with Samba this does not work (yet). "NV Domain"="domain.local" -- View this message in context: http://www.nabble.com/Windows-7-RC-tp23405949p24998818.html Sent from the Samba - General mailing list archive at Nabble.com.