Linux システムを Active Directory ドメインに参加させる方法

Microsoft の Active Directory (AD) は、多くの組織で利用されているディレクトリサービスです。もしあなたとあなたのチームが Windows と Linux の混在環境を担当しているなら、おそらく両方のプラットフォームの認証を一元化したいとお考えでしょう。この記事では、Linux コンピュータを Active Directory ドメインに追加する方法について説明します。

Active Directory と一元的なアクセス管理の必要性

Microsoft の Active Directory (通称 AD) は、長年にわたりエンタープライズ・アクセス管理の市場で圧倒的なシェアを占めてきました。世界中の機関や個人が、組織に属するリソースへのアクセスを集中管理するために使用しています。これにより、ユーザー、パスワード、コンピュータなどのリソースを管理し、誰が何にアクセスできるかを指示できます。この記事を読んでいる方の中には、特に大きな機関で働いている方は、以前 AD を使ったことがあるでしょう。通常、その操作は、組織内のどのワークステーションにも 1 組のログイン資格情報を使用してログインするというものです。それは巨大な氷山の一角にすぎません。

ある会社に 40 台のコンピュータシステムと 70 人のユーザーがいると想像してみてください。一部の従業員はシフト制で働き、他の従業員は通常時間帯に働きます。印刷にアクセスできる人もいれば、できない人もいます。従来の作業方法は、ユーザーがアクセスする必要のある各コンピュータにローカル・ユーザー・アカウントを作成することです。エンドユーザー・サポート・チームの作業負荷を想像してみてください。ユーザーが何らかの理由でパスワードを変更した場合、同期を保つために、以前アクセスできたすべてのコンピュータでパスワードを変更する必要があります。あっという間に混乱状態になるでしょう。さて、スタッフが 2 人辞職したと想像してみてください。人員やワークステーションに変更があるたびに繰り返さなければならない単調な作業については、言うまでもありません。IT チームにとって、これは悪夢です。革新的なタスクに使えるはずの時間が、今や車輪の再発明に費やされています。プリンターへのアクセス管理については、まだ触れてもいません。

ここで Active Directory のようなディレクトリサービスが活躍します。文字通り、救世主になり得ます。Active Directory を使用すると、各ユーザーは 1 組の資格情報を持ち、中央のデータベースにオブジェクトとして一意に作成されます。各コンピュータシステムもオブジェクトとして作成されます。自動的に、すべてのユーザーが同じ資格情報セットで、すべてのワークステーションにアクセスできます。アカウントの変更が必要な場合は、中央のデータベースで 1 回行うだけです。スタッフは同じ資格情報セットを使用してプリンターにアクセスできます。プリンターの認証メカニズムを AD と連携させることで、それを実現できます。ユーザーも IT チームもハッピーです。

[ 関連記事: SAML を使用して Active Directory Federation Services (ADFS) 認証を Red Hat SSO と統合する方法. ]

グループや組織単位 (OU) を使用して、さまざまなリソースへのアクセスを調整し、維持することができます。さらに良くなることもあります。このディレクトリには、スタッフの電話番号、メールアドレスを保存でき、拡張して他の情報を保存することもできます。誰かが辞職した場合はどうでしょうか？ 問題ありません。単にユーザーのアカウントを無効にするだけです。その人のすべてのリソースへのアクセスは、その場ですぐに無効になります。組織が大きければ大きいほど、一元管理の必要性が高まります。時間を節約し、感情的な負担も減らします。

その核となるディレクトリサービスは、組織内のすべてのリソースを項目別に整理し、それらのリソースへの容易なアクセスを促進する方法にすぎません。基本的に、AD は一種の分散データベースであり、Lightweight Directory Access Protocol (LDAP) を介してリモートでアクセスされます。LDAP は、TCP/IP のような接続指向のメディアを介してディレクトリサービスにリモートアクセスするためのオープンプロトコルです。

AD は、x.500 標準に基づいている、または LDAP を使用してアクセスできる唯一のディレクトリサービスではありません。他のディレクトリサービスには、OpenLDAP や FreeIPA などがあります。しかし、AD は Windows Server システムに組み込まれている、成熟した Windows ベースのサービスです。言い換えれば、組織に多くの Windows システムがある場合、自動的に勝者となります。これが、AD が広く普及している理由の 1 つです。FreeIPA のようなディレクトリサービスは Linux ベースであり、Linux が安定して稼働する環境に優れたサービスを提供します。いざという時、どちらを選ぶかは、現在の環境とチームのスキルセットを考慮して、どちらを迅速にセットアップできるかにかかってきます。

