Google Apps の無料運用が終わることになり、これまで運用してきた独自ドメインのメールアカウントをどこかへ移行する必要が生じました。

いくつかの移行先候補の中で、「無料で」続けることができる数少ない選択肢が Zoho メール だと思っています。というわけで、Google Apps からの移行を視野に入れて、Zoho メールで独自ドメインのメールアカウントを運用する方法を調べました（ちなみに以下のスクリーンショットを撮った時には FireFox を使っています）：



【Zoho メールとは】
個人や小規模組織を対象に無料のメール環境を提供しています。GMail 同様、個人でも @zohomail.jp ドメインのメールアカウントを取得することもできますが、今回は独自ドメインでメールを運用できる点に絞って紹介します。なお無料で Zoho の独自ドメインメールを運用する場合の条件は以下のようになります：
・最大５ユーザー
・１ユーザーあたり 5GB のメール容量
・添付ファイルは最大 25MB まで
・Webメールとモバイルアプリのみ（POP3/IMAPなし）


【Zoho メールを独自ドメインで利用するまでの手順】
以下に実際に自分が所有しているドメイン（yellowmix.net）で利用できるようにするまでの手続きの様子を紹介します。Zoho は Zoho Japan が日本人向けのサービスも提供していますが、この Zoho メールの手続きは途中から英語のみになるので、その点にご注意ください。

まずは Zoho メールのトップページへ行き、「広告表示なしメールの使用を開始する」と書かれた箇所で「メールアドレス」を選んで「無料プランに登録する」ボタンを選択します：



※ちなみにここで「個人向け」を選ぶと、@zohomail.jp ドメインの無料メールアカウントを取得できます。

このような画面が表示されます。この辺りは有料サービスなので下にスクロールします：



「永久に無料のプラン」と書かれたサービスの「無料お試し登録」をクリックします：



次の画面では新たに申し込むアカウントの設定に利用する氏名とメールアドレス（今回申し込むメールアドレスのドメインとは別のもの）、そしてパスワードを入力します（既にそのメールアドレスで Zoho のアカウントを取得している場合はログインします）。最後に「登録する」ボタンをクリックします：



Zoho メールの設定ウィザードがスタートします。まずはドメインを追加します。今回は既に所有済みのドメインを利用するため「既存のドメインを追加する」の「今すぐ追加する」ボタンをクリックします：



以下のようなダイアログが表示されるので、登録するドメイン名（www. が表示されているので、そこに続けてドメイン名を入力）、組織名、そして組織の分類（自分は IT を選びました）を指定して「追加する」を選択します：



すると次のような画面になり、ドメインの追加ができました。ただ本当にこのドメインを所有しているかどうかを確認する必要があります。続けて「ドメイン認証に進む」をクリックします：



ドメインの所有権を認証する画面が表示されます。ここから先はドメインを取得したプロバイダーによって作業内容が変わると思いますが、自分の場合は GoDaddy.com でこのドメインを取得しており、GoDaddy.com の場合は左の「自分の DNS にログインする」を選ぶことで先にすすめることができました。以下、この方法を選んだ場合として説明を続けます：



「自分の DNS にログインする」を選択すると DNS プロバイダー（自分の場合は GoDaddy.com）へのログイン認証が行われるので、該当プロバイダーへログインする ID とパスワードを入力してサインインします：



正しくサインインできると、Zoho Mail Hosting を有効にする許可を与えるかどうかの確認画面になります。内容を確認して「接続」をクリックします：



すると元の画面に戻り、「ドメインの所有者が確認されました」のメッセージが表示されます。これで指定したドメインを本当に自分が取得していることを証明できました。

続けてこのドメインでのユーザーを作成します。

"Your login mail address" と書かれたテキストフィールドに作成するメールアドレスを入力（@yellowmix.net は入力済みなので、その前の部分を入力）して、「作成する」をクリックします：



すると以下のような画面が表示され、ユーザーが追加されたことが確認できます。必要に応じてここで「追加する」を選択して、このドメインのメールユーザーを（無料プランであれば最大５ユーザーまで）追加できます。ユーザーの追加が完了したら「グループの設定に進む」をクリックします：



グループはユーザーが共有して利用することができるメールアドレスです。必要に応じて「作成する」からグループを作成してください（不要であれば作る必要はありません）。次に進む場合は「DNSの関連付けに進む」をクリックします：



次に MX レコードなどのメール用 DNS 設定を行います。が、この前の手続きでドメイン認証が済んでいれば「MX、SPF、DKIM を自動で設定できます」ボタンをクリックするだけです：



