We are using the username from one account and the uid from another one. This is a bit confusing. I'm not sure if its even possible/desirable to drop accounts (or we just deactivate them or whatever).

If I can only keep one, I prefer the first one
uid=phamhi,ou=people,dc=wikimedia,dc=org

• uid=hpham,ou=people,dc=wikimedia,dc=org has no Cloud VPS memberships
  • Created by the OIT group on the first day.. I think.. according to them.. it's for "your Gmail, SF Office WiFi, VPN, and Fileserver".. if this is the case is it a good idea to block it?

The rest of the plan looks good I guess.. I have no idea..haha.

In T230126#5403598, @Phamhi wrote:

• uid=hpham,ou=people,dc=wikimedia,dc=org has no Cloud VPS memberships
  • Created by the OIT group on the first day.. I think.. according to them.. it's for "your Gmail, SF Office WiFi, VPN, and Fileserver".. if this is the case is it a good idea to block it?

I think this may be a case of the confusing naming of "LDAP accounts" which was the basis for T179461: Use the term "developer account" for Wikimedia LDAP accounts.

There are two distinct and separate LDAP directories which Wikimedia Foundation staff may have accounts in. The first is the LDAP directory which is the backing data store for Developer accounts. This directory used by our Cloud VPS projects, Gerrit, Phabricator, Wikitech, and various other support tools. This LDAP directory exists inside the "production" Wikimedia Foundation network and is managed jointly by the SRE team and the Cloud Services team.

The second LDAP directory is directory.corp.wikimedia.org. This LDAP directory is the backing data store for accounts which are used by the Wikimedia Foundation's integration with Google's "G Suite" products, VPN access, shared file server, and WiFi portals at the main office. This LDAP directory exists inside the Foundation's corporate network and is managed by the Foundation's Office IT (OIT) group.

Let's dig a bit deeper though...

$ ldap '(&(objectClass=posixAccount)(mail=hpham@wikimedia.org))' creatorsName createTimestamp
dn: uid=phamhi,ou=people,dc=wikimedia,dc=org
creatorsName: uid=novaadmin,ou=people,dc=wikimedia,dc=org
createTimestamp: 20190805122447Z

dn: uid=hpham,ou=people,dc=wikimedia,dc=org
creatorsName: uid=novaadmin,ou=people,dc=wikimedia,dc=org
createTimestamp: 20190805123356Z

dn: uid=hieupham,ou=people,dc=wikimedia,dc=org
creatorsName: uid=novaadmin,ou=people,dc=wikimedia,dc=org
createTimestamp: 20190805154514Z

I can see on Wikitech that uid=phamhi,ou=people,dc=wikimedia,dc=org was created there. I can see in Striker's database that uid=hieupham,ou=people,dc=wikimedia,dc=org was created there. I can't find the creation of uid=hpham,ou=people,dc=wikimedia,dc=org in either which is confusing, especially because the 'creatorsName' attribute of the record aligns with Wikitech/Striker and to my knowledge that admin account is not used elsewhere. I will follow up with OIT to see if they did create this account somehow, but locking it should not cause any problems for your access anywhere once we take care of the steps to move your Toolforge access to uid=phamhi,ou=people,dc=wikimedia,dc=org.

In T230126#5403925, @bd808 wrote:

I can't find the creation of uid=hpham,ou=people,dc=wikimedia,dc=org in either which is confusing, especially because the 'creatorsName' attribute of the record aligns with Wikitech/Striker and to my knowledge that admin account is not used elsewhere. I will follow up with OIT to see if they did create this account somehow, but locking it should not cause any problems for your access anywhere once we take care of the steps to move your Toolforge access to uid=phamhi,ou=people,dc=wikimedia,dc=org.

I think I was typoing the account name as "HPham" rather than "Hpham". The account creation for this one was done via Wikitech too. Mystery solved. :)

Figure out what to do about modules/admin/data/data.yaml username mismatch

@MoritzMuehlenhoff what are your thoughts here? There isn't anything explicit in modules/admin/README about renaming. As far as I can tell the mechanics in the ::admin module use the Puppet user built-in to do the needful. The upstream docs indicate that the useradd provider tolerates duplicate uid values, so at least in theory we could just absent the entry with the wrong name and add the new one.

The diff for that would look like this:

diff --git i/modules/admin/data/data.yaml w/modules/admin/data/data.yaml
index 697ada3b0a..65b0761645 100644
--- i/modules/admin/data/data.yaml
+++ w/modules/admin/data/data.yaml
@@ -13,7 +13,7 @@ groups:
               yuvipanda, shrlak, madhuvishy, groovier, khorn, ironholds, katie, chedasaurus,
               cy534, pnorman, mpany, deskana, arnad, nithum, banyek, imarlier, mkroetzsch,
               mtizzoni, panisson, paolotti, ciro, dartar, melodykramer, gtirloni, tbayer, pirroh,
