ども。こんばんは。
久々に動画です。
[W:ヴァイオレット・エヴァーガーデン]から「Violet Snow」 をアルトサックスで。
この曲めっちゃ好き。劇場版もみたいなー。
原曲フルバージョンはこちら。
BGMはこちからおかりました。
ではでは。またの機会に。
ども。こんばんは。
久々に動画です。
[W:ヴァイオレット・エヴァーガーデン]から「Violet Snow」 をアルトサックスで。
この曲めっちゃ好き。劇場版もみたいなー。
原曲フルバージョンはこちら。
BGMはこちからおかりました。
ではでは。またの機会に。
ども。こんばんは。
Azure ADでは、パスワードを入力せずにサインイン(ログイン)できる「パスワードレス」認証に対応しています。
まだプレビューっぽいですが、Microsoft Authenticatorを利用してパスワードレスができそうだったのでやってみました。
以下参考ドキュメントです。
Azure Active Directory のパスワードレス認証オプション
Azure Active Directory でパスワードレス認証のデプロイを計画する
Microsoft Authenticator アプリを使用したパスワードなしのサインインを有効にする (プレビュー)
まずは、多要素認証の検証方法でプッシュ通知が許可されていないとだめらしい。。。がどこの設定かわからない・・・
[Azure AD]->[セキュリティ]->[MFA]の「追加のクラウドベースの MFA 設定」かな?
とりあえず何もしなくても、Microsoft Authenticatorアプリ上で、「パスワードレスが有効」となっているので、使えるものと信じて進めます。
続いて、Azure ADのセキュリティから認証方法ポリシーを設定します。
有効にするかつ有効にするユーザを選択します。
※おいらは一旦1ユーザのみテストしてからすべてのユーザに変更しました。
設定はこれだけ!
これで時間ログイン時、ID入力後、パスワード入力の画面で「代わりにアプリを使用する」というリンクが出るようになります。
あとは、これをアプリで同じ番号を選ぶだけ。
とてもかんたんです。(アプリの写真は後で撮影したので番号が一致していませんが。。)
とても簡単にパスワードレス認証が実装できました。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
今回は、FortiGateのSSL-VPN接続(Webモード)をAzure ADを使ったSSO(シングル・サインオン)で実装します。
基本このあたりのチュートリアル通りです。
チュートリアル:Azure Active Directory シングル サインオン (SSO) と FortiGate SSL VPN の統合
Configuring SAML SSO login for SSL VPN web mode with Azure AD acting as SAML IdP
先にハマった?ポイントを・・・。
FortiGate SSL-VPNのSSOはSP-Initiatedのため、FortiGate側からフローを開始することで認証が行われます。(前回行ったAWSはIdp-Initiatedなため、Idp(Azure AD)からフローを開始します。)
完成形がこちらの画面ですが、「Single Sign-On」のボタンを表示させるためには、SAMLの設定をするだけではだめで、実際に「SSL-VPN」インターフェースから、LAN側等へのポリシーを設定し、そのポリシーの送信元にSAMLユーザを含むグループを指定する必要があります。。。
これを知らなくて、Single Sign-Onボタンを表示させるのにめちゃくちゃ時間かかりましたが、ここさえ把握しておけば設定はかんたんです。
まずは、エンタープライズアプリケーションにFortiGate SSL VPNを追加します。
※FortinetのドキュメントだとNon Galleryになっていますが、今は存在するようです。
アプリケーションにユーザを割り当てます。
シングルサインオンの設定からSAMLを選択します。
例にのっとって、識別子(エンティティID)、応答URL、サイオンURL、ログアウトURLを設定します。
次に、「ユーザー属性とクレーム 」を設定します。
※ここで指定した属性をFortiGateが受け取ってユーザ名などを処理するイメージです。デフォルトで「name」 があるのでこれでユーザ名使えるのかなと思ったのですがうまく行かなかったので、下記のようにusernameを追加しています。この”username”はFortiGate側にも設定します。
冒頭で記載したMicrosoftのチュートリアルでは、グループについても追加していますが、グループの追加はグレーアウトして押せなくかったので、やっていません・・・。
続いて、SAML署名証明書から、証明書(Base64)をダウンロードします。
ここからFortiGateの設定をします。
今回FortiGateはForiGate 60E、FortiOSは6.2.5で、VDOM環境です。
まずは、先程ダウンロードした証明書をインポートします。
証明書(Certificates)のGUIが標準では表示されていないので、まずは、そこから設定します。
Global VDOMの[System]->[Feature Visibility]から、Certificatesを有効します。
対象のVDOMに移動して、証明書をImportします。
インポートした証明書の名前を覚えておきます。
※画面では、「REMOTE_Cert_1」 です。
続いてコマンドラインで以下の設定を導入します。
idp-entity-id 、idp-single-sign-on-url、idp-single-logout-url は、Azure ADの画面からコピペします。
なお、idp-single-logout-url には「?(クエッションマーク、はてなマーク)」が入っています。
FortiGateにCLIで?を入力する場合は「Ctrl+v」のあとに「?」を入力すれば、コマンド候補の代わりに「?」が入力できます。
「set user-name “username”」のusernameは、Azure ADのユーザ属性に自分で追加した名前です。
config user saml
edit "azure"
set entity-id "https://[FortiGateのFQDN]/remote/saml/metadata"
set single-sign-on-url "[FortiGateのFQDN]/remote/saml/login"
set single-logout-url "https://[FortiGateのFQDN]/remote/saml/logout"
set idp-entity-id "https://sts.windows.net/xxxx/"
set idp-single-sign-on-url "https://login.microsoftonline.com/xxxx/saml2"
set idp-single-logout-url "https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0"
set idp-cert "REMOTE_Cert_1"
set user-name "username"
set group-name "group"
next
end
作成したユーザをグループに入れます。
※グループに突っ込まないと、そもそもポリシーで利用できません。
Microsoftのチュートリアルでは、さらにmatchをつかって、Group-IDで絞り込んでいますが、今回はそこまでやっていません。
config user group
edit "SSLVPN_from_AzureAD"
set member "azure"
next
end
最後にポリシーに適用します。
※ポリシーに設定して、初めてログイン画面にSingle Sing-onボタンが表示されます。
今回はSP-Initiatedなので、FortiGateの画面から行きます。
おお。できた。
ちなみに、パーソナルブックマークとか作ってもちゃんと保存されます。
設定は、ユーザ名「[email protected]#SAML設定名」としてconfigに保存されるようです。
あと、FortiClientもSAML Logonというのができそうなのですが、どうもこれは、有償版?か6.4の機能っぽい?
こんなふうにできるはず?
今回はSSL-VPNに関してSSOを設定しましたが、管理画面もできるようなので、今後は管理画面もSSO対応を検討したいと思います。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
厳密には、Azure AD Premiumの機能ではないのですが、せっかくAzure ADを利用しており、条件付きアクセスも設定したので、AWSコンソール(AWS Console)へのログインをSAMLを使ったSSOで実装します。
基本的に以下のドキュメントに従って進めていけばOKです。
若干AWSの画面が変わっているので手順をご紹介します。
チュートリアル:Azure Active Directory シングル サインオン (SSO) とアマゾン ウェブ サービス (AWS) の統合
まずは、Azure ADのエンタープライズアプリケーションにAmazon Web Services(AWS)を追加します。
なんか2個ありますが、Amazon Web Servicesの方です。
数秒で追加は完了します。
シングルサインオンの設定に移動し、SAMLを選択します。
なんか聞かれたのでとりあえず「はい」を押しておきます。
チュートリアル通りだと次に証明書を作りますが、チュートリアルと違ってすでに証明書が存在していました・・・が、一応手順どおりに「新しい証明書」をクリックして作ります。
出来上がったらアクティブ化します。
「フェデレーション証明書XML(フェデレーションメタデータXML)」をダウンロードします。
いきなりテストする?って聞かれますが、このタイミングではAWS側の準備が整ってないので失敗するはず・・・ですのでテストはしません。
ここから、AWS Console側の設定を行います。
IAMのIDプロバイダの設定に移動します。
「IDプロバイダを作成」をクリックし、SAMLを選択します。
プロバイダ名は適当に、メタデータドキュメントにはダウンロード済みのフェデレーションメタデータXMLをアップロードします。
できました。
IAMロールを割り当てろって出てますが、次の手順で適用します。
IAMに新しいロールを作成します。
画面が見切れてしまっていますが、「信頼されたエンティティの種類」にはSAML2.0を、SAMLプロバイダーには、先程作成したAzure ADのものを選択します。
「プログラムによるアクセスとAWSマネジメントコンソールによるアクセスを許可する」を選択しておきます。
アクセス権限は、必要な内容によって決定します。
今回は管理者アクセスをしたいので、AdministratorAccessにしています。
この辺って実際の運用ではどうするんでしょうね。。
エンタープライズアプリケーションを複数登録して割り当てるユーザごとにロールも変える感じ何でしょうか。
このあたりの細かいアクセス制御は勉強不足です。
タグは省略します。
これでロールは完成です。
続いて、Azure ADがロールをフェッチするためのポリシーを作成します。ここ正直ちゃんと理解できてないです。。のでとりあえず手順どおりにやります。
IAMでポリシーを作成して以下のJSONを貼り付けます。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListRoles"
],
"Resource": "*"
}
]
}
保存します。
つづいて、今作ったポリシーを利用できるユーザを作成します。
ポリシーには先程作成したものをアタッチします。
タグは省略します。
これでロールフェッチ用のアカウントの作成は完了です。
次のページで、APIキーとシークレットが表示されるので、ダウンロードするなどして控えておきます。
プロビジョニングの設定をします。
Amazon Web Services(AWS)アプリケーションのプロビジョニングに移動し、作業を開始します。
プロビジョニングを自動にし、AWS側の設定で作成したロールフェッチ用のユーザのAPIキーとシークレットを入力し、テスト接続します。
右上にテスト接続が問題ないことを示すメッセージが表示されることを確認します。
忘れずにプロビジョニング状態をオンにします。
これで準備は完了です。
アプリケーションにユーザを追加(割り当て)します。
テストします。
いけたー!ちゃんとフェデレーションログインになっています。
ざっと見たところ、EC2などの管理もちゃんとできそうです。
次回以降のアクセスは、Office 365のポータルからどうぞ。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
前回までに、Intuneに各種デバイスの登録を行いました。
今回は、Azure AD Premiumの条件付きアクセスを設定して、サインイン時に2要素認証(MFA)を設定します。
まず、アカウントへのMFA(Microsoft Authenticatorや電話認証等)の設定は以下から行います。
手順は省略しますが、いい感じに、認証アプリ(Microsoft Authenticator)を設定しました。
QRコードをアプリに取りむ感じです。
今回の条件付きアクセスは、以下のように設定しました。
まずは、グローバルIPアドレスをネームドロケーションに登録します。
※標準で「MFA信頼済みIP」という設定がありますが、今回はあえて新しく作ってみました。
今回設定した条件付きアクセスは以下のようなものです。
※条件付きアクセスの設定時は、警告の通り自分が追い出されない(条件に引っかかってサインインできなくならない)ように自分は除外するとかテスト用アカウントで試すとか、「レポート専用」にして様子を見るなど、準備が必要です。以下の画面は、テストが終わった後、対象を「すべてのユーザ」に広げています。
上記設定で、自分の要件は満たせており、レガシ認証にはMFAは適用されないし、テザリングなどで自宅以外のIPアドレスから接続するとMFAが有効になります。
・・・が、Intuneでデバイスが準拠しているという条件がいまいち反応してくれません。
以下、マネージドGoogleプレイストアから配信したAndroid用Edgeでサインインしたときのログです。
これは割といい感じなんですが、macOSで同じようなことをしてもデバイス準拠が「いいえ」になってしまいます。。。
そもそも、Google Chromeで、IntuneのステータスをAzure ADに連携するには、Windows 10 Accounntsという拡張機能が必要なようです。
うーん、インストールしてるんですけどねえ。あと、iPadのTeamsアプリなんかでログインしてもデバイス準拠は「いいえ」になってしまう模様。
まいった。。一旦お手上げですが、とりあえず最低限やりたかったMFAは実装できました。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
前回の続きです。
今回はiPadとmacOS XをIntuneに登録していきます。
iPadOSは14.2、macOSは導入時はCatalinaその後、Big Surにバージョンアップしていますが特に問題ありません。
※公式にもBig Surはサポートされています。
まずは、iPad、macOSをIntuneに登録するための共通の手順である「Apple MDM プッシュ通知証明書」を入手します。
Appleへのアクセス許可に同意してCSRをダウンロードします。
以降はAppleのサイトで操作します。
※Apple IDでサインイン済みです。
CSRをアップロードします。
署名が終わったらダウンロードします。
エンドポイント管理センターに戻って、署名時に利用したAppleIDを入力、ダウンロードした署名済みの証明書をアップロードします。
うまくできれば、こんな感じになります。
ここから、macOSをIntuneに登録します。
まず、以下のURLからポータルアプリのpkgをダウンロードします。App Storeではないようですね。
https://go.microsoft.com/fwlink/?linkid=853070
いい感じにインストールします。
アプリを起動します。
すでに、Office365を利用しているためかアカウントが見つかりました。
サインインして登録を開始します。
プロファイルをダウンロードします。
これで完了です。
続いてIPadをIntuneに登録します。
※ここでもMDMプッシュ通知証明書が必要なので、冒頭の手順が完了している必要があります。
まずは、App SotreからIntune ポータルサイトをインストールします。
iPadでもアカントが見つかりました。
サインインしたら設定を開始します。
管理プロファイルをダウンロードします。
手順に従って管理プロファイルをインストールします。
これで完了です。
これで我が家のだいたいのデバイスは登録完了です。
こんな感じになりました。
次回はいよいよAzure AD Premiumの機能である条件付きアクセスを設定してIDを脅威から保護します。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
前回の続きです。
今回はAndroidをIntuneに登録していきます。
今回はHTV33(Android 9.0)とSHG01(Android 10.0)で試していますが、主にAndroid 10について紹介します。
まず、Androidについては、いくつか管理方法があるようです。
おいらは古いタイプの人間なので、てっきりデバイス管理者にIntuneを登録してフル管理だと思ってましたが、最近の流行りはAndroid Enterpriseを使って、プロファイルとして仕事用を分けるようですね。
※Playストアやアプリが全部別で管理できるようになります。
まずは、マネージドGoogle Playに接続してAndroid Enterpriseを利用できるようにします。
エンドポイント管理センターの「デバイス」->「Android」→「Android 登録」から接続します。
いい感じに登録します。
準備完了。
準備ができたので、AndroidをIntuneに登録していきます。
Playストアから「Microsoft Intune ポータルサイト」をインストールします。
サインインしてセットアップをすすめます
仕事用プロファイルとやらができます。
あとは何もしなくてもおわるっぽい。
ほー。おわるとこんな感じに仕事用にアプリが別れます。
※機種依存なのか、Android 9.0のHTCU11(HTV33)ではこのような別れた表示にはなりませんでした。
しかし、名前が気にいらねぇ。
「ユーザ名_AndroidForWork_11/14/2020_1:03 PM」みたいな名前になっててしまう。Intuneポータルアプリから名前を変更しても、エンドポイント管理センター上の表示は変わらない模様。。。まぁいいか。。。
これで登録は終わりです。
試しにアプリを配布してみます。
エンドポイント管理センターの「アプリ」->「Android」->「Android 個のアプリ」で、「追加」します。
Playストアを検索して追加します。
追加後「割り当て」を行う必要があります。割り当てにはいくつか種類があり、必須とする、インストール許可する、禁止するなどがあるようです。
割とすぐ反映されるので、Android側の仕事用のPlayストアでインストール可能になりました。
以上で完了です。
次回はiPadとmacOS XをIntuneに登録したいと思います。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
前回の続きです。
早速Windows 10にIntuneを展開していきます。
大規模環境ならAutoPilotで自動的に展開したり、GPOで配ったりとかあると思いますが、今回は手動で登録します。
なお、一応、今後追加されるWindows 10がAzure ADにサインインした場合に自動的にIntuneに登録されるようにAzure ADのMDMを構成します。
Azure ADの「モビリティ (MDM および MAM)」から「Microsoft Intune」を選択して以下の画面に移動します。
それぞれ割り当てたいユーザやグループを指定しておきます。
これで、新しくサインインすると自動でIntuneにも登録される・・・はずです。
続いてDNSにIntuneのCNAMEを登録します。
以下のドキュメントを参考に、EnterpriseEnrollmentとEnterpriseRegistrationを自分のDNSサーバにCNAMEを追加します。
これをやっておかないと、「入力されたユーザ名と一致する管理エンドポイントを自動検出できませんでした。ユーザ名を確認して、やり直してください。管理エンドポイントのURLがわかっている場合は、それを入力してください。」というエラーになります。
一応テストもしておきます。
準備ができたので、Windows 10にIntuneをインストールします。
まず、ストアから「ポータル サイト」を入手します。
続いてデバイスを職場に接続します。
これでおわり。
これで、Intuneにデバイスが登録されました。
次回はAndridをIntuneに登録したいと思います。
【バックナンバー】
ではでは。またの機会に。
ども。こんばんは。
最近のセキュリティ界隈では「ゼロトラスト(セロトラストネットワーク)」なるキーワードが盛んですね。
これまでのようにファイアウォール等の境界で守られたネットワークを信用しない、という考え方のようですね。
例えば、カフェなどの公衆Wi-Fiにつなごうが、社内LANにつなごうがどちらも同じ、何も信用しないという考え方です。
いろいろな構成要素がありますが、自宅でも気軽に試せる部分として
・IDセキュリティ(IDを安全にする)
・デバイス管理(MDM)
からやってみたいと思います。
※あとは、SASE(Secure Access Service Edge)とかEDR(Endpoint Detection & Response)があると、どこでも同じポリシーのセキュリティを、境界ではなくエンドポイント上で不審な動きを監視、といったよりゼロトラストな感じになると思います。
さて、今我が家ではMicrosoft 365 Business Basicを契約しています。
これに、Enterprise Mobility + Security E3を追加して、ID保護としてのAzure AD Premium P1、MDMとして、Microsoft Intuneを使えるようにします。
Microsoft 365 Business Premium(¥26,160/年)にすべきかも悩んだのですが、Microsoft 365 Business Basic(¥6,480/年)+EMS E3(¥11,520/年)にしました。Business Premiumよりも、¥8,000くらい安くなりました。この差額は、デスクトップアプリ版のOffice分ですかね。最近IPadばっかりでWindowsをあまり使ってないのでデスクトップ版Officeアプリはいいかなーという感じです。
ちなみにEMS E3は「Enterprise Mobility Suite Direct」に名前が変わった(変わる?)ようです。
サクッと買います。購入はMicrosoft 365管理センターの「サービスを購入する」から。
無事買えました。
続いてライセンスを割り当てます。
無事にAzure AD上のライセンス画面でも割当が行われました。
知らない間に、Azure ADのライセンスもPremium P1になっていました。
次回からは、各デバイスをIntuneに登録していきたいと思います。
ではでは。またの機会に。
ども。こんばんは。
前回の続きです。
M5Stackの開発には、大きく、
Arduino IDE
M5Cloud
UIFlow
が、あるようでそれぞれファームウェアを入れ替えることで開発環境も変わります。
Python(MicroPython)での開発だと、M5CloudかUIFlowですが、M5Cloudはあんまりメンテナンスされていないらしい?という情報もあり、最新のUIFlowを導入します。
なお、UIFlowは完全ブラウザベースのものとDesktop版がありますが、今回は折角なので完全ブラウザベースのもので挑戦します。
いろんな記事を見ていると、以前はesptoolで書き込むのが主流だったようですが、現在はM5Burnerを使うようです。
M5Burnerは公式サイトからダウンロードできます。
https://m5stack.com/pages/download
インストーラはないのですが、重要な注意事項があります。
必ず、「アプリケーション」にappを移動してください。そうしないと、起動するものの、ファームウェアのリストが全然出てきません。地味にはまりました。。ちゃんと同梱のテキストファイルに書いてます。
【注意書き】

