我が家で長らく動いてるSophos UTM9。Home Editionライセンスで稼働していて、今ではかなり重要な経路を担当しています。
にも拘わらず長年シングル構成をとっていました。ってのも、なかなかHA構成を挑んでうまくいくことがなかったのです。
はい。そこで思い立ってHA構成を組んでいこうと言うことでリソースを確保して実装しました。・・・が、早速初期化して間もないスタンバイノードのデータがPrimaryデータとして既存UTMに同期される始末・・・。一度は見事にUTMが全面初期化され、いろんな所に通信できなくなりました。
が、3点ほど気をつければきちんと設定できることが分かりました。取り敢えずこれを備忘録として記載しようと思います。
ある日のAzureからの通知メール
入院中の時だったのですが、こんなメールが来ました。
You’re receiving this email because you use Azure Active Directory.
[Microsoft Azure]
Update your machines to use TLS 1.2 for Azure AD Connect Agents
You’re receiving this email because you use Azure Active Directory.
We’re continually updating our services to ensure enhanced security and the best-in-class encryption. As a result, starting on October 31, 2019, Azure Active Directory (Azure AD) Connect agents such as the Pass-through Authentication agent and Provisioning agent will only accept TLS 1.2, and we will retire support for TLS 1.0 and 1.1 on this date.
Our records indicate that your organization has installed one of these agents and has servers connecting to Azure AD services using pre-TLS 1.2 protocols. To prepare for this change, make sure that all servers are updated to use TLS 1.2 to maintain connection to the Azure AD service.Required action
For servers with Azure AD agents installed, use the following steps to ensure TLS 1.2 is enabled by October 31, 2019:
Set these registry keys to enable TLS 1.2 on your Windows Server 2012 R2 or later:・・・・・・・（中略）・・・・・・
See TLS 1.2 in Office 365
https://support.microsoft.com/help/4057306/preparing-for-tls-1-2-in-office-365 for references and resourcesFor complete information see:
Azure AD Connect Pass-through Authentication Agent
https://docs.microsoft.com/azure/active-directory/hybrid/how-to-connect-pta-quick-start
Azure AD Connect Provisioning Agent
https://docs.microsoft.com/azure/active-directory/saas-apps/workday-inbound-tutorial#planning-deployment-of-azure-ad-connect-provisioning-agent
If you have questions, please contact usaadapfeedback@microsoft.com.
どうやら、2019年10月いっぱいでTLS1.2以外のAzure AD Connectの接続は行えなくなるようです。我が家のドメインコントローラはWindows Server 2008 R2を、Azure AD ConnectサーバにはWindows Server 2012 R2を使用していますが、システム上Windows Server 2012 R2はTLS1.1以前を使用してAzure ADとの同期をとっているように見受けられます。そこでMicrosoftから上記のようなメールがきたっぽいですね。
というわけで、この記載に従いTLS1.2を有効にし、これでAzure ADとの同期が行えるようレジストリ設定を変更することにしました。備忘録として手順をまとめます。
なお、ここで掲載している手法ですが、あくまで私の目指すゴールは「ログイン時のアクセスを通常のIPoEから固定IP経路へシフトさせ、二要素認証をバイパスする」というものであり、Enterprise方向に対するローカルブレイクアウトを実現するには行う処理が足りません。
O365から受信する経路にはIPアドレス以外に、URLもあり、そこに対するケアが出来ないと本当の意味でクラウド経路をインターネットへ寄り軽い経路に回すローカルブレイクアウトは実現できません。
このあたりはSquidで手作りでもよいでしょうし、FortigateやA10Thunder CFWなどのようなプロキシアプライアンス機能が必要になります。あらかじめご了承ください。
この前、Untangle Firewallを使ってこんなことをしました。
要は、Interlink-PPPoE回線やHomenocの回線は、サーバが主に使用しているということもあり、クライアントで扱う際に結構帯域が狭くなってるのです。特にMisskeyの受信を受け持つInterlink-PPPoEは壊滅的で、下り速度がマジに遅いです。
そこでInterlink-IPoEを恒常的に使うよう、Untangle Firewallを使用しまして、回線を固定しつつセキュリティを保つことが出来たのであります。・・・が面倒なことが起きました。
Office365のSingle SignOnが効かんのです。
Azure Portalへのアクセスで常に二要素認証を求められるのです。
原因はそう、IPoE回線が変動IPアドレスだから。故に、自宅のクライアントセグメントからアクセスしようとすると大体IPが都度都度変わります。これは正直困った。事あるごとに認証をせんとイカン。
DKIMってなんじゃろ？と思う人や、名前は聞いたことがあるけどよーわからん・・と言う人いるんじゃないでしょうか。実は私も先日まで名前しか知らなくて、「ああ、DKIMね」とか言ってみるものの、単なる知ったかぶりだったりしていたわけですが、この際キチンと覚えていこうということで、自宅環境に対して取り組んでみました。
図にまとめるとこんな感じのようです。
上図にあるように、所謂「送信ドメインのなりすましを防ぐ」ために、「送信ドメインDNSの所有者であるかどうかを確認する」方法なんだと思います。図の下の方にも書いていますが、実はSPFと言う方式もあり、これもDNSと連携して送信元SMTPサーバの確認を行います。
アプローチとしてはSSL証明書のDV証明に似たところがあるかな？と感じますね。
つい先日Exchange Onlineにめでたく切り替わった我が家のメールインフラ。
実は既存オンプレ環境から残して使い続けたい機能がひとつだけあり、それがメールアーカイバ機能です。
製品は非常に古いんですが、MailArchiva OpenSource Editionというものを使っているんですが、過去メールの検索や、ドメイン承認メールを拾うのにかなり重宝しており、これは基本的に手元においておきたいデータだったりします。
今回、Exchange Onlineとこのメールアーカイブ基盤の連携をとってみることにしました。