Azure AD ハイブリッドAD joinとSSOの実装

■目的
AADjoinデバイス、HybridADjoinデバイスにてsSSO(シームレスSSO)を有効にする
※社外NWからの接続はAzureADユーザでログイン時のみsSSO有効化

■必要設定
ユーザプロビジョニング等の初期設定は実装済の想定

・AADC
 -デバイスオプションにてHybrid AD join有効化
 -同期オプションにてデバイスのをjoin有効化
 -ユーザサインインオプションにてSSO有効化
・GPO(端末のインターネットオプション設定でも可)
 -MSwebサイト、AAD関連サイトをイントラネット判定
 -イントラゾーンサイの自動ログオンを有効化
・FW設定
 -AADC→オンプレAD
 -AADC→AAD
 -クライアント→AAD
※プロキシ環境の場合は、イントラゾーン登録Webサイトのみ許可
 
■FWルール設定詳細
・AADC→オンプレAD
・AADC→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/reference-connect-ports

・クライアント→AAD
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-azure-ad-join

https://learn.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-connectivity

■イントラ判定
https://learn.microsoft.com/ja-jp/azure/active-directory/devices/howto-hybrid-join-downlevel

ここに記載のURLに加えてonmicrosoft等のSWGベンダー指定のバイパス除外ドメインも?
これらはプロキシバイパスされる

Azure ADの種類

■Azure ADとは
クラウドベースのディレクトリサービス
オンプレミスADとの連携が取れるのが特徴

■Azure ADを利用するケース
・Azure AD registered:AADにユーザが登録されている、端末はドメイン参加していない
・Azure AD joined:AADにユーザが登録されている、端末はドメイン参加している
・Hybrid Azure AD joined:AAD/オンプレADに共通のユーザが登録されている、端末は両方のドメインに参加している

■各ケースの特徴
・Azure AD registered
-○メリット
IDaaSとしてAzure AD使うだけなので、端末がドメイン参加する形ではなく端末側設定が不要
Windows以外のデバイスでも利用可能

-●デメリット
オンプレミス側のユーザ管理は別途AD等(ディレクトリサービス)が必要となる
※ユーザ情報自体はオンプレADからプロビジョニング可能

個人利用等でオンプレにADが必要ない場合はこれでも十分

・Azure AD joined
-○メリット
オンプレADを持たない企業でもディレクトリサービスとして利用できる
SSOができる(クラウドサービスのみ)

-●デメリット
インターネット接続がない環境では利用不可
オンプレAD等と併用する場合はIDが二重管理になる

オンプレにADが無くディレクトリサービスを利用したい場合はこの選択肢おあり

・Hybrid Azure AD joined
-○メリット
オンプレADのユーザでAzure ADの機能も使えるようになる
SSOができる(クラウドサービス/オンプレリソース両方)

-●デメリット
オンプレおよびAzure AD Connect + 各種設定が必要

環境構築の手間はあるが、利便性では圧倒的にこれ

AWS 知っ得ハンズオン 「はじめてのServerless」に参加してきた

IT技術系の研修はかなり高額なものが多いイメージだったのですが、
AWSが無料の研修を開催していることを知り参加してきました。

内容

・講義
サーバレスとは何か、そのメリットとデメリット
AWSのサービスの簡単な紹介(Lambda,IAM,Cognito,API Gateway)
AWSのサービスを使ってどのようにサーバレスを実現するか
・ハンズオン
用意されたシナリオをもとに、Lambda,API GateWay,DynamoDB,Cognitoを使用して
RESTインターフェースを構築するといったハンズオン

所感

ハンズオンの資料は非常に丁寧で分かりやすかったのですが、
私自身AWSの業務経験が無いこともあり、ハンズオンを進めていても
なぜこのサービスを使っているのかや、なぜこのサービスのこの設定を変更しているのか等が
分からないまま操作をしていたので作業ちっくな感じになってしまいました。

ただ、AWSを業務で触ることがない私にとって
課題に対してAWSのサービスで解決するという経験は有意義だったかな思います。

「さくらのVPS」から「AWS Lightsail」に移行した理由

はじめに

 現在このブログはWordpressを使っており
 AWSのLightsail上で動いております。

WordPressを始めた理由

 LPIC(LinuC)の学習をする時に、どうせなら1から
 LinuxでWebサーバの構築をしてみようと思い、
 今流行りのWordpress環境を構築してみました。

さくらのVPSを使っていた理由

構築マニュアルがかなりわかりやすい。

一番の理由はこれです。Linux経験があまり無かった私にとって「Linuxとは」や「VPSとは」から説明があるのは有り難かったので料金やサーバのスペックはあまり考慮しませんでした。ここでのLAMP環境構築経験は今でも業務で活かされています。
※ネコでもわかる講座 → さくらのページ

サーバスペックや料金を比較

※私が契約していた(している)プランです。

  さくらのVPS AWS Lightsail
料金(月額) 685円 約500円(4.5$弱)
メモリ 512mb 512mb
CPU 仮想1コア 仮想1コア
SSD 20GB 20GB

AWS Lightsailの方が年間で2000円程安くなりました。

AWS Lightsailに移行した理由

サーバを弄りすぎてWordpress環境を再構築する必要性が出てきた時に、2度目の環境構築は作業でしかないと思い他社のサービスも調べてみました。そして「Wordpressのインスタンスイメージがあるので構築手順が不要」「AWSを触ってみたかった」という理由からAWS Lightsailに移行しました。

AWS Lightsailのメリット

回線が高速

このサイトで実感出来るレベルでは無いかもしれないですが比較サイトの回線速度計測値によるとAWS Lightsailの方がさくらのVPSよりも、回線速度が上りも下りも大幅に上回っておりました。AWSの土台は強いですね。

EC2へのアップグレードが出来る

EC2へのアップグレードが簡単に出来るらしいのでちょっとやってみたい。ただLightsailのように固定料金ではなく従量課金制になるのでEDoS攻撃とかが恐い。

すぐにwordpressを始められる

構築手順が不要な事もあり、AWSアカウントの作成からWebサイト公開まで15分程でできてしまいびっくりしました(コマンドによる操作は無し)。Wordpressのデータ移行は「All-in-One WP Migration」というプラグインを使用することでかんたんに出来ます。

最後に

勢いでLightsailを始めましたが満足しています。
お金に余裕ができればEC2へ移行も検討したいと思います。