Notes on switching to Samba 4
When Samba 4 had reached stable, the development and maintenance work for the Samba 3 branch was discontinued. As a result, almost all common Linux distributions (client and server versions) come with Samba 4 instead of Samba 3. This results in some changes that will be documented in this chapter.
Samba shares are an essential component for the functionality of opsi. Due to the "general" update to Samba 4, there are a few things to consider that will be briefly explained in the following chapters.
A distinction must be made in which operating mode Samba is executed. A special feature of Samba 4 is the ability to run as a fully-fledged Active Directory-compatible domain controller. In this operating mode (which is called PDC mode in the following chapters for reasons of simplification), there are restrictions that had to be adopted from Active Directory for reasons of compatibility. Most distributions are usually equipped with Samba 4, but only in the normal shares operating mode. Operating a full-fledged Active Directory domain is generally not possible with the standard packages from the distributions. An exception here is the Univention Corporate Server, in which the PDC mode is also integrated in the standard packages.
|The restrictions described in this chapter only affect the PDC mode of Samba 4.
The classic installation variant with the user:
pcpatch with the primary group:
pcpatch cannot be followed for installations with Samba 4. Since Samba 4 is subject to the basic restrictions of Active Directory, groups with the same name as users (as is usual in Unix/Linux) are no longer allowed. For this reason, a new configuration file has been introduced for Samba 4 installations:
/etc/opsi/opsi.conf, which controls how the group is determined for Samba access to the shares. In the case of Samba 4 installations, the group name
pcpatch is now renamed via this file and is now called
opsifileadmins. This means that the users which must have access rights to the shares of opsi (opsi-packagers) under Samba 4 cannot become a member of the
pcpatch group, but must be a member of the
Furthermore, in this case the user
pcpatch must now be created as a fully-fledged domain user and no longer as a system user, since otherwise he cannot access the domain shares.
These steps are carried out automatically when installing opsi on a Univention Corporate Server, if the installation process detects that Samba 4 is running in PDC mode.
Besides the UCS installations, currently there are no other default Active Directory configurations. So these steps have to be done manually for any other Samba 4 Active Directory domain contoller installation. During future updates, the opsi system checks for the required user configuration and does not try to create users, that already exist.
For any questions please contact opsi support. In case you do not have an opsi support contract, please contact firstname.lastname@example.org.
|The changes described in this chapter are relevant for all operating modes of Samba 4.
In Samba 3 the default setting was, that every file or directory was executable by the clients. This behavior has been completely changed in Samba 4. Now all files, that should be executable from the share, must also have the executable bit set on the Unix side.
This is a problem for the operation of opsi. It is not possible to circumvent this behavior via the opsi rights management, as this would require a complete revision of the opsi rights system. This is not possible in opsi 4.
There are two ways to work around the problem with opsi 4.0:
Option 1 (recommended): You can set the following option in smb.conf:
acl allow execute always = true
This option restores the behavior of Samba 3 for the relevant shares.
This option can be set for individual shares as well as globally. We recommend that you do not set this globally but individually for all opsi shares (unless this has already been set automatically).
This variant may not work with Univention Corporate Server, since a highly modified Samba 4 variant is used here. In this case, use option two.
Option 2: this behavior can be overridden on the affected shares via the individual share configuration using the following option for each member of the pcpatch group (share users):
admin users = @pcpatch
Opsi has been using this fix for a while with UCS >= 3 and Samba 4. With this fix, the Samba process of the user is executed with elevated rights.
Opsi automatically sets this option for the 'opsi_depot' share for Samba 4 distributions via
opsi-setup --auto-configure-samba. Since this share is only mounted read-only, the security risk is relatively low.
|For all other shares, that are mounted as read/write, it should be borne in mind that with this fix the Samba process runs with elevated rights. This can be a potential risk. No exploits are currently known for this vulnerability, but of course this is no guarantee that such an exploit does not exist.
|The Linux smb daemon has a bug. This is in combination with the 'opsi_depot' share definition in smb.conf. The oplock parameters must be removed on existing installations. New opsi installations and, accordingly, new shares are created without oplocks.
|This restriction affects all operating modes of Samba 4.
When using Samba 4, it may be necessary to explicitly specify the domain/user combination with which to mount the depot share. There is also the new setting:
clientconfig.depot.user. If there is no such setting, the user
pcpatch is used.
The value of this setting has the syntax:
<domain name>\<user name>
For example, the setting:
clientconfig.depot.user = opsiserver\pcpatch indicates that when mounting the depot share the authentication will be done as domain
opsiserver and as user
Such a setting can be created via opsi-configed:
Server configuration / clientconfig / right mouse button: Add standard configuration entry.
Such a setting can also be created on the command line (whereby 'pcpatch' must be replaced by the desired value e.g. 'opsiserver\pcpatch'):
opsi-admin -d method config_createUnicode clientconfig.depot.user "clientconfig.depot.user" pcpatch
This system-wide setting can be customized per client (e.g. in configed in the Host parameters tab).