LDAP は死んだ

この記事は https://docs.evolveum.com/iam/ldap/ldap-is-dead/ の翻訳です。

Radovan Semančík

Lightweight ディレクトリアクセスプロトコル (LDAP) は、エンタープライズや telco 環境でアカウントを維持するために使われるプロトコルです。 広く使われているにもかかわらず、LDAP は深く problematic で、不完全で、維持管理されていないプロトコルです。 LDAP には numerous 問題 があるにもかかわらず、ほぼ20年にわたり進化していません。 Software システムが evolve を止める理由は2つしかありません。 それは perfect であるか、死んだ であるかのどちらかです。

LDAP を使ったことがある人なら誰でも、心の中では LDAP が perfect からほど遠い ことを知っています。 スキーマ課題、missing 機能、曖昧さ、redundancy、architectural oversight、obsolete 機構、必要な非標準拡張、独自 ソリューション、antique 遺物など、大幅な改訂 を切実に必要とする仕様化の典型的な症状 がすべてあります。 それでも revision は起こりませんでした。 実際、LDAP 仕様化を revise し、問題を修正することについて話す人すらいません。 私たちは、古き良き broken プロトコルを使い続け、問題を静かに作業 around し、すべて問題ないふりをしています。 正直に言うと、なぜ私たちがそれをしているのか、私は本当に理解したことがありません。

LDAP 問題

厳密に言えば、LDAP は インターネット Engineering 作業 Force RFC の series で規定されたプロトコルであり、その中には情報モデル、スキーマ、認証機構、識別子形式、検索 filter 構造、その他詳細も含まれます。 仕様化はかなり comprehensive です。 相互運用性は、仕様作成者の主な目的の1つだったことが明らかです。

しかし LDAP 実務は仕様化に実際には準拠していません。 LDAP の世界には多くの慣習、暗黙のルール、すべきこととすべきでないこと、サーバー固有の技法、回避策があります。 LDAP 仕様化に厳密に adherence すると、相互運用性問題に入ることが保証されます。 たとえば通常の LDAP グループ化機構は、標準スキーマが non-standard 方法で modified されない限り、本当には機能しません。 これは LDAP コミュニティで広く accepted された事実であるため、多くの LDAP サーバーは off-the-shelf で pre-violated スキーマを持っています。

ここで server-to-server 相互運用性について話しているのではありません。それは私の知る限り、このプロトコルの意図ではありませんでした。 私は単純で現実的な client-to-server 相互運用性について話しています。 実務上、LDAP サーバーはすべてのクライアントを adjust せずに簡単に置き換えできません。 クライアントは、アカウントオブジェクト種類、識別子名、グループオブジェクト種類、アカウントとグループの配置、識別子パターン、属性名、参照機構などの厄介な詳細を構成しなければ LDAP サーバーに接続 できません。本来なら標準によって規定されるべき詳細です。 ちなみに LDAP には3つ以上のグループ化機構があり、それらは mutually non-compatible です。 これは正気ではありません。

さらに、基本を少しでも超えた reasonable やり取りをサーバーと行うには、non-standard 拡張が必要です。 memberOf や Virtual List Views (VLV) などの non-standard 機構は、LDAP データを scale して扱うために絶対的に necessary です。 permissive modify は整合性を維持するために必要です。もっともサーバーがあなたの 都合 のためにすでに仕様化から逸脱していない場合ですが。 このような non-standard 機構には サーバー固有のニュアンス があり、実装ごとに少しずつ異なって動作します。

さらに悪いことに、一部の課題は non-standard 拡張によってさえまったく解決されていません。 アカウント有効化、つまりアカウントを 無効化 と enable する能力は悪名高い例です。 各 LDAP サーバーはそれを行う独自方法を持っています。OpenLDAP だけは、それを行う方法がありません。 ほぼすべてについて サーバー固有の機構、特定の、tweak があります。

TIP: Several 広く使われている LDAP サーバーの一般的 workaround の説明を含む詳細は、LDAP サバイバルガイド を参照してください。

