Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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
>  * IRC, the @tor-tpomember group
>  * Nagios contacts (almost cleaned up, but will still need checking for
> sysadmins arriving/departing)
>  * Nextcloud (#32332)
>  * rt.torproject.org, see #34036 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 [https://help.torproject.org/tsa/howto/new-person/
> 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.
>
> 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 for that particularly
> tricky problem.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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
  * email, see also #32558
  * IRC, the @tor-tpomember group
  * Nagios contacts (almost cleaned up, but will still need checking for
 sysadmins arriving/departing)
  * Nextcloud (#32332)
  * rt.torproject.org, see #34036 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

 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 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by ggus):

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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 for an example audit
>  * blog.torproject.org
>  * email, see also #32558
>  * 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 [https://help.torproject.org/tsa/howto/new-person/
> 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.
>
> 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 for that particularly
> tricky problem.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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
  * IRC, the @tor-tpomember group
  * Nagios contacts (almost cleaned up, but will still need checking for
 sysadmins arriving/departing)
  * Nextcloud (#32332)
  * rt.torproject.org, see #34036 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

 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 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Description changed by anarcat:

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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
>  * 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 [https://help.torproject.org/tsa/howto/new-person/
> 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.
>
> 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 for that particularly
> tricky problem.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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 for an example audit
  * blog.torproject.org
  * email, see also #32558
  * 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

 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 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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 [https://help.torproject.org/tsa/howto/new-person/
> 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.
>
> 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 for that particularly
> tricky problem.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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
  * 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

 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 for that particularly tricky
 problem.

--

Comment (by anarcat):

 regroup the list of services in the description explicitely.

--
Ticket URL: 

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by anarcat):

 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 and another is the @tor-tpomember irc group.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Comment (by arma):

 "the blog" is another service with its own accounts

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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 [https://help.torproject.org/tsa/howto/new-person/
> 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.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

 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 for that particularly tricky
 problem.

--

Comment (by anarcat):

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

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-
Changes (by gaba):

 * cc: gaba (added)


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   | Resolution:
 Keywords:   |  Actual Points:
Parent ID:   | Points:
 Reviewer:   |Sponsor:
-+-

Old 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). i added a note about this in the
> [https://help.torproject.org/tsa/howto/retire-a-user/ 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.

New 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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 [https://help.torproject.org/tsa/howto/new-person/
 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.

--

Comment (by anarcat):

 mention the new person page as well

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

[tor-bugs] #32519 [Internal Services/Tor Sysadmin Team]: improve user onboard/offboarding procedures

[Tor Bug Tracker & Wiki]

#32519: improve user onboard/offboarding procedures
-+-
 Reporter:  anarcat  |  Owner:  tpa
 Type:  defect   | Status:  new
 Priority:  Medium   |  Milestone:
Component:  Internal Services/Tor Sysadmin Team  |Version:
 Severity:  Normal   |   Keywords:
Actual Points:   |  Parent ID:
   Points:   |   Reviewer:
  Sponsor:   |
-+-
 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). i added a note about this in the
 [https://help.torproject.org/tsa/howto/retire-a-user/ 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.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs