トップ > Azure

Azure AD テナントを削除する際にエンタープライズ アプリケーションが残って削除できない時の対策

Azure Azure Active Directory

検証で使って不要になったAzure AD テナントを削除する時にはまったので備忘録的に。

全体的にはAzure AD テナントから削除に進むとチェックが走り、必要な操作に沿って対応していくと状態が全てグリーンになります。
が、色々外部連携やAzure DevOps等を利用していくと削除のできないものが出てきます。
削除時に出るエラーは以下のような状態ですね。

f:id:tsukatoh:20200709014953p:plain

一旦以下の手順で削除していき、これで解決できるならOKです。

docs.microsoft.com

しかしながら、Azure DevOps等はこの手順では消えてくれませんでした。
他システムや他テナントと連携するようなアプリケーションは削除ロックがかかるようで、普通には消えません。
残っている状態が以下のような状態ですね。

f:id:tsukatoh:20200709014922p:plain

そのような場合は以下の手順にて削除します。
事前に用意するものはWindows PowerShellへ以下モジュールのインストールをします。

事前準備

管理者権限でWindows PowerShellプロンプトを起動します。
以下コマンドでモジュールのインストールを行います。

Install-Module MSOnline

作業対象ディレクトリ確認

以下コマンドで対象のディレクトリか確認します。
間違ったテナントで作業すると大変なことになるので確認しましょう。

Get-MsolDomain

対象アプリケーションの無効化及び削除

以下コマンドで対象のアプリケーションを無効化します。
ObjectIdはAzure PortalのAzure AD → エンタープライズアプリケーション などから取得します。

Get-MsolServicePrincipal -ObjectId <ObjectId> | Set-MsolServicePrincipal -AccountEnabled $false

無効化されたら削除します。

Get-MsolServicePrincipal -ObjectId <ObjectId> | Remove-MsolServicePrincipal

ポータルのエンタープライズアプリケーションから表示されなくなっていれば成功です。

WVDのプロファイルをFSLogixを使って Private Link 経由で Azure Storage へ保管する

Azure Virtual Desktop Azure

Windows Virtual Desktop (WVD) のプロファイルを外部へ保管する方法としてFSLogixが推奨されています。
WVDを使う理由としてデータを社外に持ち出したくないというところもあると思います。
Azure 上にプロファイルサーバーを立ててそこに保管する方法もありますが、サーバーを管理したくないので Azure Storage のBLOBへ配置します。
また、表題にもあるように完全にVNet内で通信を完結するために Private Link でBLOBへ接続します。

docs.microsoft.com

流れとしては以下となります。

  • Azure Storage の作成
  • WVD用仮想マシン（イメージ）の作成
  • FSLogix をインストール
  • サインインしての検証

Azure Storage の作成

まず Azure ポータルからStorage Accountを作成します。

名称等を入れます。
注意事項としてはパフォーマンスはPremiumを選択しましょう。
Standardだとサインイン・アウト時の読み込みなどの速度に影響してきます。

f:id:tsukatoh:20200605100613p:plain

接続方法はプライベート エンドポイントを選択します。

f:id:tsukatoh:20200605100632p:plain

名称と展開する仮想ネットワーク・サブネットを選択します。
ここでプライベートDNS統合を選択することで接続文字列等を変更なく利用できます。

f:id:tsukatoh:20200605100644p:plain

検証に成功したら作成します。
ARMテンプレートにも対応しているので、利用したい場合はダウンロードして参考にしてみてください。

f:id:tsukatoh:20200605100726p:plain

WVD用仮想マシン（イメージ）の作成

今回は Microsoft Windows 10 + Office 365 ProPlus で構築していきます。
選択したのは Windows 10 Enterprise multi-session, Version 2004 + Office 365 ProPlusです。
画面についてはここでは触れませんが、ネットワークは先ほど作った Azure Storage の Private Link のエンドポイントに接続できるよう、同一VNet内かPeeringされたネットワークに配置してください。

f:id:tsukatoh:20200605100801p:plain

FSLogix をインストール

VMの展開が完了したらリモートデスクトップ接続して作業します。
（安全に接続するには Azure Bastion で接続する方がいいと思います。）

FSLogix をダウンロードします。

https://aka.ms/fslogix_download

