Re: SSO / AREA LDAP question
The Bmc OOTB SSO Plugin is very easy to break since it only depends on http
header authentication. It has nothing to do with LDAP or AD. the scenario
changes if you use the basic SSO with site minder or an external authentication
plugin with a hub.
The best way you can start troubleshooting the issue is to turn ON debug
logging on the plugin and turn ON your plugin logs on the server and identify
the API calls when the account gets locked.
We use JSS SSO plugin and cannot be happier with the support and the security
features of the product.
Regards,
Roney Samuel Varghese. .
Sent from my iPhone
On Mar 14, 2013, at 12:32 PM, "Lotz, David" wrote:
> **
> Yes, we have the plugin and we can get sso to function. The issue is that we
> get random lockouts for the users when they are coming in through the
> mid-tier. It doesn’t happen to everyone at the same time. There have been
> times where it does not affect a given user for several days. Then they log
> in and they get locked out, like I said it seems pretty random. For instance,
> I log in and usually don’t see the lockout issue whereas my co-developer logs
> in and almost instantly gets locked out. Then after resetting his domain id
> he is fine for several hours and then we both start getting locked out. We
> are troubleshooting with our AD team but it isn’t looking promising. I was
> hoping that someone who is using the BMC supplied SSO code experienced this
> and was able to solve the issue.
>
>
> Thanks
> Dave
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Yogesh Ketkar
> Sent: Thursday, March 14, 2013 12:43 PM
> To: arslist@ARSLIST.ORG
> Subject: Re: SSO / AREA LDAP question
>
> **
> Hello David,
>
> >> 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.
> I think there is some confusion here. For SSO to work in general with
> Midtier, there has to be some work done on 2 ends, the Midtier end and the
> ARServer end. AR Server (either form based or AREA LDAP based) needs
> username/password combination for authentication by default. You can have
> some chaining setups where some users will get authenticated against Form and
> other using LDAP which people typically do when they have AREA LDAP setup and
> they setup user password as BLANK in user form for users which need to be
> authenticated against LDAP. But AR Server, by default, will not authenticate
> a user unless password is supplied. BMC whitepaper says that once you have
> overridden DefaultAuthenticator on Miditer side, you can bypass login page
> and as you said, you are getting username somehow. Now this username and some
> TOKEN has to be passed back to AR Server and you need to write an custom AREA
> plug-in which will validate username/TOKEN combination, may be talking to
> some SSO server or in some way. Point is, unless you write a custom AREA
> plug-in SSO will not work. Also in your case, it sounds like, you are
> satisfied by just having extracted username from the browser (IE) and you
> want AR Server to authenticate the user just based on that.
>
> Regards, Yogesh
>
> From: Action Request System discussion list(ARSList)
> [mailto:arslist@ARSLIST.ORG] On Behalf Of Lotz, David
> Sent: Thursday, March 14, 2013 12:37 AM
> To: arslist@ARSLIST.ORG
> Subject: SSO / AREA LDAP question
>
> **
> 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.
>
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */
> AREAVerifyLoginCallback
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */
> Connecting via SSL(host= port=636,
> certPath=c:\ldap_certs)
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */ connect
> timeout previously: -1
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */ connect
> timeout used: 35000
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */
> ldap_simple_bind("cn=", hidden)
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */ After
> the bind
> 390695> /* Wed Mar 13 2013 09:22:41.1950 */
> ldap_search_ext("
Re: SSO / AREA LDAP question
Yes, we have the plugin and we can get sso to function. The issue is that we
get random lockouts for the users when they are coming in through the mid-tier.
It doesn't happen to everyone at the same time. There have been times where it
does not affect a given user for several days. Then they log in and they get
locked out, like I said it seems pretty random. For instance, I log in and
usually don't see the lockout issue whereas my co-developer logs in and almost
instantly gets locked out. Then after resetting his domain id he is fine for
several hours and then we both start getting locked out. We are troubleshooting
with our AD team but it isn't looking promising. I was hoping that someone who
is using the BMC supplied SSO code experienced this and was able to solve the
issue.
Thanks
Dave
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Yogesh Ketkar
Sent: Thursday, March 14, 2013 12:43 PM
To: arslist@ARSLIST.ORG
Subject: Re: SSO / AREA LDAP question
**
Hello David,
>> 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.
I think there is some confusion here. For SSO to work in general with Midtier,
there has to be some work done on 2 ends, the Midtier end and the ARServer end.
AR Server (either form based or AREA LDAP based) needs username/password
combination for authentication by default. You can have some chaining setups
where some users will get authenticated against Form and other using LDAP which
people typically do when they have AREA LDAP setup and they setup user password
as BLANK in user form for users which need to be authenticated against LDAP.
But AR Server, by default, will not authenticate a user unless password is
supplied. BMC whitepaper says that once you have overridden
DefaultAuthenticator on Miditer side, you can bypass login page and as you
said, you are getting username somehow. Now this username and some TOKEN has to
be passed back to AR Server and you need to write an custom AREA plug-in which
will validate username/TOKEN combination, may be talking to some SSO server or
in some way. Point is, unless you write a custom AREA plug-in SSO will not
work. Also in your case, it sounds like, you are satisfied by just having
extracted username from the browser (IE) and you want AR Server to authenticate
the user just based on that.
Regards, Yogesh
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Lotz, David
Sent: Thursday, March 14, 2013 12:37 AM
To: arslist@ARSLIST.ORG<mailto:arslist@ARSLIST.ORG>
Subject: SSO / AREA LDAP question
**
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.
/* Wed Mar 13 2013 09:22:41.1950 */
AREAVerifyLoginCallback
/* Wed Mar 13 2013 09:22:41.1950 */ Connecting
via SSL(host= port=636, certPath=c:\ldap_certs)
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout previously: -1
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout used: 35000
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_simple_bind("cn=", hidden)
/* Wed Mar 13 2013 09:22:41.1950 */ After the
bind
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_search_ext("", 2, "cn=")
/* Wed Mar 13 2013 09:22:41.2110 */
ldap_simple_bind("CN= /* Wed Mar 13 2013 09:22:41.3200 */ Bind:
Invalid credentials (LDAPERR Code 49) 80090308: LdapErr: DSID-0C0903A9,
comment: AcceptSecurityContext error, data 775, v1db1
/* Wed Mar 13 2013 09:22:41.3200 */ Found user
but password is bad
/* Wed Mar 13 2013 09:22:41.3200 */
LicenseMask=0 LicenseWrite=0 LicenseFTS=0 LicenseReserved1=0 Notification=3
Email= LoginStatus=2 ModificationTime=0
/* Wed Mar 13 2013 09:22:41.3200 */
Groups=
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 afte
Re: SSO / AREA LDAP question
Hello David,
>> 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.
I think there is some confusion here. For SSO to work in general with
Midtier, there has to be some work done on 2 ends, the Midtier end and the
ARServer end. AR Server (either form based or AREA LDAP based) needs
username/password combination for authentication by default. You can have
some chaining setups where some users will get authenticated against Form
and other using LDAP which people typically do when they have AREA LDAP
setup and they setup user password as BLANK in user form for users which
need to be authenticated against LDAP. But AR Server, by default, will not
authenticate a user unless password is supplied. BMC whitepaper says that
once you have overridden DefaultAuthenticator on Miditer side, you can
bypass login page and as you said, you are getting username somehow. Now
this username and some TOKEN has to be passed back to AR Server and you need
to write an custom AREA plug-in which will validate username/TOKEN
combination, may be talking to some SSO server or in some way. Point is,
unless you write a custom AREA plug-in SSO will not work. Also in your case,
it sounds like, you are satisfied by just having extracted username from the
browser (IE) and you want AR Server to authenticate the user just based on
that.
Regards, Yogesh
From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Lotz, David
Sent: Thursday, March 14, 2013 12:37 AM
To: arslist@ARSLIST.ORG
Subject: SSO / AREA LDAP question
**
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.
/* Wed Mar 13 2013 09:22:41.1950 */
AREAVerifyLoginCallback
/* Wed Mar 13 2013 09:22:41.1950 */
Connecting via SSL(host= port=636,
certPath=c:\ldap_certs)
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout previously: -1
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout used: 35000
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_simple_bind("cn=", hidden)
/* Wed Mar 13 2013 09:22:41.1950 */ After
the bind
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_search_ext("", 2, "cn=")
/* Wed Mar 13 2013 09:22:41.2110 */
ldap_simple_bind("CN= /* Wed Mar 13 2013 09:22:41.3200 */ Bind:
Invalid credentials (LDAPERR Code 49) 80090308: LdapErr: DSID-0C0903A9,
comment: AcceptSecurityContext error, data 775, v1db1
/* Wed Mar 13 2013 09:22:41.3200 */ Found
user but password is bad
/* Wed Mar 13 2013 09:22:41.3200 */
LicenseMask=0 LicenseWrite=0 LicenseFTS=0 LicenseReserved1=0 Notification=3
Email= LoginStatus=2 ModificationTime=0
/* Wed Mar 13 2013 09:22:41.3200 */
Groups=
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 Applicatio
SSO / AREA LDAP question
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.
/* Wed Mar 13 2013 09:22:41.1950 */
AREAVerifyLoginCallback
/* Wed Mar 13 2013 09:22:41.1950 */ Connecting
via SSL(host= port=636, certPath=c:\ldap_certs)
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout previously: -1
/* Wed Mar 13 2013 09:22:41.1950 */ connect
timeout used: 35000
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_simple_bind("cn=", hidden)
/* Wed Mar 13 2013 09:22:41.1950 */ After the
bind
/* Wed Mar 13 2013 09:22:41.1950 */
ldap_search_ext("", 2, "cn=")
/* Wed Mar 13 2013 09:22:41.2110 */
ldap_simple_bind("CN= /* Wed Mar 13 2013 09:22:41.3200 */ Bind:
Invalid credentials (LDAPERR Code 49) 80090308: LdapErr: DSID-0C0903A9,
comment: AcceptSecurityContext error, data 775, v1db1
/* Wed Mar 13 2013 09:22:41.3200 */ Found user
but password is bad
/* Wed Mar 13 2013 09:22:41.3200 */
LicenseMask=0 LicenseWrite=0 LicenseFTS=0 LicenseReserved1=0 Notification=3
Email= LoginStatus=2 ModificationTime=0
/* Wed Mar 13 2013 09:22:41.3200 */
Groups=
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: david.l...@53.com mailto:david.l...@53.com>
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"
