Hello list,
Remedy 7.5
Oracle 10g
Mid-Tier is patch 3
3 app servers
3 mid tier servers
I am having a peculiar problem and thought I would ask the list if anyone had
seen a similar issue. We are attempting to implement SSO with the BMC supplied
plugin and appear to be successful but (yes there is probably always a but)
users are randomly being locked out of the Domain when in the mid-tier.
We have only implemented SSO for the mid-tier and I have a portion of a
mid-tier log that I have specific question about.
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINEST>
AREAVerifyLoginCallback
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINER> Connecting
via SSL(host=<FQDN for our ldap server> port=636, certPath=c:\ldap_certs)
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINER> connect
timeout previously: -1
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINER> connect
timeout used: 35000
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINER>
ldap_simple_bind("cn=<ldap user name>", hidden)
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINEST> After the
bind
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.1950 */<ARSYS.AREA.LDAP> <FINER>
ldap_search_ext("<search path>", 2, "cn=<me in this case>")
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.2110 */<ARSYS.AREA.LDAP> <FINER>
ldap_simple_bind("CN=<again my correctly formatted credentials", hidden)
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.3200 */<ARSYS.AREA.LDAP> <SEVERE> Bind:
Invalid credentials (LDAPERR Code 49) 80090308: LdapErr: DSID-0C0903A9,
comment: AcceptSecurityContext error, data 775, v1db1
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.3200 */<ARSYS.AREA.LDAP> <FINE> Found user
but password is bad
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.3200 */<ARSYS.AREA.LDAP> <FINER>
LicenseMask=0 LicenseWrite=0 LicenseFTS=0 LicenseReserved1=0 Notification=3
Email=<NULL> LoginStatus=2 ModificationTime=0
<PLGN> <TID: 004912> <RPC ID: 0000000561> <Queue: AREA > <Client-RPC:
390695> /* Wed Mar 13 2013 09:22:41.3200 */<ARSYS.AREA.LDAP> <FINER>
Groups=<NULL>
I know that when LDAP is used for authentication a bind happens for the user
defined in the AREA LDAP Configuration form, and when that is successful
another bind is done for the actual user logging into the system. As you can
see in the log excerpt it does this when using the SSO Plugin as well. We are
only using SSO when logging in through the web. As it was explained to me and
through reading the SSO integration white paper capturing the user ID should be
all that is needed to get the user logged in at that point. We are pulling the
user ID from the header of the IE page and using it after removing the domain
information. My question is if that is all true and we accept that if the user
is logged into the network and able to access it through the web page why is
AREA LDAP trying to do the bind with the user information instead of just a
search and acknowledgement that the user exists on the network? Is there a way
to turn off the second bind for Mid-Tier only? Also, has anyone run into a
problem like this before? I can be logged into the tool for hours and not be
locked out. Then one of my co-workers attempts to login and gets locked out
repeatedly.
Any help would be greatly appreciated.
We use a load balancer before the mid-tier and then again before the
application server. The problem doesn't appear to be linked to any server in
the pool. I have repeatedly gone through the SSO setup for each server and they
are identical and appear to be correct. I have used SSL and non SSL connections
and there doesn't appear to be a problem with any of the certificates.
David Lotz
Fifth Third Bank
Enterprise Solutions-Enterprise Applications
Remedy Application Team
email: [email protected] <blocked::mailto:[email protected]>
P:513.534.3371
F:513.534.3421
MD:1090W2
This e-mail transmission contains information that is confidential and may be
privileged.
It is intended only for the addressee(s) named above. If you receive this
e-mail in error,
please do not read, copy or disseminate it in any manner. If you are not the
intended
recipient, any disclosure, copying, distribution or use of the contents of this
information
is prohibited. Please reply to the message immediately by informing the sender
that the
message was misdirected. After replying, please erase it from your computer
system. Your
assistance in correcting this error is appreciated.
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
