Wiki Page
HowTo: Setup MS Active Directory integration with Cyn.in
Get to ZMI Screen for your site.
Login with admin user (password: Whatever you changed it to, from the default of "secret") at http://<siteURL OR IP address>:8080/manage to get ZMI screen
Open up your site (cynin link) and click portal_quickinstaller
Install LDAP Support
Check the product shown and hit the Install button
Go to /cynin/acl_users and add ACL plugin
For Microsoft Active Directory, this must be : Plone Active Directory plugin, for other services, Plone LDAP plugin would be first choice
Fill in the details for the AD connection...
This is the crucial step, and must be done right, because without successful connection, the plugin will not install and all you'll get is an Error screen. If you do get an error screen, hit Back in your browser, and change what is needed to fix, and try again.
More details follow in further screenshots.
Get details from your AD
For doing this with MSAD specifically, I recommend the SysInternals tool, AD Explorer. You need to use a tool only to determine the values of your DNs for the AD hookup. If you're well versed with your configuration, then just follow along and fill in appropriate values.
So install AD Explorer, open it up, connect to your Active Directory, and go to the DC, navigate to the place where you're storing User data. This is typically (at least in the out-of-box setup), going to be the one highlighted in the screenshot.
Pick up the base DN and paste
The default AD setup has users and groups in the same DN, Users, so do a right-click on the Folder, and copy the value of Distinguished Name, and paste it into both, the Users Base DN and the Groups Base DN fields. Adjust as required for your own setup, if different.
Pick up the DN of the Administrator user and paste
The Plone AD plugin will use this user to connect to your AD, so if you're not particular about it, the Administrator user will do (right click->properties on the Admnistrator user), else substitute any user's DN as appropriate, just make sure at least Read access to the Base DN that you're selecting is available.
Paste the DN into... you guessed it, the Manager DN field. :)
Fill in the remaining fields
- Fill in the password for the Admin user.
- Fill in the hostname and port of the AD server in the LDAP Server:port field. The format of this must be either IPAddress:port (as shown), or hostname:port, as per your needs.
- Check on Read Only unless you want users to be able to modify their AD profile through their Cyn.in profile.
- Change the default user roles from Anonymous, Member to just Member
- Fill in an ID and a Title. Whatever you want in this, it doesn't really matter, just as long as you remember it.
... And hit Save
Now depending on validation of the info you filled in, you'll either get the screen shown below, with your newly added item showing in the list, or you'll get an error, if the connection to your AD failed. Diagnose and adjust accordingly, if so by hitting back in your browser and changing what's necessary. Passing this step is crucial for the integration to work.
Turn on all the plugin's methods, hit Update
Click the Properties plugin and move it higher in priority
Select the AD plugin
and click the Up arrow to move it up.
Fix the incorrect Group ID Attribute in Properties Tab
Change from groupid_attr = ObjectGUID to...
... to groupid_attr = sAMAccountName and hit Save.
Yes, the case of the value is important, you have to type it exactly as shown.
Open the Contents tab
...and then open up the nested acl_users object.
Fix the User Object Classes
Change from pilotPerson, uidObject to...
..... to organizationalPerson, as shown. Again, CaSe is important.
Check the Groups tab
You should see all the groups in your AD showing up here, now. Verify that all looks ok, don't change anything.
Verify User lookup
Click the Users tab, fill in a known value and choose the appropriate field, and hit Search.
Verify the Search Results
Click a result and ensure correct Group assignment
The user should have appropriate Groups checked as per "belongs to" relationship.
Login should now be working with AD :)
But you still have to do Schema mapping...
The fullname of the user, the email address is not being mapped to the user yet. You need to map this up properly so that things like notification emails, etc. work properly. Read on...
Go to LDAP Schema tab...
Add displayName as FullNameAdd mail as email
Refer to /cynin/portal_metadata and map other fields
Navigate out to /cynin and then to portal_metadata object. Here, you'll see the fields that Cyn.in currently stores against all users.
The idea is that you can map things like phone numbers, job titles (designation), etc., by matching these fields against the ones stored and in use, in your AD. To add a new mapping, see the name here, compare it with your AD field's name and add a new mapping in LDAP schema screen, as shown for displayName and mail. The rest of the fields are left up to you as per your requirements and usage.
- If you don't map a field, it won't get filled automatically, but your users will be able to use it normally from their Cyn.in edit profile
- If you do map a field, and your AD connection is set to Read Only, then users will not be able to edit it
- If you do map a field, and you AD connection is not set to Read Only, then changes users will make, will make it back to your AD, if the username/password combination you put in the Manager DN field has write permssions
Clear Cache and revisit
If you, like me, wanted to login first to see if it works, then you get to visit the Caches tab to purge all caches, after you do the schema mapping.
Logins are cached as per the setting in the Caches tab, so that your AD is not looked up constantly. Tweak here only if necessary.
Once you map up the schema as per above, your People Directory will come pre-populated with the users from your AD, as shown. If you're setting up a complex Space structure, do note that you canmap groups from AD to local roles on the Sharing tab of a Space - and it should work fine.
So set your Cyn.in's up, let's see if you can get it to work properly. :)
Let us know if you have any ideas, suggestions about this or if you get stuck in a problem with the AD integration, just post up a new discussion with the details.

Blog
Status Log




























Please start a new discussion topic for this and tell us what you want to accomplish, in as much detail as possible.
For Cynapse.com we currently have an SSO between Drupal 6.x, Redmine and Cyn.in.
So you had pointed the Users and Group OUs to the top-level and it was not working fully?
Weird. The normal behavior mode is "SUBTREE" where any matches from any descending structure should be returned, for all queries.
Or was it some other top-level branch of the AD tree altogether?
The reason that delete works is because Cyn.in knows that it's an AD user and when you administratively ask to delete the user, the choice is either to say not-can-do, or to go ahead and delete it.
In the case of create user, Cyn.in will create a "normal" user, one that it can manage fully, in the internal source_users implementation.
I have everything working properly with AD, I wanted to see if he could give access (login) only to a group of AD, such that only group members of GG_CynFRD group can log into Cyn.In
Thanks in advance, Cristian.
For a user having an accent in his CN, If I look at his properties and the list of groups he belongs to, that's ok.
But if I go the the group properties, I only see users NOT having accents in their name. The effect is that the effective privileges of the user when he logs in ignores this group belonging.
That is a very big issue if I'm not alone !
domain.com
> Location1.OU
> Computers
> Users
> Location2.OU
> Computers
> Users
And so on. So in order to grab all users, I have to enter the root dn. so dc=domain, dc=com. So it is grabbing ALL users. But my problem is it is grabbing all objects, computers, servers, etc. So when browsing the "People" section of cyn.in it is showing a bunch of computer names and server names. Any way around this?