Active Directoryをリモートユーザーのパブリックインターネットに公開する必要がありますか？

AppleとWindows 7のPC /ラップトップを組み合わせて使用​​する従業員がすべてリモートの従業員で構成されているクライアントがいます。

ユーザーは現時点ではドメインに対して認証しませんが、組織はいくつかの理由でその方向に移行したいと考えています。これらは会社所有のマシンであり、会社はアカウントの非アクティブ化、グループポリシー、および軽いデータ損失防止（リモートメディア、USBなどの無効化）をある程度制御しようとしています。特に退職した従業員とリモートマシン上のキャッシュされた資格情報が交差する場所では、面倒です。

組織内のほとんどのサービスはGoogleベース（メール、ファイル、チャットなど）であるため、ドメインサービスはDNSとCisco ASA VPNの認証のみです。

お客様は、ドメインコントローラーを公開することが受け入れられない理由を理解したいと考えています。また、分散リモートワーカーのより受け入れ可能なドメイン構造は何ですか？

編集：

Centrifyは、少数のMacクライアントで使用されています。

主に誰もが経験、サードパーティの情報、伝聞、およびIT内の部族の知識に基づいた独自の「教育的意見」を持っているため、これを回答として投稿していますが、これはMicrosoftからの「直接」の引用と読みのリストです 従業員が行ったすべての意見を適切にフィルタリングするわけではないと確信しているため、引用を使用しましたがauthoritative、Microsoftからの直接の参照が必要な場合でも、これは役立つはずです。

ところで、私はドメインコントローラ==アクティブディレクトリと言うのは非常に簡単だと思いますが、そうではありません。AD FSプロキシおよびその他の手段（OWA、EASなどのフォームベース認証）は、AD自体をWebに「公開」する方法を提供し、クライアントが少なくともDC自体を公開せずにAD経由で認証を試行できるようにします。誰かのOWAサイトにアクセスしてログインを試みると、AD はバックエンドDCで認証の要求を取得するため、ADは技術的に「公開」されますが、SSLで保護され、Exchangeサーバーを介してプロキシされます。

引用＃1

Windows Azure仮想マシンにWindows Server Active Directoryを展開するためのガイドライン

「Azureは、ADではありません」に進む前に、Azure VMにADDSをデプロイできます。

しかし、関連するビットを引用するには：

STSをインターネットに直接公開しないでください。

セキュリティのベストプラクティスとして、STSインスタンスをファイアウォールの内側に配置し、企業ネットワークに接続して、インターネットへの露出を防ぎます。STSの役割はセキュリティトークンを発行するため、これは重要です。そのため、ドメインコントローラーと同じレベルの保護で処理する必要があります。STSが危険にさらされた場合、悪意のあるユーザーは、信頼する組織の依存パーティアプリケーションや他のSTSに対する選択の要求を潜在的に含むアクセストークンを発行することができます。

ergo ...ドメインコントローラーをインターネットに直接公開しないでください。

引用＃2

Active Directory-AD LDSのUnicodePwdミステリー

ドメインコントローラをインターネットに公開することは、運用環境から直接アクセスする場合でも、境界ネットワークを経由する場合でも、通常は悪い習慣です。自然な代替方法は、境界ネットワークで実行されているActive Directoryライトウェイトディレクトリサービス（AD LDS）の役割を持つWindows Server 2008サーバーを配置することです。

引用＃3-MSからではなく、まだ先を見据えて有用

Active Directory-as-a-Service？Azure、クラウドでホストされるADの未来を示唆するIntune

最終的に、Azureの代替と引き換えにADサーバーのオフィスをなくすという目標を達成するための素晴らしい「短い」答えはありません。マイクロソフトは、顧客がAzureのServer 2012および2008 R2ボックスでActive Directoryドメインサービスをホストできるようにすることに満足していますが、その有用性は、スタッフが必要とするVPN接続と同等です。DirectAccessは非常に有望なテクノロジーですが、不幸な制限のために手を縛られています。

引用＃4

シングルサインオンおよびWindows Azure仮想マシンでAD DSまたはAD FSとOffice 365を展開する

ドメインコントローラーとAD FSサーバーはインターネットに直接公開されることはなく、VPNを介してのみ到達可能である必要があります。

Active Directory（AD）は、この種の展開用に設計されていません。

製品の設計で使用される脅威モデルは、ネットワーク境界でフィルタリングされた敵対的なアクターの一部を含む「ファイアウォールの背後」での展開を想定しています。Windows Serverをパブリックネットワークに公開することは確かに強化できますが、Active Directoryが正しく機能するには、パブリックネットワーク用に強化されたホストよりも明らかに緩いセキュリティ状態が必要です。ADが適切に機能するには、多くのサービスをドメインコントローラー（DC）から公開する必要があります。

