Skip to Content
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:

    1. failedlogonattempts
    2. 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.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Anonymous
    Hello Marc

    This is a very nice article. I need to know all the attributes which can be added to the datasource.xml, more precisely the attributes which specify the user account locked information, like who locked it, when it was locked etc… Could you please let me know if there is some kind of documentation, which provides a list of all the attributes under the “com.sap.security.core.usermanagement” namespace.

    Regards
    Kalpesh

    (0) 
    1. Marc Timperley Post author
      http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd“>

      Kalpesh,

      There was a fair amount of trial and error here 🙂

      Some of the attributes are documented: NW04s and NW04, but others we had to find out for ourselves by increasing the logging on the class “com.sap.security.core.usermanagement”. We then used WireShark to trace the calls to the help LDAP troubleshooting to find the type of information being sent.

      If you’re using Microsoft AD/AM, you need to use UNICODE STRING data types for the attributes, not BOOLEAN types.

      The attributes we use are:

      • ispassworddisabled – is the password disabled (not locked) BOOLEAN
      • lockreason – the reason the account was locked INTEGER
      • lockperson – who locked the account STRING
      • locktext – text added when locking the account STRING
      • islocked – flag set when account is locked by administrator BOOLEAN
      • isaccountlocked – flag set when account is locked by user BOOLEAN
      • ispasswordlocked – flag set when password is locked
      • unlockperson – who unlocked the account STRING
      • unlocktext – text added when unlocking the account STRING
      • passwordchangerequired – flag set when a password change is required on next login BOOLEAN

      Hope this helps,

      Marc

      (0) 

Leave a Reply