Bugzilla – Bug 391495
Joining SMB domain during install does not work if the firewall is enabled
Last modified: 2017-08-10 09:55:50 UTC
Performing a fresh install of opensuse 11.0 Beta 3, I selected as authentication method "Windows domain". During the phase 2 of the install, after the network is configured, when I was at the point to add the machine to the domain, I entered the domain name, but after a short while it reported failure. I went back to the network setup, disabled the firewall, and then joining the domain succeeded. Cheers
Created attachment 216079 [details] log files during the install
Lukas/Ludwig, I'm not sure if I remember correctly, but is this known and expected issue or should it work?
ftp://cml.suse.cz/netboot/find/openSUSE-11.0-Beta3-DVD-x86_64/docu/RELEASE-NOTES.en.html#05 SuSEfirewall2: New Variables Starting with FW_SERVICES_ACCEPT_RELATED_ SuSEfirewall2 implements a subtle change regarding packets that are considered RELATED by netfilter. For example, to allow finer grained filtering of Samba broadcast packets, RELATED packets are no longer accepted unconditionally. The new variables starting with FW_SERVICES_ACCEPT_RELATED_ have been introduced to allow restricting RELATED packets handling to certain networks, protocols and ports. This means adding conntrack modules to FW_LOAD_MODULES does no longer automatically result in accepting the packets tagged by those modules. Additionally, you must set variables starting with FW_SERVICES_ACCEPT_RELATED_ to a suitable value.
Well, hm, but how does this relate to current samba behavior? What should be changed, YaST module (how?) or samba tools?
Query the firewall config for unprotected zones, if there are none chances are good that broadcast based stuff doesn't work so you can warn the user.
This should be fixed from the firewall side, I think samba can do nothing if firewall blocks it
And what was the previous behavior? Did join work with the firewall configured? If the only thing YaST module could do is warning user, this is not very helpful.
Samba-team: please answer if anything regarding samba and firewall was changed since 10.3 If join is not possible when firewall is up, that there is a problem during installation, because in default instalation, you cannot switch the fireall off. Lukas, Ludwig: I do not understand what could YaST module do: what is the SuSEFirewall API to enable samba join through firewall (if it is possible)? Or should some samba package update the firewall settings when it is installed (post-script)?
It's FATE #300970, comments #22 and #24. The feature handles FW_SERVICES_ACCEPT_RELATED_EXT and FW_LOAD_MODULES. BTW: it's not so easy to tune the settings, but there should be functions available in SuSEFirewall YCP module. Don't know if we can fix it now.
Nothing on samba itself should have change w.r.t. firewall since 10.3, but if samba ports haven't been opened, join isn't going to work. We'll certainly need 137-139, 445 open, in particular the name resolution won't work without 137, since it may well be happening through broadcast.
Oh. Should I add "Open Port in Firewall" widget for samba-client now?
Created attachment 220438 [details] proposed patch
Users will ask why they have "Samba Server" enabled in their firewall. + CWMFirewallInterfaces::CreateOpenFirewallWidget ($[ + "services" : [ "samba-server" ], + "display_details" : true, + ]);
The answer is, that it is the technical side of the "Open Port in Firewall" check box present in Samba Client/Server. "samba-server" service as defined in SuSEFirewallServices.ycp covers the ports listed in comment 13.
... and that's a side effect of bug 247344 still in NEW state
No, it does not depend. While it would be nice to have "service" called samba-client, the point of this bug and the reason why it is marked as critical is that it is not possible to join Windows domain during installation.
I don't see this as critical, and as such would not fix it.
I still wonder why people want to join an AD domain via an external interface. IMO (although not useful to fix this bug post text freeze) the yast module should check for internal zones resp ask which interface to mark as internal instead of suggesting to open ports.
Because on my laptop all interfaces (LAN and WiFi) are marked as external in case I connect to an "alien" network. But anyway - this case is all about that the option is provided (join domain at install), but even not a warning is issued as what can be the problem if it does not succeed. Also, during install, one does not have enough control over the firewall settings to fine-tune. So, I guess, just a warning, or option to disable the firewall temporary during the domain join are good enough. With a proper warning, that if the firewall is up, w/o opening the smb ports, even authentication will not work, but opening the necessary ports (samba client firewall service, as suggested) can be done later.
Just an addition - I really like the idea of adding samba client service for the firewall. The manual config for 10.3 was hard enough, and in case you want network neighborhood browsing, the broadcast ports opening did not work, but an additional kernel modules had to be installed. If now the firewall can be fine-tuned to allow broadcasts as they are needed by samba client, the service will help a lot.
The modules, needed in 10.3 to browse network are described in bug 225635.
11.1: Lukas, please create "samba-client" in SuSEFirewallServices (with the same values as current samba-server). You may remove it later when bug 247344 is fixed (rather let's not wait for it).
All services will become obsolete and I'd be for solving that a standard way: adding a file into samba-client package. I think I can do it myself (for 11.1).
So do it and return the bug to me when it is ready.
LATER (after 11.0)
mass reopening of later+remind bugs of 11.0
I rather don't want to change samba package, Lars, could you, please, add that file?
P2, Major... This is required for Samba to work with firewall.
Ludwig expressed in his comment #22 this is something YaST should care about. While Lukas in comment #27 + #31 claims this is something samba on the package level has to care about. It's not clear to me how we can ensure to open the ports described in comment #10 while joining a daomain as part of the join process.
There is no second stage in installation anymore and thus you cannot switch to using SMB for authentication. This needs to be done later on a running system via Yast Users (or Yast Samba Client?) then, if you need to open any ports, they have to be listed in samba Firewall plug-in for opening ports (service file). The situation has changed since 2008 and I no longer see into this problem so I can't really tell what's the solution.
Based off the last comment here i'm going to close this one as WONTFIX feel free to create a new issue or update this one if it is required.