We have a Federated Portal using two portals and a common LDAP directory as a user repository. Our problem was that although the Federated Portal worked most of the time, issues could occur when a password change is required, for example when a user follows the 'Login Problems? Get Support' link to reset their own password, or when an administrator performs a password reset.
- *<attribute name="ispassworddisabled"/>
- *<attribute name="lockreason"/>
- *<attribute name="lockperson"/>
- *<attribute name="locktext"/>
- *<attribute name="islocked"/>
- *<attribute name="isaccountlocked"/>
- *<attribute name="displayname"/>
- *<attribute name="unlockperson"/>
- *<attribute name="ispasswordlocked"/>
- *<attribute name="passwordchangerequired"/>
- *<attribute name="unlocktext"/>
- <attribute name="logonalias"/>
- * <physicalAttribute name="displayname"/>
- *</attribute>
- *<attribute name="failedlogonattempts">
- *<physicalAttribute name="failedlogonattempts"/>
- *</attribute>
- *<attribute name="ispassworddisabled">
- *<physicalAttribute name="ispassworddisabled"/>
- *</attribute>
- <ume.ldap.access.base_path.uacc>OU=Users,O=ORGANISATION,DC=COM</ume.ldap.access.base_path.uacc>
<ume.ldap.access.server_type>MSADS</ume.ldap.access.server_type>
<ume.ldap.access.user_as_account>true</ume.ldap.access.user_as_account>
</pre>The new physical attributes above also need to be created as attributes of the User class in the LDAP schema. Note: Boolean values such as passwordchangerequired and ispasswordlocked cannot be set up as Boolean values in Microsoft AD/AM as they are written as 'True' or 'False' in Java, but Microsoft expects a Boolean to be 'TRUE' or 'FALSE'. The Boolean attributes, therefore have to be set up as strings. The following attributes are set up as Unicode Strings for Microsoft AD/AM: - ispassworddisabled
- ispasswordlocked
- islocked
- lockperson
- locktext
- logonalias
- unlockperson
- isaccountlocked
- passwordchangerequired
The following attributes are set up as Integers: - failedlogonattempts
- lockreason
These attributes must be associated with the User LDAP class and the schema refreshed. A LDIF file with LDIFDE.exe can be used to do this for multiple Microsoft AD/AM servers. The final stages are to change the server configurations and restart both servers.
Once this is in place, the extended attributes are written to the LDAP and a change to the password on either portal means the 'passwordchangerequired' flag is set in the LDAP, not the local UME. Thus the user is prompted to change their password whichever portal they log on to.
Similarly, this means that if a user is locked on Portal B, they cannot log into Portal A.
With these steps, it is possible to improve authentication and security across multiple portals, either in a federated or non-federated environment.
