You are browsing a read-only backup copy of Wikitech. The primary site can be found at wikitech.wikimedia.org

SRE/Clinic Duty/Access requests: Difference between revisions

From Wikitech-static
Jump to navigation Jump to search
imported>Jbond
No edit summary
imported>Jcrespo
 
(8 intermediate revisions by 5 users not shown)
Line 1: Line 1:
==LDAP group changes==
==LDAP access==
Access to a range of mostly web-based services is granted via the "wmf" and "nda" groups. The specific permissions are listed here: https://wikitech.wikimedia.org/wiki/LDAP_Groups The change should be tracked in a ticket.
Access to a range of mostly web-based services is granted via the "wmf" and "nda" groups. The specific permissions are listed here: https://wikitech.wikimedia.org/wiki/LDAP_Groups The change should be tracked in a ticket.
=== WMF Group ===
=== WMF group ===
*WMF staff can be added to the "wmf" group on request (not everyone needs that kind of access)
WMF staff and contractors with a wikimedia.org email address can be added to the "wmf" group on request (not everyone needs this access).
**to confirm a staff member use [[Ldapsearch]] to check they have been created on the OIT ldap mirror (i.e. ldap-corp1001.wikimedia.org).
 
**alternatively, you can search on Namely (note some contractors will only appear in ldap corp i.e. they will have a wikimedia.org email address but wont be in namely)
When doing this, make sure to:
**contractors with a wikimedia.org address are also placed in the WMF group
*check that the developer account belongs to a real staff member by following the instructions in [[SRE/Clinic Duty/Access requests#Verifying%20WMF%20developer%20accounts|#Verifying WMF developer accounts]].
*also add the user to the [[phab:tag/wmf-nda/|wmf-nda Phabricator group]] (click "members"->"add members", see [[phab:T290605|T290605]] for background on this).
 
=== NDA Group ===
=== NDA Group ===
*For contractors that do not exists in LDAP (i.e. they do not have a wikimedia.org email address), ask for the person's manager/point of contact for approval, on the phabricator task
*For contractors that do not exists in LDAP (i.e. they do not have a wikimedia.org email address), ask for the person's manager/point of contact for approval, on the phabricator task
*Volunteers and researchers can be added to the "nda" group, assuming they have signed an NDA which can be confirmed by adding @KFrancis to the Phab task.
*Volunteers and researchers can be added to the "nda" group, assuming they have signed an NDA which can be confirmed by adding @KFrancis to the Phab task.
===Analytics Groups===
*There are multiple potential groups.  They have been detailed on [[Analytics/Data_access#Access_Groups]].
**The clinic duty person can often link to this page for the person requesting access, and require the requestor to define which of the groups are required.
**The clinic duty person should also highlight [[Analytics/Data access#User responsibilities]] to the requestor.
*Make sure to seek signoff from Analytics folks on access tasks
==== analytics-privatedata-users ====
The '''analytics-privatedata-users''' Unix group is one of the more confusing groups as it can be configured in three different ways.  Either: no ssh (no shell) and no Kerberos; no Kerberos (standard admin.yaml) or as a shell account with Kerberos.  In all cases the user should be configured under the user section of admin.yaml not the ldap_only_user section.  Please see The [[Analytics/Data access|analytics specific page]] for more details
=== Other groups ===
=== Other groups ===
*All other groups need to be approved by the user's manager
*All other groups need to be approved by the user's manager
Line 17: Line 27:
**NB that in the case of a Toolforge-only account, Wikitech will have no knowledge of the user account, despite it existing in LDAP, and the account being valid for logging into other things.  This is [[phab:T250189#6086726|expected but not widely understood]]
**NB that in the case of a Toolforge-only account, Wikitech will have no knowledge of the user account, despite it existing in LDAP, and the account being valid for logging into other things.  This is [[phab:T250189#6086726|expected but not widely understood]]
In either case you will need to know the username (for Wikitech) or shell account name (for Toolforge) name used. You can also search ldap to try and find it: <code>mwmaint1002$ ldapsearch -x mail=user@example.org</code>
In either case you will need to know the username (for Wikitech) or shell account name (for Toolforge) name used. You can also search ldap to try and find it: <code>mwmaint1002$ ldapsearch -x mail=user@example.org</code>
If the user claims to be a Wikimedia Foundation staff member or contractor, you should verify that by following the instructions in [[SRE/Clinic Duty/Access requests#Verifying%20WMF%20developer%20accounts|#Verifying WMF developer accounts]].
====Update data.yaml====
====Update data.yaml====
Check whether there's an existing entry in {{Gitweb|project=operations/puppet|file=modules/admin/data/data.yaml}}:
Check whether there's an existing entry in {{Gitweb|project=operations/puppet|file=modules/admin/data/data.yaml}}:
Line 37: Line 49:
After having added the user to data.yaml, the change in LDAP can be done from one of the "mediawiki maintenance" hosts like mwmaint1002 (this will be automated in a subsequent step):
After having added the user to data.yaml, the change in LDAP can be done from one of the "mediawiki maintenance" hosts like mwmaint1002 (this will be automated in a subsequent step):
*Check if they are a member of the group from the Cloud VPS LDAP server: <code>ldapsearch -x cn=grpname</code>
*Check if they are a member of the group from the Cloud VPS LDAP server: <code>ldapsearch -x cn=grpname</code>
*Add them if they are not there: <code>modify-ldap-group grpname</code> and add their entry in the editor window that pops up
*Add them if they are not there: <code>sudo modify-ldap-group grpname</code> and add their entry in the editor window that pops up
*To remove someone from an ldap group you can <code>modify-ldap-group grpname</code> and delete their entry in the editor window that pops up
*To remove someone from an ldap group you can <code>sudo modify-ldap-group grpname</code> and delete their entry in the editor window that pops up
''TIP: If a user has to be removed from special LDAP access, in most cases (e.g. contract termination) you may want to notify also @aklapper to remove/check Phabricator access on the same ticket.''
''TIP: If a user has to be removed from special LDAP access, in most cases (e.g. contract termination) you may want to notify also @aklapper to remove/check Phabricator access on the same ticket.''
*When adding a user to the wmf LDAP group, please also add them to the [https://phabricator.wikimedia.org/tag/wmf-nda/ Phabricator group wmf-nda] ((click "members"->"add members", see [https://phabricator.wikimedia.org/T290605 T290605] for background on this).
For further instructions see [[Help:Access]], [[LDAP]] and [[LDAP Groups]].


For further instructions see [[Help:Access]], [[LDAP]] and [[LDAP Groups]].
====wmde access====
====wmde access====
Anyone at Wikimedia Deutschland who wants to get added to the "wmde" LDAP group needs to sign an NDA with the Legal department of the WMF. Simply add [[phab:p/KFrancis|@KFrancis]] to the Phab task and she'll deal with it.
Anyone at Wikimedia Deutschland who wants to get added to the "wmde" LDAP group needs to sign an NDA with the Legal department of the WMF. Simply add [[phab:p/KFrancis|@KFrancis]] to the Phab task and she'll deal with it.


In addition, the access to "wmde" needs to be approved by an engineering manager from Wikimedia Deutschland. You can add either of the four to the Phab task:
In addition, the access to "wmde" needs to be approved by an engineering manager from Wikimedia Deutschland. You can add either of the six to the Phab task:
*[[phab:p/conny-kawohl_WMDE|@conny-kawohl_WMDE]]
*[[phab:p/conny-kawohl_WMDE|@conny-kawohl_WMDE]]
*[[phab:p/WMDE-leszek|@WMDE-leszek]]
*[[phab:p/WMDE-leszek|@WMDE-leszek]]
Line 53: Line 66:
*[[phab:p/karapayneWMDE|@karapayneWMDE]]
*[[phab:p/karapayneWMDE|@karapayneWMDE]]


==Access requests==
==Production shell access==
Access and reasoning for requesting it are documented on [[Requesting shell access]].  Please read and understand entirely before processing any access requests, as this very brief summary documentation may not cover all required points in the linked page.
Access and reasoning for requesting it are documented on [[Requesting shell access]].  Please read and understand entirely before processing any access requests, as this very brief summary documentation may not cover all required points in the linked page.


Line 78: Line 91:
*Please update the Task in phabricator, as the requestor will get update.
*Please update the Task in phabricator, as the requestor will get update.
*Please raise any security concerns on ticket via comments.
*Please raise any security concerns on ticket via comments.
====Analytics Groups====
*There are multiple potential groups.  They have been detailed on [[Analytics/Data_access#Access_Groups]].
**The clinic duty person can often link to this page for the person requesting access, and require the requestor to define which of the groups are required.
**The clinic duty person should also highlight [[Analytics/Data access#User responsibilities]] to the requestor.
*Make sure to seek signoff from Analytics folks on access tasks
====Deployment Groups====
====Deployment Groups====
*Requires Shell and must have approval from releng to be added to the deployment group
*Requires Shell and must have approval from releng to be added to the deployment group
**The user should also be added to the Gerrit group [[gerrit:#/admin/groups/21,members|wmf-deployment]].
**The user should also be added to the Gerrit group [[gerrit:#/admin/groups/21,members|wmf-deployment]].
====Creating new shell users====
====Creating new shell users====
Please see instructions in the puppet admin module's [https://github.com/wikimedia/puppet/blob/production/modules/admin/README#L46 README].
Please see instructions in the puppet admin module's [https://github.com/wikimedia/puppet/blob/production/modules/admin/README.md README].


Some notable changes since February 2017:
Some notable changes since February 2017:
Line 120: Line 128:
====Check on a Phabricator user====
====Check on a Phabricator user====
As part of an access request you might want to check first if a Phabricator user is actually who they say they are. There is a shell command on the the Phabricator server. see [[Phabricator#Check_on_a_Phabricator_user]]
As part of an access request you might want to check first if a Phabricator user is actually who they say they are. There is a shell command on the the Phabricator server. see [[Phabricator#Check_on_a_Phabricator_user]]
== Google & Bing search console access ==
Access to Google Search Console and Bing Webmaster tools is '''no longer owned by SREs'''. '''Core Experiences owns it''', approving and deploying the access. Normally, they will be able to self serve and no work from us SREs will be needed. However, we still have a small role overseeing and assisting on those requests, upon their request:
* SREs still keep an admin password in pwstore in case the current administrator in unavailable or his account gets disabled
* SREs manage the external service authentication through DNS keys (in case new services or domains have to be added. [https://gerrit.wikimedia.org/g/operations/dns/+/bcd9657e5970d1bb0cd7683b8d0d89ab1d62cc49 e.g.]).
* SREs can help verify employees' Phabricator identity in the same way regular access requests are (with <code>check_user</code>).
:''The process is fully documented at: [[Search_Console_Data#Notes_for_Console_administrators]].''
:''The Phabricator tag used for this access requests is: [[phab:/tag/search-console-access-request/|#search-console-access-request]]''
[[phab:p/SCherukuwada/|@SCherukuwada]] is the person to contact, or that will contact us if help is needed regarding Console admin access.
== Verifying WMF developer accounts ==
Both LDAP and shell access is tied to a user's [[Help:Create a Wikimedia developer account|developer account]], so a key task is verifying that a developer account actually belongs to the claimed person.
To do this, use the <code>check_user</code> script on the [[cumin]] hosts, which returns any developer accounts and Wikimedia Foundation GSuite accounts matching the provided email. Here's an example:<syntaxhighlight lang="console">
$ sudo check_user jbond@wikimedia.org                                                     
WikiTech Users:
        Username:      Jbond42
        Verified Email: 20190107105404
        Username:      Jbond
        Verified Email: 20190110142649
Gsuit User:
        name:          jbond@wikimedia.org
        title:          Senior Site Reliability Engineer
        manager:        fliambotis@wikimedia.org
        agreedToTerms:  True
</syntaxhighlight>The output above shows that jbond@wikimedia.org is a valid GSuite account and has been verified as the owner of the developer accounts Jbond42 and Jbond. It also shows that Faidon (fliambotis@wikimedia.org) can be contacted for managerial approval. In this case, the manger field is out of date and Faidon is no longer the user's manger, but is still a good starting point if no other information is available.
=== Background ===
When a user signs up for a Wikitech account and provides an email address, a developer LDAP account is immediately created with that address attached, without waiting for the user the verify the address. So it is not sufficient to check the address in LDAP; we need to check that the email address has actuallybeen verified on Wikitech. The script does this by checking Wikitech's <code>user</code> database.
Note that is possible that a developer account exists without a corresponding Wikitech account, if the user signed up for the account using the Toolforge admin console and has not logged into Wikitech.
As of November 2021, there is no single source of truth which includes up-to-date details on all Wikimedia Foundation staff and contractors. However, querying GSuite allows us to at least verify that an email belongs to a real user and learn the user's manager ''when they first joined the organization''.

Latest revision as of 13:56, 28 April 2022

LDAP access

Access to a range of mostly web-based services is granted via the "wmf" and "nda" groups. The specific permissions are listed here: https://wikitech.wikimedia.org/wiki/LDAP_Groups The change should be tracked in a ticket.

WMF group

WMF staff and contractors with a wikimedia.org email address can be added to the "wmf" group on request (not everyone needs this access).

When doing this, make sure to:

NDA Group

  • For contractors that do not exists in LDAP (i.e. they do not have a wikimedia.org email address), ask for the person's manager/point of contact for approval, on the phabricator task
  • Volunteers and researchers can be added to the "nda" group, assuming they have signed an NDA which can be confirmed by adding @KFrancis to the Phab task.

Analytics Groups

  • There are multiple potential groups. They have been detailed on Analytics/Data_access#Access_Groups.
    • The clinic duty person can often link to this page for the person requesting access, and require the requestor to define which of the groups are required.
    • The clinic duty person should also highlight Analytics/Data access#User responsibilities to the requestor.
  • Make sure to seek signoff from Analytics folks on access tasks

analytics-privatedata-users

The analytics-privatedata-users Unix group is one of the more confusing groups as it can be configured in three different ways. Either: no ssh (no shell) and no Kerberos; no Kerberos (standard admin.yaml) or as a shell account with Kerberos. In all cases the user should be configured under the user section of admin.yaml not the ldap_only_user section. Please see The analytics specific page for more details

Other groups

  • All other groups need to be approved by the user's manager

Create/Get LDAP account

In order to add or update a a user's LDAP permissions, they will first need an LDAP account. This can be created by either:

  • having the user create a Wikitech account
  • if the user already has a meta account, using it to create a Toolforge account
    • NB that in the case of a Toolforge-only account, Wikitech will have no knowledge of the user account, despite it existing in LDAP, and the account being valid for logging into other things. This is expected but not widely understood

In either case you will need to know the username (for Wikitech) or shell account name (for Toolforge) name used. You can also search ldap to try and find it: mwmaint1002$ ldapsearch -x mail=user@example.org

If the user claims to be a Wikimedia Foundation staff member or contractor, you should verify that by following the instructions in #Verifying WMF developer accounts.

Update data.yaml

Check whether there's an existing entry in modules/admin/data/data.yaml:

  • If the user already has shell access, no further change is needed. You can proceed with the LDAP change below:
  • If not, add the user to the ldap_only_users table at the end of the file, using their would-be shell username (LDAP uid=) as the key within ldap_only_users. (This is just added for tracking/verification purposes. As you'll be making the LDAP changes yourself, no puppet run is required after this.)
    • Add the realname of the user (most Cloud VPS accounts don't have a real name set)
    • Add the email address of the users:
      • If the user is WMF staff, use the email address of their Google account (You can double-check the account name in the Gmail interface). Some users have aliases for their nickname; don't use these, use the official Google account (this allows cross-checking data against corp LDAP)
      • If the user is not staff, ask for a contact email address (to have a reliable contact e.g. in case of an account compromise)
    • If the user is someone with a time-limited access e.g. interns, researchers who have time-limited MOUs or short term contractor, add the estimated account end date as expiry_date (format is YYYY-MM-DD) and a staff contact as expiry_contact

The entry should look something like the following:

exampleuser:
  ensure: present
  realname: Example User
  email: exampleuser@example.org
  expiry_date: 2038-01-19 
  expiry_contact: examplestaff@wikimedia.org

Modify LDAP groups

After having added the user to data.yaml, the change in LDAP can be done from one of the "mediawiki maintenance" hosts like mwmaint1002 (this will be automated in a subsequent step):

  • Check if they are a member of the group from the Cloud VPS LDAP server: ldapsearch -x cn=grpname
  • Add them if they are not there: sudo modify-ldap-group grpname and add their entry in the editor window that pops up
  • To remove someone from an ldap group you can sudo modify-ldap-group grpname and delete their entry in the editor window that pops up

TIP: If a user has to be removed from special LDAP access, in most cases (e.g. contract termination) you may want to notify also @aklapper to remove/check Phabricator access on the same ticket.

  • When adding a user to the wmf LDAP group, please also add them to the Phabricator group wmf-nda ((click "members"->"add members", see T290605 for background on this).

For further instructions see Help:Access, LDAP and LDAP Groups.

wmde access

Anyone at Wikimedia Deutschland who wants to get added to the "wmde" LDAP group needs to sign an NDA with the Legal department of the WMF. Simply add @KFrancis to the Phab task and she'll deal with it.

In addition, the access to "wmde" needs to be approved by an engineering manager from Wikimedia Deutschland. You can add either of the six to the Phab task:

Production shell access

Access and reasoning for requesting it are documented on Requesting shell access. Please read and understand entirely before processing any access requests, as this very brief summary documentation may not cover all required points in the linked page.

If a request asks for things like new shell accounts, access to additional servers, log files, personal data, admin roles in systems like Mailman, Bugzilla, data center access, opening a firewall rule etc, then it is an access request and should be moved into the SRE-Access-Requests Project. Once the initial request is made, a number of follow up steps must be confirmed. Here is a checklist that can be pasted into the Phab task:

 [] - User has signed the L3 Acknowledgement of Wikimedia Server Access Responsibilities Document.
 [] - User has a valid NDA on file with WMF legal.  (This can be checked by SRE via the NDA tracking sheet & is included in all WMF Staff/Contractor hiring.)
 [] - User has provided the following: wikitech username, preferred shell username, email address, and full reasoning for access (including what commands and/or tasks they expect to perform.
 [] - User has provided a public SSH key.  This ssh key pair should only be used for WMF cluster access, and not share with any other service (this includes not sharing with WMCS access, no shared keys.)
 [] - Access request (or expansion) has sign off of WMF sponsor/manager (sponsor for volunteers, manager for WMF/WMDE staff). If the permissions also give access to restricted data then the data owner must also approve the request.
 [] - Patchset for access request

More details on the above.

  • User's direct supervisor has approved of access request via comment on phabricator task.
  • Approval from project lead where user's access will be granted via comment on phabricator task.
  • Confirmation that the user has read, comprehend, and signed the Acknowledgement of Wikimedia Server Access Responsibilities document.
  • ALL ACCESS REQUESTS REQUIRE AN NDA.
    • Anyone who's Wikimedia staff has signed an NDA as part of their work contract. To validate that someone is staff you can either (1) check ldap-corp1001 via an LDAP search for the GCorp username (2) have the person's manager confirm (they need to sign off anyway)
    • Volunteers and researchers need to sign an NDA with the legal department. You can check existing NDAs on file at https://docs.google.com/spreadsheets/d/1xQNx5s2yErvayCMzvk9VkIA2ZihFXSBEhT5Z5ziCsi4
    • If that's not the case, add @KFrancis to the Phabricator task to prepare an NDA (she'll confirm on task when that's completed)
  • SSH public key has to be submitted via gerrit patchset by user, or by some confirmed (non-email) method (suggestion: wiki user page).
    • You can verify that the SSH key is not used in WMCS by running from the current MediaWiki maintenance host (mwmaint1002 as of March 2021) the cross-validate-accounts command, for example like:
      cross-validate-accounts --username USRNAME --uid 00000 --email address@example.com --real-name "Real User" --ssh-key "ssh-ed25519 AAAAC...." --kerberos
      
  • Any requests to add sudo rights to a group should be reviewed at the Infrastructure Foundations SRE meeting. Tag the task with #Infrastructure-Foundations and assign it to @joanna_borun to add it to the next meeting's agenda; don't grant access until it's discussed at the meeting. Skip this step for requests to add a user to an existing group (the most common kind of production access request).
  • Please update the Task in phabricator, as the requestor will get update.
  • Please raise any security concerns on ticket via comments.

Deployment Groups

  • Requires Shell and must have approval from releng to be added to the deployment group

Creating new shell users

Please see instructions in the puppet admin module's README.

Some notable changes since February 2017:

  • Add the realname of the user (most Cloud VPS accounts don't have a real name set)
  • Add the email address of the users:
    • If the user is WMF staff use the email address of their Google account (usually the first letter of the first name and the surname, you can double-check the account name in the Gmail interface). Some users have aliases for their nickname e.g., don't use these, use the official Google account (this allows cross-checking data against corp LDAP)
    • If the user is a volunteer, a researcher or contractor without access to a wikimedia.org account, ask for a contact email address (to have a reliable contact e.g. in case of an account compromise)
  • If the user to be added is someone with a time-limited access (e.g. interns, researchers (who have time-limited MOUs) or short term contractor), add the estimated account end date as expiry_date (format is YYYY-MM-DD) and add a staff contact as expiry_contact

Renaming shell users

Sometimes we have to rename a shell user. This is typically when their shell name doesn't match their login name, and they have issues logging into items requiring LDAP credentials.

Renaming a user will require a few things happen, in a very specific order. Since many users keep data in their home directories, backups can sometimes be made, but not always. (Private data that isn't allowed to be copied off the cluster should not be backed up to laptops.) The existing username has to be removed from the host, since the new username will use the old username's UID.

  • Patchset is prepared, but not merged.
  • Using cumin for these batch commands, all hosts that have the existing (to be replaced) username should have puppet halted.
  • Affected hosts should have the user (to be replaced) deleted. DO NOT DELETE THE USER'S HOME DIRECTORY.
  • Merge patchset with username change (UID remains the same).
  • Run puppet on affected hosts, and they will create the new user (using the same UID.)
  • Batch move the contents of the old user home into the new user home.

IRC channel access

/query chanserv
help access
access #channel list
access #channel add *!*@wikimedia/cloak 
14:07 -ChanServ(ChanServ@services.)- Flags +Aiortv were set on ...

For people wanting to be a channel operator for #wikimedia-operations, first check they got nick protection enabled

  /msg nickserv info <nick>
  ...
  <nick> has enabled nick protection

and then

  /msg chanserv flags #wikimedia-operations <nick> +Aiotv

Check on a Phabricator user

As part of an access request you might want to check first if a Phabricator user is actually who they say they are. There is a shell command on the the Phabricator server. see Phabricator#Check_on_a_Phabricator_user

Google & Bing search console access

Access to Google Search Console and Bing Webmaster tools is no longer owned by SREs. Core Experiences owns it, approving and deploying the access. Normally, they will be able to self serve and no work from us SREs will be needed. However, we still have a small role overseeing and assisting on those requests, upon their request:

  • SREs still keep an admin password in pwstore in case the current administrator in unavailable or his account gets disabled
  • SREs manage the external service authentication through DNS keys (in case new services or domains have to be added. e.g.).
  • SREs can help verify employees' Phabricator identity in the same way regular access requests are (with check_user).
The process is fully documented at: Search_Console_Data#Notes_for_Console_administrators.
The Phabricator tag used for this access requests is: #search-console-access-request

@SCherukuwada is the person to contact, or that will contact us if help is needed regarding Console admin access.

Verifying WMF developer accounts

Both LDAP and shell access is tied to a user's developer account, so a key task is verifying that a developer account actually belongs to the claimed person.

To do this, use the check_user script on the cumin hosts, which returns any developer accounts and Wikimedia Foundation GSuite accounts matching the provided email. Here's an example:

$ sudo check_user jbond@wikimedia.org                                                       
WikiTech Users:
        Username:       Jbond42
        Verified Email: 20190107105404
        Username:       Jbond
        Verified Email: 20190110142649

Gsuit User:
        name:           jbond@wikimedia.org
        title:          Senior Site Reliability Engineer
        manager:        fliambotis@wikimedia.org
        agreedToTerms:  True

The output above shows that jbond@wikimedia.org is a valid GSuite account and has been verified as the owner of the developer accounts Jbond42 and Jbond. It also shows that Faidon (fliambotis@wikimedia.org) can be contacted for managerial approval. In this case, the manger field is out of date and Faidon is no longer the user's manger, but is still a good starting point if no other information is available.

Background

When a user signs up for a Wikitech account and provides an email address, a developer LDAP account is immediately created with that address attached, without waiting for the user the verify the address. So it is not sufficient to check the address in LDAP; we need to check that the email address has actuallybeen verified on Wikitech. The script does this by checking Wikitech's user database.

Note that is possible that a developer account exists without a corresponding Wikitech account, if the user signed up for the account using the Toolforge admin console and has not logged into Wikitech.

As of November 2021, there is no single source of truth which includes up-to-date details on all Wikimedia Foundation staff and contractors. However, querying GSuite allows us to at least verify that an email belongs to a real user and learn the user's manager when they first joined the organization.