かみーの備忘録

技術的な内容（インフラ基盤、ネットワーク寄り）や趣味に関して雑多にログを残していきます！

英語のお勉強（2021/2/15週）

学習・勉強

こんばんわ。かみーです。日本語で書いた日記を英訳して、自分の気持ちが入った英語の日記をつぶやいてみよう的なことを急に始めておりまして本日で３日目でございます。もっとイングリッシュに慣れていかないとミーはこのままじゃスピーキングできない。うさんくさ。

今週調べてみた単語や使いまわしは以下でした。

  • うたたね（居眠り）
    　　★dozed off.
    　　使い方：I dozed off.
    　　和　訳：私はうたたねしていた。
  • ３日坊主（すぐあきらめる）
    　　★easily give up, 
    　　使い方：I always easily give up.
    　　和　訳：私はいつもすぐあきらめてしまう。

英語、喋るのも話すのも読むのも億劫にはならないんだけど、いまだに触れ始める前には「ウッ」という気合が必要なのです。この辺りがどうにかなるとまた少し変わってくるかな？ゆっくりですが頑張っていきましょーーー。それでは。

SAMLとは…？

Identity SSO

こんにちわ。かみーです。最近は白菜と豚バラばかり食べてます。

さて、今回はSaaSアプリとAzureADとでSAML連携を実施してみました。今回は「SAMLってなに？」ってところからinputした内容をブログに記載していきます。

SAMLとは？

  • Security Assertion Markup Languageの略
  • 読み方は「サムル」
  • AzureADはSAML2.0に対応している
  • 認証フローの始まり方が2種類ある。
    　IdPから始まる「IdP-Initiated」
    　SPから始まる「SP-Initiated」
    　※IdP: Identity Provider。本記事においてはAzureADのこと。
    　※SP: Service Provider。本記事においてはSaaSアプリのこと。

 

認証フローについても図を書いてみました。

SAMLの認証フローについて（IdP-Initiated）

f:id:Le7Wy:20210201182831p:plain

SAML(IdP-Initiated)の認証フロー

 

SAMLの認証フローについて（SP-Initiated）

f:id:Le7Wy:20210201182907p:plain

SAML(SP-Initiated)の認証フロー

個人的にポイントだな、と思ったのは以下です。

  • 認証はIdPにて実施
  • 認証が成功するとSAML応答をユーザへ送り、その応答をSaaSアプリへ送信

 

今回連携したSaaSアプリですが、SaaSアプリ側でもユーザ作成および権限の設定が必要で「認証はIdP」「認可はSaaSアプリ」というようなものでした。他のアプリもこんな感じなのでしょうか。認証のAAAについてもおさらいで再度調べました。

  • 認証(Authentication)・・・ID/Passなどを用いてユーザの正しさを確認する。
  • 認可(Authorized)・・・認証成功したユーザにアクセス権や管理権限などの権限を付与する。
  • アカウンティング(Accounting)・・・認証成功したユーザの情報を収集する。

 

AzureADで実施するメリット？

今回SAML連携用に「エンタープライズ アプリケーション」で新しくアプリを作成しました。

ここで新しくアプリを作成するとリソース一覧に追加され、AADP P1で利用できる「条件付きアクセス」にて他のマイクロソフトのアプリと同じようにアクセス制限ができるようになりました。

これで、条件付きアクセスを用いたAzureMFAの利用や、ネットワーク的なアクセス制限も可能になる・・・はず。出来ることが増えていくと楽しいですね。

 

終わりに

アプリケーションプロキシも同じように条件付きアクセスに組み込めるっぽいのだよな。はよやろ。

脆弱性cve-2020-1472について調べてみたこと

ZeroLogon

こんにちわ。かみーです。インフラ部分の情シス的なことをやっています。多分。。。Outputの練習で色々書いていきます。

今回はもうじきStep2（強制切断）のパッチが配布されるZerologonについて改めて調べた内容を記載します。色々記載していますが内容については私はまだ検証できていないため、諸々自己責任でお願いします。

 

 

◆ADの脆弱性（CVE-2020-1472: 通称Zerologon）について

Zerologonについては以下を参照させていただきました。イチから勉強できた！

https://www.lac.co.jp/lacwatch/alert/202

 

脆弱性のZerologonについてざっくりと認識したのは以下です。

 

その中で、対策としてMSが配布しているパッチの概要は以下です。

  • Step1のパッチは2020/8/11に配布済
  • Step1では通信断は発生せず、様子見のみ
  • Step1以降、ADDSサーバでイベントログが出るようになる（ID5827-5831の5つ）
  • Step2のパッチは2021/2/9に配布予定
  • Step2では「許可していた脆弱なNetlogon通信を強制的に遮断」

 

イベントログID5827-5831の概要は以下。

  • 5827: 脆弱なNetlogonプロトコルを利用したコンピュータ―オブジェクトを拒否
  • 5828: 脆弱なNetlogonプロトコルを利用したアカウントを拒否
  • 5829: 脆弱なNetlogonプロトコルを利用しているが許可した
  • 5830: 脆弱なNetlogonプロトコルを利用したコンピュータ―オブジェクトを許可
  • 5831: 脆弱なNetlogonプロトコルを利用したアカウントを許可

 

つまり・・・特に何もせずに2021/2/9に配布されるパッチをのほほんとADDSサーバに当てると、このイベントログ5829に該当する通信が軒並みブロックされることと理解しました。なるほど。

 

 

 

 

 

 

 

 

なるほど・・・。インパクト結構大きいな・・・？後述しますがサポートされたWindowsバージョンだけがある環境ならまだしも、しっかり管理出来ていないところとか野放しとか全然あるよね。きっと。

 

 

 

 

 

 

 

 

イベントログを調べてみたら私が取り扱っている環境でも結構ログ出てました。今後の対応の一案としては「準備期間のために一時的に穴をあける方法」や逆に先んじて「強制的にチャネルを有効」。どちらもレジストリの値を変える方法のようです。（未検証のため要検証）（HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Prameters\FullSecureChannelProtectionの値を変更）

 

support.microsoft.com

 

msrc-blog.microsoft.com

 

ただ、なかなかにインパクトのある脆弱性のため、仮に穴をあけて一時回避したとしても必ずスケジュールしていった方がいいですよねこれ。「そのうち～～」とかやってると忘れるヤツ。

 

なお、この影響を受ける端末については以下のように記載されています。サーバは言わずもがなドメコン全てです。

ドメイン メンバーサーバー、ドメイン クライアント

  • Active Directory に参加しているすべてのデバイスは、Secure RPC に対応する必要があります。
  • サポート対象内の Windows OSの場合は、既定で Secure RPCを利用可能です。追加の作業は必要ありません。ドメインコントローラが Secure RPC を利用するようになれば、ドメイン参加しているクライアントも自動的に Secure RPC を利用するようになります。サポート対象外の Windows を使用している場合、サポート対象の Windows にアップグレードします。
    • 非 Windows OS の場合は、Netlogon 実装が Secure RPC に対応するよう更新する必要があります。詳細は、提供元にご確認ください。

 

そもそもRPC接続ってどんな時に使ってるんだろう？私が確認したログだと、某社ストレージの認証で使ってるように見えた。勉強することたくさんですのう。それでは今回はこの辺りで。