Mac が参加するADのドメイン名で .local を使わないでください。


.local ドメインを使用しないでください

 


※こちらのページは Windows Server の Active Directory で Mac, iPhone, iPadにもポリシーを適用して一元連携管理する
Apple対応AD 連携 改修サービス」のFAQページです。

しかし、こちらに記載している情報は一般のネットワークにも適用されます。
サービスにご興味有りましたら最後のほうに広告がございます。

    目次

  1. .local 問題
  2. Mac トラブル症状の例
  3. 対処方法(暫定的)
  4. マイクロソフト社製品間で発生する問題
  5. 米国マイクロソフト社 Active Directory ネットワーク推奨設計指針ドキュメント
  6. Active Directory 構築 – 正式ドメイン+サブドメイン の メリット
  7. サブドメイン名を考える
  8. 正式にローカルで使用できるドメイン名
    ※追記 永久補欠ドメイン

1.  .local 問題

Apple 製品(Mac, iPhone, iPad, AppleTV)が参加するネットワーク上の Active Directory ローカルドメイン名として末尾に .local が使用されていると動作が不安定になる場合があります。
また、Microsoft 社製品でも問題が発生するため、.local の使用を廃止することを推奨しています。
さらに言えば、将来の Windows でも同様な症状が発生する可能性があります。
そうならない為の解決方法は、最初からMicrosoft 社の Active Directory ネットワーク推奨設計指針(後述)の通りに構築する事が重要です。
日本国内では Microsoft社の推奨設計指針を完全に無視して .local で終わるドメインが多く構築されているのが、とても残念な事です。

ダメな例: corp.local

mac 管理者が消えたりします。これはApple製品(Mac,iPhone,iPad)は Bonjour サービスによって、IP ネットワーク上のコンピュータ、デバイス、およびサービスを自動検出してるためです。

MacとWindowsを共有している場合など注意してください。

2013年に発行されたインターネット標準規格 (RFC 6762)としてはmDNS(マルチキャストドメインネームサービス【multicast domain name service】)と呼ばれるものになりますが、mDNSでは .local を使用しているために、コンフリクトが発生する場合があります。

現在では、Linux,BSD系でも”avahi“としてmDNSは搭載されています。

.local ドメインを使用するとインターネット標準規格を使用している機器類が想定外の所にアクセスするのでセキュリティ的にも問題が発生します。

Windows Server, Active Directory 書籍、インターネットの情報などでは .local での構築例が多用されている場合がありますが、Microsoft社の推奨ではありません。企業が所有しているドメイン名を使用して、社内ドメインはサブドメインで構築するのが推奨(後述)です。

あるいは、社内インフラ用に新規に短いドメインを取得しても良いと思います。

重要なのは、正式に取得したドメイン名を使用することです!!

(例: corp.picturecode.co.jp)

Microsoft社から出ている資料では

OS X 10.3 以上搭載の Macintosh コンピュータがネットワーク上にある場合は、内部ドメインに .local 以外の AD DS 名拡張子を指定する必要があります。OS X 10.3 以上搭載の Macintosh コンピュータの Rendezvous サービスでは、.local を使用してネットワーク上の他のコンピュータが検索されます。

とも明記されています。

サーバーと内部ドメインに名前をつける必要がある理由 (リンク:Microsoft TechNet)

つまりMacをADに接続するしないに関わらず、社内ネットワーク上に Mac を設置する可能性があるならば、Windows Server の設定で .local で終わるドメインを使用すると動作に問題が出る恐れがあります。

 

とても重要なことなので強調して記載します。

Mac (Linux,BSDも)を設置する場合は .local で終わる
ディレクトリサービスを避けてください

DNS問い合わせがコンフリクトする可能性があるので、様々な不可思議な状態が発生する可能性があります。
しかもDNSの”問い合わせタイミング”も影響するので、再現性があるとは限りません。

