前回の記事( Windows10をAzure ADに参加させる!【M365フルクラウド環境検証 その1】 | Microsoft Cloud Administrators )ではAADにWin10をAAD Joinさせて、AAD上のIDで直接Win10にサインインができるようにしました。

Win10で直接、職場または学校アカウントでサインイン

これはこれで素敵なのですが、AADの規定のドメイン名は「xxxxxxxxx.onmicrosoft.com」という形式であり、ちょっと長いですし、やはり企業用途であれば独自ドメインを使いたいですよね。そうすればユーザーもわかりやすく短いユーザーIDを使ってWin10にログインすることも可能になります。

ということで今回はAADにドメインを追加してユーザーIDを変更してみます。このときに既存のユーザーおよびユーザープロファイル上のファイル等に影響が出るのか、出ないのかも確認します。

現状確認

まず、現状を確認しておきましょう。

初期状態でローカルにユーザーが1つあり、その状態からAADに参加し、AAD上のユーザーで一度サインインした状態のWin10があります。

もちろんローカルユーザーはビルトインのユーザー群と当初に作成した1ユーザーのみであり、AADのユーザーは表示されていません。

ログインしているユーザーはAzure AD上のユーザーです。

環境変数を確認してみます。

C:\Users\mebisuda>setALLUSERSPROFILE=C:\ProgramDataAPPDATA=C:\Users\mebisuda\AppData\Roamingasl.log=Destination=fileCommonProgramFiles=C:\ProgramFiles\CommonFilesCommonProgramFiles(x86)=C:\ProgramFiles(x86)\CommonFilesCommonProgramW6432=C:\ProgramFiles\CommonFilesCOMPUTERNAME=DESKTOP-7JO0TJGComSpec=C:\WINDOWS\system32\cmd.exeDriverData=C:\Windows\System32\Drivers\DriverDataFPS_BROWSER_APP_PROFILE_STRING=InternetExplorerFPS_BROWSER_USER_PROFILE_STRING=DefaultHOMEDRIVE=C:HOMEPATH=\Users\mebisudaLOCALAPPDATA=C:\Users\mebisuda\AppData\LocalLOGONSERVER=\DESKTOP-7JO0TJGNUMBER_OF_PROCESSORS=4OneDrive=C:\Users\mebisuda\OneDriveOS=Windows_NTPath=C:\ProgramFiles(x86)\CommonFiles\Oracle\Java\javapath;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\WINDOWS\System32\WindowsPowerShell\v1.0\;C:\WINDOWS\System32\OpenSSH\;C:\ProgramFiles\Intel\WiFi\bin\;C:\ProgramFiles\CommonFiles\Intel\WirelessCommon\;C:\ProgramFiles\TortoiseGit\bin;C:\ProgramFiles\Git\cmd;C:\Users\mebisuda\AppData\Local\Microsoft\WindowsAppsPATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSCPROCESSOR_ARCHITECTURE=AMD64PROCESSOR_IDENTIFIER=Intel64Family6Model69Stepping1,GenuineIntelPROCESSOR_LEVEL=6PROCESSOR_REVISION=4501ProgramData=C:\ProgramDataProgramFiles=C:\ProgramFilesProgramFiles(x86)=C:\ProgramFiles(x86)ProgramW6432=C:\ProgramFilesPROMPT=$P$GPSModulePath=%ProgramFiles%\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\ModulesPUBLIC=C:\Users\PublicSESSIONNAME=ConsoleSystemDrive=C:SystemRoot=C:\WINDOWSTEMP=C:\Users\mebisuda\AppData\Local\TempTMP=C:\Users\mebisuda\AppData\Local\TempUSERDOMAIN=AzureADUSERDOMAIN_ROAMINGPROFILE=AzureADUSERNAME=mebisudaUSERPROFILE=C:\Users\mebisudawindir=C:\WINDOWS

きちんとユーザーのドメインはAzureADと表示されていますね。さらに、プロファイルはC:\Users\mebisuda にセットされています。

これからドメインを追加し、ユーザーのユーザーIDが変化したときにプロファイルが同じものがつかわれるのか、違うものがつかわれるのかが一つ大事なところですので、デスクトップに確認用のファイルを1つおいておきます。

Azure ADへのドメイン追加

では、AADにドメインを追加していきましょう。管理操作はAzure管理ポータルを利用します。

現在は作成時につけたebisudatest.onmicrosoft.comというドメイン名のみが登録されています。

持っているけれども全然使っていないtm-plan.netというドメインが余ってますのでそれをテスト用途で今回使いたいと思います。

ドメインをAzureADに追加して利用可能にするためには、そのドメインを本当に保持していることの証明として指定された確認用のTXTレコードあるいはMXレコードをDNSに登録する必要があります。

このドメインはお名前.comで管理されていますので、お名前.comの管理画面からレコードを追加します。

追加後、Azure管理ポータル上でレコード確認を行います。

確認できるとAAD上で利用可能となります。さらに、プライマリとすることもできます。プライマリにすることに抵抗ある方も随分いるようですが、私はプライマリにすべきと考えますのでプライマリにします。 (※詳細はこのエントリの本筋と外れるので割愛)

これでめでたくドメインが追加され、プライマリとなりました。

ユーザー名の変更

それでは、テストユーザーのユーザー名を新しいドメインに変更しましょう。ターゲットはmebisuda@ebisudatest.onmicrosoft.comです。

ユーザー名が変更できました。

新しいユーザー名でのWindows 10の挙動確認

さて、新しいユーザー名になりましたのでこの状態でAzure AD Join済みのWindows10の挙動がどうなるのか見てみましょう。

・・・。と思ったのですが、そもそもWindows10側にはユーザー名はドメイン部分は表示されていませんでした。

きちんと何も意識せずにPCにサインインできましたし、SSOもきちんと動作しました。もちろんユーザー名も変更されていました。

その他、デスクトップに配置してあったファイルもそのままでしたし、プロファイルが再作成されるような動きもありませんでした。

ドメイン追加、ユーザー名のドメインパート変更はかなりカジュアルにやってしまっても大丈夫な構造がしっかりと作られているようです。

ユーザー名を大きく変更

せっかくの検証環境なのでユーザー名を大きく変更してみようと思います。

mebisudaからebiに変更しちゃいます。

さて、ここまでやるとどうでしょうか?

結果としては、win10上ではmebisudaとして今まで通りの挙動をしつつ、SSOもきちんと動くというものでした。

さらに「別のユーザー」としてebi@tm-plan.netを明示的に指定してサインインもしてみましたが、同じく「mebisuda」に紐付き、結果は全く同じとなりました。

どうやらユーザー名とは異なる属性できちんと紐付けが働くような仕組みになっているようです。レジストリを見る感じ、SIDはAzureADのユーザーとの紐付けでも健在なように見えます。(※ただの私の推測です。)

このエントリはこのくらいにしておきたいと思います。

次はIntuneでデバイスを管理化において少しポリシーを適用するくらいの事をしてみようかと思います!(※他にもしてほしい事あったらリクエストください!)

シリーズの次の記事はこちら!