- UNIFYNow Forum
-
Questions
Expected Behavior around polling incorrect credentials on AD Agents
Hi Gents,
We've had an issue in PROD at DET - essentially as part of a new deployment, EVB configuration from DEV was deployed, the service started and then left for a period with the scheduler in a paused/stopped state. The credentials for the agents were not updated at that time.
In this case, the credentials on a bunch of the AD agents used the same account names as in DEV but (obviously) different passwords. Also DET has an across the board policy on service accounts including lockouts.
As such, after running in this state for a while, we discovered that the AD service accounts in-use had become locked out/disabled. Unfortunately for us, one of those accounts was also shared by the VIS service which ended in a number of outages :(
What we're asking however, is this expected behavior of the Agent? What is the polling interval between credential checks? And should this be reviewed (perhaps something like if the last 1-2 checks failed, don't poll again until the agent is updated) or should polling be performed at all?
Answer
Hi Richard,
Yes, this is expected behaviour. The scheduler stops operation lists from being executed; it does not stop everything (as EB has numerous schedules that are required for its operation, as well as actions that occur at startup to ensure that locally cached information is correct).
Would following best practice and keeping services accounts mapped to single applications solve this particular problem? Or, if EB was desired to be stopped completely, couldn't the service have been stopped? Or would you feel there'd be some benefit to us looking at evaluating what is and isn't stopped when the scheduler is stopped?
Thanks.
Adam and Richard - I've thought I raised a UE ticket on a related issue but I can't find it so it must have over Skype. I observed this week that with the Scheduler stopped the Agent connection tests are still being run - and in my environment this shows up as failures like these:
The trigger for operation list with id b7e59dbc-3c7e-42a6-bff8-344e6a95ddfa has failed to attached with the message The supplied credential is invalid..System.DirectoryServices.Protocols.LdapException: The supplied credential is invalid. at System.DirectoryServices.Protocols.LdapConnection.BindHelper(NetworkCredential newCredential, Boolean needSetCredential) at System.DirectoryServices.Protocols.LdapConnection.SendRequestHelper(DirectoryRequest request, Int32& messageID) at System.DirectoryServices.Protocols.LdapConnection.BeginSendRequest(DirectoryRequest request, TimeSpan requestTimeout, PartialResultProcessing partialMode, AsyncCallback callback, Object state) at Unify.Product.EventBroker.OpenLDAPListenPlugIn.AttachTrigger(IListenOperationInformation listenOperationInformation) at Unify.Product.EventBroker.OperationListExecutorSink.RecycleListenOperation(IListenOperationFactoryInformation checkOperation)
This is concerning me as there are no alerts shown on the dashboard and connectivity appears to be fine for execution of operations.
I personally don't think there should be any polling activity at all happening if all operation lists are disabled - even if the scheduler is running.
I will raise as separate ticket for this problem above.
Thanks Bob. I spoke to Richard earlier today about this and he's going to get me more details on the location that's causing his issue. I'll then compile it all together as a feature request to be a little more explicit about what does and doesn't run when the scheduler is disabled.
Customer support service by UserEcho
Hi Richard,
Yes, this is expected behaviour. The scheduler stops operation lists from being executed; it does not stop everything (as EB has numerous schedules that are required for its operation, as well as actions that occur at startup to ensure that locally cached information is correct).
Would following best practice and keeping services accounts mapped to single applications solve this particular problem? Or, if EB was desired to be stopped completely, couldn't the service have been stopped? Or would you feel there'd be some benefit to us looking at evaluating what is and isn't stopped when the scheduler is stopped?
Thanks.