2 votes0 comments · Azure Monitor- Alert Management » Managing Alerts · Flag idea as inappropriate… · Admin →
1 vote0 comments · Azure Active Directory » Azure AD Connect Health · Flag idea as inappropriate… · Admin →
53 votes7 comments · Azure Monitor-Log Analytics » Agent Management (OnPrem components) / Connectivity / Setup · Flag idea as inappropriate… · Admin →
We’re aware of an issue that can cause this error to be logged when the Update Assessment solution is installed.
You can check if this is what you’re seeing my temporarily removing the Update Assessment solution and confirming the errors stop.
The Update Assessment solution functionality is not affected and you can safely ignore this error.
Frustrating to see that almost 3 years from this issue being "Planned" it's still unfixed. Yes, it's benign as far as functionality goes, but it adds a substantial amount of noise to the system event logs and the error events being generated are easily mistaken for genuine issues which need to be rectified.
Can we please get an update on this? While the issue is "harmless" it results in dozens of error events on managed servers, often in a single day. This makes identifying genuine issues more difficult during analysis of Event Logs, and also requires additional filtering when forwarding logs to a server.
4 votes0 comments · Azure Monitor-Log Analytics » Change Tracking Solution · Flag idea as inappropriate… · Admin →
We continue to investigate this. Due to the current roadmap and strategy this will remain in our backlog. Please continue to share feedback related to this topic to help us make an informed decision at a later time.
We are currently working on this
This is an absolute showstopper for us w.r.t. usage of this feature and we'd really like to hear from any engineers who can provide some insight as to why such an old algorithm was chosen as the sole supported cipher for Seamless SSO.
The best practice has been to disable RC4_HMAC_MD5 for well over a decade, alongside the similarly obsolete DES_CBC_CRC and DES_CBC_MD5 algorithms. The AES encryption types have been supported since Windows Server 2008 and Windows Vista, so backwards compatibility shouldn't be a significant concern here?
Granted, the Kerberos ticket transmitted by clients for Seamless SSO is as far as I'm aware only ever sent over HTTPS, which should be using modern and far stronger encryption, but enabling support for RC4_HMAC_MD5 has to effectively be done domain-wide. That obviously opens up numerous risks in now allowing such an old encryption algorithm to be used by any Kerberos clients on the given domain.
Thanks for your interest on this feature. This capability is still in the pipeline. The initial estimate was obviously off and we are looking at a new timeline. We are aware of the benefit of having this rollover made automatic and the interest you have on the feature, and that’s how we are looking at it while prioritizing it against other capabilities requests.
Thanks for your patience!
Principal Program Manager
DNSSEC remains on our long term roadmap, however it is unlikely to be available in CY 2019. If DNSSEC is a critical and immediate requirement for your business we’d suggest that you consider evaluating 3rd party DNS hosting solutions that provide this feature.
Hey folks, sorry for the late update. Some backend changes were made to alleviate this issue but I believe it doesn’t solve it for everyone yet. Let me go get some details and come back with a better update. Thanks!