あと、やっぱりブロックされるのでセキュリティとプライバシーから解除する必要があります。
起動するとこんな感じです。
いろんなファームウェアやサンプルが並んでますね。
初期のエヴァ風のものは、「Core2FactoryTest」のようです。
とりあえず「UIFlow_Core2」をDownloadして、Burnします。
このとき最新は「v1.6.5.1-core2」でした。
なるほど。内部的にはesptoolが動いているんですね。
ファームウェアの書き込みが終わるとリセットされて、こんな感じで立ち上がります。
Setupをタップして、Config WI-Fi by WebのStartをします。
すると、こんな画面になります。
指定されたSSIDにPCやスマホを接続ます(パスワードはかかっていません)
次に「http://192.168.4.1」にアクセスします。
以下のような画面が見えるので、アクセスポイントを選択して、パスワードを入力したら「Configure」をクリックします。
URLにパスワードがダダ漏れorz
再起動してもちゃんとアクセスポイントの設定は残っています。
で、真ん中のFlowを押すとモードを聞かれるのでWI-FIを選びます。
※メニューの移動?が毎回リセットしないとだめっぽくてちょっと鬱陶しいかも。
Wi-Fiに接続中。
無事に繋がると、APIキーが表示されます。
ここまででM5Stack側の準備は完了です。
なお、m5stack社のサーバとは、mqttを使って通信しているようです。途中にFW等がある場合は、1883/tcpポート宛の通信を許可してあげてください。
https://flow.m5stack.com/にアクセスします。
Core 2はBetaでしか対応していないようなのでBetaを選択します。
設定画面が勝手に出てくる(でなければ右側メニューから)ので、API Keyには、M5Stack上に表示されているキーを入力し、DeviceはM5Stack Core 2っぽいのを選択します。
テストプログラムを適当に書きます。
ちゃんとPythonコードも見ることができます。
できたら、右上の▷をクリックして実行します。
いけた!
時計がめちゃくちゃずれてるっぽいので以下のようなプログラムを実行して時計をあわせておきました。
UIFlowはMicroPythonが動くファームウェアですが、シリアル接続でかんたんなPythonコマンドを実行することもできます。
TeraTermなどでつながると思いますが、うちはmacなのでscreenコマンドを使います。
こんな感じ。
screen /dev/tty.SLAB_USBtoUART 115200
※スクリーンコマンドを抜けるには、Ctrl+A+Kのあとにy。
何回かエンターキーを押すとプロンプトになるので、適当に実行できます。
【バックナンバー】
ではでは。またの機会に。