Sambaの更新
目次
- 1 はじめに
- 2 Samba4についての誤解
- 3 更新のプロセス
- 4 複数のSambaドメインコントローラの更新
- 5 Samba AD DCデータベースチェック
- 6 注目すべき拡張と変更
- 6.1 すべてのSambaインストールモードに影響する変更
- 6.2 Samba Active Directoryドメインコントローラ
- 6.3 Sambaドメインメンバ
はじめに
次のドキュメントでは、Sambaを新しいバージョンに更新するプロセスについて説明します。
Samba NT4ドメインをSamba Active Directory（AD）に移行する場合は、Samba NTドメインのSamba ADへの移行（Classicアップグレード）を参照してください。
Samba4についての誤解
 | Samba 4以降に更新する場合、必ずしもActive Directoryに移行する必要はありません。 |
Active Directory（AD）ドメインコントローラ（DC）サポートは、Samba 4.0で導入された拡張機能の1つです。しかし、すべての新しいバージョンには、以前のバージョンの機能が含まれています。これには、NT4スタイルの（古典的な）ドメインサポートが含まれます。つまり、以前に更新したように、Samba 3.x NT4形式のプライマリドメインコントローラ（PDC）を最新バージョンに更新することができます（たとえば、3.4.xから3.5.xへ）。 NT4形式のドメインをADに移行する必要はありません。
さらに、最近のすべてのバージョンでは、新しいNT4形式のPDCの設定が引き続きサポートされています。 Samba 4.0以降のADサポートはオプションで、PDC機能のいずれかを置き換えるものではありません。 Sambaチームは、既存のLDAP構造によってもたらされる困難を理解しています。そのため、従来のPDCサポートを削除する予定はありません。さらに、継続的な統合システムでPDCサポートのテストを続けます。
更新のプロセス
Samba Active Directory（AD）ドメインコントローラ（DC）、Samba NT4形式のPDC、Sambaドメインメンバ、またはスタンドアロンインストールを更新するかどうかにかかわらず、次の手順を実行します。
- すべてのSambaサービスを停止します。
- バックアップを作成します。
- スキップされたバージョンのリリースノートを読んでください。それらには、新機能、変更されたパラメータ、バグ修正などの重要な情報が含まれています。新しいメジャーリリースに切り替える場合は、初期バージョン（x.y.0）のリリースノートとマイナーバージョンからアップデートする新しいバージョンまでのリリースノートをお読みください。たとえば、4.4.4から4.6.2に更新する場合は、4.5.0,4.6.0,4.6.1、および4.6.2のリリースノートをお読みください。
- 既存のバージョンに最新バージョンをインストールします。
- ソースからSambaをコンパイルする場合は、以前のバージョンで使用したのと同じconfigureオプションを使用します。詳細は、「ソースからのSambaのビルド」を参照してください。
- パッケージを使用して更新する場合、更新方法については、ディストリビューションのドキュメントをお読みください。
- Sambaを起動します。
- 以前のバージョンと同じデーモンを起動してください：
- Samba AD DCについて：
samba - Samba NT4形式のPDC/BDC：
smbd、nmbd - Sambaドメインメンバ上で：
smbd、nmbd（winbind、使用されている場合） - Sambaのスタンドアロンホストの場合：
smbd
- Samba AD DCについて：
- Samba AD DCのみ：Samba AD DCデータベースチェックを実行します。
- Sambaのログファイルにエラーがないかどうか確認してください。
- 更新されたインストールをテストします。
複数のSambaドメインコントローラの更新
複数のSamba Active Directory（AD）ドメインコントローラ（DC）を更新する場合、推奨される順序は次のとおりです。
- Flexible single master operations（FSMO）の役割を持たないSamba AD DCを1つ更新します。
- 更新されたDC上でSambaを起動します。
- すべてのDC間のディレクトリ複製が正しく機能していることを確認します。
#samba-tool drs showrepl
- インストールをテストして、新しいバージョンが正しく動作することを確認します。
- 他のすべてのSamba DCを一度に1つずつアップグレードし、常にレプリケーションが正しく機能していることを確認します。
Samba AD DCデータベースチェック
samba-toolユーティリティを使用すると、Samba Active Directory（AD）データベースの問題を検出して修 正できます。たとえば、以前のSambaのバージョンが属性を誤って格納していて、更新されたバージョンが 問題を修正した場合などです。一部の修正は複製されていない属性に適用され、変更が他のDCに複製されな いため、すべてのSamba AD DCでcheckとfixコマンドをローカルで実行する必要があります。
ADデータベースを確認するには、次のコマンドを実行します。
# samba-tool dbcheck --cross-ncs
報告されたエラーを修正するには、
# samba-tool dbcheck --cross-ncs --fix
コマンドに--yesパラメータを渡すと、すべての質問にyesが自動的に返されま
す。 --yesパラメータを省略すると、データベースチェックは各オブジェクトに対して3つのfsync()
呼び出しを実行することに注意してください。その結果、実行時間が長くなります。たとえば、テ
スト環境では、-yesパラメータを10秒間に3500個のオブジェクトを固定したコマンドに渡します。このパラ
メータがないと、コマンドは同じ操作で4:50分必要でした。
修復後、データベースを再確認して、正常な操作を確認します。
注目すべき拡張と変更
Sambaを更新する場合は、前のバージョンと更新するバージョンのリリースノートを必ずお読みください。 これらには、新機能、変更されたパラメータオプションなどに関する重要な追加情報が含まれています。
このセクションでは、以前のバージョンの問題を修正するために注意が必要な重要な変更の概要を示し、パ フォーマンスの低下などを回避します。
すべてのSambaインストールモードに影響する変更
ファイル実行権限
4.0.0以降
以前は、Sambaはファイルの実行ビットをチェックしていませんでした。その結果、xビットが設定されてい ない場合、ユーザーは共有上で* .exeや* .batなどのファイルを実行できます。 Sambaが拡張され、xビッ トが設定されていない場合、ファイルの実行を拒否しました。以前のバージョンからアップグレードする場 合など、実行可能ファイルにxビットがない可能性があります。回避策として、個々の共有または[global] セクションに次のパラメータを設定すると、古い動作を有効にすることができます。
acl allow execute always = yes
Samba Active Directoryドメインコントローラ
ntvfs ファイルサーバーのバックエンドが無効になっています
4.5.0以降
以前は、Sambaを使用して、ntvfsファイルサーバーのバックエンドを使用してドメインコン
トローラ（DC）をプロビジョニングすることができました。このバックエンドはサポートされていないため、ntvfs機能はSamba 4.5.0ではデフォルトではビルドされなくなりました。その結果、ntvfsバックエンドを使用してDC上でsambaサービスを開始すると、更新後にエラーが発生し、次のエラーが記録されます。
[2016/09/01 08:00:00.000000, 0, pid=995] ../source4/smbd/service.c:98(server_service_startup) Failed to start service 'smb' - NT_STATUS_INVALID_SYSTEM_SERVICE [2016/09/01 08:00:00.000000, 0, pid=995] ../lib/util/become_daemon.c:111(exit_daemon) STATUS=daemon failed to start: Samba failed to start services, error code -1073741796
この問題を解決するには、DC上のファイルサーバーバックエンドをサポートされているs3fs
バックエンドに移行します。詳細は、ntvfsファイルサーバーのバックエンドをs3fsに移行するを
参照してください。
replPropertyMetaData属性の修正
4.5.0以降
4.5.0より前のバージョンのSambaでは、replPropertyMetaData属性が誤って格納されていました。結果として、管理者は、たとえば競合の名前を変更するなどの経験をすることができます。この問題は4.5.0以降の バージョンで修正され、Sambaは属性を正しく保存するようになりました。 samba-toolユーティリティは、間違って格納されたreplPropertyMetaData属性を検出するように拡張されました。
＃samba-tool dbcheck --cross-ncs
属性を修正するには、次のコマンドを実行します。
# samba-tool dbcheck --cross-ncs --fix --yes ... CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000003 CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com: 0x00000000 ERROR: unsorted attributeID values in replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com Fix replPropertyMetaData on CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com by sorting the attribute list? [YES] Fixed attribute 'replPropertyMetaData' of 'CN=NTDS Settings,CN=DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=samdom,DC=example,DC=com'
--yesパラメータはreplPropertyMetaData属性だけでなく、見つかったすべて
の問題を自動的に修正することに注意してください。
replPropertyMetaDataは複製されていない属性であり、変更は他のDCに複製されないため、
すべてのSambaドメインコントローラ（DC）で検査と修正の操作を実行します。
詳細については、[[#Samba AD DCデータベースチェック|]]セクションを参照してください。
idmap configパラメータがsmb.confファイルで設定されているとドメインコントローラ上の共有にアクセスできない
4.4.6以降
Samba Active Directory（AD）ドメインコントローラ（DC）のwinbinddサービスは、ユーザ
ーアカウントとグループのActive DirectoryのuidNumberとgidNumber属性で設定されたIDを自動的に使用します。属性が設定されていない場合、SambaはDC上でIDをローカルに生成し、idmap.ldbデータベースに格納します。したがって、Samba AD DCでは、smb.confファイルに設定されたidmap configパラメータは無視されました。 Samba 4.4.6以降のバグにより、パラメータは無視されなくなり、クライアントはDC上の共有に接続できなくなります。問題を解決するには：
- DC上の
smb.confファイル内のすべてのidmap configパラメータを削除します。 - samba
サービスを再起動します。 - クライアントを再起動します。
その結果、クライアントはDC上の共有に正しく接続するようになります。
新しいデフォルトのLDAP接続はで強力な認証を必要とします
4.4.1以降/ 4.3.7以降/ 4.2.10以降
セキュリティ更新プログラム4.4.1,4.3.7および4.2.10では、Active Directory（AD）LDAPサーバー用に強
力な認証を実施するための新しいsmb.confオプションが導入されました。この新しいオプション、ldap server require strong authのデフォルトはyesで、TLS暗号化接続を介した認証
方式Simpleのみが許可されます。その結果、LDAPを使用してADに接続する外部アプリケーションは、TLS暗
号化接続を使用していないか、またはサポートしていない場合、接続を確立できません。
暗号化せずにLDAPプロトコルを使用してSamba ADに接続するアプリケーションは、次のエラーメッセージを表示します。
ldap_bind: Strong(er) authentication required (8)
additional info: BindSimple: Transport encryption required.
詳細は、4.4.1,4.3.7、または4.2.10のリリースノートを参照してください。
削除されたLDAP DNSエントリのADデータベースクリーンアップ
4.1.12以降
以前は、Sambaは、削除されたDNSエントリの削除されたActive Directory（AD）オブジェクトを誤って作成しました。問題は修正されました。固定Sambaバージョンで最初のドメインコントローラ（DC）を起動する と、削除されたオブジェクトはすべて削除されます。その結果、削除されたオブジェクトが削除されるまでパフォーマンスが低下する可能性があります。
不適切なTLSファイルのアクセス許可
4.1.2以降/ 4.0.12以降
以前は、Sambaは安全でないアクセス権を持つLDAP TLS暗号化に使用される* .pemファイルを作成していま した。安全でない接続を回避するには、すべてのドメインコントローラ（DC）上のファイルを削除します。
# rm /usr/local/samba/private/tls/*.pem
新しい証明書を自動的に再作成するためにファイルを削除した後でSambaを再起動してください。
動的DNSアップデートの問題の修正
4.0.7以降
詳細については、Samba 4.0.7より前のバージョンでのDNS動的更新の修正を参照してください。
不適切なSysvolおよびディレクトリACLの修正
4.0.x以前のバージョンからアップデートする場合、4.0beta と 4.0RC
- 不適切なSysvol ACLをリセットするには、次のコマンドを実行します。
# samba-tool ntacl sysvolreset
- ディレクトリ内のよく知られているすべてのACLをリセットするには、次のコマンドを実行します。
# samba-tool dbcheck --cross-ncs --reset-well-known-acls --fix
- Active Directory（AD）データベースのエラーを修正するには、次のコマンドを実行します。
# samba-tool dbcheck --cross-ncs --fix
Sambaドメインメンバ
IDマッピングの設定検証
4.6.0以降
以前は、Sambaはドメインメンバーのsmb.confファイルのIDマッピング設定を確認していませんでした。したがって、ユーザーは、重複するID範囲や、デフォルトドメインの不正なバックエンドなど、誤ったIDマッピング構成を設定する可能性があります。その結果、winbinddサービスが開始
され、IDマッピングが失敗したか、期待どおりに動作しませんでした。 testparmユーティリティが強化され、誤ったIDマッピング設定が報告されるようになりました。例えば：
ERROR: The idmap range for the domain * (tdb) overlaps with the range of SAMDOM (ad)!
ERROR: Do not use the 'ad' backend as the default idmap backend!
さらに、誤ったIDマッピング設定を使用すると、winbinddサービスが起動できず、エラーメッセージが記録されます。例えば：
[2017/03/01 12:00:00.000000, 0, pid=980] ../source3/winbindd/winbindd.c:1705(main) main: FATAL: Invalid idmap backend ad configured as the default backend!
Samba 4.6.0以降を使用すると、ユーザーは誤ったIDマッピング設定を使用できなくなります。
詳細、ドメインメンバーのサポートされているバックエンド、およびその設定については、以下を参照してください。
- Identity Mapping Back Ends
smb.conf(5)のマニュアルページの「IDENTITY MAPPING CONSIDERATIONS」セクション
adマッピングのバックエンドは、ドメインごとにRFC2307またはテンプレートモードを有効にすることをサポートしています
4.6.0以降
以前は、winbind nss infoパラメータがrfc2307に設定されていたとき、SambaのadIDマッピングバックエンドはすべてのActive Directory（AD）ドメインのシェルとホー
ムディレクトリ設定をADから取得しました。 Samba 4.6.0では、新しいidmap config domain_name：unix_nss_infoパラメータが追加されました。このパラメータを使用すると、管理者は、ユーザーのシェルおよびホームディレクトリ設定をADから取得する必要がある場合、またはテンプレートシェルおよびテンプレートのhomedirパラメータに設定されているテンプレート設定が適用されている場合、ADドメイン
単位で設定できます。
新しいidmap config domain_name：unix_nss_infoパラメータの優先度は、グローバルwinbind nss info = rfc2307の設定よりも高くなっています。したがって、idmap config domain_name：unix_nss_info = noを ADドメインのデフォルト設定としての使用すると、シェルおよ
びホームディレクトリはADから取得されなくなり、template shellおよびtemplate homedirパラメータに設定された値が適用されます。ドメインのADから値を取得できるようにするには、smb.confファイルの[global]セクションで次のように設定します。
idmap config domain_name：unix_nss_info = yes
詳細と設定方法の例については、idmap config ad - adバックエンドの設定を参照してください。
