MAC 登録した Mac が Wi-Fi に繋がらない。それでも 802.1X は見送った

「MAC アドレスを登録したのに、Wi-Fi に繋がらない」。新しい Mac で、これが続いた。担当者からは「MAC 以外の方法にできないか」と聞かれ、自分は教科書どおりに「端末に証明書を配って 802.1X にしましょう」と答えた。

結論から言うと、その案は見送った。繋がらない原因は Mac のプライベート Wi-Fi アドレス（MAC アドレスのランダム化）で、MDM の設定1つで止められる。困りごとが方式を替えずに消えるなら、方式ごと替える理由は大きく減る。ある会社（約90名）での話だ。

Wi-Fi の認証方式は「どれが正しいか」だけでは決まらない。端末を誰が管理していて、その端末がオフィスにどれだけ来るかで、割に合う方式が変わる。

▼きっかけ：MAC を登録したのに、新しい Mac だけ繋がらない

この会社のオフィスの Wi-Fi は、ヤマハの無線 AP（WLX202）が4台。Wi-Fi のパスワードに加えて、AP に MAC アドレスを登録した端末だけが繋がる設定（MAC アドレスフィルタリング）になっている。新しい端末が来たら、MAC を AP に登録して、全 AP に設定を送り、AP を1台ずつ再起動する。前任からこの作業を引き継いだ。

引き継いで2日後の定例で、担当者から相談が来た。MAC を登録した人から、直近で何度か「繋がらない」と言われている。確かめると、登録した MAC と、繋ぎに来ている MAC が違っていた。

起きていたのは、最近ゼロタッチ（箱から出して初回起動を進めるだけで MDM に登録される形）で JumpCloud に入れた Mac の3台だった。昔から使っている端末の1台は、OS を上げても普通に繋がっていた。この時点では、原因はわかっていない。

▼最初に出したのは、教科書どおりの「証明書を配って 802.1X」

「MAC 以外の方法にできないか」と聞かれて、自分が出したのは一般的な答えだった。MDM から各端末にデバイス証明書を配り、証明書を持っている端末だけがその SSID に繋がるようにする（802.1X の EAP-TLS という方式）。MAC を登録する手間も、MAC が変わる問題も、まとめて消える。

ただ、仕組みはこう変わる。

802.1X では、AP は認証の中身を見ない。外部の RADIUS サーバーに中継して、通すかどうかはそちらが決める。つまり証明書方式にすると、増える持ち物は「MDM の証明書の設定」と「RADIUS サーバー」の2つ。それに「MDM で証明書を配れない端末をどうするか」という宿題が付いてくる。

この時点で、導入ベンダーに2つ相談した。繋がらない事象の原因と直し方、そして証明書方式が今の契約で実現できるか、だ。今振り返ると、原因がわからないまま方式の答えに行っていた。

▼原因は Mac の MAC ランダム化だった

ベンダーの見立ては、macOS のプライベート Wi-Fi アドレスだった。Wi-Fi のネットワークごとに、本体とは別の MAC アドレスを使う機能だ。Mac では macOS 15（Sequoia）から入った。WPA2 以上のネットワークでは、本体とは別の「固定」のアドレスを使うのが既定になっている。

つまり、Wi-Fi から見ると Mac の MAC アドレスが変わる。本体の MAC を AP に登録しても、端末は別のアドレスで繋ぎに来る。登録が合わないので、弾かれる。

止め方もある。MDM で配る Wi-Fi の設定に「MAC のランダム化を無効にする」項目があり、JumpCloud の Wi-Fi ポリシーにもある。この会社のポリシーでは、この項目が設定されていなかった。つまり、ランダム化は止まっていなかった。この設定は、MDM で配った社内の SSID にだけ効く。自宅やカフェの Wi-Fi では、これまでどおりプライベートアドレスが使われる。

昔から使っている端末で起きなかった引き金は、まだ調べている。Apple の説明では、「固定」が既定になるのは新しく繋ぐネットワークだ。macOS 15 より前からこの Wi-Fi に繋いでいた端末で起きなかったのは、そのためかもしれない。

ここで、証明書方式を検討する理由の一つが消えた。「繋がらない」は、方式の問題ではなく端末の設定の問題だった。

