Thoughts on Portal from Level 2 Support

com Identificações: login

WAS may make multiple calls to Active Directory domain controller for each Portal login attempt

twcornwe Identificações: ldap active directory ad authenticate domain login 2.223 Visitas

There has been at least one case when a customer reported that in the Production environment, when a user attempted to authenticate with Portal and put in the wrong password 2 times, at the 3rd attempt, his/her LDAP account was locked and the user could no longer log in to Portal

In this specific environment, Portal is configured with the Active Directory (AD) LDAP. The AD LDAP is set up to allow 5 invalid attempt. During troubleshooting Portal support suggested that customer tested with authentication with AD directly, and it indeed allowed up to 5 invalid attempts. Whereas, Portal would lock the user account at 3rd attempt to login to Portal, after 2 failed attempts.

Customer also has a Test environment with similar Websphere/Portal version, but the problem did not exist there: users could still log in to Portal at 5th attempts in the Test environment server.

Support then found that in the Test environment (which was working correctly), the LDAP host name pointed to a single LDAP server. Whereas, in the Production environment (where the problem occurred), the LDAP host name pointed to the LDAP Domain Controller.

So, it appears in the case of Production environment, for each attempt to log in to Portal, two calls were made to the AD Domain Controller. Thus, after two invalid Portal login attempts, the AD Domain would see those as 4 invalid attempts, so at subsequent attempt to authenticate with Portal (which make them the 5th and 6th LDAP calls), the AD user account was locked.

A review of Portal login traces showed the following:

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

[10/18/11 15:51:19:545 PDT] 00000062 ltpaLoginModu 3 Authenticating "WPS/e123456"

[10/18/11 15:51:19:545 PDT] 00000062 LTPAServerObj > authenticate Entry

[10/18/11 15:51:19:545 PDT] 00000062 UserRegistryI > checkPassword Entry e123456

****

.......

[10/18/11 15:51:28:107 PDT] 00000062 ltpaLoginModu 3 Authenticating "WPS/e123456"

[10/18/11 15:51:28:107 PDT] 00000062 LTPAServerObj > authenticate Entry

[10/18/11 15:51:28:107 PDT] 00000062 UserRegistryI > checkPassword Entry e123456

****

[10/18/11 15:51:28:107 PDT] 00000062 LdapRegistryI > checkPassword Entry e123456

[10/18/11 15:51:28:116 PDT] 00000062 LdapRegistryI 3 Found user CN=Test User(E123456),OU=EAST,OU=SALES,DC=IBM,DC=COM

[10/18/11 15:51:28:117 PDT] 00000062 LdapRegistryI 3 enterJNDI:WebContainer : 1

[10/18/11 15:51:28:146 PDT] 00000062 LdapRegistryI 3 exitJNDI:WebContainer : 1

[10/18/11 15:51:28:146 PDT] 00000062 LdapRegistryI < checkPassword Exit javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903AA, comment: AcceptSecurityContext error, data 775, v1772 ]

at com.sun.jndi.ldap.LdapCtx.mapErrorCode(LdapCtx.java:3045)

at com.sun.jndi.ldap.LdapCtx.processReturnCode(LdapCtx.java:2991)

...

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

