LDAP目錄設計注意事項

-1

在組織中，每個員工都使用多個服務，因此我決定使用OpenLDAP服務器將用戶相關信息存儲在一個集中位置（目前情況並非如此，從而導致了很多頭痛）。在網上閱讀了幾本書和無數文章後，我仍然無法在兩種設計方法之間下定決心。LDAP目錄設計注意事項

爲了把人的起碼的個人資料（姓名，電話，電子郵件）下的ou = people，DC =例如，DC = COM和應用程序特定的條目爲單獨的子樹，它們鏈接到用戶通過DN-s。例如，像別名，配額等的電子郵件的單獨子樹一樣; PBX憑證的單獨子樹，等等。這樣應用程序訪問更直接。另一方面，在不同的子樹中重複相同的信息：「ou = people，dc = example，dc = com」下的用戶電子郵件和uid，以及將電子郵件地址鏈接到用戶郵箱的郵箱記錄這恰好與用戶的uid一致）。

2. 一種不同的方法，也可見於一些教程，是東西應用相關的個人數據到人的目的是使用輔助類，就像這裏：

http://www.watersprings.org/pub/id/draft-srivastava-ldap-mail-00.txt

與實際這裏的模式：

http://www.netfrag.org/webnews/article.php?id=89&group=nfo.links.computing

它認爲，第一種方法是比較合理的，但由於這是我參與第一次嚴肅的LDAP目錄實現，所以我更願意向更有經驗的LDAP-ers尋求建議。

我對可能太籠統的問題表示歉意。

來源

2012-02-25 badbishop

以上都不是。

第一個想法是可怕的設計。你會把所有的浮點列放到數據庫中的一個表中嗎？

第二個想法使用了近13年前過期的Internet草案。有一個原因，它從來沒有成爲一個RFC。

使用inetOrgPerson對象類，並將所有內容粘在那裏。使用該目錄來表示目錄結構，例如用戶，組，角色...不是根據您的第一個想法來隔離數據類型。

來源

2012-02-28 04:16:05 EJP

感謝您的冷靜回覆:)。「你會把所有的浮點列放到數據庫中的一個表中嗎？」幾乎沒有。但是，我會考慮將複雜搜索中密集使用的數據和包含大型條目的數據分開。「可怕」的想法不是關於隔離數據類型，而是根據它們應該如何使用來組織數據對象樹。 Postfix不會對某個人的電話號碼感興趣，而查找其他員工電話號碼的員工幾乎不會對她使用的郵件配額感興趣。 – badbishop 2012-02-29 13:40:45

@badbishop它仍然是一個可怕的想法，一個非常奇怪的方式來組織一個LDAP目錄。大多數情況下，他們被組織起來反映組織結構，這也是一個可怕的想法，另一個原因，或者按照我上面提到的方式，即功能上。 – EJP 2012-03-03 09:10:27

LDAP目錄設計注意事項

回答

相關問題