展開して x64\Release\FSLogixAppsSetup.exe を実行します。
他にある実行ファイルはそれぞれ以下の役割をインストールしますが今回は対象外です。
FSLogixAppsJavaRuleEditorSetup.exe　→　Javaバージョン管理機能のルール作成 FSLogixAppsRuleEditorSetup.exe　→　Application Masking

f:id:tsukatoh:20200605101303p:plain

次にGPO設定用にadml、admxファイルをコピーします。
fslogix.adml　→　C:\Windows\PolicyDefinitions\en-US
fslogix.admx　→　C:\Windows\PolicyDefinitions

f:id:tsukatoh:20200605101448p:plainf:id:tsukatoh:20200605104035p:plain

ファイル名を指定して実行で「gpedit.msc」を実行します。

f:id:tsukatoh:20200605101734p:plain

[コンピューターの構成] → [管理用テンプレート] → [FSLogix] → [Profile Containers] → [Enabled]　をEnabledへ変更
[コンピューターの構成] → [管理用テンプレート] → [FSLogix] → [Profile Containers] → [Cloud Cache] → [Cloud Cache Locations] を有効にして「type=azure,connectionString="接続文字列"」を入れます。

f:id:tsukatoh:20200605102751p:plainf:id:tsukatoh:20200605102804p:plain

でもこのままではキーがそのまま見えてしまうので隠蔽して登録します。

C:\Program Files\FSLogix\Apps\frx.exe add-secure-key -key blobkey -value [BLOB Key]

f:id:tsukatoh:20200605102904p:plain

出来上がったら以下に置き換えて登録しなおします。

type=azure,connectionString=”DefaultEndpointsProtocol=https;AccountName=[account_name];AccountKey=|fslogix/blobkey|;EndpointSuffix=core.windows.net”;

サインインしての検証

設定が終わったらサインインして検証します。
一度サインアウトしてサインインしなおします。

ディスクの管理から見るとプロファイルがVHDとしてマウントされています。

f:id:tsukatoh:20200605103158p:plain

VNet上のマシンから Azure Storage Explorer や Azure Portal から見ると以下のようにユーザー毎にコンテナーが作られ、その中にvhdファイルが保管されていることが確認できます。

f:id:tsukatoh:20200605103235p:plainf:id:tsukatoh:20200605103246p:plain

VNet外のマシンから上記のように確認しても権限がないとアクセスすることができません。

f:id:tsukatoh:20200605103300p:plain

Storage BLOB へのアクセスをPrivate Link経由にすることでBLOBストレージを外部に公開することなくプライベートなネットワークで利用することができ、WVDのプロファイルの保管用途としても外部に公開したくないというニーズにも応えられるようになっています。

リモートワークのお供にWindows Virtual Desktop (WVD)

Azure Azure Virtual Desktop

Windows Virtual Desktop (WVD)

昨今の社会情勢からリモートワークが基本となり、お家から仕事するという生活が続いているかと思います。
ですが、職種や職域によってはどうしてもオフィスに行かなければならない方々もいらっしゃいます。
それを少しでも緩和できる可能性があるのがWindows Virtual Desktop(WVD)ではないかと思います。
WVDとはMicrosoft Azure上で動作するマネージドVirtual Desktop Infrastructure(VDI)サービスです。
Azure上にWindows 10デスクトップ環境を用意してリモートで接続し、作業できる環境を用意するサービスです。
Express RouteやVPNを使ってオンプレミスのデータセンターと接続することで、社内データやネットワークにもアクセスすることができます。

個人的にもVDIはもう10年以上触ってきているので、Azureでここまで簡単に構築できるのは感慨深いです。
2020/05/01にパブリックプレビューとして公開されたARMで管理された新しいWVDのご紹介をしていきます。

docs.microsoft.com

構築には以下の方法があります。

※ 2020年5月25日現在はAzure Resource Manager (ARM) での構築は非対応です

Azure Portal で構築する

前提としてAzure AD DSかAzure AD Connectで構築されたAzure ADが構築済みなこと。

tsukatoh.hatenablog.com

Azure Portalから「Windows Virtual Desktop」を検索します。

f:id:tsukatoh:20200525182237p:plain

「Create a host pool」をクリックします。

f:id:tsukatoh:20200525182316p:plain

Basicesには以下の情報を入力します。

