Azure Files にアクセスする Linux クライアントに対して SMB 経由で Azure Active Directory 認証を有効にする

[アーティクル]
04/25/2023

サポートされているオプションと考慮事項の詳細については、「SMB アクセスの Azure Files ID ベース認証オプションの概要」を参照してください。

Azure Files では、次の方法で Kerberos 認証プロトコルを使用することで、Linux 仮想マシン (VM) に対するサーバーメッセージブロック (SMB) 経由の ID ベース認証がサポートされています。

オンプレミス Windows Active Directory Domain Services (AD DS)
Microsoft Entra Domain Services

1 つ目のオプション (AD DS) を使うには、Microsoft Entra Connect を使って、AD DS を Microsoft Entra ID に同期する必要があります。

Note

この記事では、手順の例として Ubuntu を使用します。 RHEL マシンと SLES マシンでも同様の構成が機能するため、Active Directory を使用して Azure ファイル共有をマウントできます。

適用対象

ファイル共有の種類	SMB	NFS
Standard ファイル共有 (GPv2)、LRS/ZRS
Standard ファイル共有 (GPv2)、GRS/GZRS
Premium ファイル共有 (FileStorage)、LRS/ZRS

Linux SMB クライアントの制限事項

ID ベースの認証を使用して、起動時に fstab エントリを使用して Linux クライアントに Azure ファイル共有をマウントすることはできません。これは、クライアントが、起動時にマウントできるだけ十分早くに Kerberos チケットを取得できないためです。ただし、fstab エントリを使用して noauto オプションを指定できます。これにより起動時に共有がマウントされることはありませんが、ユーザーは、すべてのパラメーターを指定することなく単純なマウントコマンドを使用してログインした後に、ファイル共有を簡単にマウントできます。 autofs を使用して、アクセス時に共有をマウントすることもできます。

前提条件

Azure ファイル共有に対する SMB 経由の AD 認証を有効にする前に、次の前提条件を完了していることを確認します。

Azure で実行している Linux VM (Ubuntu 18.04 以降か、同等の RHEL または SLES VM)。 VM には、Microsoft Entra Domain Services を含む VNET 上少なくとも 1 つのネットワークインターフェイス、または AD DS が Microsoft Entra ID と同期されているオンプレミスの Linux VM が必要です。
完全な sudo 権限を持つローカルユーザーアカウントへのルートユーザーまたはユーザー資格情報 (このガイドでは localadmin)。
Linux VM が AD ドメインに参加していない必要があります。既にドメインの一部である場合は、このドメインに参加する前に、まずそのドメインから離れる必要があります。
ドメインユーザーが既に設定されている、完全に構成されている Microsoft Entra テナント。

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 ホストがドメインサーバーと時刻を同期し続けていることを確認します。 Linux ディストリビューションのドキュメントを参照してください。一部のディストリビューションでは、systemd-timesyncd を使用してこれを行うことができます。次を含むように、普段使用しているテキストエディターで /etc/systemd/timesyncd.conf を編集します。

[Time]
NTP=onpremaadint.com
FallbackNTP=ntp.ubuntu.com

その後、サービスを再起動します。

sudo systemctl restart systemd-timesyncd.service

AD Kerberos 認証を有効にする

AD Kerberos 認証を有効にするには、次の手順に従います。この Samba ドキュメントは、リファレンスとして役立つ場合があります。

ドメインサーバーが到達可能で検出可能であることを確認する

指定された DNS サーバーにドメインサーバーの IP アドレスが含まれていることを確認します。

systemd-resolve --status

Global 
          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.com

このコマンドでうまくいった場合は、以下の手順をスキップして、次のセクションに進みます。
うまくいかなかった場合は、ドメインサーバーの IP アドレスが ping を実行していることを確認します。

ping 10.0.2.5

PING 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 ms

ping が機能しない場合は、前提条件に戻って、VM が Microsoft Entra テナントにアクセスできる VNET 上にあることを確認します。
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 apply

Winbind では、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

Microsoft Entra Domain Services に接続し、サービスが検出可能であることを確認する

ドメイン名でドメインサーバーに ping を実行できることを確認します。

ping contosodomain.contoso.com