通常であれば Mac からは DNS Serer への問い合わせが優先されますが、ADが動作しているWindows Server (通常はDNS Serverも設定されています)の処理がたまたま重なった時など、SOAレコード問い合わせへの返答が遅延すると .local ホストの場合は mDNSの問い合わせに切り替わります。つまりDNSの問い合わせが正しく帰ってきたり、帰ってこなかったり、別のマシンを刺したりします。この場合余りにも多大な影響がありすぎて、どんなことが実際の現象として発生するのかは全くわかりませんが、とても嫌な挙動になるのだけは確実です。どこにアクセスするのかが全く解らないので、セキュリティを重視する組織は特に注意しましょう。

2. Mac トラブル症状の例

※あくまでもこれは弊社での経験知識です、DNSの問題なので、ドメインに接続していないMacでも発生します。
ログイン・認証部分で、特に不可思議な問題が発生しがちです、例えば

  • 管理者アカウントが消える
  • 管理者権限がなくなる
  • ドメインに参加できない(バインドできない)
  • ログインできない(ログイン画面にユーザが表示されない)
  • Mac のログイン パスワードが通らない、エラーになる、入れない
  • Mac の接続が遅い

等です。しかし、実際にはDNSがあてにならないと、他にも何があるのかは全く予想できません。

3. 対処方法(暫定的)

macOS 等のバージョンアップに伴い、Apple側でDNS評価タイミングの調整を入れ、解釈の処理を入れたたこと、DNSサーバーの処理能力が向上したことにより以前に比べて症状が出ない確率が増えているのは事実ですが、根本的に解決されているわけではありません。根本的な解決は .local の使用を避けることです。

すでに、社内に .local ドメインの Active Directory が存在してMacの挙動が怪しすぎるという状況が発生している場合ですが、AD,DNSを動作させているWindows Server 搭載機のスペック(メモリ、CPU、SSD等)を上げ、とにかくDNS レコード問い合わせのレスポンスを向上し、タイムアウトが発生しないようにするのも一つの方法かもしれません。特に旧機材で運用している場合には検討する価値があると思います。ネットワーク機器のチェックも行いましょう。拠点間をVPNなどで接続している場合は、拠点にもDNSサーバーを設置することを考えましょう。

例えば、アップルから出ている文章ですが、

Mac OS X v10.4、10.5、10.6:「.local」ホスト名を Bonjour および標準 DNS を使って検索する方法 (リンク:Apple サポートページ)

この文章で注意するべき部分は

ご利用のネットワークの DNS サーバが適切に設定されている限り

という箇所です。
タイムアウトするDNSサーバーは、適切に設定されているとは見なされません。

他にも注意するべき文章です。

OS X Mountain Lion:Active Directory の「.local」ドメインにおけるモバイルユーザのログイン時間の改善 (リンク:Apple サポートページ)

※追記:本件について、Apple社からも正式に情報が掲載されました。

Apple 製のデバイスで社内ネットワークの ‘.local’ ドメインを開けない場合
社内ネットワークで問題が起きないように、所属組織に公に登録されている DNS 名を使ってください。(リンク:Apple サポートページ)

繰り返しますが、これらは.localドメインの場合の対処療法になります。根本的な解決方法は .local ドメインにしないと言うことです。世界標準規格のサービスで使用されている現代ではこのドメインで構築すると、セキュリティも含めて様々なリスクが発生します。

 

4. マイクロソフト社製品間で発生する問題

また、最近のマイクロソフト社製品でも .local を使用したドメインだと office 365 等のディレクトリ同期で問題が発生するため、対処方法としては

現時点で Active Directory のユーザー アカウント用に .local ドメインを使用している場合は、Office 365 ドメインと適切に同期するために、(billa@contoso.com などの) 確認済みドメインを使用するように .local ドメインを変更することを推奨します。

と、明快に記載されています。

ディレクトリ同期用に (.local ドメインなどの) 非ルーティング ドメインを準備する方法  (リンク:Microsoft サポートページ)

