Page MenuHomePhabricator

LDAP: multiples accounts for Phamhi
Closed, ResolvedPublic

Description

It seems we have 3 accounts for @Phamhi on LDAP:

# phamhi, people, wikimedia.org
dn: uid=phamhi,ou=people,dc=wikimedia,dc=org
uid: phamhi
sn: Phamhi
cn: Phamhi
objectClass: inetOrgPerson
objectClass: person
objectClass: ldapPublicKey
objectClass: posixAccount
objectClass: shadowAccount
uidNumber: 21844
gidNumber: 500
homeDirectory: /home/phamhi
loginShell: /bin/bash
sshPublicKey: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDk4D6nPW8HE0scTBsFGOQdvf40
 1b9XzsF/IbKWWUU8pgPkl6a1PdmdgpiSiGdgOno4GMmwWUVMmvCgPgxN0IY2mB9Nii55vTCq2peNA
 CpqE3/GWGzT17x3GfKUqwao0ZGymsMAuubYn1JjN+oCE0tM+3aWhA1RHlw6L5MWJ+fVv5xTk35Dkm
 QTt5VgQv7Ti1pd3vsl5Xm2HhH3wy9sqi47hKmwWJx/VOCVhIBh9glu7zMkB5sBWIQrTEU5vglq0ng
 8kbrC2QlqnAHBBJKtYWuNsIympeGD2UMDRSnUwePJeI5BRvb2vsneNY+ttLWkvvmlxtjLEv+z7UJV
 Ky/HcJrX hpham@wikimedia.org
mail: hpham@wikimedia.org

# hpham, people, wikimedia.org
dn: uid=hpham,ou=people,dc=wikimedia,dc=org
uid: hpham
sn: Hpham
cn: Hpham
objectClass: inetOrgPerson
objectClass: person
objectClass: ldapPublicKey
objectClass: posixAccount
objectClass: shadowAccount
uidNumber: 21845
gidNumber: 500
homeDirectory: /home/hpham
loginShell: /bin/bash
mail: hpham@wikimedia.org

# hieupham, people, wikimedia.org
dn: uid=hieupham,ou=people,dc=wikimedia,dc=org
objectClass: person
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: ldapPublicKey
objectClass: posixAccount
objectClass: shadowAccount
cn: Hieupham
gidNumber: 500
homeDirectory: /home/hieupham
loginShell: /bin/bash
mail: hpham@wikimedia.org
sn: Hieupham
uidNumber: 21847
uid: hieupham
sshPublicKey: ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOCSlNOQXEH27IoEPV8WprlO9WFI
 fQ3gts8mTMqOSFfF hpham@wikimedia.org

In operations/puppet.git we are using:

hpham:                                                                        
  ensure: present                                                             
  gid: 500                                                                    
  name: hpham                                                                 
  realname: Hieu Pham                                                         
  ssh_keys:                                                                   
    - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHJ+tdR854tJNFXK14dxJFrURxnEpk1rE+KkEUPeXrrZ hpham@wikimedia.org(prod)
  uid: 21844                                                                  
  email: hpham@wikimedia.org

Cleanup

  • Block uid=hpham,ou=people,dc=wikimedia,dc=org on Wikitech (which will cascade disable the account in Cloud VPS, Gerrit, etc)
  • Disassociate @Phamhi and HPham (WMF) from uid=hieupham,ou=people,dc=wikimedia,dc=org in Striker
  • Block uid=hieupham,ou=people,dc=wikimedia,dc=org on Wikitech
  • Associate @Phamhi and HPham (WMF) with uid=phamhi,ou=people,dc=wikimedia,dc=org in Striker
  • Figure out what to do about modules/admin/data/data.yaml username mismatch

Event Timeline

aborrero renamed this task from LDAP account: multiples account for Phamhi to LDAP: multiples accounts for Phamhi.Aug 8 2019, 12:20 PM
aborrero created this task.

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).

aborrero triaged this task as High priority.Aug 8 2019, 12:26 PM
aborrero moved this task from Inbox to Important on the cloud-services-team (Kanban) board.
aborrero added projects: LDAP, Operations.
Phamhi added a comment.EditedAug 8 2019, 4:02 PM

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

bd808 claimed this task.Aug 8 2019, 6:30 PM
  • uid=phamhi,ou=people,dc=wikimedia,dc=org is preferred per T230126#5402992
    • This is the Developer account connected to @Phamhi here on Phabricator
    • This is the source of the uidNumber used in modules/admin/data/data.yaml
    • This is a member of Toolforge (can't find toolsadmin request to go with this...)
  • uid=hpham,ou=people,dc=wikimedia,dc=org has no Cloud VPS memberships
  • uid=hieupham,ou=people,dc=wikimedia,dc=org is a member of Toolforge, but no tools

Proposed cleanup:

  • Block uid=hpham,ou=people,dc=wikimedia,dc=org on Wikitech (which will cascade disable the account in Cloud VPS, Gerrit, etc)
  • Disassociate @Phamhi and HPham (WMF) from uid=hieupham,ou=people,dc=wikimedia,dc=org in Striker
  • Associate @Phamhi and HPham (WMF) with uid=phamhi,ou=people,dc=wikimedia,dc=org in Striker
  • Block uid=hieupham,ou=people,dc=wikimedia,dc=org on Wikitech

Those steps will get Hieu down to one active Developer account that is linked to his Foundation work accounts.

I am not sure yet about changing Hieu's shell name in modules/admin/data/data.yaml. I need to look at code/talk to someone about how that might work in practice. The uidNumber used in prod (21844) is the one from uid=phamhi,ou=people,dc=wikimedia,dc=org so the change if it is made would only be the cosmetic renaming from 'hpham' to 'phamhi' in the /etc/password files that Puppet generates. I would need to hand off to a full root to make those changes as I do not have the rights to do more than propose gerrit patches anyway.

Phamhi added a comment.Aug 8 2019, 6:54 PM
  • 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.

bd808 added a comment.Aug 8 2019, 9:01 PM
  • 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.

bd808 updated the task description. (Show Details)Aug 8 2019, 9:48 PM
bd808 updated the task description. (Show Details)Aug 8 2019, 9:53 PM

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. :)

bd808 updated the task description. (Show Details)
bd808 added a comment.Aug 8 2019, 10:10 PM
$ openstack role assignment list --names --user hieupham
+------+------------------+-------+---------------+--------+-----------+
| Role | User             | Group | Project       | Domain | Inherited |
+------+------------------+-------+---------------+--------+-----------+
| user | Hieupham@Default |       | tools@Default |        | False     |
+------+------------------+-------+---------------+--------+-----------+
$ openstack role remove --user hieupham --project tools user
$ openstack role assignment list --names --user hieupham
bd808 added a comment.Aug 8 2019, 10:43 PM

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
bd808 added a comment.Aug 9 2019, 3:36 PM

@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
aborrero updated the task description. (Show Details)Aug 9 2019, 4:20 PM

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

bd808 closed this task as Resolved.Aug 9 2019, 9:45 PM

I think this is all fixed up now. Please reopen with comments if I am mistaken.