Brian,

I got this nailed down a while ago.  I found that one server I was using for 
standard LDAP queries didn't have the port open for LDAPS, and that the server 
that did support LDAPS didn't have the port open for LDAP.  I also found that I 
had to create a separate AREA configuration entry for each OU where accounts 
could potentially exist on the domain.  I also had to play with the bind user 
field needing to be in LDAP format instead of domain\username format.


I hope this makes sense.  Thanks to all who helped me get this taken care of.


--Dustin


________________________________
From: Action Request System discussion list(ARSList) <[email protected]> on 
behalf of Brian Gillock <[email protected]>
Sent: Friday, December 16, 2016 3:46 PM
To: [email protected]
Subject: Re: AREA failures

**
If you haven't nailed this down yet, in addition to the format Carl Wilson 
mentioned for Bind User, we use samAccountName=$\USER$ for User Search Filter 
and Port 3268 for LDAP and 3269 for SSL connections.  I'm not a hundred percent 
on this, but I think the port number has something to do with the Global 
Catalog for AD.  We have a gc tacked on to the beginning of our Host Name.

Cheers!
Brian

On Tue, Nov 8, 2016 at 3:56 PM, Carl Wilson 
<[email protected]<mailto:[email protected]>> wrote:
**
Hi,
The simple bind user needs to be in the format of the fully qualified 
distinguishedName including CN, OU and DC values not Domain/User.

----------------------------------------------

Kind Regards,

Carl Wilson


From: Action Request System discussion list(ARSList) 
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Fawver, 
Dustin
Sent: 08 November 2016 20:36

To: [email protected]<mailto:[email protected]>
Subject: Re: AREA failures

**

Ok.  The arjavaplugin.log file has these two lines that appear for each attempt 
that I try.


<PLUGINSVR> <TNAME: pool-4-thread-4          > <ERROR> <ARPluginContext         
                          > <                              
ARPluginContext.java:176       > /* Tue Nov 08 2016 03:31:53.944 */  
<ARSYS.AREA.ATRIUMSSO>Login Failed as Atrium SSO Server Location is null

<PLUGINSVR> <TNAME: pool-4-thread-4          > <ERROR> <ARPluginContext         
                          > <                              
ARPluginContext.java:176       > /* Tue Nov 08 2016 03:31:54.973 */  
<AREA.LDAP>Ldap Authentication failed!javax.naming.CommunicationException: 
ldap.etsu.edu:389<http://ldap.etsu.edu:389> [Root exception is 
java.net.ConnectException: Connection refused: connect]


I'm not trying to use the Atrium SSO feature.  As far as the second line goes, 
what I'm not sure of is whether that message is because the credentials I gave 
in the configuration form are failing, or if the credentials I'm giving on the 
login page are failing, or if the LDAP server is simply refusing the AR 
server's attempt to connect.



--Dustin

________________________________
From: Action Request System discussion list(ARSList) 
<[email protected]<mailto:[email protected]>> on behalf of andres tamayo 
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 8, 2016 3:21 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: AREA failures

**
as recommendation i always use ldp.exe tool to validate my setup first and be 
sure every setting is ok before to go to configuration on AR.

to configure plugin logs check this document

https://docs.bmc.com/docs/display/public/ars81/Troubleshooting+AREA+LDAP+plug-in+issues

2016-11-08 15:11 GMT-05:00 Fawver, Dustin 
<[email protected]<mailto:[email protected]>>:
**

I just tried that and authentication is still failing.  Since I failed to 
mention it the last time, we have an Active Directory environment.  I have also 
tried turning on the plug-in and API logs, but the authentication attempts 
don't seem to be logged there.



Thanks!



--Dustin

________________________________
From: Action Request System discussion list(ARSList) 
<[email protected]<mailto:[email protected]>> on behalf of andres tamayo 
<[email protected]<mailto:[email protected]>>
Sent: Tuesday, November 8, 2016 3:06 PM
To: [email protected]<mailto:[email protected]>
Subject: Re: AREA failures

**
hi there

in User search filter field try uid=$\USER$

2016-11-08 14:59 GMT-05:00 Fawver, Dustin 
<[email protected]<mailto:[email protected]>>:
**

Greetings!



This is probably an easy one for the vets, but my Googlefu is weak.  On an ARS 
9.1 (no ITSM) system, I have been attempting to set up AREA to authenticate via 
LDAP.  Authentication is failing.  I was trying to use LDAPS, but I have 
reverted back to just LDAP so that I can eliminate any issues regarding SSL for 
now.  The user account that I'm using as my test is present in the User form 
with a blank password.  Since I don't know if the listserv allows for 
screenshots, here are the settings that I have.



EA tab in Server Information

----

RPC Program Number:  390695

RPC timeout:  30

Need To Sync:  300

Authenticate Unregistered Users:  not checked

Cross Reference Blank Password:  checked

Authentication Chaining Mode:  AREA - ARS

Group Mapping:  blank

Ignore Excess Groups:  checked





AREA LDAP Configuration

----

Host Name:  ldap.etsu.edu<http://ldap.etsu.edu>

Port Number:  389

Bind User:  domain\username

Bind Password:  (supplied)

User Secure Socket Layer:  No

Failover Timeout:  5

Chase Referral:  No

User Base:  ou=FacStaff,dc=etsu,dc=edu

User Search Filter:  cn=$\USER$

Group Membership:  None



Nothing else is filled in on the AREA configuration form.  With the User Base, 
an issue I'm going to run into with that is that user accounts are placed in 
different OUs based on their status with the university.  I had tried a User 
Base of just "dc=etsu,dc=edu", but I don't know if that will work.



I would appreciate any assistance with this.



Thanks!



--Dustin Fawver



HelpDesk Technician

East Tennessee State University
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_
_ARSlist: "Where the Answers Are" and have been for 20 years_

_ARSlist: "Where the Answers Are" and have been for 20 years_



--
Brian Gillock


_ARSlist: "Where the Answers Are" and have been for 20 years_

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"

Reply via email to