I think we should use the same wmf-user.schema file across the labs and corp servers, but introduce a separate object class for storing the SUL mapping. This allows us to extend staff-specific attributes independantly and it the corp LDAP needs the SUL mapping at some point we can add the new object class to corp user accounts.

@faidon, @Volans, and I talked about this at the Vienna hackathon. Moving this data from Striker's local DB to LDAP would be a useful step in an as yet undocumented project to create an LDAP management portal to replace the current mix of wikitech, Striker, and cli tools used by SRE.

In T148048#8470183, @akosiaris wrote:

This is open since 2016 with minimal updates, probably inaccurate now (as far as I know the corp LDAP doesn't exist now) and it is unclear, at least to me, what work can be done and by who. Thus, I am setting it as Stalled, feel free to reopen

We'll actually work on this as part of the Bitu IDM work, either next Q or the subsequent one, depending on progress and forthcoming quarterly planning! I'm adding it as a sub task of the IDM roadmap to keep track.

Ah, that's awesome. Thanks!

Change 886799 had a related patch set uploaded (by Slyngshede; author: Slyngshede):

[operations/puppet@production] P:openldap Extend wmf-user schema with SUL account.

https://gerrit.wikimedia.org/r/886799

Mentioned in SAL (#wikimedia-operations) [2023-04-24T09:55:51Z] <slyngs> Update LDAP schema wmf-user: T148048

Change 886799 merged by Slyngshede:

[operations/puppet@production] P:openldap Extend wmf-user schema with global account.

https://gerrit.wikimedia.org/r/886799

SLyngshede-WMF claimed this task.

@SLyngshede-WMF Are you expecting to update Striker to add objectClass: wikimediaPerson and set the wikimediaGlobalAccountId and wikimediaGlobalAccountName attributes on accounts it creates/updates?

@bd808 Wasn't expecting to, but I can do it :-)

In T148048#8802325, @SLyngshede-WMF wrote:

@bd808 Wasn't expecting to, but I can do it :-)

I was mostly asking because of your claiming of this task. It will need doing at some point and this task was the tracking task for that need. The task decomposition probably could have been cleaner so that we had a task about the LDAP schema change and then a dependent ("parent" in Phabricator terms) task to track implementing the data storage changes in Striker to use the new schema.

Either way I will try to do a bit of analysis of at least the starting changes that will be needed on the Striker side to take advantage of the LDAP schema you have designed.

I think that broadly the changes needed for Striker now that the new LDAP schema has landed will be:

• Add the wmf-user schema to the LDAP service in Striker's development environment
• Update striker.labsauth.models.LabsUser to track the user's numeric SUL/Central Auth id as a new sulid field.
• Update the Wikimedia OAuth connection process to collect the user's numeric SUL/Central Auth id.
• Figure out a process to backfill the new LabsUser sulid field for existing users with a sulname value set. (This should be possible via the stored Wikimedia OAuth credentials for these users.)
• Update striker.labsauth.models.LdapUser to include the wikimediaPerson objectClass.
  • NOTE: I can't remember if the declared object_classes are used as part of lookup queries or not. If they are, we will likely have to script a data migration to add the wikimediaPerson objectClass to all existing Developer accounts to keep everything working as expected.
• Update striker.labsauth.models.LdapUser to include the new wikimediaGlobalAccountId and wikimediaGlobalAccountName attributes.
• Update striker.labsauth.views.oauth_callback to set the wikimediaGlobalAccountId and wikimediaGlobalAccountName attributes on both the LabsUser and LdapUser models when an authenticated user is found.
• Update striker.labsauth.utils.add_ldap_user to set the wikimediaGlobalAccountId and wikimediaGlobalAccountName attributes when creating a new LdapUser.
• Figure out a process to backfill the new LdapUser wikimediaGlobalAccountId and wikimediaGlobalAccountName attributes for existing LabsUser records with sulname and sulid data.

I have local draft changes which confirm that a migration is needed to add an objectClass: wikimediaPerson attribute to each existing Developer account under the plan outlined in T148048#8802511.

Change 1009321 had a related patch set uploaded (by BryanDavis; author: Bryan Davis):

[labs/striker@master] [WIP] Store SUL information in LDAP

https://gerrit.wikimedia.org/r/1009321