続いてデータ移行の画面になります。既存メール環境からのデータ移行ができるようですが、今回の自分の場合は新規のメール環境登録なので既存メール環境がありません。ここは何もせずに次の「モバイル設定に進む」を選択しました。ここは実際に試した人からの情報があればいただきたいです：



スマホからこのメールを使うための設定画面です。といっても実際にはモバイルアプリへのリンクがあるだけのページでした。必要であればこのページのリンクから Zoho メールのモバイルアプリをダウンロード＆インストールしてください。最後に「設定の完了に進む」をクリックします：



※上のリンクをクリックするとこのような画面になって、モバイルアプリのダウンロードができるようです：



これで全ての設定が完了しました。「受信トレイを確認してください」をクリックします：



新しいメール環境が確認できるようになりました。が、改めて最初からのアクセス方法を確認するため、一旦ログアウトしましょう。右上のアイコンをクリックします：



そして「サインアウトする」を選択して、サインアウトします：




では改めて Zoho メールに作成した独自ドメインのユーザーでログインしてメールを使ってみます。まずは Zoho メールのトップページにアクセスします：
https://www.zoho.com/jp/mail/


そして右上の「サインイン」をクリックします：



先程登録した独自ドメインのユーザー名とパスワードでサインインします：



初回ログイン時には２段階認証を有効にするよう注意画面が表示されます。必要に応じてここで２段階認証を有効にしてください（後から設定することも可能です）。ここでは一旦「後で確認する」をクリックして先に進みます：



これで Zoho メールを送受信できる画面に移動できました！安全のため２段階認証も有効にしておきましょう：




以上、独自ドメインを Zoho メールで運用する場合の設定手順を紹介しました。１ドメインあたり５ユーザーまで、というのが個人的にはちと厳しい気もするのですが、Google Apps 亡き今となっては無料で独自ドメインメール運用ができる環境の選択肢そのものが少なく、無料となると（格安のはいくつかありますが）個人的にはここしか知りません。この５ユーザーの範囲内でうまく使っていけると、Google Apps 難民にとっても有用な移行先であるように思えました。

タグ ：

#google

#apps

#migration

#zoho

#mail

#domain

かなり以前に Bluemix(IBM Cloud) の CloudFoundry ランタイム環境でカスタムドメインを運用する手順を紹介したことがありました。今回はその IKS(IBM Kubernetes Services) 版とも言える内容で、特にカスタムドメイン管理を適用する部分については IBM Cloud から提供されるドメイン単位でのオール・イン・ワン・セキュリティーサービスでもある CIS(Cloud Internet Services) を使った場合の手順を確認する機会があったので、その流れを紹介します。

なお、今回紹介する手順を実行するための前提条件として (0) カスタムドメインを所有していること、(1) ベーシックプラン以上の IBM Cloud アカウントを取得していること、(2) IKS（+ Ingress）サービスが利用できること、そして (3) CIS サービスが利用できるという３点が必要です。(0) は今回の作業では当然必要です。また (1) がないと (2) も (3) も利用できないので IBM Cloud アカウントは取得しているとして、このアカウントは無料のライトプランではなく、ベーシックプラン以上でないと (2) も (3) も作成できない点にご注意ください。

また (2) について、IKS は１ヶ月間無料の Free プランもありますが、今回紹介する内容では（Free プランでは使えない） Ingress によるサーバー名管理が必要なため、事実上この (2) は無料では試せない点をご了承ください。シングルゾーンの最弱スペックで１ワーカーノード環境（１時間で約13円）でも構いませんが、IKS を利用するための料金が必要です。なお IKS ではなく上位版の OpenShift 環境でも大丈夫です：



(3) の CIS は１アカウントにつき１回だけ、30日間無料プランを申し込むことが可能です。このプランを利用せずにスタンダードプランを利用する場合は、ドメイン１つにつき１ヶ月約30000円です：




では以下で具体的な手順を追いながら説明します。

【IKS + Ingress を使ってアプリケーションをデプロイする】
まずは IKS + Ingress 環境で動くウェブアプリケーションを用意します。この時点ではカスタムドメインを意識せずに環境を作ります。

自分で IKS にデプロイしたアプリケーションがあればそれを使っていただいても構いませんが、動作確認用のサンプルとして、以前のブログエントリでも紹介したこのアプリケーションを使う方法も紹介します（アクセスすると、サーバーの /etc/hostname ファイルの内容を表示するだけのアプリケーションです）。ソースコード内に IKS + Ingress 環境を想定したデプロイ用の yaml ファイルが含まれているのでこれを自分の環境向けに編集してデプロイに使うことにします。

