NDS(Novell Directory Services / eDirectory)完全ガイド:仕組み・運用・移行の実践ポイント

NDSとは何か — 企業ディレクトリの起点

NDS(Novell Directory Services、後の eDirectory)は、1990年代にNovellが開発した階層型・分散型ディレクトリサービスです。ユーザー、グループ、プリンタやサーバといったリソースを一元的に管理することを目的としており、X.500の思想を継承した名前空間、スキーマ、レプリケーションを備えています。企業内の認証・認可、シングルサインオンやID管理の基盤として広く使われてきました。

歴史と進化の概観

NDSは1993年にNetWare 4.0とともに登場し、従来のフラットなネットワーク管理に代わるディレクトリベースの管理モデルを提供しました。その後、1990年代後半以降、NDSはプラットフォーム独立性を高めてさまざまなOS上で動作するようになり、製品名として「eDirectory」として位置づけられることが増えました。Novellはディレクトリに対する管理ツール(ConsoleOne や iManager)や同期・プロビジョニング製品(DirXML/Identity Manager)を整備して、既存のLDAP対応システムやMicrosoft Active Directoryとの相互運用性を追求してきました。2014年以降はMicro Focusによる製品継承もあり、現在でも企業向けディレクトリ製品として提供されています。

基本アーキテクチャと設計思想

NDS の重要な設計要素は次の通りです。

  • 階層的な名前空間:ツリー構造のコンテキスト(組織、部門、国など)でオブジェクトを整理します。
  • スキーマベース:オブジェクトクラスと属性によってデータモデルを定義し、拡張やカスタマイズが可能です。
  • 分散・複製:ディレクトリは1台に集中するのではなく、パーティション(またはコンテキスト単位)ごとに複数のレプリカを配置し、可用性と近接アクセスを確保します。
  • マルチマスターモデル:複数のサーバ上で同一パーティションの書き込みを許容し、レプリケーションによって変更を伝播します。

スキーマとオブジェクトモデリング

NDS/eDirectoryはスキーマによって管理対象の型を定義します。ユーザーやグループ、デバイス、サービスアカウントなどはそれぞれオブジェクトクラスでモデル化され、属性が割り当てられます。スキーマは拡張可能で、アプリケーションや業務要件に合わせてカスタム属性を追加できますが、変更は慎重に行う必要があります(スキーマ変更は後戻りが難しい場合があります)。

レプリケーションと整合性

スケーラビリティと可用性を実現するため、NDSはパーティション単位でのレプリケーションを採用します。各パーティションは複数のレプリカを持てるため、片方のサーバがダウンしてもディレクトリ全体の読み取りや多くの認証処理は継続できます。更新は多地点で行えるマルチマスター方式であり、各変更には時系列情報や更新番号が付与されて伝播されます。競合が発生した場合は一般に更新時刻やバージョンに基づいて解決されますが、設計次第では意図しない上書きが起き得るため運用ポリシーの整備が重要です。

認証・認可とセキュリティ

NDSはディレクトリ自体に認証情報とアクセス制御を保持します。細かいアクセス制御はトラスティ(trustee)権限やアクセス権リストで管理され、オブジェクトごとの読み取り・書き込み権限を設定できます。近年の実装はLDAP v3をサポートし、TLS(LDAPS)による暗号化やSASLによる拡張認証を利用可能です。また、Kerberosやパスワードポリシーとの連携、証明書ベースの認証との統合も行えます。

運用上のポイントとベストプラクティス

  • 設計段階での命名規則とコンテキスト分割:組織の変化を見越した柔軟な名前空間設計が、後の管理コストを下げます。
  • レプリカ配置計画:地理的に分散した拠点やバックアップ用にレプリカを適切に配置し、ネットワーク負荷と応答性のバランスを取ること。
  • スキーマ管理の慎重さ:スキーマ変更は影響範囲が大きいため、テスト環境で検証した上で本番へ適用すること。
  • 定期バックアップとリカバリ手順:パーティション単位のバックアップ、フルリストア手順、レプリカの再構築方法を運用手順として明文化すること。
  • 監査とログ管理:認証失敗や管理者操作の監査ログを収集し、セキュリティインシデント対応の基礎を整えること。

Active Directoryやクラウドとの統合・移行

多くの企業では既存のNDS/eDirectory環境をMicrosoft Active DirectoryやクラウドID基盤に統合・移行するニーズがあります。移行にはユーザー属性のマッピング、パスワードシンク、グループの取り扱い、アプリケーション連携の再設定などが発生します。Novellの時代から提供されている同期ツール(DirXML/Identity Manager)は、ディレクトリ間の属性同期やプロビジョニングの自動化に役立ちますが、移行プロジェクトでは事前のアセスメントと段階的な移行計画が不可欠です。

運用でよくある課題と対策

  • レプリケーション遅延や競合:ネットワークトポロジーの見直し、レプリカ数の最適化、衝突検知と手動解決手順の整備が必要です。
  • スキーマの肥大化:不要属性やオブジェクトの整理、アーカイブ方針によりディレクトリの肥大化を防ぎます。
  • 管理ツールの依存性:ConsoleOne(Javaベース)やiManagerのバージョン依存を把握し、互換性ポリシーを整備します。
  • セキュリティ設定の不備:TLS設定、パスワードポリシー、権限の最小化(最小権限の原則)を徹底します。

現代におけるNDS/eDirectoryの位置づけ

クラウドIDやSaaS型ディレクトリが普及する中でも、オンプレミス環境やレガシーアプリケーションを多く抱える組織では、NDS/eDirectoryが引き続き重要な役割を果たしています。特に高い可用性・分散性を要求する環境や、既存投資を維持しつつID管理を近代化したいケースでは、eDirectoryを中心に据えたハイブリッドな設計が採用されます。とはいえ、新規導入時にはLDAP互換性、クラウド連携、運用スキルの確保を含めた総合判断が必要です。

まとめ — 技術的理解と運用の両輪が成功の鍵

NDS(eDirectory)は、階層的で分散可能なディレクトリという強力な概念を企業に提供してきました。その設計思想は今日のディレクトリサービスに通じるものがあり、スキーマ設計、レプリケーション、アクセス制御など運用上のポイントは普遍的です。導入・維持・移行を成功させるには、設計段階での要件整理と運用手順の整備、そしてセキュリティ対応が不可欠です。既存環境の分析と段階的な近代化計画があれば、NDS/eDirectoryは今なお実用的で信頼できるID基盤となり得ます。

参考文献

Novell eDirectory - Wikipedia

Micro Focus eDirectory Documentation

Novell Directory Services - Wikipedia

RFC 4511: Lightweight Directory Access Protocol (LDAP): The Protocol