5. 米国マイクロソフト社 Active Directory ネットワーク推奨設計指針ドキュメント

マイクロソフト社は(英語圏では)AD登場の最初から 正式ドメイン名+サブドメイン形式でADを構築することを勧めています。

下記の米国マイクロソフトが発行している公式のWindowsネットワーク推奨設計指針の文章ですが、大変残念な事に日本語に翻訳されていないため、日本では全く認知されていないドキュメントになります、 Windows Server 2000 時代からの推奨設計指針ですが。これは現在でも変更されていません。つまり Active Directory の最初期から現在に至るまで一貫して、正式なDNS名+サブドメイン形式で作ることを実は推奨していたのです。

このような重要な文章が日本では全く広がらなかったのは非常に残念な事です。英語圏では当初からマイクロソフト社の推奨設計指針に沿った構築を行なっているので .local ドメインで構築されている所は大変に少ないのが現状です。
Windows Server 最初期からマイクロソフト社自身がベストなADネットワーク構築方法を提示していたので当然ですね。

Best Practice Active Directory Design for Managing Windows Networks  (リンク:米国Microsoft サポートページ)

重要な部分のみ翻訳しますが

フォレストルートドメインを設計するためには、ドメイン名を割り当てる必要があります。 Active Directoryドメインには、次の2種類の名前があります:

– Windows 2000クライアントが使用するドメインネームシステム(DNS)名。
– 以前のバージョンのWindowsを実行しているクライアントで使用されていたNetBIOS名。

フォレストルートドメイン名は、フォレストの名前でもあります。フォレストルートドメインに名前を付けるには:

  1. あなたの組織のDNS管理者を特定して、Active Directoryをホストするネットワーク上で利用可能な登録済みDNS名を決定します。このネットワークで使用できる名前は、あなたの会社がインターネット上で公開している名前とは異なる場合もあります。
    たとえば、組織がインターネット上で使用している名前はcontosopharma.com であるかもしれませんが、企業内ネットワークで使用される名前は contoso.com であるかもしれません。この場合、選択する名前は contoso.com です。登録されたドメイン名が無い場合には、インターネットDNS登録機関に名前を登録する必要があります。

    注意:
    ベストプラクティスとして、Active Directory 名前空間には、インターネット機関に登録されているDNS名を使用してください。登録された名前のみが全世界で唯一の物であることが保証されます。
    もしも、あなたの組織が(訳者注:例えば ad.local のような)同じ DNS 名を使用している他の企業と合併、買収された場合には、2つのインフラストラクチャは絶対にお互いを認めることができなくなります

    登録済みのDNS名に現在使用されていないプレフィックスを追加して、新しいサブドメインを作成します。たとえば、DNSルート名が contoso.com の場合、concorp.contoso.com などの Active Directory フォレストルートドメイン名を作成する必要があります。
    このネームスペース concorp.contoso.com は既存ネットワーク上では使用されていないものになります。ネームスペースの、この新しい分岐部分は Active Directory と Windows 2000 専用であり、既存の DNS 実装と簡単に統合できます。

 

6. Active Directory 構築 – 正式ドメイン+サブドメイン の メリット

このように、以前とは周辺の状況が変化したこともあり、.local ドメインは時代遅れになりつつあります。

また、サービスを提供するサーバーには世界で唯一の名前をつけるというのは大前提です。

大変残念な事に、日本に Active Directory が導入され始めたときに、日本では .local で構築して良いという誤った認識が広がったために、多くのサイトに .local ドメインをつけてしまいましたが、これは日本のみの悪しき風習です。 

そのため、これから新規に構築、或いはWindows Server の更新を行うタイミングで、マイクロソフト社の推奨設計指針のとおりに .local ドメインを廃止して、正式に取得したドメイン名+サブドメインで作成することをお勧めします。
或いは、現在使用しているドメインが長すぎるということなら、社内用に新たに短いドメインを取得するのもよろしいかと思います。(例: piccode.jp)

