通过 C# 中的 System.DirectoryServices 查询自定义 LDAP 属性?
我的 OpenLDAP 服务器上安装了一个自定义 LDAP 架构,如下所示:
attributeType ( 999.0.01
NAME 'picturePath'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectClass ( 999.1.01
NAME 'indieStackTeam'
DESC 'Team definition for IndieStack'
SUP groupOfUniqueNames
STRUCTURAL
MAY ( picturePath )
)
在我的 ASP.NET MVC 2 应用程序中,我正在查询 picturePath 属性,如下所示(并且已确认 picturePath 存在于键列表中):
this.Picture = properties["picturePath"].Value as string;
当我尝试在 .NET 3.5 下执行此操作时,出现以下异常:
[COMException (0x8000500c): Unknown error (0x8000500c)]
System.DirectoryServices.PropertyValueCollection.PopulateList() +347013
System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) +49
System.DirectoryServices.PropertyCollection.get_Item(String propertyName) +150
但是,当相同的代码在 Mono(与 OpenLDAP 位于同一服务器上)下运行时,它工作得很好。 LDAPAdmin 等客户端也可以正确读取 picturePath 属性。
更重要的是,只有当我去读取该值时,它才会失败;我可以看到该属性位于密钥列表中,但我无法访问它。
不幸的是,未知错误并没有告诉我很多关于出了什么问题的信息,但我发现 System.DirectoryServices 的 .NET 实现非常不稳定(如果您在 'DC 中使用小写字母连接到 LDAP 服务器,您会得到相同的未知错误=')。
以前有人遇到过这个问题吗?如果有,是如何解决的?
I have a custom LDAP schema installed on my OpenLDAP server which is as follows:
attributeType ( 999.0.01
NAME 'picturePath'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
objectClass ( 999.1.01
NAME 'indieStackTeam'
DESC 'Team definition for IndieStack'
SUP groupOfUniqueNames
STRUCTURAL
MAY ( picturePath )
)
In my ASP.NET MVC 2 application, I'm querying for the picturePath property like so (and it is confirmed that picturePath exists in the list of keys):
this.Picture = properties["picturePath"].Value as string;
When I attempt to do this under .NET 3.5 I get the following exception:
[COMException (0x8000500c): Unknown error (0x8000500c)]
System.DirectoryServices.PropertyValueCollection.PopulateList() +347013
System.DirectoryServices.PropertyValueCollection..ctor(DirectoryEntry entry, String propertyName) +49
System.DirectoryServices.PropertyCollection.get_Item(String propertyName) +150
However, when the same code runs under Mono (on the same server as OpenLDAP) it works perfectly fine. Clients such as LDAPAdmin can also read the picturePath property correctly.
More so, it's only when I go to read the value that it fails; I can see the property is there in the keys list, I just can't access it.
Unfortunately unknown error doesn't tell me a lot about what's going wrong, but I'm finding the .NET implementation of System.DirectoryServices is very flaky (you get the same unknown error if you connect to the LDAP server using lowercase in 'DC=').
Has anyone had this problem before and if so, how is it solved?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您应该检查两件事:
1) 该特定用户对象确实在
picturePath
中具有值吗?您可能想在访问属性之前检查该属性是否存在:2)如果我没记错的话,要访问自定义属性,您应该在执行任何操作之前显式刷新用户对象的缓存:
或者:
另外:<中的类code>System.DirectoryServices 实际上主要是针对 Active Directory 使用的 - 当用于其他一些 LDAP 服务器(例如 OpenLDAP)时,可能会出现“意外”或细微的不兼容性。
Two things you should check:
1) does that particular user object indeed have a value in
picturePath
? You might want to check for existance of the property before accessing it:2) If I remember correctly, to get access to custom attributes, you should explicitly refresh the cache for a user object before doing anything:
or:
Also: the classes in
System.DirectoryServices
are really mostly geared towards being used against Active Directory - there might be "surprises" or subtle incompatibilities when used against some other LDAP server - like OpenLDAP..NET LDAP 客户端似乎需要属性类型和对象类的正确格式的 OID。
您会注意到,我使用的是 999.X.YY 形式的 OID,虽然它们在语法上可能是正确的,但在现实世界中通常不会遇到。我的猜测是 LDAP 客户端解析 OID,并且由于这些不符合预期,因此会引发错误。
我将OID分别更改为1.3.6.1.4.1.40000.1.3.1和1.3.6.1.4.1.40000.1.4.1(我还申请了PEN,这会给我一个分配的号码而不是“40000”),刷新服务器中的架构并重新创建条目,LDAP 客户端现在可以正确读取自定义属性。
It seems that the .NET LDAP client expects a correctly formed OID for attribute types and object classes.
You'll note that I was using OIDs of the form 999.X.YY, which while they might be syntactically correct, aren't usually encountered in the real world. My guess is the LDAP client parses OIDs and since these don't conform to what is expected, it throws an error.
I changed the OIDs to 1.3.6.1.4.1.40000.1.3.1 and 1.3.6.1.4.1.40000.1.4.1 respectively (I've also applied for a PEN, which will give me an assigned number instead of '40000'), refreshed the schema in the server and recreated the entries and the LDAP client now correctly reads the custom attributes.