▼方式を選ぶ前に、今の AP で何ができるかを見た

もう一つ、先に確かめたのが AP 側だ。方式を選ぶ前に、今の機器で何ができるかを見ておく。管理画面を開くと、4台のうち1台がコントローラー（親）、残り3台がメンバー（子）のクラスター構成だった。引き継ぎの時点では、コントローラーはルーター側だと思っていた。引き継いだ機器の構成は、名前や資料ではなく管理画面で確かめる方がいい。

判断に関わったのは、次の3つだ。ヤマハの資料と実機の画面で確かめた範囲で、設定して動かすところまではやっていない。

項目	WLX202 では	実務上の意味
外部の RADIUS	指定できる（WPA2 エンタープライズ）。EAP-TLS も通る	証明書方式にするなら、ここに外部の RADIUS（たとえば JumpCloud の Cloud RADIUS）をつなぐ。今の契約で使えるかはベンダーに確認中
内蔵の RADIUS	ある。ただし ID とパスワード（PEAP）だけで、証明書（EAP-TLS）は使えない。ユーザーは200件まで	名簿は AP の中にある。登録の場所と手間は、MAC の名簿と変わらない
API・リモート管理	API はない。ヤマハのクラウド管理（YNO）は後継の WLX212 から。管理は Web の画面	この会社の今のネットワークでは、社外から（VPN 経由でも）管理画面に届かない。MAC の登録は出社日にしかできない

「AP に RADIUS が入っているなら、それで 802.1X にできる」は半分だけ正しい。WLX202 の内蔵 RADIUS は PEAP だけで、ヤマハの資料では、端末側でサーバー証明書を確かめない設定で使う前提になっている。名簿も AP の中だから、外から登録できない問題はそのまま残る。証明書で認証するなら、外部の RADIUS を持つことになる。

なお、来客用のゲスト SSID は WLX202 でも作れる。SSID ごとに VLAN を分けられるが、社内 LAN から切り離すにはルーター側の設定も要る。これは急がないので、別の話として11月にテストで作る。

▼証明書の配布を見送った3つの理由

定例で、証明書方式は見送ると決めた。理由は3つある。1つ目は今回の困りごとの中身、2つ目と3つ目は会社の条件だ。証明書方式で元が取れるのは、全端末に証明書を配れて、社員が日常的にオフィスで Wi-Fi を使う会社で、この会社はどちらにも当てはまらなかった。

理由1：繋がらない原因は、方式を替えなくても消える

一番大きいのはこれだ。担当者が困っていたのは「登録したのに繋がらない」で、MAC 登録という方式そのものではなかった。その原因はランダム化で、MDM の設定1つで止められる。

方式を替えるのは、運用で直せないときだけでいい。順番は「原因を確かめる → 方式の問題か、運用・設定の問題かを分ける → 運用で直せないものだけ方式で解く」。今回、自分はこの1歩目を飛ばして方式の答えを出していた。

理由2：Windows は別の管理者の端末で、方式が2つに分かれる

このオフィスの Wi-Fi には、別の管理者が Intune で管理している Windows も繋がる。その管理者からは、こちらの都合で特定の端末だけに設定を配ることは断られている。こちらから Windows に証明書は配れない。

すると Windows は今の方式のまま残り、証明書にできるのは Mac だけになる。方式が2つに分かれると、MAC の名簿はなくならない。名簿の管理は続けたまま、証明書と RADIUS の管理が増える。一本化できないなら、移行の手間に対して減る手間が小さい。

理由3：Mac の利用者はオフィスに年に数回しか来ない。外部 RADIUS を1つ持つ手間に見合わない

この会社はリモート中心で、Mac を使う人がオフィスに来るのは年に数回だ。定例でも「工数に見合わない」で合意した。

証明書方式にすると、増えるのはこういう手間だ。

• ▶ 外部の RADIUS を用意して、AP の SSID とつなぐ（今の契約で使えるかの確認から）
• ▶ MDM で証明書の発行と配布を設定して、全 Mac に配る
• ▶ 別の管理者の Windows と、同じオフィスでぶつからないかを確かめる
• ▶ 入れた後も、RADIUS と証明書の更新を見続ける

