はじめに
これから試す内容は下記 Microsoft の公開情報に書いてある内容を基に、実際に動作検証をした内容になります。
-参考情報
CentOS Linux 仮想マシンを Azure AD Domain Services のマネージド ドメインに参加させる
URL:https://docs.microsoft.com/ja-jp/azure/active-directory-domain-services/join-centos-linux-vm#configure-the-hosts-file
-参考情報
プレビュー:Azure Active Directory 認証を使用して Azure の Linux 仮想マシンにログインする
URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad
1 つ目は、Azure AD DS のドメインに CentOS をコンピューターとして参加させ、Azure AD ユーザーで SSH 接続ができるかを試しました。
2 つ目は、パブリック プレビューの機能である「Azure AD の資格情報を使用してログインする」を使って CentOS に Azure AD ユーザーで SSH 接続できるかを試してみました。
CentOS を含む Linux OS を Azure AD DS のドメインに参加させるメリットの 1 つとして、Azure AD (オンプレ AD から Azure AD Connect 経由で同期されたユーザーも含む) から Azure AD DS に同期されたユーザーの資格情報を利用して Linux OS に SSH 接続できる、という点があります。
つまり、CentOS 上でユーザーを作成して管理する必要がなくなる上に、Azure AD DS のロックアウト ポリシーなどを効かすこともできる、というメリットがあります。
また、 CentOS の場合 CentOS 6 および CentOS 7 系であれば、パブリック プレビューの機能ではありますが、Azure AD の資格情報を使用してログインする という機能が使えるため、Azure AD DS のマネージド ドメインに参加させる必要もなく Azure AD ユーザーで SSH 接続できるようになりました。
パブリック プレビューの機能だけを確認したい方は、こちらのリンクから該当の手順に飛んでご覧ください。
やってみる
CentOS の以下 2 つのバージョンで SSH 接続をためしてみました。
| OS | 認証方法 |
|---|---|
| CentOS 8.1 | Auzre AD DS ドメイン参加後 SSH 接続 |
| CentOS 7.5 | Azure AD の資格情報を使用してログインする (プレビュー) の機能で SSH 接続 |
CentOS 8.1 で仮想マシンを作成すると下記画面ショットのように「Azure AD の資格情報を使用してログインする」の機能がサポートされていないため、有効化できません。
※後からわかったのですが、CentOS はすべての OS バージョンにおいて Azure ポータルからは有効にできないため、Azure CLI にて後から拡張機能をインストールする必要があります。
Microsoft の公開情報によると、下記 Linux ディストリビューションとバージョンがサポートされているようです。
-参考情報
プレビュー:Azure Active Directory 認証を使用して Azure の Linux 仮想マシンにログインする サポートされている Azure リージョンと Linux ディストリビューション
URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#supported-azure-regions-and-linux-distributions
この機能のプレビュー期間中は、次の Linux ディストリビューションがサポートされます。
| Distribution | Version |
|---|---|
| CentOS | CentOS 6、CentOS 7 |
| Debian | Debian 9 |
| openSUSE | openSUSE Leap 42.3 |
| RedHat Enterprise Linux | RHEL 6、RHEL 7 |
| SUSE Linux Enterprise Server | SLES 12 |
| Ubuntu Server | Ubuntu 14.04 LTS、Ubuntu Server 16.04、Ubuntu Server 18.04 |
Azure AD DS マネージド ドメインに参加して Azure AD ユーザーでSSH 接続する手順
SSH で対象のコンピューターに接続した後に下記のように hosts ファイルを構成します。
ローカルホストに指定しているのは、Azure AD DS のマネージド ドメイン名と、そのドメインに参加するコンピューターのホスト名になります。
[root@CentOS-001 etc]# diff ./hosts ./hosts.org
1c1
< 127.0.0.1 adds001.work CentOS-001
---
> 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
次に yum コマンドで Azure AD DS に参加するために必要なパッケージをインストールします。
[root@CentOS-001 etc]# yum install realmd sssd krb5-workstation krb5-libs oddjob oddjob-mkhomedir samba-common-tools
CentOS-8 - AppStream 25 kB/s | 3.5 kB 00:00
CentOS-8 - Base 515 kB/s | 3.1 kB 00:00
CentOS-8 - Extras 2.3 kB/s | 1.5 kB 00:00
Package realmd-0.16.3-16.el8.x86_64 is already installed.
Package sssd-2.2.0-19.el8_1.1.x86_64 is already installed.
Package krb5-libs-1.17-9.el8.x86_64 is already installed.
Dependencies resolved.
==============================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================
Installing:
oddjob x86_64 0.34.4-7.el8 AppStream 83 k
oddjob-mkhomedir x86_64 0.34.4-7.el8 AppStream 52 k
krb5-workstation x86_64 1.17-9.el8 BaseOS 940 k
samba-common-tools x86_64 4.10.4-101.el8_1 BaseOS 469 k
Installing dependencies:
libkadm5 x86_64 1.17-9.el8 BaseOS 184 k
psmisc x86_64 23.1-3.el8 BaseOS 151 k
samba-libs x86_64 4.10.4-101.el8_1 BaseOS 185 k
Transaction Summary
==============================================================================================================================
Install 7 Packages
Total download size: 2.0 M
Installed size: 6.1 M
Is this ok [y/N]: Y
Downloading Packages:
(1/7): oddjob-mkhomedir-0.34.4-7.el8.x86_64.rpm 60 kB/s | 52 kB 00:00
(2/7): krb5-workstation-1.17-9.el8.x86_64.rpm 1.0 MB/s | 940 kB 00:00
(3/7): oddjob-0.34.4-7.el8.x86_64.rpm 88 kB/s | 83 kB 00:00
(4/7): libkadm5-1.17-9.el8.x86_64.rpm 751 kB/s | 184 kB 00:00
(5/7): psmisc-23.1-3.el8.x86_64.rpm 388 kB/s | 151 kB 00:00
(6/7): samba-libs-4.10.4-101.el8_1.x86_64.rpm 792 kB/s | 185 kB 00:00
(7/7): samba-common-tools-4.10.4-101.el8_1.x86_64.rpm 1.0 MB/s | 469 kB 00:00
------------------------------------------------------------------------------------------------------------------------------
Total 1.5 MB/s | 2.0 MB 00:01
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : psmisc-23.1-3.el8.x86_64 1/7
Installing : oddjob-0.34.4-7.el8.x86_64 2/7
Running scriptlet: oddjob-0.34.4-7.el8.x86_64 2/7
Installing : samba-libs-4.10.4-101.el8_1.x86_64 3/7
Installing : libkadm5-1.17-9.el8.x86_64 4/7
Installing : krb5-workstation-1.17-9.el8.x86_64 5/7
Installing : samba-common-tools-4.10.4-101.el8_1.x86_64 6/7
Installing : oddjob-mkhomedir-0.34.4-7.el8.x86_64 7/7
Running scriptlet: oddjob-mkhomedir-0.34.4-7.el8.x86_64 7/7
Verifying : oddjob-0.34.4-7.el8.x86_64 1/7
Verifying : oddjob-mkhomedir-0.34.4-7.el8.x86_64 2/7
Verifying : krb5-workstation-1.17-9.el8.x86_64 3/7
Verifying : libkadm5-1.17-9.el8.x86_64 4/7
Verifying : psmisc-23.1-3.el8.x86_64 5/7
Verifying : samba-common-tools-4.10.4-101.el8_1.x86_64 6/7
Verifying : samba-libs-4.10.4-101.el8_1.x86_64 7/7
Installed:
oddjob-0.34.4-7.el8.x86_64 oddjob-mkhomedir-0.34.4-7.el8.x86_64 krb5-workstation-1.17-9.el8.x86_64
samba-common-tools-4.10.4-101.el8_1.x86_64 libkadm5-1.17-9.el8.x86_64 psmisc-23.1-3.el8.x86_64
samba-libs-4.10.4-101.el8_1.x86_64
Complete!
次に、「realm discover」コマンドを使い、参加する対象の Azure AD DS マネージド ドメインを探します。
正常に検索出来た場合は、下記のような応答が返ってきます。
[root@CentOS-001 etc]# realm discover adds001.work
adds001.work
type: kerberos
realm-name: ADDS001.WORK
domain-name: adds001.work
configured: no
server-software: active-directory
client-software: sssd
required-package: oddjob
required-package: oddjob-mkhomedir
required-package: sssd
required-package: adcli
required-package: samba-common-tools
意図的に存在しないドメインを指定すると、見つからない旨のメッセージが返ってきます。
[root@CentOS-001 etc]# realm discover adds001.work2
realm: No such realm found: adds001.work2
次に「kinit」コマンドを使い、Kerberos を初期化します。
ここで指定するユーザーは既に Azure AD から Azure AD DS に同期されているユーザーを指定します。
また、公開情報にも記載されていますが、マネージド ドメイン名の名前は すべて大文字 で指定する必要があります。
大文字を指定しないと以降のドメイン参加に KDC reply did not match expectations while getting initial credentials と表示 (ドメインが小文字と怒られて) されて失敗します。
[root@CentOS-001 etc]# kinit admin001@ADDS001.WORK
Password for admin001@ADDS001.WORK:
最後に、「realm join」コマンドを使い、Azure AD DS マネージド ドメインに参加します。
この時に指定するユーザーはさきほど kinit コマンドで指定したユーザーと同じユーザーを指定して実行します。
また、マネージド ドメイン名も必ず 大文字 で指定してください。
※ここでパッケージが不足している (Necessary packages are not installed) などの理由で怒られる場合は、必要なパッケージを yum コマンドでインストールしてください。
もう 1 つハマりポイントとして、「realm join」コマンドを実行してドメインに参加するためには、Azure AD の「AAD DC Administrators」グループに所属しているユーザーで実行する必要があります。下記グループです。
このグループに所属していないユーザーで「realm join」コマンドを実行しても「realm: Couldn't join realm: Insufficient permissions to join the domain」と言われ、ドメインに参加する権限がないと怒られます。
下記のとおり「AAD DC Administrators」グループに参加したユーザーで実行するとドメインの参加に成功します。
[root@CentOS-001 etc]# realm join --verbose ADDS001.WORK -U 'admin001@ADDS001.WORK'
* Resolving: _ldap._tcp.adds001.work
* Performing LDAP DSE lookup on: 10.0.128.4
* Performing LDAP DSE lookup on: 10.0.128.5
* Successfully discovered: adds001.work
Password for admin001@ADDS001.WORK:
* Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/sssd, /usr/sbin/adcli
* LANG=C /usr/sbin/adcli join --verbose --domain adds001.work --domain-realm ADDS001.WORK --domain-controller 10.0.128.4 --login-type user --login-user admin001@ADDS001.WORK --stdin-password
* Using domain name: adds001.work
* Calculated computer account name from fqdn: ADDS001
* Using domain realm: adds001.work
* Sending netlogon pings to domain controller: cldap://10.0.128.4
* Received NetLogon info from: YPQT7E6FN35QB2T.adds001.work
* Wrote out krb5.conf snippet to /var/cache/realmd/adcli-krb5-RUnvLC/krb5.d/adcli-krb5-conf-Gni9DF
* Authenticated as user: admin001@ADDS001.WORK
* Looked up short domain name: ADDS001
* Looked up domain SID: S-1-5-21-725261351-3815095135-1752245733
* Using fully qualified name: adds001.work
* Using domain name: adds001.work
* Using computer account name: ADDS001
* Using domain realm: adds001.work
* Calculated computer account name from fqdn: ADDS001
* Generated 120 character computer password
* Using keytab: FILE:/etc/krb5.keytab
* Computer account for ADDS001$ does not exist
* Found well known computer container at: OU=AADDC Computers,DC=adds001,DC=work
* Calculated computer account: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Encryption type [16] not permitted.
* Encryption type [23] not permitted.
* Encryption type [3] not permitted.
* Encryption type [1] not permitted.
* Created computer account: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Sending netlogon pings to domain controller: cldap://10.0.128.4
* Received NetLogon info from: YPQT7E6FN35QB2T.adds001.work
* Set computer password
* Retrieved kvno '2' for computer account in directory: CN=ADDS001,OU=AADDC Computers,DC=adds001,DC=work
* Checking RestrictedKrbHost/adds001.work
* Added RestrictedKrbHost/adds001.work
* Checking RestrictedKrbHost/ADDS001
* Added RestrictedKrbHost/ADDS001
* Checking host/adds001.work
* Added host/adds001.work
* Checking host/ADDS001
* Added host/ADDS001
* Discovered which keytab salt to use
* Added the entries to the keytab: ADDS001$@ADDS001.WORK: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/ADDS001@ADDS001.WORK: FILE:/etc/krb5.keytab
* Added the entries to the keytab: host/adds001.work@ADDS001.WORK: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/ADDS001@ADDS001.WORK: FILE:/etc/krb5.keytab
* Added the entries to the keytab: RestrictedKrbHost/adds001.work@ADDS001.WORK: FILE:/etc/krb5.keytab
* /usr/bin/systemctl enable sssd.service
* /usr/bin/systemctl restart sssd.service
* /usr/bin/sh -c /usr/bin/authselect select sssd with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service
Profile "sssd" was selected.
The following nsswitch maps are overwritten by the profile:
- passwd
- group
- netgroup
- automount
- services
Make sure that SSSD service is configured and enabled. See SSSD documentation for more information.
- with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module
is present and oddjobd service is enabled
- systemctl enable oddjobd.service
- systemctl start oddjobd.service
Created symlink /etc/systemd/system/multi-user.target.wants/oddjobd.service → /usr/lib/systemd/system/oddjobd.service.
* Successfully enrolled machine in realm
この時点で Azure AD DS の 「AADDC Computers」OU を確認してみると、それらしいコンピューターが参加されていることが確認できます。
Azure VM 作成時に既定では SSH 公開鍵認証が選択されています。
パスワード認証を有効化するためには、sshd_config の PasswordAuthentication を有効化します。
VM 作成時にパスワード認証を選択されている場合は、既にこの設定値は「yes」になっています。
[root@CentOS-001 ssh]# pwd
/etc/ssh
[root@CentOS-001 ssh]# cat ./sshd_config | grep PasswordAuthentication
#PasswordAuthentication yes
PasswordAuthentication yes
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication, then enable this but set PasswordAuthentication
Azure AD DS の「AAD DC Administrators」グループ内のメンバーに対して sudo 権限を付与するための設定を行います。
sudo visudo
[root@CentOS-001 etc]# diff ./sudoers ./sudoers.org
121,123d120
<
< # Add 'AAD DC Administrators' group members as admins.
< %AAD\ DC\ Administrators@adds001.work ALL=(ALL) NOPASSWD:ALL
準備が整ったので、SSH クライアントから Azure AD から同期した Azure AD DS ユーザー (admin001@adds001.work) で対象の CentOS に SSH 接続できるか確認してみます。
問題なく接続できました。
sudo で root 権限が持てるか試してみます。
[admin001@adds001.work@CentOS-001 ~]$ sudo su -
Last login: Sat May 2 16:55:36 UTC 2020 on pts/0
Last failed login: Sat May 2 17:24:28 UTC 2020 from 209.141.55.11 on ssh:notty
There were 2 failed login attempts since the last successful login.
[root@CentOS-001 ~]#
[root@CentOS-001 ~]#
問題なく root に昇格できました。
以上で、Azure AD DS のマネージド ドメインへの参加、Azure AD ユーザーによる SSH 接続の手順は完了になります。
次はもう 1 パターン、パブリック プレビュー機能である「Azure Active Directory 認証を使用して SSH 接続する手順」を試してみます。
Azure Active Directory 認証を使用して SSH 接続する手順
こちらの手順については、Azure VM 作成時にもしくは作成後に Azure VM の拡張機能をインストールするだけなので、何ら難しい作業は必要ありません。
拡張機能のインストール手順は、下記公開情報にも記載されています。
-参考情報
Azure AD ログイン VM 拡張機能をインストールする
URL:https://docs.microsoft.com/ja-jp/azure/virtual-machines/linux/login-using-aad#install-the-azure-ad-login-vm-extension
色々試してみましたが、RHEL や Ubuntu OS は下記画面ショットのように Azure ポータルの仮想マシン作成の画面より「Azure AD の資格情報を使用してログインする」より機能を有効化することができましたが、CentOS の場合はサポートしている、とされている CentOS 6系 7 系いずれにおいても VM 作成時には有効化することができませんでした。
従って、上記公開情報に記載されている VM 拡張機能をインストールして試してみます。
まず、Azure ポータルから Cloud Shell を起動し、公開情報に書かれているとおり、以下コマンドレットを実行し VM 拡張機能をインストールします。
myResourceGroup と myVM は適宜実行対象の環境の名前に置き換えて実行してください。
az vm extension set \
--publisher Microsoft.Azure.ActiveDirectory.LinuxSSH \
--name AADLoginForLinux \
--resource-group myResourceGroup \
--vm-name myVM
インストールに成功すると、下記画面ショットのように provisioningState が Succeeded と出力されます。
次に対象の仮想マシンにたいして、SSH 接続するために必要な RBAC (ロールベース アクセス制御)のロールを割り当てます。
公開情報にも書いてある通り、仮想マシンの「所有者」や「共同作成者」ロールが割り当てられているユーザーも SSH 接続はできません。
従って明示的に 仮想マシンの管理者ログイン もしくは 仮想マシンのユーザー ログイン のロールを割り当てる必要があります。
上記画面ショットのように Azure ポータルから割り当てても問題ありませんが、せっかく Cloud Shell を開いているのでこのまま下記のように az role assignment create コマンドレットにて「仮想マシンの管理者ログイン」の割り当てをやってみます。
また、公開情報では username が Cloud Shell の実行ユーザーを指定していますが、「Azure AD DS マネージド ドメインに参加して Azure AD ユーザーでSSH 接続する手順」の項目では「AAD DC Administrators」グループに所属しているユーザーに対して SSH できる権限を付与しました。
ですので、assignee の対象を「AAD DC Administrators」にするために、下記のとおり、グループ名「AAD DC Administrators」から objectId を抽出して「--assignee-object-id」オプションで指定するコマンドに修正しています。
※下記で引数と指定している myResourceGroup と myVM は適宜実行対象の環境の名前に置き換えて実行してください。
groupid=$(az ad group list --filter "displayname eq 'AAD DC Administrators'" --query "[].objectId" --output tsv)
vm=$(az vm show --resource-group myResourceGroup --name myVM --query id -o tsv)
az role assignment create \
--role "Virtual Machine Administrator Login" \
--assignee-object-id $groupid \
--scope $vm
下記画面ショットは実行に成功した例となります。
これで Azure AD ユーザーで SSH 接続できる準備が整いました。
さっそく SSH クライアントから接続してみましょう。
公開情報には ssh -l コマンドにて指定していますが、SSH クライアントを使って初めて Linux OS の Azure VM に SSH 接続する時のイメージを知って欲しいので、以下内容を記載します。
Azure AD DS のマネージド ドメインに参加する際には、「ユーザー名」と「パスワード」を利用して認証をしますが、この 「Azure Active Directory 認証」の VM 拡張機能を利用する場合は、「インタラクティブ認証」にて SSH 接続する必要があります。
例えば、Tera Term を使う場合には、下記画面ショットのように「キーボードインタラクティブ認証を使う」を選択して認証してください。
だだし、ここで注意点があります。
これは嘘のような本当の話ですが、Tera Term でインタラクティブ認証をする場合、下記画面ショットのように肝心の認証コードが画面に収まらなくて見ることができません…。
ですので、TeraTerm を使う場合は、一度踏み台サーバーなどから SSH 接続済みの状態でプロンプトから SSH 接続する必要がありそうです。
Tera Term だと実際の画面をお見せできないので PuTTY で試してみます。
PuTTY の login as にて「AAD DC Administrators」グループのメンバーである Azure AD ユーザーを指定して Enter を押下すると、下記画面ショットのように code を入力するように要求されます、code の入力先の URL は「https://microsoft.com/devicelogin 」になります。アクセスしてみましょう。
下記画面ショットのように PuTTY の画面上に表示されていた code を入力 (ペースト) し、「次へ」をクリックします。
認証を行うユーザーが一覧にない場合は「別のアカウントを使用する」をクリックします。
対象の Azure AD ユーザーを入力し「次へ」をクリックします。
パスワードを入力し「サインイン」をクリックします。
サインインが完了しました。このウィンドウは記載されているとおり閉じてしまって問題ありません。
PuTTY の画面上で Enter を押下すると下記画面ショットのように対象の CentOS マシンに Azure AD ユーザーで接続できることが確認できました。
一般ユーザーから sudo する時にも同じように code 認証が求められますが、再認証を必要としない場合は、下記「aad_admins」ファイルを編集することで再認証をスキップすることができます。
[root@centos-002-7 sudoers.d]# diff ./aad_admins ./aad_admins.org
1c1
< %aad_admins ALL=(ALL) NOPASSWD:ALL
---
> %aad_admins ALL=(ALL) ALL
\ No newline at end of file
こんな感じですね。
[admin001@adds001.work@centos-002-7 ~]$ sudo su -
Last login: Sun May 3 17:28:21 UTC 2020 on pts/0
[root@centos-002-7 ~]#
ここからはおまけですが、Azure AD ユーザーで認証をしているので、条件付きアクセスを使って SSH 接続認証時に多要素認証を要求させることもできます。イメージとしては以下のような感じになります。
デバイスの code 認証をまず行います。code を入力して「次へ」をクリックします。
アカウントが一覧にない場合は「別のアカウントを使用する」をクリックします。
ユーザー名を入力して「次へ」をクリックします。
パスワードを入力して「サインイン」をクリックします。
ここまでが通常の資格情報を利用した認証です。
下記画面ショットのように Microsoft Authenticator アプリを開いて応答してくださいと表示されます。
これは予め対象のユーザーで Microsoft Authenticator アプリのセットアップをして、このアプリを使って多要素認証をするように設定されているためです。
Microsoft Authenticator アプリをいれているスマートフォンには、以下のような通知が飛んできますのでタップします。
サインインを承認しますか？と表示されるので、「承認」をタップします。
これで多要素認証が完了したので、下記画面を閉じて、PuTTY 側の画面で Enter を押下し、SSH 接続が完了します。
おわりに
今回は Azure VM 上の CentOS を Azure AD ユーザーを使って SSH 接続するために、「Azure AD DS のマネージド ドメイン」に参加して実現する方法と、パブリック プレビュー機能である「Azure Active Directory 認証」を使用して SSH 接続する手順 2 種類のパターンをそれぞれ動作検証してみました。
両方の手順をご覧になっていただいた方はお気づきかと思いますが、後者のパブリック プレビュー機能を使った方が圧倒的に設定が楽です。
理由は Azure AD DS 環境をそもそも用意する必要もなく、Cloud Shell (Azure CLI) の中で完結できる作業だからです。
一方でまだ Azure VM の拡張機能である「Azure Active Directory 認証」は「パブリック プレビュー」機能、つまり、GA (正規版) ではない、という懸念点があります。
運用上本番環境には GA 版しか使ってはいけないというルールがある環境においては Azure AD DS に参加させるという選択の方が現時点では適切かもしれません。
希望的観測ではありますが、このパブリック プレビューの機能は Linux OS に限らず Windows OS にも利用出来て非常に便利です。
Azure AD ユーザーを使って認証するため、お見せしたとおり多要素認証を要求させることもできるため、認証セキュリティの向上も図れます。
このような観点からも、具体的にいつになるかは分かりませんが、 GA される機能だと個人的には思っています。
今回の記事が少しでも参考になれば幸いです。