実務上、LDAP 相互運用性は非常に limited です。 正直なところ、それはほとんど神話です。 私は長いキャリア の中で多くの LDAP サーバーを見てきましたが、LDAP 仕様化に完全に準拠な LDAP サーバーを知りません。 LDAP プロトコルは主に単純アプリケーションの password-based 認証に使われ、基本的な LDAP 操作、search と 結び付け の1つか2つだけを使います。 一部のアプリケーションは、悪名高い問題のすべてにもかかわらず、LDAP グループに基づく rudimentary 認可をサポートするほど bold です。 しかし LDAP クライアントは常に特定の LDAP サーバー、そのデータ構造、設定、設計上の選択、convention に適応しなければなりません。 私たちがこの痛みのある実務にこれほど簡単に慣れてしまったのは奇妙ではないでしょうか。

死んでいるのか、アンデッドなのか、それともレガシーなのか

私の "LDAP is 死んだ" という文は大胆すぎる、または premature だと思うかもしれません。 そうかもしれません。 世の中には 運用中の LDAP サーバーが多数あり、多くのアプリケーションが LDAP 認証をサポートし、ecosystem はどうにか機能しているように見えます。 しかし、それは 点 ではありません。

Point は、私たちが LDAP を、まだ1990年代であるかのように統合に使っていることです。 すべての統合 path は特定のサーバーに合わせてカスタマイズ済み と fine-tuned されています。 これは 誤りやすく、時間がかかり、壊れやすい です。 ますます得にくくなっている expertise を必要とします。 明らかに、これは適切な方法ではありません。

さらに、サイバーセキュリティとアイデンティティ状況は1990年代とは大きく異なります。 今では 数字の 0 trust が求められ、machine アイデンティティもようやく attention を集めています。 LDAP はアプリケーション認証にサービスアカウントを使うよう構築されています。 サービスアカウントの認証情報を定期的に updating していますか。 できますか。 そもそもそうすべきだと知っていますか。

LDAP は新しいサイバーセキュリティ状況と要件に適応できるでしょうか。 Technically には可能です。 プロトコル自体にそれを prohibit するものはありません。 では適応するでしょうか。 それは非常に ありそうにありません です。 LDAP 仕様化の last 大きな更新は2006年6月でした。 その間ずっと痛ましい問題があったにもかかわらず、ほぼ20年にわたり誰もそれを修正しようとしませんでした。 私の interpretation は、LDAP コミュニティは LDAP をもはや修正する価値がないと考えている、というものです。

とはいえ、LDAP は今や un維持管理レガシープロトコルと考えるべきです。 死んだ、dying、undead、legacy、好きなように呼んでください。 それらは用語 nuance にすぎません。

1つ明らかなことがあります。LDAP が修正できないなら、置き換えされます。 それはおそらく良いことです。 1990年代、そして X.500 の root における1980年代のレガシーは、LDAP core の奥深くに入り込んでいます。 Foundation は LDAP スキーマなどに非常にはっきり表れています。

LDAP が目に見えて decline するまでには何年もかかり、完全に消えるするにはさらに 何十年 かかるでしょう。 しかし LDAP の eventual demise は inevitable です。 それはすでに始まっています。 LDAP is 死んだ。 アイデンティティ industry はついに LDAP を乗り越え、先へ進むべきです。

LDAP の置き換え

そのとおりです。 LDAP は置き換えされる必要があります。 LDAP を何で置き換えるのでしょうか。 それは billion-dollar 問題です。 文字どおりに。

LDAP 機能の一部は置き換えが簡単 であり、他はそうではありません。

Authentication は簡単 な部分です。 認証に LDAP を使わないでください。 LDAP はいずれにせよ必要性を満たすには不十分です。 Strong 認証、passkey、多要素 が絶対に 必要 であり、LDAP はそれを本当には提供できません。 LDAP の代わりに OpenID Connect や proper 認証サーバーを使ってください。 LDAP はそもそも認証サーバーであることを意図していませんでした。

