「クラウド」カテゴリーアーカイブ

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 6 – AWSコンソールへのログインをSSOにする

ども。こんばんは。

厳密には、Azure AD Premiumの機能ではないのですが、せっかくAzure ADを利用しており、条件付きアクセスも設定したので、AWSコンソール(AWS Console)へのログインをSAMLを使ったSSOで実装します。

基本的に以下のドキュメントに従って進めていけばOKです。
若干AWSの画面が変わっているので手順をご紹介します。

チュートリアル:Azure Active Directory シングル サインオン (SSO) とアマゾン ウェブ サービス (AWS) の統合

■Azure ADの設定(1)

まずは、Azure ADのエンタープライズアプリケーションにAmazon Web Services(AWS)を追加します。

なんか2個ありますが、Amazon Web Servicesの方です。

数秒で追加は完了します。

シングルサインオンの設定に移動し、SAMLを選択します。

なんか聞かれたのでとりあえず「はい」を押しておきます。

チュートリアル通りだと次に証明書を作りますが、チュートリアルと違ってすでに証明書が存在していました・・・が、一応手順どおりに「新しい証明書」をクリックして作ります。

出来上がったらアクティブ化します。

「フェデレーション証明書XML(フェデレーションメタデータXML)」をダウンロードします。

いきなりテストする?って聞かれますが、このタイミングではAWS側の準備が整ってないので失敗するはず・・・ですのでテストはしません。

■AWS Consoleの設定

ここから、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キーとシークレットが表示されるので、ダウンロードするなどして控えておきます。

■Azure AD側の設定(2)

プロビジョニングの設定をします。

Amazon Web Services(AWS)アプリケーションのプロビジョニングに移動し、作業を開始します。

プロビジョニングを自動にし、AWS側の設定で作成したロールフェッチ用のユーザのAPIキーとシークレットを入力し、テスト接続します。
右上にテスト接続が問題ないことを示すメッセージが表示されることを確認します。

忘れずにプロビジョニング状態をオンにします。

これで準備は完了です。

■アプリケーションへのユーザ追加とテスト

アプリケーションにユーザを追加(割り当て)します。

テストします。

いけたー!ちゃんとフェデレーションログインになっています。
ざっと見たところ、EC2などの管理もちゃんとできそうです。

次回以降のアクセスは、Office 365のポータルからどうぞ。

【バックナンバー】

ではでは。またの機会に。

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 5 – 条件付きアクセスでIDを保護する

ども。こんばんは。

 前回までに、Intuneに各種デバイスの登録を行いました。

今回は、Azure AD Premiumの条件付きアクセスを設定して、サインイン時に2要素認証(MFA)を設定します。

まず、アカウントへのMFA(Microsoft Authenticatorや電話認証等)の設定は以下から行います。

https://aka.ms/mfasetup

手順は省略しますが、いい感じに、認証アプリ(Microsoft Authenticator)を設定しました。
QRコードをアプリに取りむ感じです。

今回の条件付きアクセスは、以下のように設定しました。

  • 自宅のグローバルIPアドレスはMFAを必要としない
  • レガシ認証のアプリについては、条件付きアクセスを適用しない
    ※AndroidネイティブなExchange Active Syncを利用しているため。
    本来はOutlookアプリに切り替えるべきですが、なんやかんやでまだまだネイティブアプリのほうが便利なことがあるので、ここは断腸の思いで除外します。
  • Intuneでデバイスが準拠済みのものはMFAを必要としない

まずは、グローバルIPアドレスをネームドロケーションに登録します。
※標準で「MFA信頼済みIP」という設定がありますが、今回はあえて新しく作ってみました。

今回設定した条件付きアクセスは以下のようなものです。
※条件付きアクセスの設定時は、警告の通り自分が追い出されない(条件に引っかかってサインインできなくならない)ように自分は除外するとかテスト用アカウントで試すとか、「レポート専用」にして様子を見るなど、準備が必要です。以下の画面は、テストが終わった後、対象を「すべてのユーザ」に広げています。

上記設定で、自分の要件は満たせており、レガシ認証にはMFAは適用されないし、テザリングなどで自宅以外のIPアドレスから接続するとMFAが有効になります。

・・・が、Intuneでデバイスが準拠しているという条件がいまいち反応してくれません。

以下、マネージドGoogleプレイストアから配信したAndroid用Edgeでサインインしたときのログです。

これは割といい感じなんですが、macOSで同じようなことをしてもデバイス準拠が「いいえ」になってしまいます。。。

そもそも、Google Chromeで、IntuneのステータスをAzure ADに連携するには、Windows 10 Accounntsという拡張機能が必要なようです。

うーん、インストールしてるんですけどねえ。あと、iPadのTeamsアプリなんかでログインしてもデバイス準拠は「いいえ」になってしまう模様。

まいった。。一旦お手上げですが、とりあえず最低限やりたかったMFAは実装できました。