PING contosodomain.contoso.com (10.0.2.4) 56(84) bytes of data.
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=1 ttl=128 time=1.41 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=2 ttl=128 time=1.02 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=3 ttl=128 time=0.740 ms
64 bytes from pwe-oqarc11l568.internal.cloudapp.net (10.0.2.4): icmp_seq=4 ttl=128 time=0.925 ms 

^C 

--- contosodomain.contoso.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3016ms
rtt min/avg/max/mdev = 0.740/1.026/1.419/0.248 ms

ネットワーク上の Microsoft Entra サービスを検出できることを確認します。

nslookup
> set type=SRV
> _ldap._tcp.contosodomain.contoso.com.

Server:         127.0.0.53
Address:        127.0.0.53#53

Non-authoritative answer: 

_ldap._tcp.contosodomain.contoso.com service = 0 100 389 pwe-oqarc11l568.contosodomain.contoso.com.
_ldap._tcp.contosodomain.contoso.com service = 0 100 389 hxt4yo--jb9q529.contosodomain.contoso.com.

ホスト名と完全修飾ドメイン名 (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 "ubuntvm.contosodomain.contoso.com UbuntuVM"

次にホスト名を解決する必要があります。現時点では、解決後の IP アドレスは無視できます。短いホスト名は FQDN に解決する必要があります。

getent hosts contosovm

127.0.0.1       contosovm.contosodomain.contoso.com contosovm

dnsdomainname

contosodomain.contoso.com

hostname -f

contosovm.contosodomain.contoso.com

注意

一部のディストリビューションでは、hostname -f を更新するために hostnamectl コマンドを実行する必要があります。

hostnamectl set-hostname contosovm.contosodomain.contoso.com

krb5.conf を設定する

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 構成を変更します。詳細については、ドメインメンバーとしての Samba の設定に関するページを参照してください。次にサンプル smb.conf ファイルを示します。

Note

この例は Microsoft Entra Domain Services の場合であり、idmap の構成時に backend = rid を設定することをお勧めします。オンプレミスの AD DS ユーザーは、別の idmap バックエンドを選択することもできます。

[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

ドメインに参加する

net ads join コマンドを使って、ホストを Microsoft Entra Domain Services ドメインに参加させます。コマンドでエラーがスローされる場合は、samba ドメインメンバーのトラブルシューティングに関するページを参照して問題を解決してください。

sudo net ads join -U contososmbadmin    # user  - garead

Enter contososmbadmin's password:

Using short domain name -- CONTOSODOMAIN
Joined 'CONTOSOVM' to dns domain 'contosodomain.contoso.com'

ドメインサーバー上にこのホストの 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

ユーザーがクライアントコンピューターまたは VM に積極的にログインし、Azure ファイル共有にアクセスする場合は、nsswitch.conf を設定し、winbind 用に PAM を構成する必要があります。ファイル共有にアクセスするために Kerberos 認証が必要なユーザーアカウントまたはコンピューターアカウントで表されるアプリケーションにアクセスが制限される場合は、これらの手順をスキップできます。

nsswitch.conf を設定する

ホストがドメインに参加したので、ユーザーとグループの検索時に検索する場所に winbind ライブラリを配置する必要があります。これを行うには、nsswitch.conf の passwd エントリと group エントリを更新します。テキストエディターを使用して、/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 ツールを使用してドメインコントローラーに到達できるかどうかを調べます。

wbinfo --ping-dc

winbind 用に PAM を構成する

winbind 用の PAM (プラグ可能な認証モジュール) を構成することで、ドメインユーザーが winbind を使用して認証されるように、winbind を認証スタックに配置する必要があります。 2 番目のコマンドにより、このシステムに最初にログインしたときに、ドメインユーザーに対して homedir が確実に作成されます。

sudo pam-auth-update --enable winbind
sudo pam-auth-update --enable mkhomedir

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

これで、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)

構成の確認

クライアントコンピューターがドメインに参加していることを確認するには、ドメインコントローラーでクライアントの FQDN を検索し、この特定のクライアントの一覧にある DNS エントリを見つけます。多くの場合、<dnsserver> は、クライアントが参加しているドメイン名と同じです。

nslookup <clientname> <dnsserver>

次に、klist コマンドを使用して、Kerberos キャッシュ内のチケットを表示します。次のように見える krbtgt で始まるエントリが表示されています。

krbtgt/CONTOSODOMAIN.CONTOSO.COM@CONTOSODOMAIN.CONTOSO.COM

winbind 用に PAM を構成しなかった場合は、klist でチケットエントリが表示されない可能性があります。この場合は、手動でユーザーを認証してチケットを取得できます。

wbinfo -K contososmbadmin

スクリプトの一部としてコマンドを実行することもできます。

wbinfo -K 'contososmbadmin%SUPERSECRETPASSWORD'

AD (または Microsoft Entra ID) Kerberos 認証を有効にし、Linux VM のドメインに参加した後に、ファイル共有をマウントできます。

マウント手順の詳細については、「Azure ファイル共有を mount を使用してオンデマンドでマウントする」を参照してください。

Kerberos セキュリティを有効にするには、すべてのアクセス制御モデルで次の追加マウントオプションを使用します: sec=krb5

注意

この機能では、モードビットなしで NT ACL を使用する、サーバーによって適用されるアクセス制御モデルのみがサポートされます。 NT ACL を更新する Linux ツールは最小限であるため、Windows 経由で ACL を更新します。クライアントによって適用されるアクセス制御 (modefromsid,idsfromsid) モデルとクライアント変換アクセス制御 (cifsacl) モデルは現在サポートされていません。

その他のマウントオプション

シングルユーザーマウントとマルチユーザーマウント

シングルユーザーのマウントユースケースでは、マウントポイントには AD ドメインの単一のユーザーがアクセスし、ドメインの他のユーザーとは共有されません。各ファイルアクセスは、ファイル共有のマウントに使用した krb5 資格情報を所有するユーザーのコンテキストで行われます。マウントポイントにアクセスするローカルシステム上のすべてのユーザーは、そのユーザーの権限を借用します。

マルチユーザーマウントユースケースでも単一のマウントポイントがありますが、複数の AD ユーザーがその同じマウントポイントにアクセスできます。同じクライアント上の複数のユーザーが同じ共有にアクセスし、システムが Kerberos 用に構成され、sec=krb5 でマウントされているシナリオでは、multiuser マウントオプションを使用することを検討してください。

ファイルのアクセス許可

特に、Linux クライアントと Windows クライアントの両方がファイル共有にアクセスする場合は、ファイルのアクセス許可が重要です。ファイルのアクセス許可をファイルの DACL に変換するには、file_mode=<>,dir_mode=<> などの既定のマウントオプションを使用します。 file_mode および dir_mode として指定されたファイルのアクセス許可は、クライアント内でのみ適用されます。サーバーは、ファイルまたはディレクトリのセキュリティ記述子に基づいてアクセス制御を適用します。

ファイル所有権

特に、Linux クライアントと Windows クライアントの両方がファイル共有にアクセスする場合は、ファイル所有権が重要です。次のいずれかのマウントオプションを選択して、ファイルの所有権 UID/GID をファイル DACL の所有者/グループ SID に変換します。

uid=<>,gid=<> などの既定値を使用する
RFC2307 と Active Directory (nss_winbind または nss_sssd) を使用して UID/GID マッピングを構成する

ファイル属性キャッシュの一貫性

ファイル属性が常に正確であるとは限らない場合でも、パフォーマンスは重要です。 actimeo の既定値は 1 (秒) です。つまり、キャッシュされた属性が 1 秒を超えて存続する場合は、ファイル属性がサーバーから再度フェッチされます。値を 60 に増やすと、属性は少なくとも 1 分間キャッシュされます。ほとんどのユースケースでは、このオプションに 30 の値を使用すること (actimeo=30) をお勧めします。

新しいカーネルの場合は、actimeo 機能をより細かく設定することを検討してください。ディレクトリエントリの再検証キャッシュには acdirmax を、ファイルメタデータのキャッシュには acregmax を使用できます (たとえば、acdirmax=60,acregmax=5)。

次のステップ

Linux で SMB ファイル共有をマウントする方法の詳細については、次を参照してください。

SMB Azure ファイル共有を Linux でマウントする