一方、MAC 登録の手間は、新しい端末が来たときに、出社日に登録して4台の AP に送り、再起動する作業だ。端末1台につき1回で済む。Wi-Fi の認証にかける手間は、オフィスで Wi-Fi を使う回数に比例させる。たまにしか使わない Wi-Fi のために、RADIUS を1つ持ち続けるのは重い。

▼代わりに決めた運用：MAC はキッティングの前に登録する

MAC 登録で運用するには、端末の MAC アドレスが変わらないことが前提になる。そこで、JumpCloud の Wi-Fi ポリシーでプライベート Wi-Fi アドレス（ランダム化）をオフにし、本体の MAC で繋ぐ形に固定する。これを今後のキッティングの前提にした。

定例の後、使っていない Mac を1台借りて、初期化して、JumpCloud で使える状態に設定し直す（キッティング）、を何度か繰り返した。そのたびに、本体の Wi-Fi の MAC アドレスは変わらなかった。初期化しても変わらないなら、ABM に出る MAC を、端末が届く前に登録しておける。手順はこうした。

1. 端末を Apple Business Manager（ABM）に登録する。ABM のデバイス情報には Wi-Fi の MAC アドレスが出る（Mac は2025年12月から表示されるようになった）
2. その MAC を、キッティングの前に AP のコントローラーに登録する（オフィスの中で）
3. JumpCloud から SSID・パスワードと、ランダム化をオフにする設定を配る
4. 本人は初回起動を進めるだけで繋がる想定（通しの確認は次の端末で）

リース端末なら、リース会社から ABM に入れてもらえば、端末が手元に届く前に MAC がわかり、本人が開く前に登録しておける。「端末が届いてから出社して、MAC を調べて登録」が要らなくなる。ただし、ABM に手で追加した端末でも MAC が出るかは、Apple の資料には書かれていない。

▼MAC 登録で残るリスクと、見直す条件

先に言っておくと、MAC 登録は強い認証ではない。MAC アドレスは偽装できる。守りの本体は Wi-Fi のパスワードで、MAC の名簿は「パスワードを知っている人の、会社が把握していない端末を入れない」ための台帳だ。そこを誤解しないで使う。

残るものは、こう手当てする。

• ▶ 外から登録できない：登録は出社日に寄せる。リース端末は届く前に MAC を取って、出社日にまとめて登録する
• ▶ 名簿を整理して MAC を消した端末は、繋がらなくなる：名簿と端末台帳を突き合わせてから消す
• ▶ パスワードを知っている人の範囲：退職者の端末を名簿から外しているか、パスワードをいつ変えたかを次に確かめる。名簿が台帳として効くのは、そこが回っているときだけだ
• ▶ 来客・私物用の口がない：ゲスト SSID を分けて作る（11月にテスト。2.4GHz と 5GHz を実際に繋いで比べる）

見送ったのは「今は」だ。条件が変わったら決め直す。

こうなったら	次の手
Windows にも証明書を配れるようになった（管理がこちらに来る、または管理者側で配れる）	方式を一本化できる。証明書方式を検討し直す
Mac の利用者が日常的に出社するようになった	登録の手間が増える。同じく検討し直す
AP を更新する（WLX202 は2016年発売で、すでに生産完了）	後継機ならクラウド管理で外から触れる。認証方式もこのタイミングで決め直す

▼まとめ

• ▶ 「MAC を登録したのに繋がらない」は、まず Mac のプライベート Wi-Fi アドレスを疑う。macOS 15 から既定で効き、MDM で止められる
• ▶ 方式を替えるのは、原因を確かめて、運用や設定で直せないとわかってから
• ▶ 証明書方式は、全端末に証明書を配れて、社員が日常的にオフィスで Wi-Fi を使う会社で元が取れる。管理者が分かれ、出社が年に数回なら、MAC 登録を運用で回す方が割に合う
• ▶ WLX202 は外部 RADIUS なら EAP-TLS を通せるが、内蔵 RADIUS は PEAP だけ。API もクラウド管理もない
• ▶ MAC 登録はキッティングの前に。ABM で MAC を先に取れば、本人が開く前に繋がる状態にできる（通しの確認は次の端末で）