【バックナンバー】

ではでは。またの機会に。

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 4 – iPadとmacOSをIntuneに登録する

ども。こんばんは。

 前回の続きです。

今回は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に登録する

ここから、macOSをIntuneに登録します。

まず、以下のURLからポータルアプリのpkgをダウンロードします。App Storeではないようですね。

https://go.microsoft.com/fwlink/?linkid=853070

いい感じにインストールします。

アプリを起動します。

すでに、Office365を利用しているためかアカウントが見つかりました。

サインインして登録を開始します。

プロファイルをダウンロードします。

これで完了です。

■iPadをIntuneに登録する

続いてIPadをIntuneに登録します。
※ここでもMDMプッシュ通知証明書が必要なので、冒頭の手順が完了している必要があります。

まずは、App SotreからIntune ポータルサイトをインストールします。

iPadでもアカントが見つかりました。

サインインしたら設定を開始します。

管理プロファイルをダウンロードします。

手順に従って管理プロファイルをインストールします。

これで完了です。

 

これで我が家のだいたいのデバイスは登録完了です。

こんな感じになりました。

次回はいよいよAzure AD Premiumの機能である条件付きアクセスを設定してIDを脅威から保護します。

【バックナンバー】

ではでは。またの機会に。

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 3 – AndroidをIntuneに登録する

ども。こんばんは。

 前回の続きです。

今回は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に登録したいと思います。

 

【バックナンバー】

ではでは。またの機会に。

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 2 – Windows 10を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を追加します。

Windows デバイスの登録をセットアップする

これをやっておかないと、「入力されたユーザ名と一致する管理エンドポイントを自動検出できませんでした。ユーザ名を確認して、やり直してください。管理エンドポイントのURLがわかっている場合は、それを入力してください。」というエラーになります。

一応テストもしておきます。

 

準備ができたので、Windows 10にIntuneをインストールします。

まず、ストアから「ポータル サイト」を入手します。

続いてデバイスを職場に接続します。

これでおわり。

これで、Intuneにデバイスが登録されました。
次回はAndridをIntuneに登録したいと思います。

【バックナンバー】

ではでは。またの機会に。

Enterprise Mobility + Security E3ではじめるゼロトラスト入門 – 1 – 購入編

ども。こんばんは。

最近のセキュリティ界隈では「ゼロトラスト(セロトラストネットワーク)」なるキーワードが盛んですね。

これまでのようにファイアウォール等の境界で守られたネットワークを信用しない、という考え方のようですね。
例えば、カフェなどの公衆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に登録していきたいと思います。

ではでは。またの機会に。

無料のOneNoteからOffice 365への移行

ども。こんばんは。

あんまり参考になりませんがちょっと苦労したので書いておきます。

やりたいこと

  • 無料のOneNoteからOffice 365に移行したい
  • Office 365はデスクトップアプリなし(Office 365 Business EssentialsやE1)

デスクトップアプリのある、Office 365 Business Premiumでは、以下のサイトの方法が参考になります。

Office365 BusinessへOneNote移行が難しすぎる件 | しきろぐ

この通りにやろうとしても、OneNote2016では、Offiece 365のOneDriveにサインインできないため、うまくいきません。

以下のようなエラーになります。そりゃぁまあライセンス買ってないししょうがないけど。。。無料でも使えるのにちょっとこれは悲しい。

このノートブックを使うには、有効な Office 365 サブスクリプションのライセンス認証を行う必要があります

強引にエクスポートしたonepkgファイルを開こうとしても、以下のようなエラーになります。

現在、OneDrive では、ノートブックの作成のみ可能です。ノートブクのその他のオプションを利用するには、Office 365 サブスクリプションのライセンス認証を行ってください。

結論、手でコピーするしか無いようです。

一番やりやすかったのは、

  1. OneNote 2016で無料版OneNoteを開く
  2. ストア版のOneNoteアプリ(UWP)でOffice 365のOneNoteを開く
  3. OneNote 2016でページをコピーしてOneNoteに貼り付ける

セクションをまるごと移せないので最低限必要なページだけ手で移行しました。

まぁ、やろうと思えばOffice 365 Business Premiumを評価版で一時的に使うっていう方法もありかと思います。

ではでは。またの機会に。

 

 

令和になったことだしクラウドへ移行する – 15 – Azure AD Connectを強制停止する

ども。こんにちは。

先日ADをぶっ壊してしまい、再構築しましたが、AD Connectはインストールしておらず、以前のオンプレEchangeからExchange online(Office 365)へ移行した際に設定したAzure AD Connectがずっと同期エラーの状態でした。

また、こんな感じでソースが「Windows Server AD」となっているユーザは、Azure AD上で編集や削除ができません。
不要なユーザはAzure AD上でサインインをブロックに設定はしていましたが、いい加減適当な名前のユーザも結構います・・・。

