LDAP + Contact Display Name

Openfire Openfire Support
1

We currently use LDAP for our users and groups and everything has been working fine. However, I would like to be able to add each Contact’s phone extension to the end of thier displayname in the Spark Contact list (as it shows in Spark). It seems that you should be able to go into the LDAP setup and for the fields “Name” and/or “Full Name” append the telephone attribute to the current attribute as such: instead of “” have it read " ". But, it seems when I do this it does not affect the name displayed in the contact list is Spark. I have tried refreshing the server cache and still no go. Is this even possible? What value is being used to populate the Contact list?

Openfire Enterprise v 3.4.5

JVM 1.5

Linux

LDAP: Fedora Directory Server 1.x

My openfire.xml is below (usernames/passwords removed):

<?xml version="1.0" encoding="UTF-8"?> <!--
    This file stores bootstrap properties needed by Wildfire.
    Property names must be in the format: "prop.name.is.blah=value"
    That will be stored as:
        <prop>
            <name>
                <is>
                    <blah>value</blah>
                </is>
            </name>
        </prop>     Most properties are stored in the Wildfire database. A
        property viewer and editor is included in the admin console.
-->
<!-- root element, all properties must be under this element -->
<jive>
  <adminConsole>
    <!-- Disable either port by setting the value to -1 -->
    <port>9090</port>
    <securePort>9091</securePort>
  </adminConsole>
  <admin>
    <!-- Use this section to define users that will have admin privileges. Below,
          you will find two ways to specify which users are admins. Admins will
          have access to the admin console (only local users) and may have also access
          to other functionalities like ad-hoc commands. -->
    <!-- By default, only the user with the username "admin" can login
         to the admin console. Alternatively, you can specify a comma-delimitted
         list usernames that should be authorized to login to the admin console
         by setting the <authorizedUsernames> field below. -->
    <!-- <authorizedUsernames></authorizedUsernames> -->
    <!-- Comma-delimitted list of bare JIDs. The JIDs may belong to local
         or remote users. -->
    <!-- <authorizedJIDs></authorizedJIDs> -->
    <authorizedUsernames>admin</authorizedUsernames>
  </admin>
  <locale>en</locale>
  <!-- Network settings. By default, Wildfire will bind to all network interfaces.
      Alternatively, you can specify a specific network interfaces that the server
      will listen on. For example, 127.0.0.1. This setting is generally only useful
       on multi-homed servers. -->
  <!--
    <network>
        <interface></interface>
    </network>
    --> <!-- Example LDAP settings -->
  <!-- Note, for Active Directory, try usernameField=sAMAccountName, nameField=displayName,
         emailField=mail -->
  <!--
    <ldap>
        <host></host>
        <port>389</port>
        <usernameField>uid</usernameField>
        <nameField>cn</nameField>
        <emailField>mail</emailField>
        <baseDN></baseDN>
        <adminDN></adminDN>
        <adminPassword></adminPassword>
    </ldap>
    <provider>
        <user>
            <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
        </user>
        <auth>
            <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
        </auth>
    </provider>
    -->
  <!-- End example LDAP settings -->
  <connectionProvider>
    <className>org.jivesoftware.database.DefaultConnectionProvider</className>
  </connectionProvider> <database>
    <defaultProvider>
      <driver>com.mysql.jdbc.Driver</driver>
      <serverURL>jdbc:mysql://localhost:3306/wildfire</serverURL>
      <username>######</username>
      <password>######</password>
      <minConnections>5</minConnections>
      <maxConnections>15</maxConnections>
      <connectionTimeout>1.0</connectionTimeout>
    </defaultProvider>
  </database>
  <setup>true</setup>
  <ldap>
    <host>192.168.1.20</host>
    <port>389</port>
    <baseDN>dc=mcs,dc=local</baseDN>
    <adminDN>#########</adminDN>
    <adminPassword>########</adminPassword>
    <connectionPoolEnabled>true</connectionPoolEnabled>
    <sslEnabled>false</sslEnabled>
    <ldapDebugEnabled>false</ldapDebugEnabled>
    <autoFollowReferrals>false</autoFollowReferrals>
    <usernameField>uid</usernameField>
    <searchFilter>(uid={0})</searchFilter>
    <vcard-mapping><![CDATA[
<vCard xmlns="vcard-temp">
  <N>
    <GIVEN>{cn} {telephonenumber}</GIVEN>
  </N>
  <EMAIL>
    <INTERNET/>
    <USERID>{mail}</USERID>
  </EMAIL>
  <FN>{cn} {telephonenumber}</FN>
  <ADR>
    <HOME/>
  </ADR>
  <ADR>
    <WORK/>
  </ADR>
</vCard>]]></vcard-mapping>
    <nameField>cn telephonenumber</nameField>
    <emailField>mail</emailField>
    <groupNameField>cn</groupNameField>
    <groupMemberField>uniquemember</groupMemberField>
    <groupDescriptionField>description</groupDescriptionField>
    <posixMode>false</posixMode>
    <groupSearchFilter>(&(objectClass=groupofuniquenames)(cn={0})(!(cn=Directory*)))</groupSearchFilter>
  </ldap>
  <provider>
    <vcard>
      <className>org.jivesoftware.openfire.ldap.LdapVCardProvider</className>
    </vcard>
    <user>
      <className>org.jivesoftware.openfire.ldap.LdapUserProvider</className>
    </user>
    <auth>
      <className>org.jivesoftware.openfire.ldap.LdapAuthProvider</className>
    </auth>
    <group>
      <className>org.jivesoftware.openfire.ldap.LdapGroupProvider</className>
    </group>
  </provider>