[ この無料の eBook をダウンロードして、Linux 環境をうまく管理する方法を学びましょう。 ]

しかし、AD を選択し、いくつかの CentOS サーバーがあり、Linux ユーザーのために別々の資格情報セットを維持したくない場合はどうなるでしょうか？ そのオーバーヘッドは完全に回避可能です。必要なのは、Windows サーバーと同じように、Linux サーバーを AD ドメインに参加させることです。

もしそれがあなたのやりたいことなら、この先を読んでその方法を確かめてください。Windows システムを FreeIPA ドメインに参加させることも可能ですが、それはこの記事の範囲外です。

前提条件

この記事は、読者が Active Directory、特にユーザーおよびコンピュータ・アカウント管理に関して、少なくとも入門レベルの経験を持っていることを前提としています。それとは別に、以下の明白な要件を満たす必要があります。

• システムをドメインに参加させるために必要な権限を持つ AD のアカウント。
• Linux サーバー (このデモンストレーションでは CentOS 7 サーバーを使用しました)。
• ドメインコントローラー。
• Linux サーバーが DNS 経由でドメインコントローラーを見つけられることを確認してください。

この記事を誰にとっても分かりやすくするために、主要な詳細のリストを以下に示します。これは、私がこの記事のために使用したラボのセットアップ方法ですので、適宜修正してください。

• AD ドメイン名: Hope.net
• ドメインに参加するためのユーザーアカウント: fkorea (フルネーム - Fiifi Korea)
• Linux サーバーのホスト名: centy2

インストールするパッケージ

この設定でインストールする不可欠なパッケージは realmd です。realmd の他に、これを機能させるためにインストールする必要がある多くのパッケージがあります。

# yum install sssd realmd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation openldap-clients policycoreutils-python

Realmd は、Active Directory ドメインを検出し、対話するための簡素化された方法を提供します。これは、リモート認証に必要な実際のルックアップや、ドメインと対話するその他の面倒な作業を行うために sssd を採用しています。簡潔にするために、リストの他のパッケージについては詳しく説明しません。

ただし、詳細に興味がある方は、Google で検索すると大いに役立つはずです。

[ Linux システムでの多要素認証の設定について学びましょう。 ]

Realmd (ドメインとの対話)

すべてのパッケージがインストールされたので、最初に行うことは CentOS システムを Active Directory ドメインに参加させることです。そのために realm アプリケーションを使用します。realm クライアントは realmd と同時にインストールされます。これは、参加、削除、アクセスの制御、その他多くのタスクを達成するために使用されます。単純なドメイン参加で期待される構文は次のとおりです。

realm join --user=[domain user account] [domain name]

ユーザーアカウントとドメインアカウントの間のスペースは、タイプミスではありません。対応する詳細を挿入すると、次のコマンドが得られます。

# realm join --user=fkorea hope.net

プロンプトが表示されたらパスワードを入力し、プロセスが終了するのを待ちます。

短い間、出力がなくてもだまされないでください。プロセスの一部として、多くの操作が実行されます。より詳細な出力を得るには -v スイッチを付けることができます。ただし、コンピュータがドメインのメンバーになったかどうかを確認する最良の方法は、realm list コマンドを実行することです。このコマンドは、ドメインに関するサーバーの現在の状態を表示しようとします。これは、どのグループまたはユーザーがサーバーにアクセスできるかを素早く知るための手っ取り早い方法です。

その出力を見てみましょう。

新しく作成された AD コンピュータ・オブジェクトを最初から特定の組織単位 (OU) に配置することも、非常に簡単です。詳細はこの記事では触れませんが、ヒントとして、man ページを参照することができます。realm クライアントを使用して、ドメインユーザーやグループへのアクセスを許可または取り消すことができます。realmd をよりきめ細かく使用する方法についての詳細な説明は、それだけで別の記事になるほどです。ただし、いくつかのパラメーター、すなわち client-software と server-software に注目しても、話が逸れることにはならないでしょう。今頃は、なぜこれほど多くのパッケージをインストールしなければならなかったのか、お分かりいただけたはずです。

