Active Directoryをリモートユーザーのパブリックインターネットに公開する必要がありますか？
AppleとWindows 7 PC /ラップトップを組み合わせて使用しているリモートの従業員のみで構成される従業員のクライアントがあります。
現時点ではユーザーはドメインに対して認証を行いませんが、組織はいくつかの理由でその方向に進みたいと考えています。これらは会社所有のマシンであり、会社はアカウントの非アクティブ化、グループポリシー、および軽度のデータ損失防止（リモートメディア、USBなどの無効化）をある程度制御することを目指しています。ADにアクセスするためにVPN認証を要求することを懸念しています特に退職した従業員とリモートマシン上のキャッシュされた資格情報の交差点では、煩雑になります。
組織のほとんどのサービスはGoogleベース（メール、ファイル、チャットなど）なので、ドメインサービスはDNSとCisco ASA VPNの認証のみです。
お客様は、ドメインコントローラーを公開することが受け入れられない理由を理解したいと考えています。さらに、分散リモートワークフォースにとって、より受け入れやすいドメイン構造とはとは何ですか？
編集：
Centrify は、少数のMacクライアントで使用されています。
主に誰もが経験、サードパーティの情報、伝聞、およびIT内の部族の知識に基づいた「教育的意見」を持っているため、これを回答として投稿していますが、これはMicrosoftからの「直接」の引用と読みのリストです。従業員が作成したすべての意見を適切にフィルター処理しないと確信しているため、引用符を使用しましたが、Microsoftから直接authoritativeを参照している場合は、これが役立つはずです。
BTW、 DOMAIN CONTROLLER == Active Directoryと言うのも非常に簡単だと思いますが、そうではありません。 AD FSプロキシおよびその他の手段（OWA、EASなどのフォームベースの認証）は、AD自体をWebに「公開」して、クライアントが少なくともAD経由で認証を試行できるようにする方法を提供しますDC自体を公開しないでください。誰かのOWAサイトにアクセスして、ログインしてADを試行してくださいwillバックエンド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ライトウェイトを備えたWindows Server 2008サーバーを配置することです境界ネットワークで実行されているディレクトリサービス（AD LDS）の役割。
引用＃3-MSからではありませんが、今後の検討に役立ちます
Active Directory-as-a-Service？Azure、Intune hinting in a cloud-hosted AD AD future
結局のところ、Azureの代替策と引き換えに、ADサーバーのオフィスを取り除くという目標を満たす優れた「短い」答えはありません。 Microsoftは、顧客がAzureのServer 2012および2008 R2ボックスでActive Directoryドメインサービスをホストできるようにすることに満足していますが、その有用性は、スタッフが必要とするVPN接続と同じくらい優れています。 DirectAccessは非常に有望なテクノロジですが、残念ながら独自の制限があるため、手をつないでいます。
引用＃4
AD DSまたはAD FSおよびシングルサインオンを備えたOffice 365とWindows Azure仮想マシン）を展開する
ドメインコントローラーとAD FSサーバーはインターネットに直接公開しないでください。また、VPN経由でのみアクセス可能にしてください。
Active Directory（AD）は、そのような展開向けに設計されていません。
製品の設計で使用される脅威モデルは、ネットワーク境界でフィルタリングされたある量の敵意のあるアクターによる「ファイアウォールの背後」の展開を想定しています。 Windows Serverをパブリックネットワークに公開するように強化することは確かに可能ですが、Active Directoryが正しく機能するためには、パブリックネットワーク向けに強化されたホストよりも明らかに緩やかなセキュリティ体制が必要です。 ADが適切に機能するためには、lotのサービスをドメインコントローラー（DC）から公開する必要があります。
コメントでのZoredacheの提案、特に証明書認証付きのマシン全体のサービスとして実行されているOpenVPNのようなものを参照することは、ちょうど良いかもしれません。他のユーザーが述べたように、DirectAccessは、必要なクロスプラットフォームサポートがないことを除いて、まさに必要なものです。
余談ですが、私は証明書ベースのトランスポートモードIPSECを使用してADを直接インターネットに公開するというアイデアに興味をそそられましたが、実際にそれを行う時間はありませんでした。マイクロソフトはWindows Server 2008/Vistaのタイムフレームに変更を加えたため、これは実現可能と思われていましたが、実際に実行したことはありません。
他の誰もが言ったこと。私は、クリストファーカレルが言及した力ずくの試みについて特に緊張しています。 最後のDef Conでのプレゼンテーション がトピックでした：
ドメインコントローラは安全だと思いますか？
ジャスティンヘンドリックスセキュリティエンジニア、マイクロソフト
ドメインコントローラーは、組織の王冠です。それらが落ちると、ドメイン内のすべてが落ちます。組織はドメインコントローラーをセキュリティで保護するために多大な努力を払っていますが、多くの場合、これらのサーバーの管理に使用されるソフトウェアを適切に保護できません。
このプレゼンテーションでは、組織が展開して使用する一般的に使用される管理ソフトウェアを悪用することにより、ドメイン管理を取得するための従来とは異なる方法について説明します。
ジャスティンヘンドリックスはOffice 365のセキュリティチームで働いており、レッドチーミング、侵入テスト、セキュリティ調査、コードレビュー、ツール開発に携わっています。
他にもたくさんの例が見つかると思います。 DCが見つかるまでの速さなどについての説明を得ることを期待して、ドメインコントローラとハッキングに関する記事を探していましたが、今のところそれで十分だと思います。
あなたが経営者を説得しようとしているなら、良いスタートはそれです：
It goes against Microsoft's Best Practices for Active Directory Deployment.
Update：ドメインコントローラを攻撃から保護することについて この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など）なので、心配する必要はありません。また、ユーザーはローカルマシンのプロファイルフォルダー内のすべてのファイル（およびリムーバブルメディア）に対する完全な権限を既に持っているため、資格情報を無効にするか、ユーザーがそのデータで希望どおりの操作を実行できないことを忘れないでください。また、ネットワークに再接続すると、ローカルマシンで機能しなくなります。
LDAPなど、Active Directoryまたはドメインコントローラーが提供するサービスを参照していますか？その場合、認証とディレクトリクエリの目的でLDAPが安全に分割されることがよくありますが、Windowsファイアウォールをオフにする（または必要なすべてのポートをパブリックまで開く-この例でも同じ）と、深刻な問題が発生する可能性があります。
ADはMacを本当に管理しないため、別のソリューションが必要になります（OS Xサーバーを考えてください）。 Macをドメインに参加させることはできますが、ネットワーク認証情報で認証させたり、ドメイン管理者をMacのローカル管理者として設定したりするだけです。グループポリシーはありません。 MSは、新しいバージョンのSCCMでアプリケーションをMacおよび* nixボックスに展開できると主張している）でその地位を突破しようとしていますが、まだ実稼働環境では見ていません。また、MacベースのOSベースのサーバーに接続するように設定して、ADベースのディレクトリを認証することもできますが、私は間違っている可能性があります。
そうは言っても、OpenVPNをサービスとして使用し、その従業員を解雇するときにマシン証明書を無効にするというEvanの提案など、いくつかの創造的なソリューションを考案することができます。
すべてがGoogleに基づいているようですが、GoogleがLDAPサーバーとして機能していますか？私は、クライアントが可能な限りそれを維持することをお勧めします。私はあなたのビジネスの性質を知りませんが、gitまたはredmineサーバーなどのWebベースのアプリの場合、社内でセットアップしても、Googleアカウントを利用してOAuthで認証できる場合があります。
最後に、このようなロードウォリアーの設定では、VPNを成功させるためにVPNがほぼ必要です。マシンがオフィスに持ち込まれて構成されたら（またはスクリプトを使用してリモートで構成されたら）、構成の変更を受け取る方法が必要になります。
Macには、VPNに加えて別の管理アプローチが必要です。本当のMacサーバーをもう作成しないのは残念ですが、前回チェックしたとき（数年前）、OS Xサーバーに適切なポリシー実装がいくつかありました。 ）。
DirectAccessは、ご要望に合わせてカスタマイズされているため、Win7 + Enterprise Editionでのみ使用できるのは残念です。しかし、エディションがわからず、MacOSがインストールされていることがわかると、機能しません。
/編集-一部のサードパーティは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つのことを警告します：
ターミナルサーバー、DNSサービス、CIFSなどのネットワークに直面している他のサービス、特にIISとそのひどいセキュリティレコード）に注意してください。
LDAPSをセキュリティ証明書と共に使用して、クリアテキストドメインの資格情報をネットワーク経由で渡さないようにします。これは、証明書サービスのインストール後に自動的に行われます（PKIには別のマシンを使用してください）
パケットスニファをインターフェイスに置き、トラフィックを監視し、クリアテキストのパスワードを修正します。ファイアウォールかどうかにかかわらず、VPNまたはLDAPSを使用していない場合、一部のレガシーシステムはクリアテキストのパスワードを送信します。
MITM攻撃により、ネイティブ認証メカニズムが強制的にダウングレードされ、より弱いNTLM認証にパスワードが公開される可能性があることを理解してください。
まだ存在する可能性のあるユーザー列挙の脆弱性に注意してください。
とはいえ、Active Directoryにはセキュリティに関して優れた実績があります。さらに、MS Active Directoryはパスワードを格納せず、侵害の重大度を軽減するハッシュのみを格納します。
よりシームレスなセキュリティインフラストラクチャの恩恵を受けることができ、特別なDNSサーバーを設定したり、domain.localを使用したりする必要がなく、domain.comなどのパブリックインターネット上の実際のドメインを使用できます。
私の専門家の意見では、Active Directoryなどのセキュリティテクノロジを公に展開することには大きなメリットがあります。ExchangeやDNSやWebサーバーなどの他のテクノロジは、単にメリットがなく、すべてのリスクを提供します。
注：Active Directoryを展開すると、DNSサーバーが含まれます。 DNSサーバーの再帰を無効にするには、CERTAINにしてください（デフォルトで有効）。サービス拒否攻撃に絶対に参加することになります。
乾杯、
-ブライアン