目次
ビジネスニーズ
私は最近、LDAP でユーザー情報、組織構造、およびドメイン認証を同期するタスクを引き受けました。もちろん、このテクノロジは、nodejs によってサポートされています。インターネット上で適切なサードパーティ モジュール リンクを見つけました:node- ldap
モジュール使用法の補足
検索部門
組織 A: Catering Co., Ltd. canying.com
組織 B: Auto Repair Co., Ltd. www.qixiu.com
では、ベースを埋めるにはどうすればよいでしょうか?
たとえば、組織 A を使用します:
canying.com/Catering Co., Ltd./IT 部門
ou=IT 部門,ou=Catering Co., Ltd.,dc=canying,dc=com
ou はディレクトリを表し、すべてのサブディレクトリを検索します。 IT 部門ディレクトリ (下位部門) の下では、IT 部門に下位部門がないと仮定すると、返される配列の長さは 0 になります。
組織 B の記入方法:
www.qixiu.com/Auto Repair Co., Ltd./RepairDepartmentou
=Repair Division,ou=Auto Repair Co., Ltd.,dc=www,dc=qixiu,dc=com
したがって、すべての組織構造を検索したい場合、実際には、特定のルート ファイル ディレクトリの下にあるすべてのサブディレクトリを検索することに似ており、
通常使用する方法は再帰的検索であり、これは後で追加されます。
部門の検索---親ディレクトリ (上位部門) のすべてのサブフォルダー (下位部門) を検索します。
client.searchOU('dc=ad,dc=yliyun,dc=com').then(function(ous) {
console.log(ous);
}).catch(function(err) {
console.error(err);
});
部門の戻り値の部門コレクションには、ここで変更できるフィールドが ldapDn と deptName の 2 つだけであることがわかりました。
まず、node_modules/node-ldap/lib/ldap.js を見つけます。vscode
を使用してプラグインをダウンロードしたので、Ctrl キーを押しながら左マウス ボタンを押し、クリックして client.searchOU にジャンプしました
。実際の戻り値は、
検索と同じ方法で _parseOU から取得されます。
明らかに私たちは
function _parseOU(entry) {
var ou = {
ldapDn: entry.dn,
deptName: entry.displayName
};
if (!ou.deptName) {
ou.deptName = entry.name;
}
if (!ou.deptName) {
ou.deptName = entry.ou;
}
return ou;
}
着替える
function _parseOU(entry) {
var ou = {
ldapDn: entry.dn,
deptName: entry.displayName,
...entry
};
if (!ou.deptName) {
ou.deptName = entry.name;
}
if (!ou.deptName) {
ou.deptName = entry.ou;
}
return ou;
}
部門に関するあらゆる情報がご覧いただけます。
ユーザーを検索する
ユーザーの検索 - 現在のディレクトリ内のファイルの検索と同様に、現在の部門 (ディレクトリの下) のすべての従業員を検索します(フォルダーを除く)。
client.searchUser('ou=IT部,ou=餐饮有限公司,dc=canying,dc=com').then(function(users) {
console.log(users);
}).catch(function(err) {
console.error(err);
});
ユーザー コレクションには 4 つのフィールドしかありません。ユーザーに関する詳細情報を表示し、上記のように _parseUser を変更する方法
function _parseUser(entry) {
var user = {
//dn: entry.dn,
ldapDn: entry.userPrincipalName,
userName: entry.sAMAccountName,
realName: entry.displayName,
mail: entry.userPrincipalName,
//...entry
};
if (!user.realName) {
user.realName = entry.name;
}
if (!user.realName) {
user.realName = entry.cn;
}
return user;
}
組織構造の同期化についての考え方
LDAP によって同期される組織構造には、いくつかの変更、
追加、削除、修正が含まれる場合があります。
クライアント側で同期した組織構造がリソースにバインドされている場合、
サーバーの組織構造が再び変更された場合、どのような影響があるでしょうか?
①サーバー部門を削除しました
クエリ部門リスト LIMIT 0,3 を分割し、for ループを使用して
例を示します: サーバー側の IT 部門が削除され、リソースがクライアント側の IT 部門にバインドされています。このとき、同期が発生し、クライアント側の IT 部門が削除され、論理的に削除されると、この部門の配下のリソースは新しい組織構造には存在しなくなります。
回答:
したがって、部門にバインドされているすべてのリソースを管理する必要があると思います。部門が論理的に削除された場合は、関連するリソースを管理および制御し、ファイルの転送と同様に、その後の転送のためにインターフェイスを開く必要があります。
②サーバー部門を削除し、再度作成した
最下位レベルでは名前は同じですが、基礎となる objectId が異なります。最下位レベルからは、両方とも IT 部門と呼ばれている場合でも、論理的には元の IT 部門を削除し、2 つの部門が統合されると論理的に 1 つを再作成します
。 「同期を実行します。IT 部門、この IT 部門はあの IT 部門ではありません。では
、古い IT 部門のリソースはどこにありますか? 多くの人は、すべてを名前で IT 部門と呼んでいます。古いリソースは新しい IT 部門に移管する必要があります。」お兄さん、恥ずかしいですよ。名前の長さをコントロールするのは難しく、タイプミスがあった場合はどうすればよいか、またタイプを見逃したり見逃したりする可能性もあります。あいまいな比較ですか?それはさらに悪いことに、旧部門は製造部門と呼ばれ、新しい部門は製造研究開発部門と製造保守部門と呼ばれていますが、彼らは誰にリソースを提供していると思いますか?したがって、同期プロセス中にリソースを転送することは適切ではありません。
回答: 質問 1 と同じで、簡単に転送できるようにリソースを管理および制御します。
③サーバー部門の名称を上位部門に変更
変更はありません。基礎となる ObjectID は同じままであるため、リソースはフロートしません。
④所有権のない部門リソースは削除できますか?
開かないように注意してください。どうしても開かなければならない場合は、ごみ箱を追加することをお勧めします。削除された所有権のないリソースは、ごみ箱に入れることができます。このとき、ごみ箱の時間を設定します。1 か月前のリソース (独自のルールを定義できます)当日は実際に可能であれば
、これらのタイミング プログラムは夜間に実行するのが最適です。
ユーザーリストの同期に関する考え
①サーバーユーザーが削除された場合
ユーザー リストのクエリでは、分割クエリ LIMIT 0,3 も使用されます。
サーバー ユーザーは削除され、クライアント ユーザーは論理的に削除され、リソースは依然としてそのユーザーの名前の下にあります。
② サーバーユーザーの名前変更
ユーザーの objectId は変更されておらず、依然として同じユーザーであるためです。
③サーバーユーザーを削除し、再作成した
ObjectId が異なるため、新しいユーザーが生成され、古いユーザーのリソースは常に保持されます。
電話番号、メール アドレス、生成されたコード、論理制限などの一部の情報の一意性を考慮して、マージを検討できます。またはここでユーザーを転送します。
すべての部門のリストを取得する
1. 部門別コレクション情報