SiT! Bugs

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001315SiT!LDAPpublic2010-05-04 10:262011-02-08 14:34
Reporternicdev 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusclosedResolutionsuspended 
PlatformOSOS Version
Product Version3.60 LTS 
Target VersionFixed in Version 
Summary0001315: Add the ability to use LDAP when contacts reside in multiple Organisational Units
DescriptionIf the AD or LDAP is configured to have the contacts of each site inside it's own OU, then LDAP does not work.

For eg:
A company has an OU for each site "Helsinki" "Paris" and "London"
So you have the following in AD:
Base DN: DC=euro,DC=company, DC=com

inside this you have for Paris for example:
OU=Users,OU=Paris,DC=euro,DC=company, DC=com

and the same for the others, eg London:
OU=Users,OU=London,DC=euro,DC=company, DC=com

In this case the LDAP functionality of SiT does not work, and on top of this problem we may even have the following for eg:

OU=Users, OU=London, DC=euro, DC=company, DC=com
OU=Users, OU=Paris, DC=euro, DC=company, DC=com
OU=Users, OU=Paris, DC=euro, DC=company, DC=com

OU=Users, OU=CapeTown, DC=africa, DC=company, DC=com
OU=Users, OU=Lusaka, DC=africa, DC=company, DC=com

and another for DC=americas, DC=company, DC=com ... etc..



Additional InformationWe realise this is quite a bit of additional work, but if you try to use the base DN to search for contacts, and you contacts overall are more than 80 000, the result set is too big and goes to timeout ..

Any ideas?
TagsNo tags attached.
Attached Files

- Relationships
related to 0001456confirmed Add ability to loop through multiple Groups to search for customers in an AD forest 

-  Notes
User avatar (0003135)
nicdev (developer)
2010-05-04 13:39

As a side note ..

maybe we could make it possible to specify more than one group, as an array in:
$CONFIG['ldap_customer_group']
and then let it loop through each group with a for .. each statement ... maybe that solution will be the easiest?
User avatar (0003137)
Tomse (developer)
2010-05-04 16:03

Can you make it so the base DN just use the root of the domain ?

e.g. DC=company,DC=com
User avatar (0003140)
paulh (administrator)
2010-05-04 19:34

Firstly let me say I'm no AD expert though this is definitely a performance problem with your AD and sadly nothing SiT! can do to work around that.

I've just tried an LDAP search against my AD in the lab with the following

time ldapsearch -h 10.1.0.20 -D administrator@ad.work.pheaney.co.uk -W -x -b dc=ad,dc=work,dc=pheaney,dc=co,dc=uk "(samaccountname=paulh)"

and that came back in

real 0m0.223s
user 0m0.000s
sys 0m0.000s

I've got 10,000 (or so) users though in a relatively flat structure (ad.work.pheaney.co.uk with containers staff, customers, users and contractors)

Is this just one domain or a forest? If its a forest then it will have quite a number of referrals which will take a while.

Alot of our customers with large environments tend to have a separate flat directory using LDAP and use an identity management product to provision/provision and keep in sync.

Your other option would be to sync users (and their passwords) into SiT using an identity management product rather than using LDAP which would overcome this problem.
User avatar (0003145)
nicdev (developer)
2010-05-05 11:45

Hi Paul/Tomse

Thanks for the feedback.
Ok let me explain a bit more:
The structure is like this:
ad.company.com
inside we have:
euro.ad.company.com
napa.ad.company.com
apac.ad.company.com

SiT is mostly used in the "Euro" part,

under the euro.ad.company.com we have many sub divisions like:
industrial controls.euro.ad.company.com
Powerquality.euro.company.com
etc...

Sit is mostly used in the OU:
OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com

the problem now is that the tree splits even further:
inside U=Industrial and Commercial Controls we have an OU for each site:
Like for example here where our Engineers are:
OU=FR-Grenoble,OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com

then inside each of these OU's(or sites) we have an OU called users:
OU=Users, OU=FR-Grenoble,OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com

in the settings for LDAP in SiT:
($CONFIG['ldap_user_base'])
DC=euro,DC=ad,DC=company,DC=com

($CONFIG['ldap_user_group'])*The users works*
CN=Support_team,OU=Security Groups,OU=FR-Grenoble,OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com

($CONFIG['ldap_customer_group']):*The contact sync fails*
OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com


When ldap syncs, the users sync ok, but i get the following for contacts in the debug file:
/pst/auto.php CONTACTS
/pst/auto.php Warning [2] ldap_search() [function.ldap-search]: Partial search results returned: Sizelimit exceeded (in line 886 of file D:\wamp\www\pst\auto.php)
/pst/auto.php Application Notice [1024] No contact group found in LDAP (in line 889 of file D:\wamp\www\pst\auto.php)

I assume this is because the setting asks for "The full DN of the group the identifies the person as a valid contact/customer ", and in our case the full DN is an OU, and the results exceed the sizelimit of PHP.

I believe we should move this to the forum after as a discussion maybe?
User avatar (0003148)
paulh (administrator)
2010-05-05 21:17

Hi Nico,

This is a configuration issue, $CONFIG['ldap_customer_group'] should be a GROUP and NOT an OU as you've specified

What is effectively happening here is sit is retrieving EVERY group in OU=Industrial and Commercial Controls,DC=euro,DC=ad,DC=company,DC=com which given the error indicated you have more than 1000 groups under this OU (as AD can only retrieve 1000 objects in a LDAP search)

All your users you want as customers need to be a member of ONE group (and a direct member) I know this isn't that best in the world but thats a topic for another day
User avatar (0003557)
ivan (administrator)
2011-02-08 14:34

Suspending this issue as it's a user config issue (and perhaps a documentation issue) rather than a bug as reported.

If an issue remains please reopen or log a new issue. thanks.

- Issue History
Date Modified Username Field Change
2010-05-04 10:26 nicdev New Issue
2010-05-04 13:39 nicdev Note Added: 0003135
2010-05-04 16:03 Tomse Note Added: 0003137
2010-05-04 19:34 paulh Note Added: 0003140
2010-05-04 19:34 paulh Status new => feedback
2010-05-05 11:45 nicdev Note Added: 0003145
2010-05-05 11:45 nicdev Status feedback => new
2010-05-05 21:17 paulh Note Added: 0003148
2010-05-05 21:17 paulh Status new => feedback
2011-02-08 14:34 ivan Note Added: 0003557
2011-02-08 14:34 ivan Status feedback => resolved
2011-02-08 14:34 ivan Resolution open => suspended
2011-02-08 14:34 ivan Assigned To => ivan
2011-02-08 14:34 ivan Status resolved => closed
2011-02-08 14:34 ivan Assigned To ivan =>
2011-02-11 09:00 nicdev Relationship added related to 0001456


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker