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:[email protected]] On Behalf Of Yogesh Ketkar Sent: Thursday, March 14, 2013 12:43 PM To: [email protected] 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:[email protected]] On Behalf Of Lotz, David Sent: Thursday, March 14, 2013 12:37 AM To: [email protected]<mailto:[email protected]> 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. <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. _ARSlist: "Where the Answers Are" and have been for 20 years_ _ARSlist: "Where the Answers Are" and have been for 20 years_ 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"
