We recently finished an internal security audit and realigned users permissions in Active Directory and Octopus Teams. In our model, each Octopus-related AD group is assigned to one Team. When user’s AD accounts changed groups, the team associated with the original group isn’t being removed:
User A (Group A) → Team A (GroupA) : Running test permissions shows user belongs to Team A
User A (Group B) → Team B (GroupB) : Running test permissions shows user belongs to Team A & B
Applied permissions appear to be aligned with the current Team (AD Group) settings; and the only way we could get Test Permissions to align with the users Team (AD Group) was to delete their account and have it recreated. Any suggestions on how this could be cleaned up without removed users accounts? Thanks.
AD Groups are not updated in real-time as you make changes to Octopus users, instead, we have an automatic task that runs every few hours called Synchronize external security groups. And as you’ve found, user creation will also query AD for the group changes as well.
You can manually re-run this task by navigating to Tasks and filtering for Include system tasks:
Sorry for the delay here; I was just testing a few things. It seems like these changes are eventually reflected on my instance, but the groups aren’t immediately removed.
I believe the removal changes always happen when the automatic 1h task is queued up by System. Re-run does work here but it seems like the AD changes aren’t immediate. This could be some kind of caching or propagation timing issue, but I’m not positive.
Have your external groups been removed or are they still persisting after a few hours?
The AD groups are persisting. User’s don’t change AD groups frequently so we don’t get many complaints about access problems. I was hoping there was option to do a per-user refresh other than deleting accounts.
That’s very odd that the groups aren’t being removed over time; I need to reach out internally to see why this might be happening.
Would it be possible for you to run through our troubleshooting here, eliminating Octopus and verify that the group membership looks correct from the machine’s perspective (run this on the server hosting Octopus)?
If that’s something you can do, please let me know.
Hi Garret. Finally got around to performing the steps in the guide. The results returned just show that my account is part of the correct AD group. The group that my account used to belong to is not there.
Is the OctopusDeploy Service itself is being run as a domain user/service or a local user? For example:
You might be able to Revoke Sessions under a user when changes are made; I’m hoping this will force a group sync on login that will help avoid actually having to delete the user:
Would it be possible to turn on AD diagnostic logging on the DC? We have a bit of guidance here on how to do that. There might be some hints in EventViewer as to why this isn’t updating correctly if you re-run the sync task from Octopus. Or if nothing changes when the task is ran we’ll know the query isn’t getting through.
Additionally, we might have some hints in the Octopus Server logs, by default, they’d be located at C:\Octopus\Logs. If we could get a copy of the latest I’ve created a secure link upload for you here.
Thanks Garret. ‘revoke sessions’ isn’t an option in our Prod environment as we are a little behind. I’ll reach out to our AD team to see if its possible to turn on diagnostic logging. Thanks.
