Teams and Permissions Octopus 2

We have just installed RC 3 to check it out.

We have noticed a few short comings with regard to teams and permissions. In 1.6 the permissions were ordered and a little clunky, however we were able to add permissions on a per application and/or per environment basis. In the new version this doesn’t seem possible? We can only apply roles to Teams and then a list of projects and/or environments that all these permissions would apply to.

Also in 1.6 we were able to enroll groups in groups. The UI implies this is possible (“The users and groups belonging to the team”) in 2.0 however when we try to add another team, the selection is not available.

Are there plans to add these features back into version 2.x? Also if they are added would it be possible to apply permissions to project groups?

Also some what an extension of this question, is Single Sign On/NTLM/Windows authentication with the Octopus portal doesn’t seem to be in place anymore?

Developers A.
Developers B.
Developers C.
Testers -> Octopus Administrators.


A -> Dependant on C
B -> Dependant on C


  1. SysOps edit environments and machines.
  2. SysOps view deployment logs.
  3. SysOps Deploy Production
  4. Developers A Deny Release Production
  5. Developers A All permissions Project A
  6. Developers A Release Project C
  7. Developers A View Output Log Project C
  8. Developers B Deny Release Production
  9. Developers B All permissions Project B
  10. Developers B Release Project C
  11. Developers B View Output Log Project C
  12. Developers C Deny Release Production
  13. Developers C All permissions Project C
  14. Everyone Deny All

Then we also have some Manual Intervention steps for deploying to UAT that members of Testers must authorse deployments.

Hi, thanks for the feedback.

We have a ticket currently for AD group integration at:

Regarding permission structures, have you considered adding each user to potentially several teams? E.g. “Production deployers”, “Project C developers” etc?

Teams in Octopus probably aren’t sophisticated enough just yet to map 1:1 with “real world” teams.

The current team setup is simplified to eliminate some issues that came out of an earlier fine-grained version, but we’re still open to fine tuning it.


Hi Nicholas,
Thanks for the response.

We could do it this way however it would be nicer if we could structure our teams as we did with groups in 1.6, or at least be able to have Teams enroll in Teams so we could create a set of permissions and then just move groups of people in and out of those permissions, so we don’t have to duplicate permissions across Teams or manage individual users joining a real world team meaning we have to move them in and out of N Octopus Teams.

Our organisation is currently embarking on a large project that will involve the creation of numerous new teams and >150 new websites, so to try and manage permissions in this way could become very cumbersome.

Thanks for the feedback, we’ll give it some more thought.

Would the AD Groups integration help with the management overhead you mention?


Perhaps. It would depend on how the AD group integration was implemented.

At this stage it would be teams of people moved from working on one site to another as well as individual users moving teams.

It would help in terms of managing from a central location for their TeamCity, Octopus, Distribution emails etc.