Thanks for getting in touch. The special Everyone group has a read-only list of every Octopus User account as members, that is true. However, the bit I find interesting is that I though you should be able to associate an external security group with the Everyone team, but you’re right - that option isn’t available in the current version of Octopus. I’ll look into that and get back to you.
At the moment with Active Directory authentication and Octopus - if a pesonal can authenticate with Active Directory, Octopus considers that identity “authoritative”. What Octopus does next is up to you:
Enable automatic user creation for Active Directory. This is a permissive mode. This means Octopus will automatically create a new Octopus User when a person authenticates with Active Directory, and add them to all the Octopus Teams where the associated Active Directory groups match. As I mentioned before, the Everyone team is a special case: it always contains every Octopus User account.
Disable automatic user creation for Active Directory. This is a strict mode. For a user to access Octopus you will need to create an Octopus User account for them using the Active Directory integration to choose which AD user the Octopus User should represent.
Perhaps you are already aware of these, and using one of those options.
Now onto the idea of associating the special Everyone Team in Octopus with Active Directory groups. We were talking about this internally on Monday and I’m interested to know how you would expect Octopus to behave in some detail.
Imagine the Everyone Team is associated with the Octopus Users Active Directory group in your domain. How would you expect Octopus to behave when:
An AD user who is not a member of the Octopus Users group tries to sign in to Octopus
An AD user who is a member of the Octopus Users group tries to sign in to Octopus
An AD user who is not a member of the Octopus Users group, but they are a member of a group associated with another Octopus Team?
An AD user, who has already signed in to Octopus and has an Octopus User account, is removed from the Octopus Users group
An AD user who is a member of the Octopus Users group is disabled in AD
I’d like to see how much your expectations align with how we are thinking about this specific set of problems.
Thank you for looking in this and bringing up these good questions.
An AD user who is not a member of the Octopus Users group tries to sign in to Octopus
Deny access.
Display message: “To request access, please contact Octopus Deploy administrators.”
An AD user who is a member of the Octopus Users group tries to sign in to Octopus
Allow access.
User gets “Project Viewer” permission only by default. Just as how “everyone” group works now.
An AD user who is not a member of the Octopus Users group, but they are a member of a group associated with another Octopus Team?
Deny access.
A user must exist in AllOctoUsers AD group in order to get access to Octopus portal. Then he/she can be added to other teams for elevated privilege.
An AD user, who has already signed in to Octopus and has an Octopus User account, is removed from the Octopus Users group
Deny access.
Users got removed from AllOctoUsers AD group either because they don’t use Octopus anymore, or they are leaving the firm. If they need access again, they can be added to the AllOctoUsers AD group again.
An AD user who is a member of the Octopus Users group is disabled in AD
Deny access.
If a user is disabled in AD, he/she should be disabled in AllOctoUsers AD group too.
On Octopus side, the user should be marked “Inactive” with name grey out.
Hope these make sense. Please let me know your thoughts.
These sound pretty sensible to me. What I’m torn about is whether to treat the Everyone Team in Octopus as a special case, thereby changing how we interpret the External Groups associated that team.
In today’s interpretation, if an Octopus Team is associated with two AD groups, these groups are combined as an OR: “AD Users who are members of ANY of these groups will be automatically added to this Octopus Team.” Put in another way it’s interpreted as an “inclusive allow”.
Option 1: We make the Everyone Octopus Team even more “special” than it is today. If the Everyone Team is associated with two AD groups, these groups are still combined as an OR, but treated as a requirement to even get in the door: “AD Users who are members of ANY of these groups will be considered as members of the Everyone Team. AD Users who are NOT members of ANY of these groups will be DENIED access to Octopus altogether.”
Option 2: We leave the Octopus Team + AD Group association alone, but add an extra option to the Active Directory Authentication Provider (Configuration > Settings > Active Directory) like this:
Members of the following Active Directory Groups will be granted access to Octopus:
Everyone (default)
OR
Members of the following Active Directory Groups will be granted access to Octopus:
SpecialGroup1, SpecialGroup2
I’m leaning towards Option 2, making sure there’s appropriate pointers for people to find this configuration from the Everyone Team if that’s where they start looking.
We agree. We aren’t able to commit to this work immediately, I think it will be something we can get done early 2019. In the meantime are you able to keep going with the current combination of features in the Active Directory support for Octopus?
Good question. The sync task runs every hour. This is not currently configurable. You can run it manually too: go the Task page, find a previously run task, and re-run it. While it’s not the best user experience, it’s a reasonable work around until we have a better UI for this purpose.