I think it also depends on how the LDAP is structured at your location. Here I use the following: ldap://domaincontrollermachine/DC=corp,DC=comapny,DC=com??sub?(objectclass=user)
I have seen people use the IP instead of the domain controller machine name. ldap://192.168.0.1/DC=corp,DC=comapny,DC=com??sub?(objectclass=user) I have also seen using the domain in there as well: ldap://corp.company.com/DC=corp,DC=comapny,DC=com??sub?(objectclass=user) I use a different vendor form to look up people in exchange groups and it has a space: ldap://domaincontrollermachine/OU=Domain Groups,DC=corp,DC=company,DC=com??sub?(objectclass=group) This is with 7.1.0 patch 004 on Solaris against Active Directory (2005 I think) The best way I know of to tell what objectclass to use is to browse the directory with a free tool like LDP from the Windows Support Tools or the free Softerra LDAP browser <http://www.ldapbrowser.com/download.htm> and see what is being used. Fred -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of Begosh, Kevin Sent: Wednesday, March 18, 2009 6:21 PM To: [email protected] Subject: Re: LDAP lookup problems James, I have gone over and over this with BMC. The query that BMC has using the vendor form times out a lot unless you put in a CN. We had to for ours. I used CN=Users, then when you bring up a vendor form you can change the query name there, like I did objectclass=*, which pulled all data fields. Let me know if you have more questions. This was different in 6.x when I used it then you could just put the DC or even leave it blank and it brought back everything. Kevin Begosh, RSP Tech Ops Enterprise Business Services 301-791-3540 Phone 410-422-3623 Cell [email protected] -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[email protected]] On Behalf Of James Pifer Sent: Wednesday, March 18, 2009 1:48 PM To: [email protected] Subject: LDAP lookup problems We've just moved to a new ARS 7.1 backend system. During this upgrade we're also making heavy use of LDAP for user management. I'm not the remedy expert so I'll explain this the best I can. Issue 1) On the Remedy side we created an ARDBC LDAP Configuration. We also created a Vendor Form. This was all done a while ago. Now we needed to add another field to the form, and this is where the problems started. When we go into the Vendor form and Load the columns available it was only showing us a few columns, not even the columns we are already using. Our connection string is something like: ldap://192.168.1.99/o=TreeRoot??sub?(objectclass=inetOrgPerson) Here's what we found out, Remedy is connecting to LDAP and looking at the last person created for pulling back column data. If I added a new test user, it would start using that users data. If I deleted the new user it would drop back to the last one. Since not all of our users are required to have some of the data, such as a fax number, we would not see those columns. So, is it possible to force Remedy to look at a specific user object when building the vendor form so you can control what columns it finds? Issue 2) We've also had some issues with the "Base DN for Discovery" in the ARDBC LDAP Configuration. Our ldap directory has several different contexts for different types of accounts. For example, out internal users, customers, and vendors all have their own contexts off the root. Unfortunately our internal users container has a space in the name, ie "Internal Users". When we try to use this for the discovery DN Remedy doesn't seem to handle it. If we put o=TreeRoot there's appears to be too much data or something. If we specify cn=RemedyLogin,o=TreeRoot then it seems to work ok. Seems strange to me to have a cn in a Base DN. Any ideas or suggestions? Thanks, James
