Mozillians/One Phonebook to Rule Them All

From MozillaWiki
Jump to: navigation, search

Mozilla has two Phonebooks for Mozillians: one for paid staff and another that is volunteer focused. Further, the People team is currently building a third interface in which paid staff can manage their internal profiles (and eventually contributors). To have 3 separate interfaces with sometimes duplicating functionality will confuse Mozillians. As a result, the "One Mozillian Phonebook" plans to make a natural and coherent explanation of how the Mozillians Phonebook and our LDAP tree will work together (and indirectly, Workday, too).


Have only one Mozillian Phonebook.



Mozillians Phonebook

The community is filled with paid-staff and volunteers and a phonebook for the project should naturally be publicly facing. There are things that the Mozillian Phonebook does not offer which it will need to fulfill the needs of various teams.

  • Be the central Phonebook resource and community site partner in the Mozilla Project.
  • Offer an easy method for Vouched Mozillians to have greater access to our LDAP-auth'd systems


  • Have a completely filled LDAP contributor tree separate from paid staff
  • Display an Org Chart (Workday will not do this)
  • Paid staff should be able to change fields in their LDAP profile view that is internally-based
    • Bugzilla E-mail Address
    • Determine who has commit access
    • Determine who is paid staff, contractors (employeeType will be auto-populated from Workday) and volunteers


  • Eventually be the single source of truth for employee data and permissions.
  • Should be able to parse for contributor information from the LDAP contributor tree

LDAP Usages

One mozillian phonebook breakdown.png

  1. Contributor-Facing Services:,,,
  2. Staff-Only Services: Wifi, Vidyo, Zimbra, Shell servers
  3. Zimbra: location and employee-status based distribution lists are generated from LDAP
  4. internal directory for mail clients
  5. All "internal" Mozilla websites
    • various others used by small teams internally
  6. General Linux server logins - Too many to list - somewhere around 100 machines
  7. Source of truth for all internal server security - sysadmin accounts for all servers and root access managed by LDAP
  8. Postini
  9. Egnyte (not production yet)
  11. (OpenVPN)
  13. WebDAV access
  14. Single-signon (soon)
    • Workday
    • jobvite
    • egencia
    • intacct
    • ... more...

Profile Fields between Phonebooks

There are a number of fields that are missing from the Mozillian Phonebook that will need to be added for paid staff employees. A lot of these fields can be generalized for contributors, but some will need to be restricted to only paid staff or administrators.



Mozillians Phonebook

Add in the profile fields necessary to duplicate the information on the Internal Phonebook to the Mozillian Phonebook. The difference in fields between the two can be found here.

Interface with LDAP

We want to offer volunteer Mozillians a simple method of accessing our LDAP-based systems. To do this, we'll set up a solution that does the following:

  1. Mozillians Phonebook and LDAP contributor tree sync on a daily basis
  2. Offer a LDAP account password to contributors within their Mozillians profile. This will be managed within the Mozillians Phonebook

Further, a Mozillian will need to reset their LDAP password every 90 days. So, communication will be a top priority via channels such as e-mail and/or through our apps.

LDAP Viewer

The Internal Phonebook will not completely go away as it offers features that the Mozillians Phonebook will not be able to offer. They are:

  1. The internal Org Chart (Done by Yammer's Org Chart app and Workday sync?)
  2. There are some LDAP fields which are only editable via the Internal Phonebook. Eventually, these editable LDAP fields will be set within Workday, but we'll need to continue to have those capabilities within the current LDAP Phonebook for now.

Interface with Workday

Workday will be interfacing with the LDAP paid-staff and contributor trees already. So, there likely won't be a need to duplicate that effort for sharing contributor profiles. The only other possible need that goes outside of LDAP usage will be the authorization of contributors if BrowserId is used. In mostly all cases though, our People systems can simply either share profile data or authorize contributors based on the contributor tree already available in LDAP.