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

STOP .local

 

Apple 製品が参加するネットワーク上の Active Directory ドメイン名として末尾に .local が使用されていると動作が不安定になります。

ダメな例: corp.local

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

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

なお、LinuxでもmDNSは使用されています。

古いMicrosoft社の技術資料などでは .local が多用されている場合がありますが、こちらは絶対に避けて、企業が所有しているドメイン名を使用して、社内ドメインはサブドメインで構築するのがベストです。

あるいは、社内用に新規にドメインを取得して、そちらにサブドメインをつけても良いと思います。

重要なのは、正式に取得したドメイン名+サブドメインにするということです。

(例: corp.picturecode.co.jp)

Microsoft社から出ている、比較的最近の資料では

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

と明記されています。

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

つまりMacをADに接続するしないに関わらず、社内ネットワーク上に Mac を設置する可能性があるならば .local で終わるドメインを使用してはいけないのです。

 

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

Mac (Linuxも)を設置する場合は .local で終わる
ディレクトリサービスを社内に設置しないこと!

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

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

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

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

Apple製品安定運用の為のとても重要なポイントです。

 

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

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

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

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

さらに言えば、マイクロソフト社は .local で作成することを推奨していません。

下記のマイクロソフトが発行している文章は Windows Server 2000 時代からの推奨設計指針です。これは現在でも変更されていません。つまり Active Directory の最初期から現在に至るまで一貫して、正式なDNS名+サブドメイン形式で作ることを推奨しています。このあたりは全くブレていません。

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 実装と簡単に統合できます。

 

このように、末尾が.local で終わるドメインを採用した場合には Apple社製品のみでなく、マイクロソフト社製品間、インターネット標準規格に基づき製造された製品、外部連携を構築する場合で接続の問題が発生します。百害あって一利は「名前が短くなる」のみです。

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

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

運用実績のあるサーバーのホスト名を後から変更するのは大変な困難が伴いますから、安易に.local を採用せずに、最初から所有しているドメインを使用したサブドメイン形式で構築することを強くお勧めします。もちろん、上記のリスクが発生することをご理解の上で採用されるのでしたら仕方がないのですけど。

具体的には、例えば最初の 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 (鹿児島)

国内空港コード

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

 

ローカルで使用できるドメイン名

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

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

あまり見栄えの良いものはありません。

ということで、Active Directory を構築し、運用開始した後に大きな苦労したくない場合は、

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

残念ながら日本では多くの Active Directory 構築関連書籍やインターネット上の情報が正しく記載されていないために .local で構築してしまう場合が多く見られます。

もしも既に.local で作成して運用を開始してしまった場合、Windows, Mac, iPhone, iPad を Active Directory 情報で一元管理可能にする 「Apple 対応 Active Directory 改修サービス」構築時に .local 以外への移行サービスも承ります。

こちらのサービスは実際にご覧いただくと、Microsoft社の Active Directory で Windowsの管理と同時にApple製品もここまで管理できるようになるのかと、システム管理者の皆様が必ず驚かれる内容です。

Windows と Mac, iPhone, iPad, そして Apple TV までも一元管理することで、多種デバイスの管理負担が一気に半分、或いは 1/3 にしながら、管理ミスを無くし、組織のセキュリティを向上するソリューションです。

ご興味がありましたら、関東圏無料のデモンストレーションをお気軽にリクエストしてください。

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