前回、同内容の連載を執筆してから8年が経過しました。この間、企業におけるActive Directoryの重要性は増す一方です。

昨今のクラウド移行の潮流の中で、Microsoft社もAzure Active Directory（Azure AD）というクラウド型の認証サービスを提供していますが、こちらは「Active Directory」という名称を使っているものの技術的にはまったく別のサービスであり、いわゆる従来からのActive Directoryの代替となるものではありません。従来のActive Directoryに相当するサービスとして、Azure Active Directory Domain Services（AADDS）というサービスの提供が始まっていますが、このサービスで提供されるActive Directoryの機能は一部に限られます。

そのため、当面の間Active Directoryは企業ネットワークにおける認証サービスの中核として、引き続き活用されていくでしょう。もちろん、Linuxも企業ネットワークの中で不可欠な存在であり、LinuxサーバのActive Directory（以下ADと呼びます）への認証統合は、さまざまな場面で必要とされています。

こうした状況の中で、Linuxサーバの認証統合の方式についても、この8年の間にsssdの登場をはじめとするさまざまな変化がありました。本連載では、こうした状況をふまえ、改めてLinuxサーバの認証統合の方法について、最新の状況を解説していきたいと思います。

今回と次回で、認証統合を検討する上での前提となる概念やライセンス面の知識と、Linuxにおける認証統合を実現する機構であるPAMおよびNSSの概要について解説します。

認証統合を実現する前に

認証統合にあたって、まずは共通的な概念やライセンス上の留意点について押さえておきましょう。

「認証統合」の概念の整理

通常は「認証統合」という言葉で一括して扱われることが多いのですが、Linuxとの認証統合を検討する上では、ユーザ名やホームディレクトリの情報といったユーザ情報の連携と認証情報（パスワードなど）の連携を区別して考える必要があります。また「連携」という表現をしましたが、統合の方法としては、都度ADを参照して情報を取得する連携と、情報自体をLinux上に複製してしまう同期を区別する必要があります。

たとえば、次回説明するpam_krb5を用いた認証統合では認証情報の連携のみを実現します。この場合、ユーザ情報の連携はないため、図1のようにユーザ自体はLinux上に作成済のユーザが参照されます。

また「同期」ではなく「連携」のため、何らかの要因でADが参照できなくなると、認証を行うことはできません。

今回説明する認証統合の方式の大半は、ユーザ情報と認証情報の両方を連携します。この場合、図2のようにLinux上のユーザ情報は参照されず、ADに存在するユーザが自動的にLinux側で認識されて、ログインが可能となります。

クライアントアクセスライセンス（CAL）について

マイクロソフト社は、サーバに「アクセス」する「デバイス」もしくは「ユーザ」ごとに、CALと呼ばれるライセンスが必要であるという定義をしています[1]⁠。

この「アクセス」ですが、「⁠マルチプレキシング」という概念で、間接的なアクセスについてもライセンスの対象になるという定義が行われています。そのため、Linuxサーバの認証をWindowsサーバ上に構築されたADで行うように認証連携した場合、そのLinuxサーバにアクセスするユーザやデバイスは、間接的にWindowsサーバにアクセスするという扱いとなるため、ライセンスが必要となります[2]⁠。

たとえば図1や図2のような形態の場合、方式によってはWindowsクライアントとActive DirectoryのドメインコントローラであるWindowsサーバとの間で直接の通信は必要ないケースもあります。そうした場合でも、Windowsクライアントもしくは認証対象のユーザごとにライセンスが必要となります。Linuxサーバ自体ではなく、末端のデバイスもしくはユーザに対してライセンスが必要となる点に注意してください。

ADの実体と認証機構

Linuxとの認証連携を実現するうえでは、Windowsの世界では隠蔽されているADの実体を理解しておく必要があります。

ADの実体は、Kerberos認証によりアクセスされるLDAPディレクトリサービスです。ドメインに参加しているユーザやコンピュータは、ログオン（サインイン）もしくは起動時にKerberos認証により認証されます。この際Active Directoryのドメインコントローラ（DC）はKerberosでいうKDC（Key Distributed Center）として機能し、ADのドメインはKerberos認証上のレルム（realm）として認識されます。このため、日本ではあまり一般的ではありませんが、Linuxサーバなどで構築されたレルムとの間で信頼関係を締結することも可能です。

なおADの実装では、コンピュータがKerberos認証を行う際のユーザ名相当の概念（プリンシパル名）として、コンピュータのFQDN名を用います。ADが動作する上ではDNSを用いたFQDN名の名前解決が必須なため、DCは通常DNSサーバとしても機能させます。Kerberos認証を行う上では時刻同期も必要なため、通常DC上がNTPサーバとして機能し、時刻同期を行います。

この他ADは、互換性維持やAD外からのアクセスに対応するため、NTLM認証と呼ばれる認証形式にも対応しています。

認証後は、LDAPを用いてADにアクセスし、ディレクトリ上の各種情報を取得するほか、マイクロソフト社固有のファイル共有プロトコルであるSMBを用いてサーバ上のファイル共有にアクセスし、グループポリシーの定義ファイルなどの各種ファイルを取得します。

なおLDAPサーバとしてのDCは、OpenLDAPなどのLinuxで一般的な実装によるLDAPサーバと異なり、デフォルトでは匿名アクセスは禁止されており、基本的にはSASLという機構を経由して、前述したKerberos認証で認証の上アクセスする必要があります。

これ以外の方法としては、平文認証に相当する簡易認証（シンプル認証、シンプルバインドと呼ばれることもあります）や、同じくSASL経由でMD5によるダイジェスト認証を用いて認証することもできますが、セキュリティ上は推奨されません。そのため、LDAPを用いてパスワード情報の書き込みを行う際には、クライアント証明書を用いたLDAPSが必須となっています。

このほか、各種管理用の通信ではMS-RPCと呼ばれるプロトコルを用いてDCにアクセスします。MS-RPCは大量のハイポート（1024以上のポート）を使用しますので、ADのDC間の通信をポート単位で制御することはあまり意味がなく、推奨されません。同じく、Kerberos認証上の制約など、いくつかの理由により、ドメインに参加している各コンピュータ（クライアント－サーバおよびサーバ同士）間の通信では、静的NATを含め、NATがサポートされていません。認証自体からは外れますが、ADが存在するネットワークのネットワーク設計やアクセス制御を行う上では、こうした点にも留意する必要があります。

駆け足で解説しましたが、このように、ドメインコントローラは多種多様なサーバとして機能しています。

次回は、Linux側の認証機構につい解説します。