-              bawolff, dkg, juliaglen, cwdent, bmansurov]
+              bawolff, dkg, juliaglen, cwdent, bmansurov, hpham]
   absent_ldap:
     description: meta group for absented users which had privileged LDAP access in the past, an automatic check verifies it has been really removed from the LDAP (but removal has to be handled separatelly)
     members: [adavenport, siddharth11, albe, audiohazel, tbolliger, jmatazzoni, pbj]
@@ -33,7 +33,7 @@ groups:
               akosiaris, mark, ariel, cmjohnson, otto, robh, tstarling,
               ori, jmm, jynus, ema, elukey, gehel, volans, marostegui,
               ayounsi, herron, aborrero, bstorm, vgutierrez, jiji, cwhite,
-              crusnov, cdanis, fsero, jbond, jeh, dzahn, hpham, sukhe]
+              crusnov, cdanis, fsero, jbond, jeh, dzahn, phamhi, sukhe]
     privileges: ['ALL = (ALL) NOPASSWD: ALL']
   ops-adm-group:
     # No gid for this group on purpose, it's a system provided one
@@ -2697,10 +2697,18 @@ users:
     uid: 18194
     email: aborrero@wikimedia.org
   hpham:
-    ensure: present
+    ensure: absent
     gid: 500
     name: hpham
     realname: Hieu Pham
+    ssh_keys: []
+    uid: 21844
+    email: hpham@wikimedia.org
+  phamhi:
+    ensure: present
+    gid: 500
+    name: phamhi
+    realname: Hieu Pham
     ssh_keys:
       - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHJ+tdR854tJNFXK14dxJFrURxnEpk1rE+KkEUPeXrrZ hpham@wikimedia.org(prod)
     uid: 21844

What I don't know is what would happen with this in practice. We don't use this module in Cloud VPS projects, so I'm not sure where/how to test safely how Puppet will apply this.

The other way I can think of doing this with Puppet would be to split the patch above so that first we merge a patch to ensure=>absent hpham, run that across the fleet, and then come back with a second patch that does the ensure=>present for phamhi. That would avoid the possible mess of the ensure=>absent and ensure=>present somehow fighting each other. If it really is all driven by useradd it does seem like the combined patch should work fine though.

Our admin module is in serious need of some revamp, I don't trust it to properly handle a rename. Hence, I'd suggest you handle it in in two steps and absent hpham with a subsequent step to re-add phamhi.

Change 529353 had a related patch set uploaded (by Phamhi; owner: Hieu Pham):
[operations/puppet@production] Mark hpham as absent and added phamhi as per T230126

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

Change 529353 had a related patch set uploaded (by Phamhi; owner: Hieu Pham):
[operations/puppet@production] admin: fix and cleanup hpham/phamhi users

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

Change 529353 merged by Arturo Borrero Gonzalez:
[operations/puppet@production] admin: fix and cleanup hpham/phamhi users

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

@bd808 the admin module changes have been merged. I don't see the changes in the LDAP directory. Let me know if I should do them myself.

If the now invalid LDAP objects are expected to be kept around, I would suggest we set some fields to clearly invalid values or whatever:

homeDirectory: /dev/null
loginShell: /dev/null
sshPublicKey: notavalidaccount
mail: notvalidaccount@example.com

In T230126#5405086, @aborrero wrote:

@bd808 the admin module changes have been merged. I don't see the changes in the LDAP directory. Let me know if I should do them myself.

If the now invalid LDAP objects are expected to be kept around, I would suggest we set some fields to clearly invalid values or whatever:

homeDirectory: /dev/null
loginShell: /dev/null
sshPublicKey: notavalidaccount
mail: notvalidaccount@example.com

The LDAP accounts are locked by virtue of having an pwdPolicySubentry: cn=disabled,ou=ppolicies,dc=wikimedia,dc=org attribute applied. We do not typically scramble any data in them.

$ ldap '(&(objectClass=posixAccount)(mail=hpham@wikimedia.org))' pwdPolicySubentry
dn: uid=phamhi,ou=people,dc=wikimedia,dc=org

dn: uid=hpham,ou=people,dc=wikimedia,dc=org
pwdPolicySubentry: cn=disabled,ou=ppolicies,dc=wikimedia,dc=org

dn: uid=hieupham,ou=people,dc=wikimedia,dc=org
pwdPolicySubentry: cn=disabled,ou=ppolicies,dc=wikimedia,dc=org

ok, ACK, thanks.

Change 529398 had a related patch set uploaded (by Phamhi; owner: Hieu Pham):
[labs/private@master] admin: add phamhi public key

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

Change 529398 merged by Phamhi:
[labs/private@master] admin: add phamhi public key

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

[batch] remove patch for review tag from resolved tasks