Support for AD

[profplump]

I've added support for ActiveDirectory as an LDAP server.

More generally, I've added the (configurable) ability to:

1. Use a private address book that's not a child of the BINDDN. In AD standard users cannot be the parents of OU objects, but this would be useful to anyone who didn't want to put private address books in their user tree, even on slapd or other servers.
2. Create new entries with a DN in the form of "CN=random,..." instead of "UID=random,...". This is an AD-specific fix required because you cannot create inetOrgPerson objects in AD without putting the CN in the DN.

[giner]

Hi,

I've check our AD and found out it doesn't have objectClass=inetOrgaPerson. We are using Windows 2003 Server as DC.

Regards, Stas

[profplump]

Yes it does. I'm pretty sure it's available as a stand-alone class on all versions of AD, though I don't actually have a Windows 2000 server around to test on.

But I know for a fact that it's available in Windows 2003, as you can tell the AD admin tools to add it to all new Windows users. And in Windows 2008 all users get the inetOrgPerson class by default.

For reference, see this Microsoft support article: http://support.microsoft.com/kb/311555

[giner]

Yes, it's available as a class but user accounts don't have it by default and I can't ask administrator to add it. On Jan 24, 2012 12:40 AM, "profplump" < [email protected]> wrote:

Yes it does. I'm pretty sure it's available as a stand-alone class on all versions of AD, though I don't actually have a Windows 2000 server around to test on.

But I know for a fact that it's available in Windows 2003, as you can tell the AD admin tools to add it to all new Windows users. And in Windows 2008 all users get the inetOrgPerson class by default.

For reference, see this Microsoft support article: http://support.microsoft.com/kb/311555

---

Reply to this email directly or view it on GitHub: https://github.com/cosmocode/contagged/pull/6#issuecomment-3621371

[profplump]

It don't understand why you need user accounts to have it at all -- just make an address book OU and let contagged populate it with inetOrgPeople. The Windows accounts need not be affected.

[giner]

I just don't like to have them duplicate.

[profplump]

I don't understand why you need to duplicate anything.

If you're trying to export the list of existing Windows users as an LDAP address book then you don't need contagged -- you almost certainly want to use the Microsoft-provided tools to manage actual users.

If you're trying to create a general-purpose address book then it doesn't matter what Windows users you have, because contagged doesn't create or consume User objects (except for authentication).

[giner]

At the moment we are using Novell eDirectory as a directory service and contagged as a useful representation of local address book with photos and search abilities.

And now we are at the middle of migration to Active Directory, so we'd like to move contagged to the new environment as well.

[giner]

I mean local address book is a list of our employees/users.

[profplump]

You can probably get contagged to read the Windows users as a list, but my changes are not intended to do that; you would need to significantly re-map the data that contagged expects in the inetOrgPerson fields to wherever Windows stores that data.

There are probably better tools though. For example, the built-in Address Book in Windows, and basically email client that supports an LDAP address book, will read and search AD user list directly. You can even use the thumbnailPhoto and/or jpegPhoto attribute to store photos.

I'd be really surprised if there isn't a dedicated "provide a web interface for my AD user list" tool that looks more or less like contagged and doesn't require you to muck around remapping attributes. Just in a feeling-lucky Google search I found this: http://www.adaxes.com/active-directory_web-interface.htm which provides admin, self-admin, and non-admin web interfaces for AD users.

[giner]

This is not an open source. I didn't manage to find another open source solution better than contagged.

[profplump]

AD isn't open source either.

Regardless, neither this branch nor the original version of contagged will do what you want without adding the inetOrgPerson class to your users and duplicating each user's information into those fields, or creating a whole list of separate inetOrgPerson records, distinct from your Windows user objects.

[giner]

AD isn't open source either. Unfortulatelly It's not in my power to change :)

I'm just telling that it'd been working with eDirectory and I'd like to make it work with AD. That's it. I also have restricted rights (not physically, but politicially) to the AD so I can't do everything I want.

[profplump]

I'm sorry you can't do what you want. I'm just saying this branch won't work for you, and can't be easily adapted. It could be done, but it's a good deal of work.

Honestly you probably don't need any of the adaptations in this branch, unless you were going to allow editing via contagged -- which I would strongly caution you against, and which the AD admins would probably not allow anyway. My changes are mostly related to the particular naming schemes that AD requires for new elements, which conflict with what contagged tries to create. But in a read-only scenario that's likely not an issue.

[giner]

I see :) Thanks a lot anyway.

Stas