ドメインから完全に離脱するには、realm leave の 2 つの単語が必要です。

さらなる設定

これで Linux サーバーが AD ドメインの一部になったので、ドメインユーザーは通常の資格情報でサーバーにアクセスできます。これで完了ですよね？ 違います。「何が問題なのですか？」という声が聞こえてきそうです。

[ 無料チートシート: サーバーとネットワークを管理するための Linux ユーティリティとコマンドのリストを入手しましょう。 ]

まず、これは稼働させるための最低限の設定です。しかし、そのエクスペリエンスは、控えめに言っても不格好です。真の AD の感触を与えるためには、サービスをさらに設定する必要があります。ドメインに参加している Windows 10 ワークステーションにログオンするのと同じようにすべきです。

第二に、システム管理者にとって厄介な問題として、Dynamic DNS Updates (DynDNS) と呼ばれるものがあります。これが正しく設定されていないと、DNS レコードを手動で維持する必要が生じ、余計なオーバーヘッドが発生します。DNS に大きく依存する環境では、これは問題になる可能性があります。Windows システムの場合、システムをドメインに参加させると、2 つのエントリが DNS サーバー上で自動的に管理・維持されます。IP アドレスが変更されると、その変更は自動的に DNS に反映されます。これは、手動メンテナンスのコストをかけることなく、システムの IP を変更できることを意味します。これは、すでに環境内で DNS を活用している人々にしか理解できないでしょう。自動化による顕著な生産性向上は別として、Windows と Linux の両環境が同じように動作することは有益です。

3 番目の問題は DNS Scavenging (DNS の清掃) です。Active Directory ドメインでは、DNS は通常、ドメインコントローラーによって提供されます。ドメインに参加しているすべてのシステムは、対応する IP アドレスを持つ DNS エントリを自動的に持ちます。これは非常に便利です。指定された間隔で、古い DNS レコードが自動的に削除され、誤ったパケットの送信を防ぎ、削除されたコンピュータ・オブジェクトの処理も行います。これは scavenging (清掃) と呼ばれ、AD ではデフォルトでオンになっていません。ただし、もしオンになっている場合は、設定を行う必要があります。通常、scavenging の間隔は 7 日間です。その期間が過ぎてもレコードの更新がない場合、静的レコードでない限り、削除されます。Windows システムの場合、Dynamic Updates (動的更新) 機能は自動的に設定されます。しかし、Linux サーバーでは、いくつかの変更を加える必要があります。それをしないと、しばらくするとサービスがダウンしてしまいます。なぜなら、それらのレコードが DNS から削除され、誰もそのコンポーネント部品に到達する方法を知なくなるからです。

対処すべき潜在的な問題のいくつかがわかったところで、エンドユーザーとシステム管理者によりシームレスなエクスペリエンスを提供するために、調整できるいくつかの点を見てみましょう。

SSSD (より簡単なログインと動的更新)

Linux システム上の sssd は、システムが Active Directory などのリモートソースから認証サービスにアクセスできるようにする役割を担っています。言い換えれば、これはディレクトリサービスと、認証サービスを要求するモジュールである realmd との間の主要なインタフェースです。その主な設定ファイルは /etc/sssd/sssd.conf にあります。実際のところ、これが私たちが修正する主な設定ファイルです。

[ SSSD のロギング改善がシステム管理者の作業を楽にする 3 つの方法をご覧ください。 ]

設定前にその内容を見てみましょう。ドメインに参加すると、すぐにファイルが変更され、ログオン成功に必要な最小限の情報が含まれるようになります。私のファイルは次のようになっていました。

先に述べた 3 つの問題すべてを解決するために、ファイルを以下のように編集してください。

ほとんどのオプションは自明であり、主要なオプションのいくつかが何を表しているかを順に説明する間、皆さんの設定を適宜修正することができます。すべてのオプションに関する詳細は、man ページをチェックすることで得られます。よく書かれていると思います。コマンドラインで man 5 sssd.conf と入力するだけです。sssd_ad の man ページでさらに情報を表示することもできます。

