获取给定 MAPI/Exchange 用户的 Active Directory 对象的最直接方法是什么？
我正在尝试从 Outlook COM 插件内部查询 MAPI 收件人的 Active Directory 属性。这是我第一次处理 AD 查询，到目前为止我发现的唯一方法似乎并不完全理想，所以如果有更多经验的人在我继续实施该方法之前插话，那就太好了。
因此，这就是我的想法：
- 读取收件人的
PR_EMAIL_ADDRESS_WMAPI 属性的值。 - 使用
IDirectorySearch查找其legacyExchangeDN属性与该值匹配的 LDAP 条目。
这看起来确实足够简单，并且概念验证正在发挥作用，但是：
- 我已经有了一个唯一的 ID - 为什么我必须进行实际的搜索？是否应该有某种方法可以直接访问 AD 用户对象，例如通过某种方式使用我所拥有的有关收件人的信息来构造一个 LDAP 路径，我可以将其简单地传递给
ADsGetObject()？ - 属性名称中的“遗留”一词意味着这可能不是一个好的长期策略。
- 上面的列表实际上缺少一个步骤：在使用 IDirectorySearch 之前，我需要确定要搜索的根容器。现在，我正在查询“
LDAP://rootDSE”，然后请求“defaultNamingContext”属性来制定新查询。这普遍安全吗？例如，当我的外接程序的 Outlook 2010 主机连接到多个不同的 Exchange 服务器并且我需要查询的收件人不是来自默认服务器时，这也适用吗？
FWIW，我正在使用优秀的 Redemption 库来访问扩展 MAPI 层，所以我实际上并没有使用IMailUser 而是使用 IAddressEntry。因此，如果有更好的方法来完成我正在尝试内置到该库中的操作，请随时提出建议。
I'm trying to query Active Directory attributes of a MAPI recipient from inside an Outlook COM-addin. This is the first time I'm dealing with AD queries and the only way I figured out so far does not seem entirely ideal, so it would be great if somebody with a little more experience would chime in before I go ahead and implement that approach.
So, here's what I came up with:
- Read the value of the recipient's
PR_EMAIL_ADDRESS_WMAPI property. - Use
IDirectorySearchto locate an LDAP-entry whoselegacyExchangeDNattribute matches that value.
That does seem straight-forward enough and the proof-of-concept is working, but:
- I already have a unique ID - why should I have to do an actual search? Shouldn't there be some way of accessing the AD user object directly, e.g. by somehow using the information I have about the recipient to construct an LDAP-path that I can simply pass to
ADsGetObject()? - The term "legacy" in the attribute name implies that this might not be a good long-term strategy.
- There's actually a step missing from the above list: Before I can use
IDirectorySearchI need to determine the root container to search. Right now I'm querying "LDAP://rootDSE" and then ask for the "defaultNamingContext" attribute to formulate a new query with. Is this universally safe? For example, will this also work when my addin's Outlook 2010 host is connected to multiple different Exchange servers and the recipient I need to query is not from the default server?
FWIW, I'm using the excellent Redemption library to access the Extended MAPI layer, so I'm not actually working with IMailUser but rather with IAddressEntry. So, if there's a better way to do what I'm trying to do built into that library feel free to suggest that as well.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
里面有很多问题，但就这样吧。
总体而言，您的概念和流程是正确的。您必须记住的是，Active Directory 和 Exchange 是两个不同的系统。他们紧密结合，但你仍然需要搜索 AD 才能找到他们的帐户。 MAPI 早于 Active Directory，并且在这个托管框架世界中并没有很好地发展，这也无济于事，因此除非 Redemption 中内置了某些东西来为您获取 AD 用户，否则您只能靠自己了。
啊，legacyExchangeDN。听起来好像有更好的事情正在发生，对吧？没有。自 Windows 2000 Active Directory 首次发布以来，该属性一直是 AD 帐户和 Exchange 邮箱之间的主要链接。这是在 Active Directory 中查找邮箱用户的最佳方法。使用安全。
你的最后一个项目符号足够复杂，足以成为它自己的问题。对于 95% 的 Exchange 和 Active Directory 安装，假设您的加载项是在现场或通过 VPN 使用，您的做法就很好。但另外5%则非常复杂。您可以对 Exchange 进行一些疯狂的设置，范围从不同的域到不同的林以及托管的 Exchange 环境。老实说，如果您需要能够从任何配置查询 AD，我会问这个问题，因为这是自己的问题。
最后，您可能可以应付大多数公司 LAN 情况。托管 Exchange 会导致问题，因为您通常无法访问支持的 Active Directory。
There's a lot of questions inside there, but here goes.
Overall your concept and flow is right. The thing you have to remember is that Active Directory and Exchange are two different systems. They are tightly integrated, but you still need to search AD to find their account. It doesn't help that MAPI predates Active Directory and hasn't aged well in this managed framework world, so unless there would be something built into Redemption to get the AD user for you, you're on your own.
Ahh, legacyExchangeDN. Sounds like there's something better on the way, right? There isn't. That property has been the main link between the AD account and the Exchange mailbox since Windows 2000 when Active Directory was first released. That's the best way of finding the mailbox's user in Active Directory. It is safe to use.
Your last bullet item is complicated enough to be it's own question. For 95% of all Exchange and Active Directory installations, the way you are doing it is fine assuming that your add-in is used on-site or over a VPN. But the other 5% are very complicated. You can do some crazy setups with Exchange ranging from different domains to different forests as well as hosted Exchange environments. Honestly, if you need to be able to query AD from any configuration, I would ask that as it's own question.
In the end, you'll probably be ok for most corporate LAN situations. Hosted Exchange will cause problems because you typically can't get to the backing Active Directory.