まずはソースコードを git clone するかダウンロードしてください：

$ git clone https://github.com/dotnsf/hostname

厳密には今回の作業で最低限必要になるのは yaml/app_deployment_ingresssample.yaml ファイル１つだけなので、ソースコード等に興味なく単に動作確認するだけであれば、このファイルをダウンロードしていただくだけでも構いません：
https://raw.githubusercontent.com/dotnsf/hostname/master/yaml/app_deployment_ingresssample.yaml


次にダウンロードした （yaml/）app_deployment_ingresssample.yaml ファイルを自分の環境向けに編集するのですが、まずは自分の Ingress サブドメインを確認しておく必要があります。IBM Cloud にログインし、利用中の IKS のダッシュボードを開いて Overview メニューから Ingress Subdomain 欄を参照して、その値を確認します：



ダウンロードした app_deployment_ingresssample.yaml ファイルをテキストエディタで開き、以下の部分を上で参照した自分の Ingress Subdomain の値に書き換えます。また k8s クラスターを東京（ jp-tok ）以外のリージョンで作成した場合はサブドメイン情報に続くリージョン情報も自分のリージョンに書き換えてください。最後に保存します：

apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
  - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

これでデプロイの準備が完了したので、実際に IKS へデプロイします：

$ kubectl apply -f yaml/app_deployment_ingresssample.yaml 

デプロイが成功すると Ingress が有効になり、https://（上述の spec.tls.hosts の値）/ でアプリケーションにアクセスできるようになります：



IKS 上にデプロイされたアプリケーションの稼働までができました。この時点では IBM Cloud のドメインによるサーバー名でアクセスされていますが、引き続いて CIS を使い、このアプリケーションをカスタムドメインのサーバー名でアクセスできるようにしていきます。


【CIS にカスタムドメインを登録する】
次の手順は CIS 側の設定です。CIS はドメイン単位で設定を行います。したがってカスタムドメインを使う場合はそのカスタムドメインを登録した上で証明書等を発行する必要があります。

今回は私個人が所有する pi314.jp というドメインを使って説明します。最終的には上述の IKS 上で動く hostname アプリケーションを https://hostname.pi314.jp/ という URL で利用できるように設定していくことにします。以下、"pi314.jp" 部分を皆さんが所有するドメイン名に置き換えて参照してください。

カスタムドメインを CIS に登録する際の最初の手順は利用ドメインの登録とネームサーバーの置き換えです。まず何はともあれ自分のドメインを CIS に管理させるために登録を行います。自分の CIS サービスを開き、Overview メニューから Add domain ボタンをクリックします：



画面右にウィザード形式のダイアログが現れるので、指示に従って入力していきます。まずは利用するドメイン（下図では pi314.jp）を入力して Next を選択します：



次の DNS レコード登録画面はスキップします。そのまま Next を選択：



最後にドメイン管理のためのネームサーバーを変更しろ、という以下のような画面が現れます：



DNS で利用するネームサーバーを CIS が管理するネームサーバーに変更する必要があります。この具体的な手順は独自ドメインを取得した業者によって異なりますが、プライマリネームサーバーとセカンダリネームサーバーをそれぞれ以下の内容に変更してください（画面は GoDaddy での DNS 管理画面のものです）：


　プライマリネームサーバー： ns012.name.cloud.ibm.com
　セカンダリネームサーバー： ns091.name.cloud.ibm.com


変更が完了したら、少し待ってから上図の Next を選択します。変更内容がネット上に反映されるまで少し時間が必要なので、すぐに実行すると「１時間後に再実行しろ」といった内容のエラーになるかもしれません。その場合は少し待ってから再実行してください。

無事に変更内容が確認できた場合は以下のような画面になります。最後に Done を選択：



CIS のコンソール画面に移動します。この時点で登録したカスタムドメインが Active になっていることが確認できます。これでドメインの登録とネームサーバーの置き換え作業は完了しました：



