推荐本地LDAP存储进行开发

时间:2010-03-05 04:35:09

标签: active-directory ldap

我们的项目使用LDAP存储库来存储用户。在生产中,这将是Active Directory。对于开发,我们似乎有几个选择:

  • 安装每个人都使用的AD LDS实例
  • 在每台开发人员计算机上安装AD LDS实例

我们试图让'F5'体验尽可能轻量级,因此安装或依赖中央AD商店并不是我最喜欢的想法。

还有其他LDAP服务器,例如Open LDAP。我希望可能有一个简单地与XML文件对话的LDAP服务器。这将允许我们将XML文件存储在源代码控制中,并且具有快速且有效的功能。我们的夜间构建仍然会使用AD来获取任何差异,但希望是因为我们使用LDAP它应该只是工作。

你能推荐一个适用于零配置无共享开发的LDAP实现吗?

3 个答案:

答案 0 :(得分:2)

我使用ADAM然后将LDS用于相当大规模的站点(多个DC,数百万个主体,~1000 auth / profile-get TPS)。

在开发期间,我们运行了类似DB的工程环境,它触及了两个建议的选项:

  1. 生产 - 分发,稳定,发布所有,发布部署,仅限客户。
  2. 测试 - 分布式,稳定,测试拥有,测试部署,类似硬件到生产。
  3. 集成 - 根据周期需求构建 - 共享,低挥发性,测试拥有,测试部署,类似硬件到生产。
  4. 开发 - 共享,易变,测试拥有,开发部署。每周通过汇总更改脚本重建。
  5. 私人 - 个人,非常不稳定,私人拥有,私下部署。使用签入的更改脚本按需构建。
  6. 我们在很大程度上依赖脚本来在环境之间部署,迁移架构和示例数据。有时PITA编写脚本来推广到共享开发人员,但它确实迫使我们在我们周期的早期阶段对模式和测试数据生成采取源代码控制心态。

    虽然这在v1中是一个相当大的开销,但在后续版本中它使得实时系统的升级和修补非常自然。

    集成框的作用在开发周期中随时间变化,在当前版本或未来版本的模式中接近循环结束。

    可以崩溃其中一些角色 - 取决于工程水平,集成要求和犯错误的后果。使我们的系统离线的成本可能是数百万 - 严格是值得的。

答案 1 :(得分:1)

AD由于LDAP具有自己的特性,因此,如果您需要多价,那么在多个LDAP服务器(OpenLDAP,Apache Directory Server,AD等)上进行测试是合理的。

此外,生产中的AD有几个(dis)优势需要考虑:

1)像LDAP一样运行AD是一个坏主意 - 它太沉重,耗费资源; 2)不要忘记AD中的用户帐户是真正的Windows帐户(即安全问题); 3)AD非常适合多站点复制,但将解决方案迁移到其他LDAP服务器是有问题的(默认情况下无法从AD导出密码哈希值);

答案 2 :(得分:0)

共享LDAP服务器很好,但是如果您真正针对LDAP而不仅仅是AD,那么您应该拥有多个具有不同软件的LDAP服务器。我们已经测试了用于开发和测试的AD和OpenLDAP虚拟服务器,并且遇到了许多小差异。在生产中我们支持其他一些服务器,但我不知道哪个服务器。

虽然设置和配置都不容易。对于AD,我们遇到了一些问题,即我们想要一个测试AD,并且不希望它干扰真正的公司AD。一般来说,OpenLDAP最初设置和加载一些数据是一件痛苦的事。我自己没有做这些任务,所以我无法提供更多细节,抱歉。

一旦设置完成,它们工作正常,所有开发人员和测试人员共享这两个服务器。我们使用命名约定,因此每个人都知道哪些用户是他们的添加/编辑/删除而不是踩到彼此的脚趾。我不认为每个开发人员都需要拥有自己的LDAP服务器。