他にADドメインをサブドメインで社内システムを構築する場合のメリットは、例えば将来、何らかの理由でサーバーを公開、それもSSL証明書を取得して公開する場合に、「証明書を取得することが可能」ということです。何らかの理由で社内サーバーを公開する場合は当然のようにSSL証明書を使用する場合がほとんどです。

実存確認が取れない「.local」 で作ったサーバーでは公的な証明書を取得することは不可能なので、再設定の必要がありますが、ホスト名変更は様々な影響があるので、最初から構築し直す場合が多くみられます。

運用実績のあるサーバーのホスト名を後から変更するのは大変な困難が伴いますから、最初から所有しているドメインを使用したサブドメイン形式で構築することをお勧めします。

7. サブドメイン名を考える

具体的には、例えば最初の Windows Server のホスト名は ad01.corp.picturecode.co.jp などとします。(既存のドメイン名が長ければ短い社内用ドメインを新規に取得するのも良いです)

ただ、悩むべき箇所はこの ad01.corp.picturecode.co.jp でアンダーライン部分となるサブドメイン名、Active Directory やケルベロス【Kerberos】ではレルム【Realm】名の付け方、ネーミングですね。

企業ドメインは文字数が多い場合があるので、サブドメイン部分にはなるべく少ない文字数、可能なら4文字以内程に収めた方が便利です。

製品名などは終了したり、古くなってしまう場合があるのでなるべく使わない方が良いです

日本の企業で社内に構築する場合を想定した、案をいくつかご紹介します。サーバー名はad01、所有ドメインは picturecode.co.jp で記載します。

汎用

ad01.corp.picturecode.co.jp (会社ということです)
ad01.local.picturecode.co.jp (ここは末尾で無いので、localでも大丈夫)
ad01.ad.picturecode.co.jp    (Active Directory 製品名なのですが…….)
ad01.int.picturecode.co.jp    (Internal 省略形)
ad01.private.picturecode.co.jp (プライベート用と明快に)
ad01.test.picturecode.co.jp (テスト用)

地名

地名は長年固定でもあり、将来事業所が増えた場合でも増設対応が容易です。メリットが多いですね。

ad01.tokyo.picturecode.co.jp (東京)
ad01.jp.picturecode.co.jp (日本)
ad01.shinjuku.picturecode.co.jp (新宿)
ad01.kst.picturecode.co.jp (北新宿、新宿区、東京の頭文字)
ad01.okubo.picturecode.co.jp (最寄り駅名)

 

国際空港都市コード

主要都市の国際空港には正式にユニークな3文字の都市コードが割り当てられていますから、それを利用するのも良いです。
国際コードは何となく地域がイメージし易く、短いので良い選択だと思います。

ad01.tyo.picturecode.co.jp (東京)
ad01.osa.picturecode.co.jp (大阪)
ad01.spk.picturecode.co.jp (札幌)
ad01.sdj.picturecode.co.jp (仙台)
ad01.ngo.picturecode.co.jp (名古屋)
ad01.hij.picturecode.co.jp (広島)
ad01.fuk.picturecode.co.jp (福岡)
ad01.oka.picturecode.co.jp (沖縄)
ad01.hkd.picturecode.co.jp (函館)
ad01.axt.picturecode.co.jp (秋田)
ad01.aoj.picturecode.co.jp (青森)
 ad01.kij.picturecode.co.jp (新潟)
 ad01.toy.picturecode.co.jp (富山)
ad01.kmq.picturecode.co.jp (小松)
ad01.okj.picturecode.co.jp (岡山)
ad01.ygj.picturecode.co.jp (米子)
ad01.tak.picturecode.co.jp (高松)
ad01.myj.picturecode.co.jp (松山)
ad01.ngs.picturecode.co.jp (長崎)
ad01.oit.picturecode.co.jp (大分)
ad01.kmj.picturecode.co.jp (熊本)
ad01.kmi.picturecode.co.jp (宮崎)
ad01.koj.picturecode.co.jp (鹿児島)