</jive>
2

Can someone from Jive please comment on this? It has been about a week and I was hoping for some guidance. Thanks.

3

Hey there,

I haven’t tried to do this exactly, but I seem to remeber that the user roster is also cached on the client side. Have you tried this on a fresh install of spark or deleted the temporary data that spark stores? It definetly looks like you should be able to use any attribue you’d like from ldap to drive the user name on the roster.

If a fresh spark install still shows the default names I’ll attempt to mock up a similar situation locally and see what I can find.

~Sean

4

Tried with a fresh install of Spark - still does not work. I have attached a screenshot of what I see in a fresh install of Spark (v2.5.8) - it is exactly what I see in other installs of Spark as well. Basically, you see the attribute at the top for your contact name (in your copy of Spark), but it does not show up in the contact list. It does not display on the server side either

5

Sean,

Have you been able to test this yet? It would be great to be able to do this again since we had this in place before moving to LDAP (extensions appended to Display Name). Lots of users miss it (in particular the president of the company who is the most vocal - you know how that goes )

Thanks,

brian

6

Still wondering if there is any word on this…

7

bumping this again in hopes of some update on this issue…

8

If OpenFire just does an LDAP query using the specified LDAP attribute name and uses the result of the query to populate the attributes of an OpenFire user, e.g. display name.

Then it may be that what you are looking to do is not possible, i.e. trying to combine the results of two seperate queries into to one OpenFire/Spark user attribute.

What will work to satisfy your requirement is to create a new attribute on a LDAP user account that contains a combination of the display name and telephone number. (Or create a new LDAP attribute for each user.)

Then configure OpenFire to use (query) the LDAP attribute you have selected (that contains the custom display name/telephone number combination) and hence display what you wanted.

Will be interesting to see if anyone can offer another interpretation of how the LDAP query works.

9

It appears that you cannot combine multiple attributes into 1 field. The “displayName” in our Active Directory differs from the standard " " rule, which is why I was trying to get " " to display as the users nickname. THis does not work.

Hopefully this can be considered a bug/feature request. Allowing multiple attributes per field would be helpful.