f:id:tsukatoh:20200525182335p:plain

  • Subscription　→　サブスクリプションを選択
  • Resource Group　→　リソースグループを作成（ここでのRGはHost poolリソースの配置先）
  • Host pool Name　→　ホストプールの名称を入力
  • Location　→　メタデータの保管先（現状は日本は選択不可）
  • Host pool type　→　Pooledは共有型、Personalは個人固定型
  • Max session limit　→　最大セッション数
  • Load balancing algorithm　→　Breadth-first Breadth-firstは幅優先の負荷分散、Depth-firtsは深さ優先の負荷分散

Virtual Machinesには以下の情報を入力します。

f:id:tsukatoh:20200525183826p:plain

  • Add virtual machines　→　デフォルトはNo、ここではVMの設定を入れるためにYes
  • Resource group　→　リソースグループを指定、何も指定しなければHost poolと同一のRGに配置
  • Virtual machine location　→　VMの配置先リージョン
  • Virtual machine size　→　VMのサイズを指定
  • Number of VMs　→　VMの台数
  • Name prefix　→　VMの名称の頭文字、後ろにナンバリングが入る
  • Image type　→　VMのイメージの選択元、作成したイメージもGalleryから選択できる
  • Image　→　イメージを選択、カスタムイメージはBrowse〜から選択する
  • OS disk type　→　ディスク種類の選択ができる、早いものがほしければPremium SSD
  • Virtual network　→　AzureADに接続可能なVNetを選択（ピアリングでも可）
  • Subnet　→　配置可能なサブネットを選択
  • Public IP　→　パブリックIPを設定する場合はYes、通常はNoでいいと思います
  • Network security group　→　NSGを設定するかどうか、Subnetに設定しておいてここではNoneにするのがいいと思います
  • Specify domain or unit　→　OUの指定をする場合に選択
  • AD domain join UPN　→　ドメイン参加実行アカウント

Workspaceには以下の情報を入力します。

f:id:tsukatoh:20200525182452p:plain

  • Register desktop app group　→　デフォルトはNo、ここではワークスペース名を指定するためYes
  • To this workspace　→　ワークスペース名を入力、WVDサインイン時にユーザーに見える名称です

Review + createをクリックして作成します。

作成完了したら接続します。

【Web Client】

https://rdweb.wvd.microsoft.com/arm/webclient/

【WVD専用クライアント】

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

f:id:tsukatoh:20200525184233p:plain f:id:tsukatoh:20200525184248p:plain

ARM対応になり、Powershellでの管理必須というハードルから解放されました。
導入もしやすくなったのではないでしょうか？
是非お試しあれ。

Azure Active Directory Domain Services を PowerShell で構築する

Azure Active Directory Azure Active Directory

Azure Active Directory Domain Services (Azure AD DS または AADDS)

AADDSって構築後にDNSの設定をしないとドメイン参加できないので、構築後のAADDSリソースの概要をAzure Portalから見るとDNSを構成するボタンが表示されています。
今回、それをPowerShellでやる場合のメモです。

そもそもとしてのAzure AD DS の構築方法としては以下があります。

  • Azure Portal で構築する
  • Azure PowerShell で構築する
  • Azure Resource Manager (ARM) で構築する

Azure Portal で構築する

docs.microsoft.com

PowerShell での構築方法

docs.microsoft.com

ARM テンプレートでの構築方法

docs.microsoft.com

今回は2つ目のPowerShellで構築していたのですがAADDS構築後に通常だとAzure Portalから操作する部分があり、そこも自動化したくて考慮点を調べました。

考慮点

  • Custom DNS をVNetへ設定しなければならない
  • Network Security Group をSubnetへ設定しなければならない

AADDS構築後に以下の画像のようにDNS構成をするボタンが概要ページに出てきますが、ここでカスタムDNSやNSGの設定をしてくれています。 f:id:tsukatoh:20200427174330p:plain

PowerShell での追加設定の仕方

Custmom DNS をVNetへ設定する

  1. 既存の構築用に使ったNew-AzVirtualNetworkの最後尾にDnsServerを追加して適用する。

【構築時のコマンド】