Authorization 機能の置き換え ははるかに困難です。 実際、アイデンティティ industry 全体において authorization 問題 への 簡単な答え はありません。 認可を適切に行う 簡単な方法はありません。 Rough-grain は問題ではありません。 Rough-grain 認可は、認可の follow-up として単一 sign on (SSO) サーバーによって 強制できます。 OpenID Provider 機能を実装する多くのサーバーは、rough-grain 認可を enforce できます。 サーバーは particular ユーザーに対してどのアプリケーションを allowed または denied するかを判断できます。 しかし 細粒度 認可になると、物事は信じられないほど複雑な になりがちです。 この複雑性には十分な理由があります。 Fine-grain 認可は本質的にアプリケーションデータ、そしてさらに重要にはアプリケーション concept に依存します。 したがって認可機構の特定の詳細はアプリケーションごとに異なります。 しかし LDAP でさえそれに対処できません。 LDAP 統合の通常の慣行は、アプリケーションが LDAP グループを利用することです。 アプリケーションはグループの上にローカルな認可の仕組み を実装します。 アイデンティティ管理者はグループ内のユーザーメンバーシップを制御できますが、認可の仕組み の他の詳細は制御できません。 同様の機能は LDAP なしでも再現できます。たとえば OpenID Connect scope を 創造的に使う、または SCIM を採用 してグループメンバーシップを制御するなどです。下記参照。 このような方法には多くの改善余地がありますが、それは LDAP も同じです。 エンタープライズ scale では、フル機能のアイデンティティ管理ソリューション、つまり アイデンティティガバナンスおよび管理 プラットフォームはいずれにせよ必須であり、LDAP グループ管理機能を容易に置き換えられます。

認可機構

TIP: 認可を externalize と standardize する労力はいくつかありますが、その大半はまだかなり基本で、現実世界のシナリオには不十分です。 しかし some progress はあります。 認可は時間とともに改善する可能性があります。

次に synchronization と プロビジョニング があります。 これらの機構は、アイデンティティデータが関連するすべてのディレクトリ、データベース、アプリケーション全体で一貫していることを保証します。 LDAP は分散した、複製ディレクトリのために設計されたため、LDAP サーバーは伝統的にアイデンティティデータ同期の中心点と見なされていました。 LDAP は 異種 同期のために設計されたわけではありませんが、LDAP サーバーの同期機能はあらゆる種類の同期とプロビジョニングエンジンによってしばしば濫用されています。

LDAP 同期

NOTE: LDAP 同期標準 (RFC5433) は存在しますが、広く使われてはいません。 実際、適切に実装済み と used されているのは単一 LDAP サーバー、OpenLDAP だけです。 標準はほぼ20年前のものですが、他のすべての LDAP サーバーはいまだに独自の 独自 同期機構を使っています。 LDAP standardization とはその程度のものです。

厳密に言えば、synchronization と プロビジョニング は LDAP の責任ではなく、LDAP サーバー単独では実装できません。 いずれにせよ additional ソフトウェアが常に必要です。 LDAP を必要とせずに同期を handle できるシステムは多数あります。 これは アイデンティティガバナンスおよび管理 (IGA) プラットフォームが本当に shine する domain です。 しかし IGA ツールは何らかの方法でデータにアクセスする必要があります。 LDAP はアイデンティティリポジトリの一部にアクセスする一般的プロトコルとして重要な役割を果たしました。 しかし LDAP はゆっくり SCIM に置き換えされています。

System for Cross-domain Identity Management (SCIM) は、アイデンティティプロビジョニングサービスの IETF 仕様化 (RFC7642) です。 SCIM 仕様化はユーザーとグループに関するデータを作成、read、更新、削除、つまり "CRUD" するサービスを describe しており、これは LDAP が提供する機能とほぼ同じです。 SCIM は LDAP より theoretical advantage を持ちます。アイデンティティリポジトリだけでなく、はるかに多くのものに reach できるからです。 理論上、すべてのアプリケーションは SCIM API を実装し、アイデンティティデータへの標準化された外部アクセスを許可することが想定されています。 しかし実務になると 多くの問題 があります。 問題はあるものの、SCIM は future アプリケーションにとって LDAP より良い choice かもしれません。

結論

Future 潜在的なという点では、LDAP は死んだです。 冷たく腐敗している corpse です。 死んだであるにもかかわらず、まだ動いています。 多くの導入で使われており、同じ unsolvable 問題に何度も対処しなければなりません。

LDAP は迅速に消えるするわけではありません。 Years、さらには何十年かかるでしょう。 それは遅い と 痛ましい death になります。

まもなく、LDAP は新しい導入で 考慮 されなくなります。 LDAP 機能は OpenID Connect や SCIM など、他のプロトコルに置き換えされていきます。 LDAP を手放すのが早いほど良いです。 LDAP は evolving しておらず、死んだ weight になっています。 LDAP に固執することは私たちを後退させます。 手放す時です。

