Just upgraded to 2020.4.2. Most of our users are unable to deploy anymore. Checking ‘Test Permissions’ shows any AD groups they are directly part of they have permissions to but any that are nested they no longer have access to deploy. This worked with our previous version (2019.12.0) without issues.
User --> GROUP A --> OCTOPUS [OK]
User --> GROUP A --> GROUP B --> OCTOPUS [NO PERMISSIONS]
Further oddities… our Test server with the same source DB dump is reporting all those permissions properly. Is there any debug logs or anything we can look at to see why one server is reporting nested permissions properly and the other one stops after the first AD group?
You can look at the task for Sync External Groups for some more information, but that may not get you more information than you already have.
Could you take a look at that page and run through the information, specifically the powershell section?
EDIT: Are these security groups all on one domain? Are the users on the same domain? A basic breakdown of your setup may be helpful in figuring out the issue.
ALL Users/Groups are in DOMAIN1
Octopus Server is in DOMAIN2 (Domain2 has no users/groups except those to administer the domain)
Service Account Running Octopus Server is in DOMAIN1
DOMAIN2 is a trust relationship with DOMAIN1
Octopus permissions work fine if we add users individually OR supply a group with users directly in it.
Octopus permissions are now failing if we add a group with a nested group with users in it.
Full disclosure during this octopus upgrade we did switch our server to the DOMAIN2 to comply with corporate mandate of where new servers are built.
Executed Powershell as Service account running Octopus Deploy on both servers (same account just ran it from both servers).
.GetAuthorizationGroups() - found both Parent and Child Group in question on Both Servers
.GetGroups() - found only the nested group test user is directly apart of (not the parent group test user is not part of directly) - on Both Servers
So powershell executed identically on both servers.
Could there be something odd about nested groups when in a trusted domain?
I just want to confirm. The Test Octopus instance and the Prod Octopus instance have the exact same setup and permissions with AD, correct? Or is the Test instance not moved to DOMAIN2?
The Test Octopus Instance is in DOMAIN1 as I’m still waiting for the servers to be built in DOMAIN2 for it. Everything else is identical though, including both running as the same service account sharing the same Database backup from the old primary server.
Would you be able to privately message the following to me:
A screenshot of your Octopus AD screen.
The output of running setspn -L <server> on the octopus server.
What type of trust is between the two domains.
A log of the latest Synchronize External Security Groups task. (If you can point out a user with the issue in the log, and what you were expecting to happen, that would also be helpful)
Please let me know if you have any questions about the above.
I wanted to update the thread as Kevin and I have been working in a private message in case anyone searches and finds this.
As it turns out, if you want nested groups to work, everything has to be on one domain. If you want to cross domains, the groups can’t be nested. This added functionality should get implemented in the future but there is no timeframe.