Ubuntu Weekly Recipe

第774回Ubuntuへのログイン認証をAzure ADで行う方法

誰もが自由にコンピューターやサービスを勝手に利用できてしまっては、セキュリティ上問題があります。そこで現代的なOSやWebサービスは、使用開始前にユーザー名とパスワード(あるいはセキュリティキーや生体情報など)を利用し、自分が正当な利用者であることを証明しなくてはなりません。この行為を「認証」と呼びます。Ubuntuでもインストール時にユーザーを作成し、ログイン用のパスワードを設定しますよね。

家庭内の個人利用であれば、こうしたOS単位のユーザー認証でも問題ありません。しかし企業などでは、社員ごとにIDを発行し、そのIDを使って様々なITリソースへの認証を一元管理できると便利です。こうした要望を実現するため、従来ではActive DirectoryやOpenLDAPなどが利用されてきました。

Active Directoryはオンプレミスに設置し、組織内に閉じた使い方をするのが前提のディレクトリサービスです。しかし近年では、クラウドサービスの利用の拡大や、テレワークの普及によって、オンプレミスのディレクトリサービスではカバーし切れないケースが出てきました。

そこで、ID管理自体もクラウド化する流れが加速しています。この分野でよく利用されているのが、Microsoft Azure(以下Azure)のサービスのひとつである「Azure Active Directory(以下Azure AD⁠⁠」です。Ubuntuも23.04から、Azure ADを利用したユーザー認証機能が提供されています。本記事ではUbuntu 23.04を使い、Azure ADのユーザーでUbuntuへログインするための手順を紹介します。

なおAzure ADは、今後「Microsoft Entra ID」に表記が変更されることが発表されていますが、本記事では従来通り「Azure AD」の名称で表記します。

Azure ADのセットアップ

Azureにサインアップ済みであること、またAzure ADを設定できるだけの組織の権限を持っていることを前提に解説します。

Azure Portalにログインしたら、左側サイドペインの「Azure Active Directory」から「アプリの登録⁠⁠→⁠新規登録」とクリックします。

図1 アプリの新規登録をクリック
図1

アプリケーションの名前を入力します。ここでは「ubuntu-test」としました。⁠サポートされているアカウントの種類」「この組織ディレクトリのみに含まれるアカウント」を選択してください。リダイレクトURIは空欄のままで構いません。

図2 アプリ名とアカウントの種類を決めて「登録」をクリック
図2

アプリの登録ができたら、左側サイドペインの「Azure Active Directory」から「アプリの登録⁠⁠→⁠所有しているアプリケーション」をクリックしてください。⁠ubuntu-test」がリストアップされているはずですので、ここをクリックして詳細画面に入ります。

図3 アプリの登録ができた状態
図3

「概要」をクリックすると、登録したアプリケーションの情報が表示されます。アプリケーションIDとテナントIDを控えておいてください。これはあとでUbuntu側の設定に使います。

図4 アプリケーションIDとテナントIDを控えておく
図4

続いて「認証」をクリックします。ここで「パブリッククライアントフローを許可する」「はい」に切り替えてください。

図5 パブリッククライアントフローを許可する設定に変更して、⁠保存」をクリックする
図5

最後にAzureのサービスの「エンタープライズアプリケーション」から「ubuntu-test」を開き、⁠アクセス許可」をクリックします。⁠(組織名)に管理者の同意を与えます」というボタンが表示されているので、これをクリックします。

図6 組織の管理者の同意を与える
図6
図7 ⁠管理者の同意」にSign in and read user profileの権限が追加されればOK
図7

これでAzure AD側のセットアップは完了です。

aad-authのセットアップ

続いてログインするUbuntu側を設定しましょう。これはsudoできるローカルユーザーでログインして作業します。

以下のコマンドを実行して、libpam-aadパッケージとlibnss-aadパッケージをインストールします。これにより自動的に/etc/nsswitch.confと/etc/pam.d/common-authに、aadを利用する設定が追記されます。

$ sudo apt install -y libpam-aad libnss-aad

続いて、以下のコマンドを実行します。これはネットワークユーザーがUbuntuにはじめてログインした際に、自動的にホームディレクトリを作成する設定です。

$ sudo pam-auth-update --enable mkhomedir

最後にAzure ADアプリケーションの設定を行います。/etc/aad.confをテキストエディタで開いてください。

以下のように、ファイル冒頭にtenant_id行とapp_id行がコメントアウトされていますので、行頭の#を削除してコメントアウトを解除した上で、先ほど控えたテナントIDとアプリケーションIDに書き換えてください。

### required values
## See https://docs.microsoft.com/en-us/azure/active-directory/develop/howto-create-service-principal-portal
## for more information on how to set up an Azure AD app.
# tenant_id = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
# app_id = yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy

以上で設定は終了です。OSの再起動などは必要ありません。

Azure ADを使ったUbuntuへのログイン

一度Ubuntuからログアウトし、ログイン画面を表示してください。Azure ADのユーザーはローカルに存在しないため、ユーザー一覧に表示されません。そこでここで「アカウントが見つかりませんか?」をクリックして、ユーザー名を直接入力します。

図8 Azure ADのユーザー名(mizuno@hoge.onmicrosoft.comなど)を入力する
図8

続いてAzure ADのパスワードを入力すれば、Ubuntuにログインすることが可能です。

図9 Azure ADのユーザーでログインした状態。⁠@hoge.onmicrosoft.com」のユーザー名でログインできており、その名前のホームディレクトリが作成されていることがわかる
図9

なおAzure ADによる認証は、GUIでのログインだけでなく、SSH経由のログインでも利用できます。そのためサーバーのユーザーをAzure ADで管理するといった用途にも使えます。

オフライン認証

先ほど編集した/etc/aad.confには、以下のような設定がありました。

# offline_credentials_expiration = 90 ; duration in days a user can log in without online verification

コメントに書かれている通り、これはユーザーがオンライン認証なしでログインできる期間です。一度オンライン認証をパスしてログインに成功すると、aad-authはその情報を/var/lib/aad/cache/以下に、ここで設定された日数が経過するまでキャッシュします。そしてキャッシュが有効な間は、改めてオンライン認証をせずとも、ログインできるのです。これによって強制的にオフラインになってしまう場所、例えば飛行機での移動中や、知床の山中でも、オンラインIDでUbuntuを使えるというわけです。

キャッシュの有効期限は、デフォルトで90日となっています。変更したい場合は、この行のコメントを解除した上で、数値を書き換えてください。またここに負数を設定すると、オフライン認証自体を無効にすることができます。

なおキャッシュが切れた状態でオフライン認証を行おうとすると、当然アクセスは拒否されます。例えばキャッシュの保持期限を1日に設定した状態で、2023-08-03 09:45:19に一度オンラインで認証を行った後、2023-08-04 11:35:20にオフライン認証を試みた際のログが以下のものです。

 8月 04 11:35:20 lunar gdm-password][6169]: pam_aad(gdm-password:auth): try to authenticate "[email protected]" from cache
 8月 04 11:35:20 lunar gdm-password][6169]: pam_aad(gdm-password:auth): getting user information from cache for "[email protected]"
 8月 04 11:35:20 lunar gdm-password][6169]: pam_aad(gdm-password:auth): Last online login was: 2023-08-03 09:45:19 +0900 JST. Current time: 2023-08-04 11:35:20.316946207 +0900 JST m=+14.465847911.
 8月 04 11:35:20 lunar gdm-password][6169]: pam_aad(gdm-password:auth): Online revalidation needed every 1 days
 8月 04 11:35:20 lunar gdm-password][6169]: pam_aad(gdm-password:auth): authenticating user "[email protected]" from cache failed: offline credentials expired. Denying access.

