improve user onboard/offboarding procedures

Trac:
Child Ticket(s): #32332 (moved), #32558 (moved)

added component::internal services/tor sysadmin team owner::tpa priority::medium severity::normal status::new type::defect labels

mention the new person page as well

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and https://help.torproject.org/tsa/howto/retire-a-user retire-a-user], the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Trac:
Cc: N/A to gaba

create #32558 (moved) to followup on the email problem, and expand on that.

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and https://help.torproject.org/tsa/howto/retire-a-user retire-a-user], the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

"the blog" is another service with its own accounts

and another is the @tor-tpomember irc group.

i started working on a fabric script to audit LDAP. i needed to implement something to talk with LDAP anyways so it made sense to start there.

this, for example, will check the EXAMPLE user:

fab  -H db.torproject.org user.audit-ldap --user=EXAMPLE

a real-world example:

$ fab  -H db.torproject.org user.audit-ldap --user=anarcat
ldaps://db.torproject.org LDAP password for uid=anarcat,ou=users,dc=torproject,dc=org: 
uid	flags	groups
anarcat	ldap-admin,login-everywhere	adm,torproject
WARNING:root:ldap-admin: has root and LDAP admin (adm group)
WARNING:root:login-everywhere: has SSH access everywhere (torproject group)

Those two WARNING lines are "flags" that are hardcoded in the code, which currently warns about about certain special groups or abnormal conditions. the idea is to have various audit tools that would raise certain "flags" like this. those, in turn, could become "actions" (like remove someone from a group or reset a password), specific to those flags.

rt.torproject.org is one of those services that has been suffering from neglect in this process as well.

regroup the list of services in the description explicitely.

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

rt.torproject.org
blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

rt.torproject.org
blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

rt.torproject.org, see #34036 (moved) for an example audit
blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

rt.torproject.org, see #34036 (moved) for an example audit
blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
Nextcloud (#32332 (moved))
rt.torproject.org, see #34036 (moved) for an example audit

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

Please, add blog account policy - https://trac.torproject.org/projects/tor/ticket/33109

Replying to ggus:

Please, add blog account policy - https://trac.torproject.org/projects/tor/ticket/33109

added to summary, thanks!

Trac:
Description: while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

blog.torproject.org
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
Nextcloud (#32332 (moved))
rt.torproject.org, see #34036 (moved) for an example audit

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

to

while working on the nextcloud project, we realized it wasn't exactly trivial to setup the LDAP bridge because of our specific requirements (no direct connexion, offline support). so we just didn't implement it yet (#32332 (moved)). i added a note about this in the retire a user procedure, but then i realized there are probably many other such services that do not connect with LDAP.

On the top of my head, there's at least Trac and mailing lists, for example, which are managed completely separarely. Audit [[org/operations/services]] and see which services are manager manually and which aren't. Those services have been identified as particularly out of sync:

blog.torproject.org, see also #33109 (moved)
email, see also #32558 (moved)
IRC, the @tor-tpomember group
Nagios contacts (almost cleaned up, but will still need checking for sysadmins arriving/departing)
Nextcloud (#32332 (moved))
rt.torproject.org, see #34036 (moved) for an example audit

That list is not exhaustive.

Then make sure there's an automated way to add/remove users to services, either by hooking up the service with LDAP, or by creating a wrapper script that will manage those accesses.

So the following needs to be done here:

document, in new-person and retire-a-user, the various services to add/remove people to
automate the above with a script or LDAP

Note that the two pages have different scope: new-person is about TSA while retire-a-user is broader. This should also be converged, probably in the broader sense.

Also note that a particularly tricky situation is when we want to do a partial removal. For example, maybe the person needs to be removed from tor-internal, but keep access to some servers. Or removed from server, but keep an email alias.

The latter case is especially sensitive: some people feel keeping their email alias around forever is an inalienable right and that we should keep forwarding their email even after they are fully retired from Tor. This policy needs to be clarified, see #32558 (moved) for that particularly tricky problem.

mentioned in issue #32558 (moved)

mentioned in issue #34036 (moved)

mentioned in issue #32332 (moved)

mentioned in issue tpo/tpa/team#32558

improve user onboard/offboarding procedures

Child items ...

Activity