SiT! Bugs - SiT!
View Issue Details
0001315SiT!LDAPpublic2010-05-04 10:262011-02-08 14:34
nicdev 
 
normalfeaturealways
closedsuspended 
3.60 LTS 
 
0001315: Add the ability to use LDAP when contacts reside in multiple Organisational Units
If 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..



We 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?
No tags attached.
related to 0001456confirmed  Add ability to loop through multiple Groups to search for customers in an AD forest 
Issue History
2010-05-04 10:26nicdevNew Issue
2010-05-04 13:39nicdevNote Added: 0003135
2010-05-04 16:03TomseNote Added: 0003137
2010-05-04 19:34paulhNote Added: 0003140
2010-05-04 19:34paulhStatusnew => feedback
2010-05-05 11:45nicdevNote Added: 0003145
2010-05-05 11:45nicdevStatusfeedback => new
2010-05-05 21:17paulhNote Added: 0003148
2010-05-05 21:17paulhStatusnew => feedback
2011-02-08 14:34ivanNote Added: 0003557
2011-02-08 14:34ivanStatusfeedback => resolved
2011-02-08 14:34ivanResolutionopen => suspended
2011-02-08 14:34ivanAssigned To => ivan
2011-02-08 14:34ivanStatusresolved => closed
2011-02-08 14:34ivanAssigned Toivan =>
2011-02-11 09:00nicdevRelationship addedrelated to 0001456

Notes
(0003135)
nicdev   
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?
(0003137)
Tomse   
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
(0003140)
paulh   
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.
(0003145)
nicdev   
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?
(0003148)
paulh   
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
(0003557)
ivan   
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.