【CIS に DNS を登録し、エッジとサーバーの接続方法の選択】
ネームサーバーの置き換え後に行う必要があるのは、DNS 設定でカスタムドメインを使ったサーバー名（今回は hostname.pi314.jp）で実際に動いているサーバー（IKS の yaml ファイルで spec.tls.hosts に書かれた値、つまりウェブブラウザで動作確認した時の URL のサーバー名）にアクセスさせるための CNAME の登録と、カスタムドメインのエッジ証明書の作成（確認）、そして CIS のエッジサーバーから IKS のサーバーへどのような方法で接続するかの接続方法の選択です。すべて CIS コンソールから行います。

まずは CNAME を登録します。"Reliability" メニューから "DNS" タブを選択します。画面下部に "DNS records" 欄がありますが、おそらく最初は中身が空のはずです。ここに新しいレコードを作成するため、Add ボタンを選択します：



画面右に "Add record" ダイアログが表示されるので、ここで以下のように入力します：
　Type: "CNAME" を選択
　TTL: "Automatic" のまま
　Name: カスタムドメインを使ってアクセスさせるホスト名のドメインを抜いた部分
　　（例えば hostname.pi314.jp でアクセスさせたい場合であれば hostname）
　Alias domain name: 現在動いているサーバー名
　　（上述のウェブサーバーで動作確認した時に入力した IBM Cloud ドメインのサーバー名）

最後に Add ボタンをクリックします：



１つ前の画面に戻り、DNS records が１件追加されていることを確認し、Proxy を ON の状態にしておきます。これで DNS の登録も完了して、hostname.pi314.jp というホスト名で IKS で稼働中のアプリケーションを指し示すようになりました：



続けて https 接続のためのエッジ証明書を確認します。CIS コンソールから "Security" メニューを選び、画面下部に Edge certificates 欄を参照します。ここにはカスタムドメインとそのワイルドカード名（今回の例であれば pi314.jp と *.pi314.jp）のエッジ証明書が入力されていればそのままで大丈夫です（2021/06/23 時点の仕様では自動的に作成されているはずです）。もしもここが空になっていたら、右上の Add ボタンを押して、この２つを指定してエッジ証明書を追加してください：



最後に CIS のエッジサーバーと、実際のサーバーとの間の通信手段を選択します。同じ "Security" メニューの画面内の TLS mode を確認します（デフォルトは End-to-end CA signed）。ここでセキュリティ要件に合わせて通信方法を選択します。最もセキュリティが高いのは End-to-end CA signed ですが、この場合は別途ドメインのワイルドカード証明書を取得する必要があります。今回は１つ下の End-to-end flexible を選択します（自動発行する自己証明書を使った暗号化通信を行うモードです）。なおこれらの選択肢の違いについて、詳しくはこちらを参照ください：



以上で CIS コンソールでの作業も完了です。


【デプロイ設定を変更して IKS にアプリケーションを再デプロイ】

最後にデプロイ設定を変更してアプリケーションを再デプロイします。現在は IBM Cloud ドメイン名でアクセスされる前提でデプロイしていますが、今後はカスタムドメインを使ったアクセスを想定する必要があり、そのための変更を app_deployment_ingressample.yaml ファイルに反映させた上で再デプロイします。

この方法には２つあります。１つは旧サーバー名でのアクセスはできないようにした上でカスタムドメインでの新サーバー名のアクセスを許可する場合、もう１つは旧サーバー名でのアクセスを許可しながら（残しながら）カスタムドメインでの新サーバー名でもアクセスを許可する場合です。両方のケースを順に説明します。

まず旧サーバー名でのアクセスが不要になる場合は前者の（旧サーバー名ではアクセスできないようにする）ケースになります。この場合は app_deployment_ingressample.yaml ファイルの２箇所を以下のように書き換えます：

apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
#   - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    - hostname.pi314.jp
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
# - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
  - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

"#" で始まる行はコメントなので無くても構いません。要するに spec.tls.hosts と spec.rules.hosts の値を旧サーバー名ではなく新サーバー名に変更する、という作業が必要になります。

もう一方の、旧サーバー名でのアクセスを残しながら新サーバー名でもアクセスできるようにする場合は app_deployment_ingressample.yaml ファイルに新しい Ingress 設定を書き足す形で以下のように書き換えます：

apiVersion: v1
kind: Service
metadata:
  name: hostname
spec:
  selector:
    app: hostname
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hostname
spec:
  replicas: 1
  selector:
    matchLabels:
      app: hostname
  template:
    metadata:
      labels:
        app: hostname
    spec:
      containers:
      - name: hostname
        image: dotnsf/hostname
        ports:
        - containerPort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    secretName: yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000
  rules:
 - host: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: hostname.yourcluster-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-0000.jp-tok.containers.appdomain.cloud
