Home › Blogs › urbr's blog

Luminis IV - EAS fallthrough / failover to internal LDAP

Thu, 2008-02-21 16:32 — urbr
5
Average: 5 (3 votes)

Luminis EAS fallthrough / failover to internal LDAP.

Like many, we do not wish to populate our campus enterprise LDAP (henceforth "external LDAP") with Luminis-specific accounts like 'alluser-lo' which already reside in the Luminis LDAP (henceforth "internal LDAP"). After unsuccessfully trying this, we decided to configure the internal LDAP exactly as if it were another external ldap source.

jaas.conf configuration for multiple authentication sources (i.e. "fallthough")...:

jaasEas {
com.pipeline.security.authen.JaasLdapLoginModule sufficient prefix=security.ias.eas.jaas.ldap;
com.pipeline.security.authen.JaasLdapLoginModule sufficient prefix=security.ias.eas.jaas.lumldap;
};

The first line of jaas.conf refers to our external LDAP server. The following values were configured:

security.ias.eas.jaas.ldap.searching.is_enabled=true
security.ias.eas.jaas.ldap.mapping.is_enabled=false
security.ias.eas.jaas.ldap.searching.user.userid=cn\=[ldap search acct],o\=[org name]
security.ias.eas.jaas.ldap.searching.dn=o\=[org name]
security.ias.eas.jaas.ldap.searching.user.password=[ldap search pw]
security.ias.eas.jaas.ldap.searching.type=uid
security.ias.eas.jaas.ldap.host.name=[external ldap server]
security.ias.eas.jaas.ldap.host.port=389
security.ias.eas.jaas.ldap.protocol.version=3
security.ias.eas.jaas.ldap.protocol=ldap
security.ias.eas.jaas.ldap.userid_format=uid
security.ias.eas.jaas.ldap.searching.user.is_enabled=true

* Note: "security.ias.eas.jaas.ldap.protocol.version=3" was not in the documentation explicitly. Needed this to function.

Next, the values to allow a search of the internal LDAP as if it were an external data source:

security.ias.eas.jaas.lumldap.searching.is_enabled=false
security.ias.eas.jaas.lumldap.mapping.is_enabled=true
security.ias.eas.jaas.lumldap.mapping.dn=ou\=People,o\=[luminis org name],o\=cp
security.ias.eas.jaas.lumldap.mapping.type=uid
security.ias.eas.jaas.lumldap.host.name=[luminis ldap server]
security.ias.eas.jaas.lumldap.host.port=389
security.ias.eas.jaas.lumldap.protocol.version=3
security.ias.eas.jaas.lumldap.protocol=ldap
security.ias.eas.jaas.lumldap.userid_format=dn
security.ias.eas.jaas.lumldap.implementation.userid_format=dn

It seems to check both sources regardless of a successful match. One significant problem we've noticed is that if someone changes their external LDAP password, the old password is still cached in Luminis's LDAP, and it works without a problem (until trying to access something that wants the external LDAP password). Once a user logs in with their external LDAP password, Luminis will cache the new password and all will be well.
A possible solution would be to wipe out the cached password on logout, via a script, etc. Haven't worked out how to do this just yet.

I am also admittedly ignoring the whole arena of password changes, because we'll most likely be handling that external from Luminis.

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Thu, 2008-03-20 10:57 — urbr

A note on this: Although one

A note on this:
Although one Sungard rep told us this was not possible, the person performing our official test install had no problem setting Luminis up in this manner.

Password synchronization is still a problem -- If someone changes their password in the EAS, Luminis still has the old password cached and will allow the person to login with the old password.

Possible solutions: Find a way to change the priority of the LDAP queries (hit campus ldap first. If UID does not exist, check luminis ldap). Another possibility is scripting the Luminis password to be wiped an logout.

Wed, 2008-04-30 16:44 — bgibson

getting rid of cached password

I saw your note about passwords being changed and the previous password being cached as being an issue. Have you implemented anything to fix this? I noticed you mentioned a script that could be called on log out that wipes out the Luminis cached copy of the encrypted password. We have our Luminis 4.0.2 server authenticating against Active Directory and we have a custom password management system for it written in PHP. I was thinking when a password gets changed on this web page we could have it connect to the Luminis LDAP server and wipe out the cached credentials. We would just need to find out what attributes and values we would have to change.

Thu, 2008-08-21 16:20 — peluso14

cached password

Has anyone Determined hot to clear the cached password, via a script, or directly in ldap? It seems there are some major over sites in the EAS implementation, we are in go live week, and a lot was left out, but sungard and the consultants on how exactly it would work. Unfortunateley, we we were told EAS was setup and working, and users could authenticate against AD, we made some assumptions that meant it actually works, not annoying, and obvious bugs like, if a external password changes it won't work, or the internal one still does....

Wed, 2008-06-11 16:21 — jchannel

RE: Password Changes in EAS FallThrough Scenario

I have set up as you described with two sources in my jaas.conf file.

For us it was
jaasEas {
com.pipeline.security.authen.JaasLdapLoginModule sufficient prefix=security.ias.eas.CAMPUS;
com.pipeline.security.authen.JaasLdapLoginModule sufficient prefix=security.ias.eas.luminis;
};

All is well with users and password changes in our EAS (CAMPUS). However, When I change luminis account password (say allusers-lo) in luminis and go to login I am redirected to the password change page and then when changing the password it errors out.

Failed to change password!

Please try again later or

Contact your system administrator. and in the cp.log the error is:
com.pipeline.security.authen.PasswordException: [CHANGE_PASSWORD_FAILED, Change password failed due to a failure in another subsystem, Failed to change the password in the EAS server.]

Has anyone came upon a fix for this? We are trying to get away from adding system users to the EAS and all users who don't have an account there should be passed back to the luminis ldap for authentication (if they exist there)

Any assistance would be appreciated.

jchannel