Azure ToolsのBlogで以下のタイトルの記事があがっています。
10月15日以降、記載されているバージョンより古いAzure CLI/Azure PowerShellでAzure ADにService Principalを作ろうとするとエラーになるようです。
エラーの原因ですが、こちらのAzure ADの更新に対応していないためです。
最近認証毎の課金から月間アクティブユーザー課金になってだいぶお得になった感のあるAzure Active Directory B2Cですが、実際の利用時にはまだまだお手軽ではありません。（欲しい属性を基本のものから追加したりUIのカスタマイズ程度ならいいのですが）
お手軽ではない要因の1つというかこれが全てですが、基本的に（実際のケースで望まれるフローを満たすような）カスタマイズを行う場合はIdentity Experience Framework（IEF）を使ってカスタムポリシーを作成する必要があり、この作業が非常にわかり辛いというところです。
幸いなことに先日Azure AD B2Cのカスタムポリシーを弄るHackFestに参加する機会があり、今更ですがものすごく理解が進んだので少しでも共有するのが今回のPostになります。（やはり実践に勝るものはない） 続きを読む
待望（？）のAzure Active Directory Domain ServicesがPublic Previewとなりました。
平たく言うとManagedな（制限付きの）Windows Server Active Directory Domain Servicesです。オンプレのActive DirectoryドメインをAzure上に建てられるうえにドメコンの管理から解放されます。Domain Controller as a Serviceですね！
同期されなくなったどころか初期化された（Trueな人がクリアされた）んですが。
不具合じゃね？
さくっとSynchronization Rules EditorでInboundに変換ルール追加してフル同期して事なきを得ました。（Deltaだとダメでした）
Office 365ネタ。
DirSyncでアカウント同期してるテナントが対象です。今月入ってからぐらいでどうも同期ユーザーのパスワードをOffice 365側で変更しようとするとエラーになるっぽいです。
一応、発生した環境はこんな感じ
初回ログイン時に初期パスワードいれてパスワード変更画面にて新しいパスワードを指定すると以下のような画面になります。
※普通にパスワード変更しようとしてもエラーになります。
謎い。いろいろ切り分けると同期してないユーザー（O365側で作成したユーザー）は問題ない。。で、聞くところによるとAD同期してる場合はAD側でパスワード変更してくれという話。そんな馬鹿な。。。前までいけてたのに。
あと同期をもう一度やってくださいとか怖いことをおっしゃるので、やむなしということでDirSyncからパスワードのライトバックができるAADSyncのほうにバージョンアップしようと思います。（さすがにプレビューのAADConnectは入れない）
さくっとDirSyncをアンインストールします。
FIMとか関連するコンポーネントもアンインストールしてくれるようです。（SQLサーバーはそのまま残ってた）
アンインストール後、AAD Syncをインストールします。インストール後、O365テナントのアカウントID/Passを入力します。
オンプレActive Directoryの資格情報を入力して「Add Forest」して追加してからNextします。
オプション機能で「Password write-back」にチェックをいれます（パスワード同期は環境に応じてお好きに）
だいたいこんな感じです。セットアップ後は一度サインアウトしましょう（管理グループに入れられるけどそのままだと権限足らないので）
手動同期は C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe delta という感じで実行すると良しなにしてくれます。
とか思ってやってみたらやっぱりエラー。結局パスワードのWrite-backはというかセルフリセットはAzure AD Premiumの機能ですとかそんなオチ。でもともとの話だったO365側のパスワード変更できない云々は未解決＼(＾o＾)／
ただのDirSyncからAADSyncへの移行ネタになってしまった。
|SR| λ…………ﾄﾎﾞﾄﾎﾞ
あるよね。そういうこと。
オンプレに
という環境があるとします。
※ちなみにオンプレ環境は全部Windows Server 2012 R2とします
で、ちょっとアドレス帳から非表示にしたいなーとか思うと
はい。ソウデスネ。
もちろんオンプレのADにはそんな（Exchange関連の）属性ありません。
どうしましょうか？素直なのは他の属性の値を使ってAADSyncとかのマッピングをいじることです。（ただこれも直感的に何をしてるのかわかりにくいのとSyncするツールに依存しちゃうのでどうなんだろう）
ということで今回は少し斜め上の対応をしてみましょう。
そう、Exchangeスキーマの拡張だけしてしまいましょう。
身もふたもない。
まず評価版のExchange Server 2013をダウンロードしましょう。
ダウンロードしたEXEを実行してファイルを展開します。その後以下のコマンドでSetup.exeを起動してスキーマ拡張だけ行います。（※もちろんバックアップとかその辺ちゃんと考えてください）
Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
※細かい話はこの辺参照
完了後、スキーマが拡張されたので後はお好きにどうぞ。
やりました。
タイトルの通り。やり方をひょんなことで知ったのでやってみました。
※ というか知識がWindows Server 2003で止まってるからナー。。
昔の知識だとブート時にF8押して～とかなんですが、いやいやbcdeditで既定のブートかえればいいじゃんという話でした。あとWindows Server 2008からかどうか知らないんですが、ディレクトリサービス復元モードでもRDP使えるみたいですね。
ちょっと前にVittorioがAzure ADのサンプル集をGitHubにしたよ！ってPostしてました。
GitHubのサンプルはこちら
いやー便利ですね～。
なんとなくAzure上の仮想マシンでVM-Generation IDがちゃんと動いてるのか見てみようと思いました。
結論↓
ちゃんとイケてるようです。
このあたりを参考にしました。
これでサポートしてるActive Directory Domain Service （Windows Server 2012以降）とかなら安心して（？）Windows Azure上で動かせますね。
細かい話はMSの安納さんに教えて頂いたほうがよいかと思います。
追記
Azure上の仮想マシンを削除（ディスクは保持）→ 同じディスクを使用して仮想マシンを再作成するとVM-Generation IDが新しくなるので、ドメインコントローラーとしては他のDCから安全に最新情報に更新できるので安全、という感じのようです。
まぁうまく使ってください。
Buildで赤シャツさんがデモしてた他のアプリケーションとの認証連携（アプリケーションアクセス拡張機能）がプレビュー公開されました。
なにはともあれ、Previewの申込みをしましょう。（たぶんすぐにActiveになると思います）
ブチザッキ 