Using AD group to control the login access to Octopus Deploy

Legacy Security
#1

Hello,

We would like to set up a AD group to control the overall access to Octopus Deploy.

That is, any users who want to log into Octopus Deploy, have to be added to that AD group first.

We initially looked into “everyone” group and see if we can put the AD group there, but the “members” field is read-only in “everyone” group.

Is it something doable?

Thanks,

Ge

#2

Hi Ge,

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:

  1. 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.
  2. 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:

  1. An AD user who is not a member of the Octopus Users group tries to sign in to Octopus
  2. An AD user who is a member of the Octopus Users group tries to sign in to Octopus
  3. 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?
  4. An AD user, who has already signed in to Octopus and has an Octopus User account, is removed from the Octopus Users group
  5. 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. :slight_smile:

Hope that helps!
Mike

#3

Hi Mike,

Thank you for looking in this and bringing up these good questions.

  1. 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.”

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

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

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

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

Thanks,

Ge

#4

Hi Ge,

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.

What do you think?
Mike

#5

Hi Mike,

Agree. Option 2 sounds appealing.

Also, since it’s a extra option, people who don’t want this feature can opt out without changing existing setting in their instances.

And in my case, I like 2nd idea in option 2 - “Members of the following Active Directory Groups will be granted access to Octopus: AllOctoUsers”

This way, users have to go through us in order to gain access to OctopusDeploy, and we’ll have more control over it.

Best,

Ge

#6

Hi Ge,

We agree. :slight_smile: 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?

Hope that helps!
Mike

#7

Hi Mike,

We can probably disable the auto user creation, which should enforce users coming to us.

I’ll test to see how that goes.

Thanks for your help!

Ge

#8

Hi Mike,

Another question.

If members in an AD group is updated (add/remove users), how long does it take to reflect that change in Octopus?

What’s the frequency that Octopus re-sync AD groups?

Thanks,

Ge

#9

Hi Ge,

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.

Hope that helps!
Mike

#10

This is exactly what I am looking for. Thanks for the information!

Ge

1 Like