spec:
  tls:
  - hosts:
    - hostname.pi314.jp
  rules:
 - host: hostname.pi314.jp
    http:
      paths:
      - path: /
        backend:
          serviceName: hostname
          servicePort: 8080

目的に応じた変更をした上で、改めて新しい yaml ファイルを使ってアプリケーションを再デプロイします：

$ kubectl apply -f yaml/app_deployment_ingresssample.yaml

再デプロイ後に新しいホスト名で https アクセスができるようになったことを確認します：



以上、CIS + IKS( + Ingress ) の環境でカスタムドメインを使った https アクセスを実現するための設定手順でした。CIS は今回紹介した DNS 関連の機能だけでなく、本来得意とするセキュリティ強化の機能が簡単に使える強みもあるので、IBM Cloud を使って k8s 環境のアプリケーションを安全に使う上での非常に便利なコンパニオンサービスだと感じています。

タグ ：

#ibm

#cloud

#cis

#iks

#k8s

#ingress

#custom

#domain

#ssl

普段、あまり Windows サーバーを使うことがない中でクラウド上の Windows サーバーにリモートデスクトップ接続をして作業する、という機会がありました。そこで遭遇したトラブルと、その解決方法の自分向け備忘録です。


まずは発生したトラブルの状況を説明します。某クラウド上に Windows サーバーインスタンスを作成・用意しました。ログイン時のクレデンシャル（ユーザー名＆パスワード）も分かっていて、サーバー・ネットワークへの VPN も接続したのでプライベート IP アドレス宛で接続することができるはず、という状況です：



いざリモートデスクトップ接続を試みます。コンピューター欄に IP アドレス、そしてユーザー名にはログイン用のクレデンシャルで確認したユーザー名（図では Administrator）を指定して「接続」します：



するとログインパスワードを聞かれます、ここまでは想定通り。同様にしてクレデンシャルで確認ずみのログインパスワードを入力して「OK」をクリック。これでリモートデスクトップ接続できるはず・・・：



・・・だったのですが、エラーが発生してログインに失敗してしまいました。入力ミスはしていないし、ネットワーク的に繋がっていない相手だとしたらパスワードを聞かれることもないし、、、原因はなんだろう？？　と、よく見るとユーザー名が入力した "Administrator" ではなく "Administrator@xxx.xxx" となっていました。なお "@xxx.xxx" 部分は会社のドメイン名です。何度か同じ手順を実行したのですが、常にこのドメイン名部分が自動的に（というか勝手に）付加されてしまい、正しいログインユーザー名ではなくなっていました。ログインエラーの原因はおそらくこれでしょう：



作業に使った Windows PC は会社貸与のもので、詳しくはわかりませんが会社の運用ポリシーに従って集中管理されているものです。おそらくですがその関係でリモートデスクトップ接続時のログインユーザー名に "@xxx.xxx" というドメイン名までが（自動的に）付与されてしまっているのだと思います。この辺りあまり詳しくないのですが、そう考えるとこの挙動自体は納得できるものではあります。

ただログインユーザー名が勝手に変更されてしまっては、いつまでたってもクラウドの Windows サーバーにログインすることができません。会社側の運用ポリシーに原因があるのだとすれば、その運用ポリシーを変更することでも解決できるかもしれませんが、残念ながら（多くのケースがそうであると想像しますが）自分は運用ポリシーを変更できるような立場ではありません。直接の原因の究明も去る事ながら、この状況を Windows ユーザー側の操作だけで解決する方法はないか？　というのが今回のブログテーマでした。


で、その応急処置的な解決方法がわかりました。先程のエラー画面内の「その他」と書かれた箇所をクリックします：



するとログインユーザーを選択する箇所が表示されるので、まずはここで「別のアカウントを使用する」を選択します：



改めてログインユーザー名とパスワードを入力する画面に遷移します。ここでログインユーザー名の頭に .\ を付けたものを指定します（パスワードは本来のものをそのまま指定します）。そして「OK」を押します：



環境によってはセキュリティ証明書に関する警告ダイアログが出ることがあるかもしれませんが、その場合は「はい」を選択します：



すると無事にリモート先の Windows デスクトップが表示されました！：



運用ポリシーによって会社ドメインが強制されてしまうようなケースでも、ログイン名の頭に .\ を付けることでログインユーザー名のドメインを強制指定して上書きすることでなんとかエラーが回避できるようでした。

タグ ：

#windows

#remote

#desktop

#rdp

#domain