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"
