to start with, let's see what existing (jenkins-related) users we have in LDAP right now:

[mwmaint1002:~] $ ldapsearch -x uid=jenkins* | grep uid=
# filter: uid=jenkins*
dn: uid=jenkins-bot,ou=people,dc=wikimedia,dc=org
dn: uid=jenkins-deploy,ou=people,dc=wikimedia,dc=org
dn: uid=jenkins-slave,ou=people,dc=wikimedia,dc=org
dn: uid=jenkins-17,ou=people,dc=wikimedia,dc=org
dn: uid=jenkins-mwext-sync,ou=people,dc=wikimedia,dc=org

Hey @jBond_WMF @Muehlenhoff are system (non-human) users in LDAP a problem? Also see existing users above. Is creation of LDAP users something that infra-security would do? Cheers

to start with, let's see what existing (jenkins-related) users we have in LDAP right now:

So they each have different purposes :]

Maybe we can use a name dedicated to the system such as wmf-docpub? Then if there are other use cases planned for sure jenkins-releases-api sounds good.

When Jenkins CSRF protection is enabled, anonymous calls to the API fail with 401, even if the required permissions are given to the "anonymous" user.

I don't think an anonymous user can trigger a build, can they? They need to get a token issued (via /crumbIssuer/api which gives a cookie).

Then, requests to the API with a user and token are exempt from CSRF:
https://www.jenkins.io/doc/book/security/csrf-protection/

Alternatively authenticate using username and API token. Requests authenticating with an API token are exempt from CSRF protection in Jenkins.

Anyway, you need a LDAP user in the first place :]

jenkins-17 looks like a human user totally unrelated to the software called jenkins. nevermind about that.

thanks for the extra details about the existing users, @hashar

I don't think an anonymous user can trigger a build, can they? They need to get a token issued (via /crumbIssuer/api which gives a cookie). Then, requests to the API with a user and token are exempt from CSRF:

Yes, that's the whole point of the ticket :)

@jbond @Muehlenhoff is this something you can help with? Should we ping someone else about this?

In T338950#8928186, @Dzahn wrote:

Hey @jBond_WMF @Muehlenhoff are system (non-human) users in LDAP a problem? Also see existing users above. Is creation of LDAP users something that infra-security would do? Cheers

We have a few historic edge cases like this, but there's no standard procedure. With the emerging buildout of the IDM these will become more visible so I think we need some structure. My proposal would be:

1. We should create all new system users under a new LDAP OU, my proposal would be ou=sysusers,dc=wikimedia,dc=org I can create that OU

2. I think teams can simply create the user via standard account creation (idm.wikimedia.org can be used as an early adopter). The responsibility to keep/transfer the password lies within the team (how they share the password is at their discretion, for a user in SRE that would be pwstore). Someone in SRE can then use ldapmodify to move the user under the sysusers OU. - The email address for the user should be set the team working with the system user

3. We should list such system LDAP users under https://wikitech.wikimedia.org/wiki/SRE/LDAP/Groups (this isn't a group, but that page is our canonical list):
   • Name of the "user"
   • Responsible team
   • Link to initial Phab task

There were no objections on IRC, so I went ahead and created the ou=sysusers

@jnuche: Please go ahead and create the LDAP user at https://idm.wikimedia.org/signup/ and use your team email alias as the email address (so that this get untangled from single people, otherwise this is tricky to keep track of if people leave or change teams. Gmail allows +suffixes as well, so you can e.g. use release-engineering+docpubuser@wikimedia.org as the email address. Make sure to share the password within the team as well. When the user is created, let me know and I'll move it under a different LDAP tree (so that we can differentiate it from human users).

I'll work on some docs on wikitech next.

@hashar You mentioned a few jenkins-related users, we can move them under the same scheme, best to open a Phab task and subscribe me and I'll look into it when I find the time. Functionally nothing would change, but moving them under ou=sysusers allows us to properly differentiate human users from these special cases.

The new OU is now listed at https://wikitech.wikimedia.org/wiki/SRE/LDAP#LDAP_structure

I've created a stub overview page at https://wikitech.wikimedia.org/wiki/SRE/LDAP/Sysusers , @jnuche please add the new user there when you created it.

@MoritzMuehlenhoff thanks a lot for looking into this.

I've created the user as jenkinsrelapi (dashes, underscores or capital letters were not accepted) using https://idm.wikimedia.org/signup and added it to https://wikitech.wikimedia.org/wiki/SRE/LDAP/Sysusers

Please note that after signing up the page showed me a message saying a verification link would be sent to the email account, but the release engineering email hasn't received anything yet after ~10m.

User is not showing up yet in queries:

jnuche@mwmaint1002:~$ ldapsearch -x uid=jenkinsrelapi
# extended LDIF
#
# LDAPv3
# base <dc=wikimedia,dc=org> (default) with scope subtree
# filter: uid=jenkinsrelapi
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

Maybe the failed verification process means the user wasn't actually created?

CC @SLyngshede-WMF

I see the error at least, let me just see if I made some mistake during code cleanup yesterday.

Okay, so the issue is that it's created with releng+jenkins-rel-api@lists.wikimedia.org, which I believe is the wrong address, shouldn't it be
releng+jenkins-rel-api@wikimedia.org

I don't think releng@lists.wikimedia.org exists, and in any case it's a mailinglist, not managed by the Google Workspace, so the +jenkins-rel-api isn't supported.

The +jenkins-rel-api was suggested by me, because we'll be checking for email addresses when creating new account, and only allowing one account per email address. If the releng@lists.wikimedia.org is correct, then please just skip the +jenkins-rel-api, the account will be moved to a separate OU afterwards anyway, and that will allow you to have multiple accounts under the same address.

I've deleted the failed signup, to free up the username which will otherwise be temporarily blocked. You should be able to try again with the correct email address.

But let's me know if I'm wrong about the email.

@SLyngshede-WMF you are right about the email, I had used releng@lists.wikimedia.org by mistake. Sorry about that.

Using releng+jenkins-rel-api@wikimedia.org I could complete the creation process and the user is now showing up in LDAP queries :)

I'll make sure I'm not looking for the user under ou=people since the plan is to move it to ou=sysusers.

Thank you @SLyngshede-WMF and @MoritzMuehlenhoff for helping with this!

@jnuche Thank you for helping us testing out the user creation, it nice to see it work for someone other than ourselves.

Looks like ou=sysusers,,dc=wikimedia,dc=org is a new feature and exceeds the scope of this task to create a new user. I guess other system users (like jenkins-bot for Zuul) would need to be moved there.

Jenkins will I think need adjustements to its LDAP configuration, its LDAP config at https://integration.wikimedia.org/ci/manage/configureSecurity/ has:

Which I guess will need some adjustment.

I am inclined to file another task for the migration to ou=sysusers and mark this one solved since the user got created (jenkinsrelapi shows up at https://integration.wikimedia.org/ci/user/jenkinsrelapi/ albeit with no groups but we can grant in Jenkinson a per user basis).

In T338950#8955323, @hashar wrote:

Looks like ou=sysusers,,dc=wikimedia,dc=org is a new feature and exceeds the scope of this task to create a new user. I guess other system users (like jenkins-bot for Zuul) would need to be moved there.

Yes, see my earlier comment at https://phabricator.wikimedia.org/T338950#8952221