コメントでのZoredacheの提案、特にOpenVPNのような証明書認証付きのマシン全体のサービスとして実行しているものを参照することは、ちょうどいいかもしれません。他の人が述べたように、DirectAccessはまさにあなたが必要とするものですが、それはあなたが望むクロスプラットフォームのサポートを持っていないことを除きます。

余談ですが、ADをインターネットに直接公開するために証明書ベースのトランスポートモードIPSECを使用するというアイデアをいじりましたが、実際にそれをする時間はありませんでした。マイクロソフトはWindows Server 2008 / Vistaのタイムフレームに変更を加えて、おそらくこれを実現可能にしましたが、実際に実行したことはありません。

みんなが言ったこと。クリストファー・カレルが言ったブルートフォースの試みに特に神経質です。 前回のDef Conでのプレゼンテーションは次のトピックに関するものでした：

ドメインコントローラは安全だと思いますか？

ジャスティンヘンドリックスセキュリティエンジニア、マイクロソフト

ドメインコントローラーは、組織の最も重要な要素です。それらが落ちると、ドメイン内のすべてが落ちます。組織はドメインコントローラーを保護するために多大な努力を払っていますが、これらのサーバーを管理するために使用されるソフトウェアを適切に保護できないことがよくあります。

このプレゼンテーションでは、組織が展開して使用する一般的に使用される管理ソフトウェアを悪用して、ドメイン管理者を獲得するための従来とは異なる方法を取り上げます。

Justin Hendricksは、Office 365セキュリティチームに所属し、レッドチーム、侵入テスト、セキュリティ調査、コードレビュー、ツール開発に関与しています。

私はあなたが他の多くの例を見つけることができると確信しています。私はドメインコントローラーとハッキングについての記事を探していましたが、DCがどれくらい早く見つかるかなどの説明を取得したいと思っていましたが、今のところはそうだと思います。

経営陣を説得しようとしている場合、良いスタートは次のことです：

It goes against Microsoft's Best Practices for Active Directory Deployment.

更新：ドメインコントローラーを攻撃から保護する方法に関するこのtechnetの記事とPerimeter Firewall Restrictions、次のようなタイトルのセクションを参照してください。

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

そして、タイトルのBlocking Internet Access for Domain Controllersあるセクション：

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

この問題に関するマイクロソフトのドキュメントをいくつか作成できると確信していますので、それだけです。それに加えて、あなたはそのような動きの危険を述べることができます：

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

キャッシュされた資格情報は、キャッシュされたものです。ドメインに接続できない場合、ローカルマシンで動作しますが、そのアカウントが無効になっている場合、ネットワークリソース（svn、vpn、smb、fbi、ciaなど）で動作しないため、心配する必要はありません。 。また、ユーザーはローカルマシン上のプロファイルフォルダー内のファイル（およびリムーバブルメディア）に対する完全な権限を既に持っているため、資格情報を無効にしたり、そのデータを使用して自分ができることを実行できないことも覚えておいてください。また、ローカルマシンがネットワークに再接続すると、それらは機能しなくなります。

Active Directoryまたはドメインコントローラーが提供するサービス（LDAPなど）を参照していますか？その場合、認証とディレクトリクエリの目的でLDAPが安全に分割されることがよくありますが、Windowsファイアウォールをオフにする（または必要なすべてのポートを公開する-この例では同じこと）だけで重大な問題が発生する可能性があります。

ADは真にMacを管理しないため、別個のソリューションが必要になります（OS X Serverを考えてください）。Macをドメインに参加させることはできますが、ネットワーク資格情報で認証したり、ドメイン管理者をMacのローカル管理者に設定したりするだけです。グループポリシーはありません。MSは、アプリケーションをMacおよび* nixボックスに展開できると主張する新しいバージョンのSCCMでその領域を突破しようとしていますが、実稼働環境ではまだ見ていません。また、ADベースのディレクトリを認証するOS Xサーバーに接続するようにMacを構成できると思いますが、間違っている可能性があります。

そうは言っても、OpenVPNをサービスとして使用し、その従業員を解雇する時が来たらマシン証明書を無効にするというEvanの提案など、いくつかの創造的なソリューションを考案できます。

すべてがGoogleベースであるように聞こえるので、GoogleはLDAPサーバーとして機能していますか？可能であれば、クライアントにそのままにしておくことをお勧めします。あなたのビジネスの性質はわかりませんが、gitまたはredmineサーバーなどのWebベースのアプリの場合、社内でセットアップしてもGoogleアカウントを利用してOAuthで認証できます。

最後に、このようなロードウォリアーのセットアップでは、VPN がほぼ成功する必要があります。マシンをオフィスに持ち込んで構成（またはスクリプトを介してリモートで構成）したら、構成の変更を受信する方法が必要です。

Macには、VPNに加えて別の管理アプローチが必要です。実際のMacサーバーをもう作成しないのは残念ですが、最後にチェックしたときにOS X Serverにいくつかの適切なポリシー実装がありました（数年前）。