もう二度とオンプレADと同期はしないと覚悟を決めたので、同期を強制的に解除します。

やり方としてはPowerShellで

 Set-MsolDirSyncEnabled -EnableDirSync $false

を叩くだけです。

参考:Office 365 のディレクトリ同期を無効にする

上記のページにも書いていますが、これは最終手段というかもう二度と同期しないくらいの覚悟?のコマンドのようですね。

PowerShell を使用して、ディレクトリ同期を無効にすることができます。 ただし、トラブルシューティング手順としてディレクトリ同期を無効にすることはお勧めしません。 ディレクトリ同期のトラブルシューティングに関してサポートが必要な場合は、「 Office 365 のディレクトリ同期の問題を解決する」の記事を参照してください。

ハマったのは、反映されるまでの時間です。

オンプレミス Active Directory Domain Services から Azure AD に同期したオブジェクトを管理、削除できない

注: アカウントが無効化されるまで、72 時間ほどかかる場合があります。処理に要する時間は、Office 365 サブスクリプション アカウントにあるオブジェクト数により異なります。

結局、ソースがAzure Active Directoryに変わるまで36時間ほどかかりました。

これで無事Azure AD上から削除できます。

で、やらかしたことは・・・

ユーザを消しすぎた

です・・。

オンプレExchangeからOffice 365に移行したときに、いくつかのメールボックスをユーザメールボックスから共有メールボックスに変換しています(ライセンス節約のため)が、変換前のユーザを勢いで消してしまい、一瞬共有メールボックスがみえなくなりました。。。。

すぐに削除済みユーザから戻したので復活しましたが・・・。

これ忘れそうだな。。。

以前ここで読んでたのに忘れてました。

ユーザー メールボックスを共有メールボックスに変換する

古いユーザー アカウントは削除しないでください。 それは共有メールボックスの固定に必要です。 ユーザー アカウントを既に削除している場合、「削除済みユーザーのメールボックスを変換する」 (削除されたユーザーのメールボックスを変換する) を参照してください。 

またやらかしそう・・・

ではでは。またの機会に。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)

ども。こんばんは。

以前も記事にしたサブディレクトリでkusanagiを動かす場合に修正が必要な/usr/lib/kusanagi/lib/functions.shですが、kusanagi-8.4.3-3くらいからいじる箇所が増えたみたいです。

これをしないと一部kusanagiコマンドが「WordPress がインストールされていません。何もしません」という表示になります。

以下、8.4.4-2対応版です。

168,169c168,169
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1718c1718
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return

> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-config.php ] || [ -e $KUSANAGI_DIR/wp-config.php ] || return
1785,1786c1785,1786
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1788c1788
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

動作okっぽいですが、修正は自己責任でお願いします。

# kusanagi bcache
bcache は有効です
完了しました。

# kusanagi update plugin
KUSANAGI プラグインは、既に最新バージョンです。
KUSANAGI 設定プラグインは、すでに最新バージョンです。
完了しました。

【バックナンバー】

ではでは。またの機会に。

令和になったことだしクラウドへ移行する – 13 – KUSANAGIのバージョンアップとfunctions.sh

—-
2019/11/02追記
8.4.3-3 あたりから修正箇所が増えているようです。

令和になったことだしクラウドへ移行する – 14 – KUSANAGIのバージョンアップとfunctions.sh(2)
—-

ども。こんばんは。

このブログはkusanagiで動いています。

8.4.3-1が出ていたので更新しました。

で、見ての通りサブディレクトリにkusanagiをインストールしています。

なので、kusanagiのバージョンアップとかをしたときにちょっとした設定の書き換えをしないとこうなります。

# kusanagi update plugin
プラグインファイルが存在ません。何もしません。
完了しました。

# kusanagi bcache
WordPress がインストールされていません。何もしません
完了しました。

という感じになります。

で、以下のファイルを修正。

/usr/lib/kusanagi/lib/functions.sh

# diff functions.sh.bak.20190728 functions.sh
166,167c166,167
< elif [ -e $TARGET_DIR/DocumentRoot/wp-config.php ]; then
< WPCONFIG=”$TARGET_DIR/DocumentRoot/wp-config.php”

> elif [ -e $TARGET_DIR/DocumentRoot/blog/wp-config.php ]; then
> WPCONFIG=”$TARGET_DIR/DocumentRoot/blog/wp-config.php”
1761,1762c1761,1762
< if [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/wp-kusanagi.php ] && \
< [ -e $KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then

> if [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/wp-kusanagi.php ] && \
> [ -e $KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins/kusanagi-wp-configure.php ]; then
1764c1764
< local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/wp-content/mu-plugins”

> local MU_PLUGINS_DIR=”$KUSANAGI_DIR/DocumentRoot/blog/wp-content/mu-plugins”

これで動くようになります。

【バックナンバー】

ではでは。またの機会に。