FAQ と反論

Confused ですか。 特にアイデンティティコミュニティにすでにしばらくいるなら、「これは正しいはずがない」と考えているかもしれません。 あなたの thought や問題の一部は、下で answer できるかもしれません。

しかし巨大な LDAP ディレクトリは存在するのでは?

はい、LDAP ディレクトリは多数あります。massive で heavily 複製なものさえあります。 はい、それらはいまだに導入されています。 Software は問題なく動作しています。そこに疑問を呈しているわけではありません。

それでも、ディレクトリは独自の LDAP dialect、拡張、独自 機構を使っています。 Dialect と サーバー固有の機構に適応する限り、問題ないかもしれません。 しかし特定のサーバーに適応しなければならないなら、標準を持つ 点 は何でしょうか。

LDAP はもはや 相互運用可能 標準ではありません。 アプリケーションに一切触れずに、LDAP サーバーを別のものに簡単に switch できますか。 プロトコルは相互運用性のためのものです。 LDAP はその側面 でひどく失敗しています。

これらのディレクトリを run するには、どんな 独自 プロトコルでも足ります。実際にそうであることもよくあります。 今日では多数の non-SQL データベース選択肢があり、多くの massive 導入があります。 確信するのは難しいですが、すでに LDAP アイデンティティリポジトリより non-LDAP アイデンティティリポジトリの方がはるかに多い可能性がかなりあります。

しかし LDAP はこれほど広く使われているプロトコルでは?

LDAP は "広く使われている" ではなく、単に widely used されているだけです。 LDAP を正直に好きな人は少なく、本当に理解している人はさらに少ないです。 LDAP expert は aging と retiring しており、それが LDAP がもはや進化しない理由の1つかもしれません。

Active Directory はどうなのか

Active Directory (AD) は LDAP に基づいているのではありませんか。 そこら中に何千もの AD instance があるのに、LDAP が死んだであるはずがあるのでしょうか。

第一に、AD は LDAP ではありません。 LDAP は AD データにアクセスするための複数の手段の1つにすぎず、best なものでも most used なものでもありません。 実際、AD はどのような意味でも LDAP に based していません。 LDAP は後付けとして AD に glued されただけです。 AD を少し深く見れば、これは非常に明らかです。

第二に、AD は本質的に strange life 形式です。 同時に死んだで alive であるように見えます。 しかし現時点では、Microsoft は Entra ID を 優先して AD を 段階的に廃止 しつつあるようです。 したがって AD は、遅かれ早かれ実際に 本当に安らかに眠る するかもしれません。

何を話しているのか分かっていない

そうかもしれません。 確信するのは常に難しいことです。 しかし私の LDAP との history はほぼ30年に及びます。 iPlanet がまだ存在していた頃、私はエンタープライズや telco 向けに LDAP ディレクトリを導入していました。 Apache ディレクトリ API の維持管理を手伝いました。 OpenLDAP の設定と維持管理を容易にするツールを作成しました。 MidPoint の柔軟 と feature-rich な LDAP と AD コネクターをゼロから開発しました。 その際、多くの LDAP サーバーを分析・テスト し、obscure 機構と workaround を実装しなければなりませんでした。 LDAP の世界 では一つや二つ、見てきました。 LDAP との長い関係の中で compile した 回避策のリスト である LDAP サバイバルガイド を参照してください。 しかし、私の言葉を信じる必要はありません。 どうぞ自分でそれらの LDAP 実装を見てください。

あなたは単なる LDAP 嫌いでは?

実際には、私はその反対にかなり近いです。 私は本当に LDAP が 好き です。 1990年代にすぐ好きになり、今でも好きです。 LDAP は単純で、それなりに elegant で、良い点が多いと思っています。 悪い点が経験を完全に ruin しているのは非常に悲しいことです。 LDAP が持つ多数の問題を修正する will がないことは、ほとんど信じられません。

しかし、LDAP がいつか修正されるという hope はすべて失いました。 Community に will がありません。 私はずっと以前に試み、失敗しました。 私にとって、壊れていて修正できないツールを使い、すべて問題ないふりをする意味はありません。 先へ進み、LDAP の先の future を見る時です。

関連項目

• LDAP サバイバルガイド

• SCIM の問題