As we can see from the traces, the wrong password was entered twice. The 3rd time, the correct password was submitted. The LDAP responded back that it found the user. But then immediately after that the LDAP threw the LDAP: error code 49 - data 775 (Note: data 775 means: user account locked").

The root cause of in this specifc case was that the LDAP custom property "com.ibm.websphere.security.ldap.retryBind" was not explicitly set. By default, it's set to "true". The WAS APAR PK42672 introduced a couple of LDAP security custom properties. Depending on how LDAP fail over is configured, either of them can be implemented to avoid this type of issue from happening.

Excerpt from the APAR document:

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

"When single LDAP hostname is mapped to multiple IP address in network configuration, If invalid password is entered at the time of login, WebSphere makes LDAP bind retries as many times as (number of associated ip addresses + 1) This may cause LDAP account lockout."

The following custom properties are introduced to prevent the issue from happening. It depends on the LDAP failover configuration to choose which property to use.

1. If LDAP failover is configured by registering backend LDAP server hostnames using wsadmin command, set the following property to true by going Security --> User Registries --> LDAP --> Custom Properties in the WAS administrative console.

com.ibm.websphere.security.registry.ldap.singleLDAP

If this property is set to true, Application Server does not resolve an LDAP hostname to multiple IP addressed. The default value for this property is "false".

2. If LDAP failover is configured by associating hostname with mutlipe IP addresses using network configuration, set the following property to false by going Security --> User Registries --> LDAP --> Custom Properties in the WAS administrative console.

com.ibm.websphere.security.ldap.retryBind

If this property is set to "false", Application Server does not retry LDAP bind calls. The default value for this property is "true".

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

Utilizing auto-login URL across the web

twcornwe Identificações: unencrypted encrypted url protected login auto-login authentication secured sniff password 4.369 Visitas

*** Login URL overview:

WebSphere Portal 6.0, 6.1 and 7.0 all offer the ability to login to the Portal using a specially crafted user of the following format:

http://server:port/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=userid&password=password

For Websphere Portal 7.0.x, a full example of this URL in use would be:

http://myportalserver.raleigh.ibm.com:10039/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=wpsadmin&password=wpsadmin

This URL does not bypass normal authentication mechanisms. The username and password are passed along the PUMA, WAS, and VMM/WMM layers as would occur with a normal login via the login portlet. Once authentication completes, users will be redirected to the first page which they have authorization to access (for example, the Getting Started page in Portal 70x). The login URL offers a means of convenience for Portal administrators to bookmark their sites and automatically login each time. Other applications also make use of this URL; Rational Application Developer, for example, uses this same URL when invoking the Portal Admin Console. This login URL can also offer a potential means for Portal adminsitrators to access the Portal Admin console if unable to do so via normal means (i.e. the login portlet, theme, etc. are not functioning correctly). Namely, you can enter the following URL:

http://myportalserver.raleigh.ibm.com:10039/wps/portal/cxml/04_SD9ePMtCP1I800I_KydQvyHFUBADPmuQy?userid=wpsadmin&password=wpsadmin

followed by:

http://myportalserver.raleigh.ibm.com:10039/wps/myportal/Administration

...which should in turn bring the Portal administrator to the Administration area without ever accessing the login portlet. There are many other uses of the login URL, and these example illustrate a few of the more common use cases.

   *** Using the Login URL over the internet:

   A STRONG warning should be given for the utilizing this URL over the internet. The existing URL by itself is unencrypted with the http protocol. Using software such as Fiddler (http://www.fiddler2.com/) or WireShark (http://www.wireshark.org/), it is trivial to sniff the unencrypted http URL and thereby obtain a valid username and password into the Portal system. Therefore, it is recommended to secure this URL if it will be sent over an unsecure network (such as the internet) prior to arriving at the Portal server.

   Although there are means to force the WebSphere Portal login portlet to use a secureURL when authenticating users, that same option is not available for the login URL. The login URL can be encrypted with SSL security. However, if this is enabled, then the entire Portal site must also be enabled with SSL, which may not be desirable. If utilizing a web server to access the Portal, such as IBM HTTP Server, it may be possible to include a mod_rewrite rule to force this specific URL over SSL, while all other requests would be permitted over HTTP. However, note this should only be used as a failsafe. Meaning, if a user accesses the login URL over the internet, and accidentally sends the request over HTTP, then the username and password would already be sent in the clear prior to it ever reaching the web server and/or Portal server. The web server with the mod_rewrite rule could reject such requests over HTTP, but, the action would have already been committed and the username and password already potentially sniffed off the network. The web server can still act as a failsafe, but, the client-side must be updated to ensure the first request sent out is not sent out in the clear.

Therefore, if using the auto-login URL, on the client-side, whether it be via a web browser, a custom application, etc., be SURE to utilize the auto-login URL over SSL as a best practice.

Feed para Entradas de Blog ▼