offline credentials expired. Denying accessと言われているのがわかります。キャッシュが期限切れになってしまった場合は、一度オンラインに接続した状態で、再度認証を行ってください。

aad-cliでAzure ADの構成を確認する

Azure ADの現在の構成は、aad-cliコマンドで確認することができます。

aad-cli configで現在のAzureテナントの情報を表示します。

$ aad-cli config
[default]
tenant_id                      = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
app_id                         = yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
offline_credentials_expiration = 90
homedir                        = /home/%f
shell                          = /bin/bash

aad-cli userで、現在ログインしているユーザーの情報を表示します。

$ aad-cli user
login            = [email protected]
password         = x
uid              = 2976482976
gid              = 2976482976
gecos            = 
home             = /home/[email protected]
shell            = /bin/bash
last_online_auth = 2023-08-04T11:40:09+09:00
shadow_password  =

--allオプションをつけると、全ユーザーをリスト表示します。

$ aad-cli user --all
[email protected]
(...略...)

その他、より詳しくはaad-cliのヘルプを参照してください。

トラブルシューティング

この手の設定作業を行っていると、慣れないうちはAzure側の設定不備などで、うまくログインができないといったトラブルに遭遇しがちです。筆者も遭遇しました。このような時のトラブルシューティング方法を紹介します。

まずpam_aadのデバッグログを有効化しましょう。/etc/pam.d/common-authを以下のように書き換えてください。

auth [success=1 default=ignore] pam_aad.so
↓
auth [success=1 default=ignore] pam_aad.so debug

その状態でログインを試行してみましょう。出力されたエラーログは、journalctlコマンドで参照できます。

$ journalctl -b0 | grep pam_aad

Azure側からエラーコードが返ってきていたら、そのエラーコードの意味を調べましょう。これはMicrosoftのエラーコードの確認ページにエラーコードを入力することで、調べることが可能です。

例えば筆者の場合、以下のようなエラーがログに出力されていました。

 8月 02 10:52:02 lunar gdm-password][1863]: pam_aad(gdm-password:auth): Connecting to "https://login.microsoftonline.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx", with clientID "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" for user "[email protected]"
 8月 02 10:52:02 lunar gdm-password][1863]: pam_aad(gdm-password:auth): Unknown error code(s) from server: [65001]

調べてみたところ、エラーコード65001は「The user or administrator has not consented to use the application with ID '{identifier}'{namePhrase}. Send an interactive authorization request for this user and resource.」という意味でした。これは検証中、前述の、アプリケーションに組織の管理者の同意を与える手順を省略してしまっていたのが原因でした。こちらのページも参考になりますので、トラブルシューティングの際には目を通してみてください。

おすすめ記事

記事・ニュース一覧