まず第一に、設定ファイルは 2 つのセクションに分かれています。グローバルセクション ([sssd] の下) とドメイン固有のオプションセクション ([domain/[domain name]]) です。

グローバルセクションには、バージョン情報や関連サービスなど、sssd の一般的な動作に影響を与えるオプションが含まれています。このセクションの主要なパラメーターの 1 つを以下に示します。

• default_domain_suffix - ログイン時に完全なユーザーアカウント名を入力したくない場合は、これをドメイン名に設定します。常に fkorea@hope.net と入力する代わりに、fkorea とパスワードを入力するだけで済みます。これは、ドメイン名が長い場合に非常に役立ちます。

ドメイン固有のセクションには、参加したドメインに固有のパラメーターが含まれています。主要なパラメーターは次のとおりです。

• access_provider - 認証目的で AD サーバーと対話するために最適化され、使用されるプロバイダーを選択できます。ad に設定する必要があります。ここで使用できる他の値は、それらのディレクトリサービスを使用していると仮定して、ldap や ipa です。
• id_provider - 識別目的で AD サーバーと対話するために最適化され、使用されるプロバイダーを選択できます。ad に設定する必要があります。
• ad_hostname - これは、サーバーの完全修飾ホスト名である必要があります。システムのホスト名が完全修飾ドメイン名以外の場合は、これを設定する必要があります。これが設定されておらず、sssd が完全修飾ホスト名にアクセスできない場合、動的更新は失敗します。
• ad_domain - これは完全なドメイン名 (この場合は hope.net) である必要があります。
• cache_credentials - これにより、ドメインコントローラーがオフラインのときに AD ユーザーがログインできるようになります。これを true に設定すると、バックエンドがオフラインのときに認証が失敗しないように、資格情報が一定期間キャッシュされます。保存期間も設定可能です。
• fallback_homedir - これは、AD にホームディレクトリ属性を持たない AD ユーザーのホームディレクトリを設定するのに役立ちます。これは、ユーザーの AD にホームディレクトリが設定されている場合に機能する override_home パラメーターとは異なります。
• dyndns_update - これは動的 DNS 更新を有効にし、値として true または false を受け入れます。動的更新が有効になると、更新は主に 3 つの条件下で発生します:
  • Linux サーバーが再起動したとき。
  • プロバイダーがオンラインになったとき。
  • 更新間隔が期限切れになったとき。
• dyndns_refresh_interval - この値は秒単位で、実用的な最小値は 60 秒です。整数の値を受け入れ、デフォルトは 24 時間 (86400s) です。この例では、12 時間に設定しています。他に更新をトリガーするものが何もない場合、定期的に更新が行われます。
• dyndns_update_ptr - 関連する PTR レコードをすべての更新サイクルで更新するかどうかを指定するブール値です。PTR レコードは逆引きに使用され、正当な理由がない限り、これを true に設定する必要があります。
• dyndns_auth - 動的更新を安全に行うかどうかを指定します。設定は AD が受け入れるモードに依存します。AD が [Secure Updates Only を受け入れる] に設定されている場合、この値は GSS-TSIG に設定する必要があります。そうではなく、(AD の強い警告にもかかわらず) 安全な動的更新のセキュリティ上の利点を気にしない場合は、この値を none に設定できます。

設定が完了したら、sssd を再起動して設定をすぐに適用します。

# systemctl restart sssd

この時点で、準備完了です。Windows ワークステーションやサーバーと同じようにログインできます。

Visudo (管理者権限の付与)

アクセスを許可されたユーザーは、Linux サーバーへの非特権アクセスを持ちます。実質的に、すべての Active Directory アカウントは、ネイティブに作成されたローカルアカウントがシステムにアクセスできるのと同じ方法で、Linux システムにアクセスできるようになりました。これで、グループへの追加、リソースの所有者への設定、その他必要な設定の構成など、通常のシステム管理タスクを実行できます。ユーザーが sudo アクセスを必要とするアクティビティを試みると、おなじみのエラーが表示されます。挿入図からわかるように、私たちのユーザーは sudoers ファイルに含まれていません。

その点から、sudoers ファイルを直接編集して、彼らにスーパーユーザー権限を付与することができます。これはスーパーユーザー権限の付与に関する記事ではありませんが、visudo ツールを使用して sudoers ファイルを安全に操作することができます。