Hi - we’re using
Using Active Directory Authentication only (and have been since OD 3.2.13)
Server Extension - Directory Services - Octopus Deploy - 18.104.22.168
We have forms authentication disabled.
I’m trying to understand a couple user management items because we have some diagnostic errors in our logs and I can’t find what I’m looking for regarding user management in the online documentation.
As people leave the company their AD accounts are disabled/hidden and deleted.
Does Octopus do any clean-up of the Octopus user list over time by checking the directory associated with the account?
Or is it expected an Octopus system admin will delete octopus accounts when users leave the company?
Here are the log messages which led to the question - any thoughts on these. I saw in another post we could turn on a higher level of diagnostic logging to see the account, but then we’d want to turn it off. Just wanted to understand the product expectations for user management when using active directory only and user accounts are created automatically.
1/3/2017 3:00:12 PM -05:00 [Warning] An error occurred while loading the users external security groups.
System.ArgumentNullException: Value cannot be null.
Parameter name: externalId
at Octopus.Server.Extensibility.Authentication.DirectoryServices.DirectoryServices.DirectoryServicesExternalSecurityGroupLocator.GetGroupIdsForUser(String externalId)
at Octopus.Server.Extensibility.Authentication.DirectoryServices.DirectoryServices.DirectoryServicesGroupsChecker.EnsureExternalSecurityGroupsAreUpToDate(IUser user, Boolean forceRefresh)
Thanks for reaching out! Octopus doesn’t do any automated user clean-up when users are removed in AD. Since certain information, like audit logs and events are associated with specific users, that user would be removed from that history, and we can’t assume you want that info changed. It would be safest to have the users removed by your admin with that in mind.
We believe the error you’re getting is caused by the way we run Active Directory combined with the Subscriptions feature. Do you have Subscriptions defined?
If so, that could cause this error by the way we retrieve AD users. When a user logs in to Octopus, we read AD and determine which Group they are a part of. When they log out, we drop the list of groups, and reload it next time they log in. With the addition of Subscriptions, which sends an email to everyone in the team, it requires reloading groups for users (in case some are not logged in) in order for all users to get the email. At this point, it recognizes that not all of the users still exist and gives this error.
The short-term solution in this case would be to manually remove the Octopus users that don’t exist in AD. The long-term solution could be the suggestion outlined in this GitHub Issue which involves changing the way we recognize which users are a part of which Groups.
I hope that helps!
We don’t have any subscriptions defined yet so unfortunately that isn’t the problem for us. We’ll review removing users who no longer exist in AD. I’ll try setting removed users to disabled as we don’t want to lose audit history and see if the diagnostic logs still have the error.
Thanks for replying. So sorry we’ve had to go back and forth. I have been re-assessing your error with the developers here. As it is now, disabling the user won’t prevent the user from being ignored. Handling disabled users is currently an open issue, and it will be included in a near-future release.
However, Service Users accessing the API using API keys will cause this same error. There was a GitHub issue that was fixed in 3.7.11 for this, so we’re confident upgrading to that version will help.
Let me know how you go!
I’ll follow the issue and see what happens. Thanks again for your help.