国内空港コード

国際空港コードに比べてコードから地名連想という点では弱いかもしれないですが、参考までに。こちらを

8. 正式にローカルで使用できるドメイン名

インターネット公式文書 RFCにおいて、ローカル設定して良いとリザーブされているのは下記トップレベルドメインですが、ご覧のように用途は全て決められています。当然 .local などはリザーブされていません。本来であればマイクロソフト社の技術資料などは、ドキュメントに記載するサンプルドメイン名を .example で表記するのが規格上正しい書き方になります。

.test    現在のDNSまたは新しいDNSのテスト用
.example  ドキュメントやサンプル用
.invalid   無効と認められるオフライン構築用
.localhost  ループバック用

あまり見栄えの良いものはありませんが、どうしてもという場合であっても既に他で使用されている .local はやめましょう。

※追記 .corp .home .mail の3つは「永久補欠ドメイン」になりました

2018年2月4日 に、DNS 命名国際組織の ICANN が「.corp」「.home」「.mail」 の3ドメインを発行すると全世界に多大な影響が出る事が予想されるので、無期限に発行しないことに決定しました。

つまり、将来に渡って、この3ドメインは名前衝突が発生しません。あくまでも、正式に使用が許されている訳ではないのですが、どうしてもローカルなドメインを使用しなければならない場合は最悪、使用する事が可能です。

既に身近に使用され、名前衝突が確定している .local よりは遥かにマシですね。

また、永久にインターネットでは発行されないドメインなので、間違えて社内の情報が他に流出することもありません。

.CORP、.HOME、および.MAILの新しいgTLDプログラムアプリケーションへの対応  (リンク:ICANN)

ということですが、後から公的な証明書を取得できないなどの問題は全く同じなので、これからActive Directory を新規に構築、或いは更新する場合は、

マイクロソフト社の推奨設計指針のとおりに、最初から「正式ドメイン+サブドメイン」で、構築することをお勧めします

自社で所有するドメインのみが世界中で保証されます。サービスを提供するサーバーは世界で唯一の名前を持つのがお約束です。

ここから宣伝

さて、ここまでお読みいただいたかたは、「実はそうなっていたのか!」と驚かれたことと思います。

実はもう一つ驚きをお伝えしたいと思います。

弊社ではMac, iPhone, iPadを Active Directory 情報で一元リモート管理し、ポリシーの適用を可能にするソリューション 「Apple 対応 Active Directory 連携 改修サービス」を提供しています。

クラウドなどにユーザ登録する必要もなく、既存登録のActive Directoryのユーザ情報で Windows と同時に Apple 製品全般にもリモート管理・設定、ポリシーの適用を行う事が可能になる連携ソリューションです。
管理台数は無制限なので、デバイスを追加する毎に支払額が変動することもありません。

Macだけならまだしも、iPhoneやiPadなどのiOSデバイスまで本当にADで管理できるのか?とシステム管理者であれば誰でも疑問に思うことです。

もしも事実ならば、多種デバイスの管理負担が一気に半分、或いは 1/3 にしながら、管理ミスを無くし、組織のセキュリティ全体を向上ことが可能になってしまいます。

ご興味がありましたら、東京圏無料のデモンストレーションをお気軽にリクエストしてください。
こちらのデモンストレーションも皆さま驚かれます(地域限定で申し訳ありません)

Active DirectoryにMacも参加して管理をシンプルに

 

ピクチャーコード株式会社について:ピクチャーコードはApple社出身のエンジニアが設立した企業です。主に組織へのApple製品導入支援を行なっています。

お困りの事柄がありましたら、お気軽になんでもお問い合わせください。

Macなどを Active Directory に接続する際、.local ドメインは問題外ですが、他にも先に設定しておいた方が後々にメリットがある構成があります。ご相談ください。 
また、Munki による社内専用の App Store 構築なども行っています。