PS> $VNet = New-AzVirtualNetwork `
      -ResourceGroupName <ResourceGroupName> `
      -Location <AzureLocation> `
      -Name <VNetName> `
      -AddressPrefix 0.0.0.0/0 `
      -Subnet <SubnetName>
PS> $VNet | Set-AzVirtualNetwork

【適用するコマンド】

PS> $VNet = New-AzVirtualNetwork `
      -ResourceGroupName <ResourceGroupName> `
      -Location <AzureLocation> `
      -Name <VNetName> `
      -AddressPrefix 0.0.0.0/0 `
      -Subnet <SubnetName> `
      -DnsServer 0.0.0.4,0.0.0.5
PS> $VNet | Set-AzVirtualNetwork

上記設定まで完了すると以下のように変化します。 NSGを設定しろ的な感じですね。 f:id:tsukatoh:20200427174421p:plain

Network Security Group (NSG) をSubnetへ設定する

  • VNetの情報取得
PS> ＄VNet = Get-AzVirtualNetwork -Name <VNetName> -ResourceGroupName <ResourceGroupName>
  • サブネットの情報取得
PS> $Subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name <SubnetName>
  • Network Security Group (NSG) の情報取得
PS> $Nsg = Get-Az NetworkSecurityGroup -ResourceGroupName <ResourceGroupName> -Name <NSGName>
  • Subnetへ適用するNSGのコンフィグ設定
PS> $Subnet.NetworkSecurityGroup = $Nsg
  • VNetへのコンフィグ適用
PS> Set-AzVirtualNetwork -VirtualNetwork $VNet

まとめると以下になります。

PS> ＄VNet = Get-AzVirtualNetwork -Name <VNetName> -ResourceGroupName <ResourceGroupName>
PS> $Subnet = Get-AzVirtualNetworkSubnetConfig -VirtualNetwork $VNet -Name <SubnetName>
PS> $Nsg = Get-Az NetworkSecurityGroup -ResourceGroupName <ResourceGroupName> -Name <NSGName>
PS> $Subnet.NetworkSecurityGroup = $Nsg
PS> Set-AzVirtualNetwork -VirtualNetwork $VNet

完了するとPortalのボタンで設定したものと同じようになります。 f:id:tsukatoh:20200427174502p:plain

上記で問題なくドメイン参加まで行けましたので、PowerShellで全部組みたい方（少数派デスヨネ）に参考になれば。

Azure BastionがGAされました

Azure

Azure BastionがMicrosoft IgniteでGA (General Availability)の発表がありました。
VMを使っている方は嬉しい発表ではないでしょうか？

Azure Bastion

利用している仮想ネットワーク内でプロビジョニングするフルマネージドなbastion serviceで、Azure portal内で直接SSLを経由して仮想マシンへのシームレスな接続を提供されます。
サポートプロトコルはRDP、SSHで、Azure Bastion経由で接続する場合、仮想マシンにパブリックIPアドレスは不要となります。
追加のクライアント、エージェント、ソフトウェアも不要といったサービスです。

ブラウザとAzureアカウントさえあれば使えるので、作業用のPCがないとアクセスできない！とかいうことから開放されますね。

デプロイ方法

AzureのMarketplaceからBastionを検索して追加します。
f:id:tsukatoh:20191105165952p:plain 作成を押します。
f:id:tsukatoh:20191105170006p:plain 必要事項を入力していきます。
f:id:tsukatoh:20191105170022p:plain

名称等を入れるブレードのところで注意が必要です。 まず、専用サブネットが必要になります。
デプロイ先の仮想ネットワークのアドレス空間の空きを確認し、AzureBastionSubnetという名称でサブネットを追加します。
サブネットの範囲は27ビットマスク以上の範囲が必要になります。

出来上がったら仮想マシンの接続からBastionを選択してアクセスします。
f:id:tsukatoh:20191105170903p:plain

2019/11/05現在は以下リージョンのみで使用可能です。

  • Australia East
  • East US
  • Japan East
  • South Central US
  • West Europe
  • West US

難しいことはあまりありませんが、サブネット名等の注意は必要ですね。
良い踏み台ライフを。

KEDA+AKSでk8s上にFaaSを構築する

Azure Kubernetes KEDA

5月に発表されたKEDA(Kubernetes-based Event-driven Autoscaling)ですが、AKS(Azure Kubernetes Service)の上でサーバーレス のイベントドリブンコンテナーをサポートするものとしてオープンソースでMicrosoftとRedHatが共同で発表しました。

KubernetesのスケーリングはコンテナのCPUとメモリ消費率に関連付けされていますが、KEDAを使う事でAzure FunctionsなどのFaaSと同様にイベントに応じたリソースのプロビジョニングやスケーリングをする事が可能になります。 

現状（2019/9/30現在）サポートされているイベントソースとスケーラーは以下になります。

  • AWS CloudWatch
  • AWS Simple Queue Service
  • Azure Event Hub†
  • Azure Service Bus Queues and Topics
  • Azure Storage Queues
  • GCP PubSub
  • Kafka
  • Liiklus
  • Prometheus
  • RabbitMQ
  • Redis Lists

詳細などはGitHubや発表時のブログを参照してください。

cloudblogs.microsoft.com

github.com

実際に動かしてみる

AKSの構築

いずれかの方法でAKSを構築します。

docs.microsoft.com

docs.microsoft.com

 

KEDAのインストール

Kubernetesクラスターにhelmをインストール

helm init

Helm repoの作成

helm repo add kedacore https://kedacore.azureedge.net/helm

 Helm repoの更新

helm repo update

keda-edge chartのインストール

helm install kedacore/keda-edge --devel --set logLevel=debug --namespace keda --name keda

Azure Functions Core Toolsのインストール

func kubernetes install --namespace keda

 

ストレージの作成

キュートリガーで動くよう作るのでストレージアカウントとキューを作成

docs.microsoft.com

docs.microsoft.com

アプリケーションの作成

作業ディレクトリの作成

mkdir kedaapp & cd kedaapp

ディレクトリの初期化

optionはnode→javascriptを選択

func init . --docker

f:id:tsukatoh:20190930175434p:plain

Queueトリガーの作成

Azure Queue Storage triggerを選択

名称は適宜変更

func new

f:id:tsukatoh:20190930175542p:plain

 function.jsonの「queueName」をStorage Queueのキュー名と合わせる

{
  "bindings": [
    {
      "name": "myQueueItem",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "js-queue-items",
      "connection": "AzureWebJobsStorage"
    }
  ]
}

local.settings.jsonのAzureWebJobsStorageへ作成したStorage accountのAccess keysよりConnection stringをコピーする（key1,key2どちらでもよい）

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "node",
    "AzureWebJobsStorage": "DefaultEndpointsProtocol=https;EndpointSuffix=core.windows.net;AccountName=mystorageaccount;AccountKey=keykey==="
  }
}

 

KEDAへアプリケーションのデプロイ

コマンドにてdocker hubへプッシュし、Kubernetesへデプロイする

func kubernetes deploy --name kedaqueue --registry <docker-user-id>

 

 動作確認

リソースが作成されていることを確認する

f:id:tsukatoh:20190930182038p:plain

キューをポータルより作成し、Podが自動的に起動するのを確認する

f:id:tsukatoh:20190930182805p:plain
上記のように処理が完了してしばらくするとTerminatingされます

 

最後に

まだベータ版で開発中です。

今後CosmosDBやAzure Monitor、IoT Hubなどの連携も予定されているので今後がたのしみなプロダクトですね！

docs.microsoft.com

 

macからAzure Cache for Redisへredis-cliにて接続する

Azure

やろうとしてちょっと困ったので備忘録的に。
Azure Cache for RedisはデフォルトでNon-SSL portがdisabledになっており、本番運用としてもNon-SSL portをenableにして使うことはないと思います。

でも格納されているデータをAzure PortalのConsoleから利用しようとすると使い勝手が悪い。。。手元のterminalで操作してデータを取りたい。ということでmacから接続する方法です。

Windowsで接続する方法は以下ドキュメントがありますのでそちらを参照してください。

docs.microsoft.com

redis-cliはssl対応されていないためstunnelでSSLトンネリングして接続します。

homebreのインストール

まずhomebrewをインストールします。

$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

redisのインストール

次にredisのインストール

$ brew install redis

stunnelのインストールとstunnel.confの編集

stunnelをインストールし、コンフィグを作成する。

$ brew install stunnel
$ vi /usr/local/etc/stunnel/stunnel.conf

stunnel.confの内容は以下のようにする。（example部分は自リソースで置き換える）

[redis-cli]
client = yes
accept = 127.0.0.1:6379
connect = example.redis.cache.windows.net:6380

接続

準備が終わったら接続です。

$ redis-server &
$ stunnel
$ redis-cli -h localhost --raw
127.0.0.1:6379> auth {access key}
OK

rawオプションをつけているのは2バイト文字の文字化け対応です。