Both LDAP servers (on two different, untrusted domains) are authenticating just fine now!
So in addition to everything else, the *one* thing that I did not initially try, seemed to do the trick: -Save a backup copy of the ar.cfg file (just in case). -Remove all references to AREA from the ar.cfg file. -Restart the ARSystem service -or- kill the plugin server process to re-read the altered config -Re-add the known-good information to the AREA config *form* which will re-write the needed entries in the ar.cfg file. -Restart the ARSystem service -or- kill the plugin server process to re-read the altered config I think it is important to note (and this was the part the docs didn't clearly define and which confused me) that when allowed to add the values for the AREA-Hub-Plugin: line, the system added two identical lines like so: AREA-Hub-Plugin: "D:\Program Files\BMC Software\ARSystem\arealdap\ arealdap.dll" AREA-Hub-Plugin: "D:\Program Files\BMC Software\ARSystem\arealdap\ arealdap.dll" And not to overstate the obvious, but just so the info is out there... On the "Server Information" EA config tab, I have: -Set the EA RPC number to 390695 -Set "Cross Reference Blank Password" checked. -Set "Authentication Chaining Mode" to "Off". On the AREA Config form, the items of note are: -The remote domain LDAP server is entered by IP Address (DNS on that domain is not available) -The bind user for both LDAP servers needed to be entered in the form of domain\username (MS Active Directory LDAP) -User Base is set to $\AUTHSTRING$ (the keyword for field ID 118 on the USER form) -User Search Filter is set to sAMAccountName=$\USER$ (the keyword for field ID 117 on the USER form) On the User form the items of note are: - Set the password to $NULL$ for the users to be externally authenticated. - Field id 101 is the regular login name field on the user form and is used to uniquely identify the user for the Remedy system, ie - how the user's name will appear in the "Submitted by" field on a record. I used the format of domain\username. - Added the special fields (field ID 117 and field id 118) (see BMC suport knowldedge article #KA288124) - Field id 117 is the network login name of the user that matches the sAMAccountName on the respective LDAP server. - Field id 118 is set to the parent LDAP container of the user. So, for example if my LDAP user's *full* DN is: cn=myUserName,OU=myDept,OU=myOrg,DC=MyDomain,DC=com Then the parent container would be: OU=myDept,OU=myOrg,DC=MyDomain,DC=com I think that about covers it! Thanks again and everyone have a happy, prosperous, peaceful New Year!! JDHood On Mon, Dec 26, 2011 at 9:48 AM, JD Hood <hood...@gmail.com> wrote: > Actually, I think I have it figured out. > > I removed all references to the AREA plugin from AR.CFG, restarted the > system and started from scratch. I added one LDAP server to the AREA config > form, allowing the system to re-add the ar.cfg lines and restarted the > services (just being overly cautious). Then I added the 2nd LDAP server and > restarted the services. > > During hte 2nd restart, I noticed that the system added the AREA-Hub-Plugin > to ar.cfg like so: > AREA-Hub-Plugin: "D:\Program Files\BMC > Software\ARSystem\arealdap\arealdap.dll" > AREA-Hub-Plugin: "D:\Program Files\BMC > Software\ARSystem\arealdap\arealdap.dll" > > And plugin logging showed that it started the AREA plugin twice, with each > server listed with each plugin start-up in the order they were listed in > the config form. > > Unfortunately at this point, the 2nd LDAP server isn't responding to > pings, so I will have to wait until someone is on-site to slap it out of > it's stupor. > > But the logged activity is looking promising and the 1st server is > authenticating just fine. > > Thanks, > JDHood > > > On Sat, Dec 24, 2011 at 8:33 AM, JD Hood <hood...@gmail.com> wrote: > >> My situation is with two different LDAP servers, in two different domains >> configured in the AREA Config form: >> >> Server-A.domain-A <<-- Remote untrusted Active Directory >> server defined in the form by I.P. >> B-Server.B-domain <<-- Local Active Directory server defined by hostname >> >> As regards area, the ar.cfg has the following lines for the plugins: >> >> Plugin-Path: D:\Program Files\BMC Software\ARSystem\arealdap >> Plugin: "D:\Program Files\BMC Software\ARSystem\arealdap\areahub.dll" >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap.dll" >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap_1.dll" >> >> There are no trusts between the domains involved, but outside of Remedy, >> I can connect to either LDAP server and authenticate just fine. >> Connectivity and bind credentials are not an issue. >> >> Within Remedy, logging shows that the first server defined in the AREA >> LDAP config form is ever used. >> >> I have tried AREA -HUB-Plugin lines like the following, killing the >> plugin process after each change... >> >> A single line: >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap.dll" >> This does not work >> >> Two Lines: >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap.dll" >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap.dll" >> This does not work >> >> Two Lines: >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap.dll" >> AREA-Hub-Plugin: "D:\Program Files\BMC >> Software\ARSystem\arealdap\arealdap_1.dll" >> In this case, I copied arealdap.dll and renamed the copied file to >> arealdap_1.dll in it's own directory >> This does not work >> >> >> Here's logging showing that the plugin tries the same server twice, and >> doesn't progress to the second server. The user in this case *CAN* be >> authenticated on the second server. When I have reversed the order of the >> servers in the config form (so that this user's server is listed first), >> then this user authenticates just fine. >> >> */+VL AREAVerifyLoginCallback -- user jdhood >> */<ARSYS.AREA.LDAP> <FINEST> AREAVerifyLoginCallback >> */<ARSYS.AREA.LDAP> <FINER> ldap_init("Server-A.domain-A", 389) >> */<ARSYS.AREA.LDAP> <FINER> connect timeout previously: -1 >> */<ARSYS.AREA.LDAP> <FINER> connect timeout used: 55000 >> */<ARSYS.AREA.LDAP> <FINER> ldap_set_option(Chase Referrals): ON (handled >> by plugin) >> */<ARSYS.AREA.LDAP> <FINER> ldap_simple_bind("MrBindUser", hidden) >> */<ARSYS.AREA.LDAP> <FINEST> After the bind >> */<ARSYS.AREA.LDAP> <FINER> >> ldap_search_ext("OU=Users,OU=fee,OU=fie,OU=foe,DC=fum,DC=com", 2, >> "sAMAccountName=jdhood") >> */<ARSYS.AREA.LDAP> <SEVERE> Search: Can't connect to the LDAP server >> (LDAPERR Code 91) 0000202B: RefErr: DSID-031006E0, data 0, 1 access points >> ref 1: 'fum.com' >> */<ARSYS.AREA.LDAP> <SEVERE> Cannot find the user info in LDAP server >> */<ARSYS.AREA.LDAP> <FINEST> AREAVerifyLoginCallback >> */<ARSYS.AREA.LDAP> <FINER> ldap_init("Server-A.domain-A", 389) >> */<ARSYS.AREA.LDAP> <FINER> connect timeout previously: -1 >> */<ARSYS.AREA.LDAP> <FINER> connect timeout used: 55000 >> */<ARSYS.AREA.LDAP> <FINER> ldap_set_option(Chase Referrals): ON (handled >> by plugin) >> */<ARSYS.AREA.LDAP> <FINER> ldap_simple_bind("MrBindUser", hidden) >> */<ARSYS.AREA.LDAP> <FINEST> After the bind >> */<ARSYS.AREA.LDAP> <FINER> >> ldap_search_ext("OU=Users,OU=fee,OU=fie,OU=foe,DC=fum,DC=com", 2, >> "sAMAccountName=jdhood") >> */<ARSYS.AREA.LDAP> <SEVERE> Search: Can't connect to the LDAP server >> (LDAPERR Code 91) 0000202B: RefErr: DSID-031006E0, data 0, 1 access points >> ref 1: 'fum.com' >> */<ARSYS.AREA.LDAP> <SEVERE> Cannot find the user info in LDAP server >> */-VL FAIL >> >> >> This can wait for the other side of the holidays though. >> >> Merry Christmas All! >> >> Thanks, >> JDHood >> >> >> >> On Sat, Dec 24, 2011 at 3:24 AM, Walters, Mark <mark_walt...@bmc.com>wrote: >> >>> You shouldn't have to manually edit the ar.cfg, all the necessary >>> changes will be made when you configure the additional LDAP servers via the >>> AREA LDAP configuration form. >>> >>> If you're only authenticating against one LDAP server then the hub is >>> not necessary, you should just have a Plugin: ..\arealdap.dll line in the >>> ar.cfg. When you configure two or more LDAP servers this gets replaced by >>> Plugin: ..\areahub.dll and there should be one AREA-Hug-Plugin: >>> ..\arealdap.dll for EACH LDAP server - i.e. 2 LDAP servers, 2 >>> AREA-Hub-Plugin: lines. >>> >>> The AREA LDAP configuration options are the ones that get the _1, _2, >>> etc suffixes, not the plugin lines. >>> >>> Mark >>> >>> ________________________________ >>> From: Action Request System discussion list(ARSList) [ >>> arslist@ARSLIST.ORG] On Behalf Of JD Hood [hood...@gmail.com] >>> Sent: 23 December 2011 22:28 >>> To: arslist@ARSLIST.ORG >>> Subject: Re: AREA LDAP logging question >>> >>> ** Now that that's working... >>> >>> If I have multiple domains defined for LDAP auth in the AREA form, I >>> understand I need to specify additional arealdap.dll's on additional >>> AREA-Hub-Plugin: lines, ala: >>> >>> AREA-Hub-Plugin: "D:\Program Files\BMC >>> Software\ARSystem\arealdap\arealdap.dll" >>> AREA-Hub-Plugin: "D:\Program Files\BMC >>> Software\ARSystem\arealdap\arealdap_1.dll" >>> >>> Is it just as simple as copying the existing arealdap.dll and renaming >>> it to something like "arealdap_1.dll" and adding it on another >>> AREA-Hub-Plugin line? >>> >>> I've tried that and it doesn't seem to work -- the authentication >>> attempt doesn't progress it to the second LDAP server... >>> >>> Thanks, >>> JDHood >>> >>> >>> >>> >>> On Fri, Dec 23, 2011 at 8:59 AM, JD Hood <hood...@gmail.com<mailto: >>> hood...@gmail.com>> wrote: >>> That did it and it's logging much more info now! >>> >>> I can *now* see from logging that the failure to auth is likely >>> simple-bind being rejected on the LDAP server (I didn't realize LDP uses >>> SASL by default). When I changed LDP to a simple, non ssl bind, the >>> known-good login failed there as well. This would be a clue. >>> >>> Thank you ARSList! >>> -JDHood >>> >>> >>> On Thu, Dec 22, 2011 at 8:12 PM, Grooms, Frederick W < >>> frederick.w.gro...@xo.com<mailto:frederick.w.gro...@xo.com>> wrote: >>> Ah ... It should be something like: >>> >>> Plugin-Path: D:\Program Files\BMC Software\ARSystem\arealdap >>> Plugin: "D:\Program Files\BMC Software\ARSystem\arealdap\areahub.dll" >>> AREA-Hub-Plugin: "D:\Program Files\BMC >>> Software\ARSystem\arealdap\arealdap.dll" >>> >>> So the hub will load the arealdap plugin. Without it the arealdap >>> plugin is not loaded. >>> >>> Fred >>> >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of JD Hood >>> Sent: Thursday, December 22, 2011 6:37 PM >>> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >>> Subject: Re: AREA LDAP logging question >>> >>> ** Ok, I just tried that with logging on and I see: >>> >>> <PLGN> <TID: 005276> <RPC ID: 0000000000> <Queue: Dispatcher> >>> <Client-RPC: 000000> /* Thu Dec 22 2011 19:16:06.3790 */AREA Plug-In >>> Loaded: ARSYS.AREA.HUB version 2 >>> >>> Next, I commented out the plugin server in the armonitor and cranked it >>> up manually and I got the following: >>> D:\Program Files\BMC Software\ARSystem>arplugin.exe --unicode -i >>> "D:\Program Files\BMC Software\ARSystem" -m >>> >>> Action Request System(R) Plug-In Server Version 7.6.04 SP2 >>> 201110080614 >>> (c) Copyright 2001-2011 BMC Software, Inc. >>> >>> Action Request System(R) Approval Server Version 7.6.04 SP2 >>> 201110080614 >>> (c) Copyright 1999-2011 BMC Software, Inc. >>> >>> >>> Next item, checking the ar.cfg, I have the following lines that >>> reference AREA and Plugin: >>> >>> Plugin-Path: D:\Program Files\BMC Software\ARSystem\arealdap >>> Plugin: "D:\Program Files\BMC Software\ARSystem\arealdap\areahub.dll" >>> AREA-Hub-Plugin: >>> >>> >>> Should I add the path to areahub.dll on the AREA-Hub-Plugin line? Or >>> something else? >>> >>> Thanks, >>> JDHood >>> >>> >>> -----Original Message----- >>> On Thu, Dec 22, 2011 at 6:49 PM, Danny Kellett wrote: >>> ** >>> JD, >>> >>> When you start the AR Server (or kill -9 arplugin) and it creates a new >>> arplugin log file, do you see this anywhere? >>> >>> Plug-In Loaded: ARSYS.AREA.LDAP version 2 >>> >>> In fact I would search for ARSYS.AREA.LDAP. If you don't have any in >>> there, then the plugin isn't loading. >>> >>> If this is the case, comment out the arplugin line in the armonitor.conf >>> and restart. Then you can start the arplugin manually from the commandline. >>> Then if something is up, it will echo it to the console. >>> >>> I don't think your arealdap plugin is loading. In your ar.conf, have you >>> got the arealdap.so (or dll) on a line beginning with Plugin: or >>> AREA-Hub-Plugin:? >>> >>> If its the second one, then make sure you have Plugin: >>> <someDir>/areahub.so (or dll) >>> >>> Kind regards >>> Danny >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of JD Hood >>> Sent: 22 December 2011 23:39 >>> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >>> Subject: Re: AREA LDAP logging question >>> >>> ** The plugin log only will show a single +VL and -VL per each login >>> attempt. I don't see anything that indicates it's loading the AREA plugin >>> in the plugin log. >>> >>> When support saw that, they went straight to the ar.cfg, but the AREA >>> config entries in there look fine. >>> >>> We do know that the bind user, login & pass are good because we can use >>> those values with LDP to browse/search LDAP. >>> >>> So, something is wonky with the Remedy AREA plugin, they just don't know >>> what yet. Bundled up the config files and logs (java stuff too) and they >>> are going to have a look, presumably with engineering. >>> >>> After all this, I wouldn't be surprised to find it's a network issue or >>> something outside of Remedy. If only we could get logging to wake up, we >>> could have better visibility into what it's doing. But the logging side is >>> just not cooperating... >>> >>> Thanks, >>> JDHood >>> >>> -----Original Message----- >>> On Thu, Dec 22, 2011 at 3:14 PM, Grooms, Frederick W wrote: >>> Do you see the lines in the log where it is loading the AREA plugin? >>> If not how is the arealdap plugin listed in the ar.cfg file? >>> >>> An additional thought... >>> On Windows 7.6.04 is AREA now a Java plugin? If so it should be debugged >>> thru the pluginsvr_config.xml and log4j_pluginsvr.xml files in the >>> pluginsvr directory. >>> >>> Fred >>> >>> -----Original Message----- >>> From: Action Request System discussion list(ARSList) [mailto: >>> arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>] On Behalf Of JD Hood >>> Sent: Wednesday, December 21, 2011 5:50 PM >>> To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG> >>> Subject: AREA LDAP logging question >>> >>> ** >>> 7.6.04 ITSM on Windows & SQL Server >>> >>> I'm trying to configure AREA authentication. I have everything >>> configured enough to make an authentication attempt and the attempt >>> naturally fails. >>> >>> I do not have a POC at the LDAP server to check my test user's account >>> or to check logging on the LDAP end. >>> >>> At this point, I'm not even sure I'm reaching LDAP, successfully binding >>> and/or hitting the test user's LDAP account. >>> >>> With plugin logging on and set to "ALL", I get about 730 lines of >>> logging when I attempt to login with a test user. >>> >>> Out of those 730 lines of logging, I only get the following two lines >>> that mention AREA or my user: >>> >>> <PLGN> <TID: 005436> <RPC ID: 0000000086> <Queue: AREA > >>> <Client-RPC: 390695> /* Wed Dec 21 2011 18:14:13.9300 */+VL >>> AREAVerifyLoginCallback -- user TRAIN19 >>> <PLGN> <TID: 005436> <RPC ID: 0000000086> <Queue: AREA > >>> <Client-RPC: 390695> /* Wed Dec 21 2011 18:14:13.9300 */-VL >>> FAIL >>> >>> >>> This is like troubleshooting via braille method. Is there another >>> AREA/LDAP log or some way to log the bind and auth attempt on the REMEDY >>> side? >>> >>> I've checked ARSList archives and the BMC KB's and can't find anything >>> that I haven't already tried. I do see some really nice log examples >>> (Knowledge Article ID: KA334262) that I *WISH* I could capture on the >>> Remedy Side. I think they would tell me what I need to know to get this >>> working. For now, all I can find is those two measly log lines above. >>> >>> Any suggestions on how to get AREA logging much more verbose on the >>> *REMEDY SIDE*? >>> >>> Thanks in advance! >>> JDHood >>> >> _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug12 www.wwrug12.com ARSList: "Where the Answers Are"