- *<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 name=”failedlogonattempts”>
- *<physicalAttribute name=”failedlogonattempts”/>
- *<attribute name=”ispassworddisabled”>
- *<physicalAttribute name=”ispassworddisabled”/>
</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:
The following attributes are set up as Integers:
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.