Currently our Octopus Deploy server is on a machine in domain A, running under an account in domain A.
All of our users are in domain B, and belong to a number of groups in domain A that we want to use for team permissions.
We can log in just fine, and manually assigning people to teams works fine. But people are not automatically given team permissions based on their Active Directory groups.
Is this a known issue? I’ve seen in other threads that groups have to be in domain A for this to work, but our groups are. I don’t see any mention of the users needing to be in domain A too…
Thanks for getting in touch! I do not believe this scenario is supported. Your options would be to have the groups in the same domain as the users or add the users to the teams in Octopus individually. In 3.4 we are looking at reworking our authentication (to include things like OAuth) and this will include a rework of AD, so we will keep this scenario in mind.
We have the same scenario as described above, and were waiting eagerly for 3.4. We have just deployed 3.4.3 and see that this is still not working - can you please provide some information about when this function will be available?
Thanks in advance,
OAuth was not a part of 3.4 The best way to check if a feature is part of the release is via our blog or release notes. We do not have dates for when this feature will be available. We will also not be mentioning versions for features any longer. If something is planned we will let customers know, but no longer want to tie the idea of features to versions as they might not make it (like this didn’t). In the past when these things were planned we had an idea, but the versions mentioned were never set in stone. Hopefully this will help with expectations.
What currently is planned is an extensible identity provider model, here is the issue for tracking: https://github.com/OctopusDeploy/Issues/issues/2593
When the feature is closer to release there will be a blog post explaining what it is and what it will open up. (Our AD extension will be OSS).
Unfortunately it will not resolve the AD problem mentioned in this thread. However Shannon who is working on the feature found a different API call that might give us better visibility of the domains a user can belong to without having to turn of group synchronization, so we are still investigating if this is even possible. Best thing to do would be to follow the issue that I have linked to and see where it gets to. Shannon will update around this issue with a conclusion.
Sorry if most of this is bad news.
This issue has been closed due to inactivity. If you encounter the same or a similar issue and require help, please open a new discussion (if we asked for logs or extra details in this thread, consider including them in the new thread). If you are the creator of this thread and believe it should not be closed let us know via our support email.