残念ながら、DirectAccessはWin7 + Enterprise Editionでのみ使用できます。これは、要求に合わせてカスタマイズされているためです。ただし、エディションがわからず、MacOSを使用していることがわからない場合は機能しません。

/ Edit-一部のサードパーティがUnicesのDAクライアントを持っていると主張しているように見えます：http ://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

ニーズを満たすために機能するMDMソリューションが利用可能です。それらの1つ（MAAS360）を同様の立場にあるクライアントに展開しています。

これは明らかに重大なセキュリティリスクになります。さらに、おそらくあなたが望むほどうまく機能しないでしょう。インターネット上のランダムな人々がAD環境にログインを試みることができる場合、すべてのユーザーがロックアウトされる可能性が高くなります。永遠に。また、ロックアウト要件を削除すると、単純なパスワードの総当たりチェックが非常に簡単になります。

さらに重要なことは、ADサーバーに直接アクセスできるようにすることなく、目標（ドメインの資格情報を使用してラップトップにログインするエンドユーザー）の実装に問題がないことです。つまり、Windowsマシンは最後にX回成功したログインをキャッシュできるため、切断されたときに同じ資格情報が機能します。これは、エンドユーザーがADサーバーに触れることなくログインして有用な作業を行えることを意味します。明らかに、VPNを使用して他の主要な企業リソースに接続する必要があり、AD / GPO設定を同時に更新できます。

ユーホワイト、

あなたの質問は非常に有効であり、慎重な検討に値します。

すべてのセキュリティ専門家は、SPIファイアウォール、IDS、ホストベースのファイアウォールなど、ネットワークリソースの前にセキュリティ層を推奨しています。可能な場合は、常にISA（現在のTMG）などのプロキシ境界ゲートウェイファイアウォールを使用する必要があります。

とは言っても、Microsoft Active Directory 2003+には一般に公開されている主要な脆弱性はありません。LDAPテクノロジーとそのハッシュアルゴリズムは一般に非常に安全です。SSL VPNがOpenSSLを実行し、ハートブリードに対して脆弱である場合、それは間違いなくSSL VPNよりも安全です。

5つの点に注意します。

1. ターミナルサーバー、DNSサービス、CIFS、特にひどいセキュリティレコードを持つIISなど、ネットワークに直面している他のサービスについて心配する必要があります。

2. LDAPSをセキュリティ証明書とともに使用して、クリアテキストドメインの資格情報をネットワーク経由で渡さないようにします。これは、証明書サービスのインストール後に自動的に行われます（PKIには別のマシンを使用します）

3. VPNまたはLDAPSを使用していない場合、一部のレガシーシステムはクリアテキストパスワードを送信します。

4. MITM攻撃により、ネイティブ認証メカニズムが強制的にダウングレードされ、パスワードが弱いNTLM認証にさらされる可能性があることを理解してください。

5. まだ存在する可能性のあるユーザー列挙の脆弱性に注意してください。

とはいえ、Active Directoryにはセキュリティの優れた実績があります。さらに、MS Active Directoryはパスワードを保存せず、ハッシュのみを保存して、侵害の重大度を緩和することもできます。

よりシームレスなセキュリティインフラストラクチャを活用できます。特別なDNSサーバーを設定したり、domain.localを使用したりする必要はなく、domain.comなどのパブリックインターネットで実際のドメインを使用できます。

私の専門家の意見では、Active Directoryなどのセキュリティテクノロジーをパブリックに展開することには大きなメリットがあります。ExchangeやDNSやWebサーバーなどの他のテクノロジーは、単に利益をもたらさず、すべてのリスクをもたらします。

注：Active Directoryを展開する場合、DNSサーバーが含まれます。DNSサーバーで再帰を無効にする（デフォルトで有効になっている）ことを確認してください。そうしないと、サービス拒否攻撃に絶対に参加することになります。

乾杯、

-ブライアン

Dell（Questの購入による（Vintelaの購入による））には、この明確な目的のためにF500企業に頻繁に展開されるクロスプラットフォームソリューションがあります。

考慮すべきこと...

1. ユーザーは常に接続されていますか？その場合、多くのアクティブなユーザーがLDAPを使用しているときに柔軟に対応できる柔軟なVMベースのホスティング環境を使用すると最適です。
2. 複数の物理データセンターで実行していますか？ユーザーとシステム間のホップ数を減らすために、ADサービスの前で地理的な負荷分散を検討します
3. また、＃2の答えが「はい」の場合、ここに示すようにフォレストを複製するために専用のネットワークリソースを設定してください。

スロットルアップリンクを使用しているユーザーや、騒がしいWiFiセンターなどから接続しているユーザーがいる場合、ファイアウォールソリューションが非常に高い再送信レートを処理できることを確認してください。