We are currently setting up Tentacles for a new project. Due to some business requirements, all Tentacles must run under domain service accounts and account permissions will be given through the AD groups which the accounts are running under.
After setting up everything, we’ve noticed that Tentacles running on service accounts under non-nested AD groups are able to load and run properly with correct permissions. However for Tentacles that are running on accounts under nested AD groups, the permissions cannot be inherited.
Does Octopus and Tentacles support service accounts in nested AD groups? We are currently using Octopus v2.6.4.951, and we would like to upgrade it to the latest version v3.3.19, does the latest version support service accounts under nested AD groups?
Are the Service account and the 2 groups (the service account is in, and the one where this group its in) on the same domain as the Octopus Server? If they are not, then I’m afraid it wont work. We have a github issue open for it: https://github.com/OctopusDeploy/Issues/issues/1000
If they are all in the same domain, It should work I believe. Is it configured like this?
Service Account -> Group1 -> Group2 (this is the one giving permissions)
Thanks for your reply. The service accounts of the Tentacles and nested groups (for both parent and sub groups) are on the same domain as the Octopus Server. And we’ve configured them as per what you’ve described :-
Service Account for Tentacle >> Sub Group >> Top Group (permissions are given on this level).
When the Tentacle service account is under the Sub Group, the Tentacle cannot get the permissions. But when we add the service account to the Top Group, then the permissions are inherited.
Are there any special settings on the AD side that we have to tweak to make this work?
I ran this question through a few members of the team, and the general consensus was that this should be working. Unless for some reason “Sub Group” is canceling the permissions given by “Top Group”, which could be possible (from my limmited AD knowledge), but seems a bit far fetched.
Is there any chance you can spin up a vanilla VM and set its permissions from scratch with the sole purpose of testing this on another Environment? I did a quick test on my end on a VM and it seemed to work just fine.
To answer your last question, there’s no special setting on the AD side to make this work.