適用対象: ✔️ SMB ファイル共有
Azure Filesは、Kerberos認証プロトコルを用いて、オンプレミスのActive Directory Domain Services(AD DS)と連携し、Linux仮想マシン(VM)に対してServer Message Block(SMB)によるIDベースの認証をサポートしています。 この手順を使用するには、Microsoft Entra Connect Sync を使用して AD DS 環境を Microsoft Entra ID と同期する必要があります。
サポートされているオプションと考慮事項の詳細については、「 SMB アクセスのAzure Files ID ベースの認証オプションの概要を参照してください。
注
この記事では、手順の例として Ubuntu を使用します。 同様の構成はRHELやSLESクライアントでも機能し、オンプレミスのAD DSを使ってAzureファイル共有をマウントできます。
Linux SMB クライアントの制限事項
ID ベースの認証を使用して、fstab エントリにより Linux クライアントの起動時に Azure ファイル共有をマウントすることはできません。 この制限は、クライアントが起動時にKerberosチケットを早期に取得できず、マウントできないために存在します。
fstab エントリを使用し、noauto オプションを指定して、すべてのパラメーターを指定せずに単純な mount コマンドを使用して、サインイン後にユーザーがファイル共有をマウントできるようにします。
autofs を使用して、アクセス時に共有をマウントすることもできます。
前提条件
LinuxクライアントをAzureファイル共有のためにSMB経由でオンプレミスのAD DS認証を設定する前に、以下の前提条件を満たしてください。
- Ubuntu 18.04 以降を実行している Linux VM、または同等の RHEL か SLES VM。 VMはオンプレミスのAD DSドメインコントローラーとネットワーク接続があり、AD DSドメインを解決できるDNSサーバーを使用している必要があります。
- オンプレミスのAD DS環境は、Microsoft Entra Connect Syncを使用してMicrosoft Entra IDと同期しています。
- オンプレミスのAD DS認証用に設定されたストレージアカウント内のSMB Azureファイル共有。
- 完全な sudo 権限を持つローカル ユーザー アカウントへのルート ユーザーまたはユーザー資格情報 (このガイドでは localadmin)。
- LinuxのVMはすでに別のAD DSドメインに加入していません。 もしそうなら、そのドメインを離れてからVMをこのドメインに移してください。
- ドメインにコンピュータを接続する権限を持つAD DSドメインユーザーアカウント。
samba パッケージのインストールは、厳密には必要ありませんが、便利なツールが複数用意されており、samba-common や smbclient などの他のパッケージが自動的に取り込まれます。 次のコマンドを実行してこれをインストールします。 インストール中に入力値を求められた場合は、空白のままにします。
sudo apt update -y
sudo apt install samba winbind libpam-winbind libnss-winbind krb5-config krb5-user keyutils cifs-utils
wbinfo ツールは samba スイートの一部であり、ドメイン コントローラーに到達可能かどうかの確認、マシンが参加しているドメインの確認、ユーザーに関する情報の検索など、認証とデバッグの目的で役立ちます。
LinuxホストがADのDSドメインコントローラーと時刻を同期させていることを確認してください。 Linuxディストリビューションのドキュメントをご覧ください。 一部のディストリビューションでは 、systemd-timesyncdを使ってこれを行うことができます。 以下の構成を含めるように編集 /etc/systemd/timesyncd.conf 。
ntp.serverをAD DS環境で使用しているのと同じネットワークタイムプロトコル(NTP)サーバーホスト名またはIPアドレスに置き換えてください。
[Time]
NTP=ntp.server
FallbackNTP=ntp.ubuntu.com
その後、サービスを再起動します。
sudo systemctl restart systemd-timesyncd.service
AD DS Kerberos認証を有効にする
オンプレミスのAD DSでKerberos認証を有効にするには、以下の手順に従ってください。 Sambaの設定についての詳細は、「 Setting up Samba as a Domain Member」をご覧ください。
AD DSドメインコントローラーが到達可能で発見可能であることを確認してください
設定されたDNSサーバーがあなたのAD、DSドメイン、ドメインコントローラーを解決できることを確認してください。
systemd-resolve --statusGlobal DNSSEC NTA: 10.in-addr.arpa 16.172.in-addr.arpa 168.192.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa corp d.f.ip6.arpa home internal intranet lan local private test Link 2 (eth0) Current Scopes: DNS LLMNR setting: yes MulticastDNS setting: no DNSSEC setting: no DNSSEC supported: no DNS Servers: 10.0.2.5 10.0.2.4 10.0.0.41 DNS Domain: domain1.contoso.comDNSサーバーにドメインコントローラーのIPアドレスが含まれている場合は、 ホスト名とFQDN(FQDN)の設定に進みます。 コマンドが期待された出力を出さない場合は、「 AD DSドメインコントローラーの検出トラブルシューティング」を参照してください。
AD DSドメインコントローラーの検出トラブルシューティング
AD DSドメインコントローラーのIPアドレスにpingが通れることを確認してください。
ping 10.0.2.5PING 10.0.2.5 (10.0.2.5) 56(84) bytes of data. 64 bytes from 10.0.2.5: icmp_seq=1 ttl=128 time=0.898 ms 64 bytes from 10.0.2.5: icmp_seq=2 ttl=128 time=0.946 ms ^C --- 10.0.2.5 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1002ms rtt min/avg/max/mdev = 0.898/0.922/0.946/0.024 mspingが機能しない場合は、 前提条件を確認し、VMがAD DSドメインコントローラーとネットワーク接続されているか確認してください。
IP アドレスが ping に応答しても DNS サーバーが自動的に検出されない場合は、DNS サーバーを手動で追加できます。 お気に入りのテキスト エディターを使用して
/etc/netplan/50-cloud-init.yamlを編集します。# This file is generated from information provided by the datasource. Changes # to it will not persist across an instance reboot. To disable cloud-init's # network configuration capabilities, write a file # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following: # network: {config: disabled} network: ethernets: eth0: dhcp4: true dhcp4-overrides: route-metric: 100 dhcp6: false match: macaddress: 00:22:48:03:6b:c5 set-name: eth0 nameservers: addresses: [10.0.2.5, 10.0.2.4] version: 2続いて変更を適用します。
sudo netplan --debug applyWinbind では、DHCP サーバーによりドメイン DNS レコードが最新の状態に保たれていると想定しています。 ただし、この前提は、Azure DHCP では当てはまりません。 DDNS 更新を行うクライアントを設定するには、 このガイド を使用してネットワーク スクリプトを作成します。
/etc/dhcp/dhclient-exit-hooks.d/ddns-updateにあるサンプル スクリプトを次に示します。#!/bin/sh # only execute on the primary nic if [ "$interface" != "eth0" ] then return fi # When you have a new IP, perform nsupdate if [ "$reason" = BOUND ] || [ "$reason" = RENEW ] || [ "$reason" = REBIND ] || [ "$reason" = REBOOT ] then host=`hostname -f` nsupdatecmds=/var/tmp/nsupdatecmds echo "update delete $host a" > $nsupdatecmds echo "update add $host 3600 a $new_ip_address" >> $nsupdatecmds echo "send" >> $nsupdatecmds nsupdate $nsupdatecmds fi
問題を解決したら、 ホスト名と完全限定ドメイン名の設定を進めます。
ホスト名と完全修飾ドメイン名 (FQDN) を設定する
テキスト エディターを使用して、最終的な FQDN (ドメインに参加後) とホストのエイリアスで /etc/hosts ファイルを更新します。 この行は主に短いホスト名を FQDN に変換するために使用されるため、現時点では IP アドレスは関係ありません。 詳細については、「 Samba をドメイン メンバーとして設定する」を参照してください。
127.0.0.1 contosovm.contosodomain.contoso.com contosovm
#cmd=sudo vim /etc/hosts
#then enter this value instead of localhost "ubuntuvm.contosodomain.contoso.com UbuntuVM"
次に、次の3つのコマンドを実行してホスト名が正しく解決されているか確認してください。
getent hostsを使用して、短縮ホスト名が FQDN に解決されることを確認します。 返されたIPアドレスは無視しても構いません。
getent hosts contosovm
127.0.0.1 contosovm.contosodomain.contoso.com contosovm
ドメイン名が正しく設定されているか dnsdomainname を使ってください。
dnsdomainname
contosodomain.contoso.com
hostname -fを使ってFQDN全体の解決を確認しましょう。
hostname -f
contosovm.contosodomain.contoso.com
注
一部のLinuxディストリビューションでは、hostnamectlを更新するためにhostname -fコマンドを実行する必要があります:
hostnamectl set-hostname contosovm.contosodomain.contoso.com
krb5.conf を設定する
AD DSドメインコントローラー上のKerberos鍵配布センター(KDC)に認証のために連絡できるように /etc/krb5.conf 設定してください。 詳細については、MIT Kerberos ドキュメントに関するページを参照してください。 次にサンプル /etc/krb5.conf ファイルを示します。
[libdefaults]
default_realm = CONTOSODOMAIN.CONTOSO.COM
dns_lookup_realm = false
dns_lookup_kdc = true
smb.conf を設定する
smb.conf へのパスを特定します。
sudo smbd -b | grep "CONFIGFILE"
CONFIGFILE: /etc/samba/smb.conf
SMBの設定をAD DSドメインメンバーとして機能するように変更してください。 以下の例は rid idmapバックエンドを使用しています。
idmap バックエンドの選択を確認し、AD DS 環境の要件を満たすバックエンドを選択してください。
[global]
workgroup = CONTOSODOMAIN
security = ADS
realm = CONTOSODOMAIN.CONTOSO.COM
winbind refresh tickets = Yes
vfs objects = acl_xattr
map acl inherit = Yes
store dos attributes = Yes
dedicated keytab file = /etc/krb5.keytab
kerberos method = secrets and keytab
winbind use default domain = Yes
load printers = No
printing = bsd
printcap name = /dev/null
disable spoolss = Yes
log file = /var/log/samba/log.%m
log level = 1
idmap config * : backend = tdb
idmap config * : range = 3000-7999
idmap config CONTOSODOMAIN : backend = rid
idmap config CONTOSODOMAIN : range = 10000-999999
template shell = /bin/bash
template homedir = /home/%U
変更された構成ファイルを強制的に winbind で再読み込みします。
sudo smbcontrol all reload-config
AD DSドメインに参加
net ads join コマンドを使用して、ホストをドメインに参加させます。 コマンドからエラーが返された場合は、 問題を解決するための samba ドメイン メンバーのトラブルシューティング を参照してください。
sudo net ads join -U contososmbadmin
Enter contososmbadmin's password:
Using short domain name -- CONTOSODOMAIN
Joined 'CONTOSOVM' to dns domain 'contosodomain.contoso.com'
このホストのDNSレコードがAD DS DNSに存在していることを確認してください。
nslookup contosovm.contosodomain.contoso.com 10.0.2.5
Server: 10.0.2.5
Address: 10.0.2.5#53
Name: contosovm.contosodomain.contoso.com
Address: 10.0.0.8
nsswitch.conf を設定する
ユーザーがクライアント コンピューターにアクティブにサインインし、Azureファイル共有にアクセスすることを計画している場合は、nsswitch.conf を設定する必要があります。 計画アクセスが、ファイル共有にアクセスするために Kerberos 認証を必要とするユーザー アカウントまたはコンピューター アカウントによって表されるアプリケーションに限定されている場合は、この手順をスキップできます。
ホストをドメインに参加したら、winbind ライブラリをユーザーとグループの参照パスに追加します。 テキスト エディターを使用して、/etc/nsswitch.conf を編集し、次のエントリを追加します。
passwd: compat systemd winbind
group: compat systemd winbind
再起動時に winbind サービスが自動的に開始できるようにします。
sudo systemctl enable winbind
Synchronizing state of winbind.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install enable winbind
サービスを再起動します。
sudo systemctl restart winbind
sudo systemctl status winbind
winbind.service - Samba Winbind Daemon
Loaded: loaded (/lib/systemd/system/winbind.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2020-04-24 09:34:31 UTC; 10s ago
Docs: man:winbindd(8)
man:samba(7)
man:smb.conf(5)
Main PID: 27349 (winbindd)
Status: "winbindd: ready to serve connections..."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/winbind.service
├─27349 /usr/sbin/winbindd --foreground --no-process-group
└─27351 /usr/sbin/winbindd --foreground --no-process-group
Apr 24 09:34:31 contosovm systemd[1]: Starting Samba Winbind Daemon...
Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.724211, 0] ../source3/winbindd/winbindd_cache.c:3170(initialize_winbindd_cache)
Apr 24 09:34:31 contosovm winbindd[27349]: initialize_winbindd_cache: clearing cache and re-creating with version number 2
Apr 24 09:34:31 contosovm winbindd[27349]: [2020/04/24 09:34:31.725486, 0] ../lib/util/become_daemon.c:124(daemon_ready)
Apr 24 09:34:31 contosovm systemd[1]: Started Samba Winbind Daemon.
Apr 24 09:34:31 contosovm winbindd[27349]: STATUS=daemon 'winbindd' finished starting up and ready to serve connections
ドメイン ユーザーとグループが検出されていることを確認します。
getent passwd contososmbadmin
contososmbadmin:*:12604:10513::/home/contososmbadmin:/bin/bash
getent group 'domain users'
domain users:x:10513:
上記の手順がうまくいかない場合は、 wbinfo ツールを使ってAD DSドメインコントローラーに到達可能かどうかを確認してください。
wbinfo --ping-dc
winbind 用に PAM を構成する
ユーザーがクライアント コンピューターにアクティブにサインインし、Azureファイル共有にアクセスすることを計画している場合は、winbind 用に PAM を構成する必要があります。 計画アクセスが、ファイル共有にアクセスするために Kerberos 認証を必要とするユーザー アカウントまたはコンピューター アカウントによって表されるアプリケーションに限定されている場合は、この手順をスキップできます。
winbind の PAM (プラグ可能な認証モジュール) を構成して、ドメイン ユーザーが winbind を使用して認証されるように、winbind を認証スタックに配置します。 2 番目のコマンドは、最初のログイン時に、システムがドメイン ユーザーのホーム ディレクトリを作成することを保証します。
sudo pam-auth-update --enable winbind
sudo pam-auth-update --enable mkhomedir
pam_winbind.so の PAM 認証設定に、正しい /etc/pam.d/common-auth 引数が設定されていることを確認します:
grep pam_winbind.so /etc/pam.d/common-auth
auth [success=1 default=ignore] pam_winbind.so krb5_auth krb5_ccache_type=FILE cached_login try_first_pass
コマンドが出力を返さない場合は、winbindがPAM認証スタックに追加されているか確認するために sudo pam-auth-update --enable winbind を再実行します。
ssh、su、またはその他の認証方法を使用して、ドメイン ユーザーとしてこのシステムにサインインできるようになりました。
su - contososmbadmin
Password:
Creating directory '/home/contososmbadmin'.
contososmbadmin@contosovm:~$ pwd
/home/contososmbadmin
contososmbadmin@contosovm:~$ id
uid=12604(contososmbadmin) gid=10513(domain users) groups=10513(domain users),10520(group policy creator owners),10572(denied rodc password replication group),11102(dnsadmins),11104(aad dc administrators),11164(group-readwrite),11165(fileshareallaccess),12604(contososmbadmin)
LinuxでAD DS認証を確認する
クライアントマシンがAD DSドメインに加入しているかを確認するには、AD DS DNS サーバーを使ってクライアントのFQDNを調べ、クライアントのDNSエントリが存在するか確認してください。 多くの場合、 <dnsserver> はクライアントが参加しているAD DSドメイン名と同じです。
nslookup <clientname> <dnsserver>
次に、Kerberosキャッシュ内のチケットを見るために klist を実行してください:
klist
出力には、次のような形の krbtgt で始まるエントリを含めるべきです。
krbtgt/CONTOSODOMAIN.CONTOSO.COM@CONTOSODOMAIN.CONTOSO.COM
winbind 用に PAM を構成しなかった場合は、klist でチケット エントリが表示されない可能性があります。 この場合は、手動でユーザーを認証してチケットを取得できます。
wbinfo -K contososmbadmin
スクリプトの一部としてコマンドを実行することもできます。
wbinfo -K 'contososmbadmin%SUPERSECRETPASSWORD'
ファイル共有のマウント
Kerberos 認証を有効にし、Linux VM にドメイン参加したら、ファイル共有をマウントできます。
Kerberos セキュリティを有効にするには、すべてのアクセス制御モデルで次のマウント オプションを使用します: sec=krb5。
sec=krb5を使用する場合は、ユーザー名とパスワードを省略します。 例えば次が挙げられます。
sudo mount -t cifs $SMB_PATH $MNT_PATH -o sec=krb5,cruid=$UID,serverino,nosharesock,actimeo=30,mfsymlinks
注
この機能は、モード ビットのない NT ACL を使用するサーバーによって強制されるアクセス制御モデルのみをサポートします。 NT ACL を更新する Linux ツールは最小限であるため、Windowsを介して ACL を更新します。 クライアントによって適用されるアクセス制御 (modefromsid,idsfromsid) モデルとクライアント変換アクセス制御 (cifsacl) モデルは現在サポートされていません。
Linux向けの追加Azure Files SMBマウントオプション
シングルユーザー マウントとマルチユーザー マウント
シングルユーザーマウントのケースでは、AD DSドメイン内の単一のユーザーがマウントポイントにアクセスし、ドメイン内の他のユーザーと共有しません。 各ファイル アクセスは、krb5 資格情報を使用してファイル共有をマウントするユーザーのコンテキストで行われます。 マウント ポイントにアクセスするローカル システム上のユーザーは、そのユーザーを偽装します。
マルチユーザーマウントのケースでは、単一のマウントポイントは存在しますが、複数のAD DSユーザーが同じマウントポイントにアクセスできます。 同じクライアント上の複数のユーザーが同じ共有にアクセスし、システムが Kerberos 用に構成され、 sec=krb5でマウントされるシナリオでは、 multiuser マウント オプションの使用を検討してください。
ファイルのアクセス許可
特に、Linux クライアントと Windows クライアントの両方がファイル共有にアクセスする場合は、ファイルのアクセス許可が重要です。 ファイルのアクセス許可をファイルの DACL に変換するには、file_mode=<>,dir_mode=<> などの既定のマウント オプションを使用します。 クライアントは、 file_modeおよびdir_mode として指定されたファイルのアクセス許可のみを適用 します。 サーバーは、ファイルまたはディレクトリのセキュリティ記述子に基づいてアクセス制御を適用します。
ファイル所有権
特に、Linux クライアントと Windows クライアントの両方がファイル共有にアクセスする場合は、ファイルの所有権が重要です。 次のいずれかのマウント オプションを選択して、ファイルの所有権 UID/GID をファイル DACL の所有者/グループ SID に変換します。
- uid=<>,gid=<> などの既定値を使用する
- RFC2307およびAD DSを通じたUID/GIDマッピングは、 nss_winbind または nss_sssdを使って設定できます。
ファイル属性キャッシュの一貫性
ファイル属性が常に正確であるとは限らない場合でも、パフォーマンスは重要です。 actimeo の既定値は 1 (秒) です。つまり、キャッシュされた属性が 1 秒を超えて存続する場合は、ファイル属性がサーバーから再度フェッチされます。 値を 60 に増やすと、属性は少なくとも 1 分間キャッシュされます。 ほとんどのユース ケースでは、このオプションには 30 の値を使用します (actimeo=30)。
新しいカーネルの場合は、actimeo 機能をより細かく設定することを検討してください。 ディレクトリ エントリの再検証キャッシュには acdirmax を、ファイル メタデータのキャッシュには acregmax を使用できます (たとえば、acdirmax=60,acregmax=5)。
次のステップ
Linux で SMB ファイル共有をマウントする方法については、次を参照してください。
Linux