I can appreciate the recent addition of a configurable session timeout for SharePoint Online, but there needs to be a way for admins to configure global timeouts for user sessions in Office 365. It is a requirement under NIST 800-171 guidelines that user sessions are timed out after a period of inactivity. For organizations that use Office 365 in the cloud, this is a problem as the supposed default timeout of 8 hours is not working properly. Testing with an unmanaged computer has shown that leaving a user logged into the "Home" page in Office 365 overnight does not trigger the session to expire, despite the user being inactive for over 16 hours.

I'm told that this would be done through the Azure portion of the Office 365 tenant and am posting here at the suggestion of an Azure support engineer.

Please allow a method of either disabling the validation of the optional parameter x5t (https://tools.ietf.org/html/rfc7517#section-4.8) or support the validation of more complex methods as defined (https://auth0.com/docs/jwks).

Our company is currently attempting to interface a client's Auth0 application as an idp with our B2C directory (via OpenID) using a custom policy. The jwks signature that is defined is producing the following error:

The jwk key can't be deserialized. Reason: 'The thumbprint in the keycontainer ‘NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg’ does not match the certificate thumbprint ‘65AF6909B1B0758E06C6E048C46002B5C695E36B’

The solution that we have found was to short circuit the process and provide our own jwks that omits the x5t parameter and allows azure to compute this value based on its own base64 sha1 hash instead of the algorithm that is provided in the jwks.

The well known metadata for this provider supplies a jwks in the following format (this is a sample that I generated from a test account the error provided is what the system would produce if fed this signing cert):

{

"keys": [
{

"alg": "RS256",

"kty": "RSA",

"use":"sig",
"x5c":["MIIC+DCCAeCgAwIBAgIJBIGjYW6hFpn2MA0GCSqGSIb3DQEBBQUAMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTAeFw0xNjExMjIyMjIyMDVaFw0zMDA4MDEyMjIyMDVaMCMxITAfBgNVBAMTGGN1c3RvbWVyLWRlbW9zLmF1dGgwLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnjZc5bm/eGIHq09N9HKHahM7Y31P0ul+A2wwP4lSpIwFrWHzxw88/7Dwk9QMc+orGXX95R6av4GF+Es/nG3uK45ooMVMa/hYCh0Mtx3gnSuoTavQEkLzCvSwTqVwzZ+5noukWVqJuMKNwjL77GNcPLY7Xy2/skMCT5bR8UoWaufooQvYq6SyPcRAU4BtdquZRiBT4U5f+4pwNTxSvey7ki50yc1tG49Per/0zA4O6Tlpv8x7Red6m1bCNHt7+Z5nSl3RX/QYyAEUX1a28VcYmR41Osy+o2OUCXYdUAphDaHo4/8rbKTJhlu8jEcc1KoMXAKjgaVZtG/v5ltx6AXY0CAwEAAaMvMC0wDAYDVR0TBAUwAwEB/zAdBgNVHQ4EFgQUQxFG602h1cG+pnyvJoy9pGJJoCswDQYJKoZIhvcNAQEFBQADggEBAGvtCbzGNBUJPLICth3mLsX0Z4z8T8iu4tyoiuAshP/Ry/ZBnFnXmhD8vwgMZ2lTgUWwlrvlgN+fAtYKnwFO2G3BOCFw96Nm8So9sjTda9CCZ3dhoH57F/hVMBB0K6xhklAc0b5ZxUpCIN92v/w+xZoz1XQBHe8ZbRHaP1HpRM4M7DJk2G5cgUCyu3UBvYS41sHvzrxQ3z7vIePRA4WF4bEkfX12gvny0RsPkrbVMXX1Rj9t6V7QXrbPYBAO+43JvDGYawxYVvLhz+BJ45x50GFQmHszfY3BR9TPK8xmMmQwtIvLu1PMttNCs7niCYkSiUv2sc2mlq1i3IashGkkgmo="],

"n": "yeNlzlub94YgerT030codqEztjfU_S6X4DbDA_iVKkjAWtYfPHDzz_sPCT1Axz6isZdf3lHpq_gYX4Sz-cbe4rjmigxUxr-FgKHQy3HeCdK6hNq9ASQvMK9LBOpXDNn7mei6RZWom4wo3CMvvsY1w8tjtfLb-yQwJPltHxShZq5-ihC9irpLI9xEBTgG12q5lGIFPhTl_7inA1PFK97LuSLnTJzW0bj096v_TMDg7pOWm_zHtF53qbVsI0e3v5nmdKXdFf9BjIARRfVrbxVxiZHjU6zL6jY5QJdh1QCmENoejj_ytspMmGW7yMRxzUqgxcAqOBpVm0b-_mW3HoBdjQ",

"e": "AQAB",

"kid": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg",

"x5t": "NjVBRjY5MDlCMUIwNzU4RTA2QzZFMDQ4QzQ2MDAyQjVDNjk1RTM2Qg"

}
]}
Available @ https://auth0.com/docs/jwks

We are using Azure Artifacts as an npm feed to store a npm package that we produce, along with cached upstream packages from npmjs.org. Public upstream has been configured per your documentation, and we have enabled retention policies on the feed with the default values.

The problem we are facing is that public upstream packages are treated the same way as package we produce - if a package/version has not been consumed for a while it will be removed in accordance with the retention policies and later also removed from the Recycle Bin. After they have been removed, either to Recycle Bin or purged completely, any build requesting this package/version will fail.

If the package/version is still available in the Recycle Bin we can manually restore it to get the build working again - not good enough (might be production critical), if the package/version has been purged completely we should be able to get it restored by contacting Microsoft - definitely not good enough, regardless of criticality.

This is a flawed approach, the expectation must be that any packages in a public upstream will always be available (if still available in the upstream and not actively removed from our feed, e.g. due to compatibility issues or security). In the case that the cached version has been removed in accordance with the retention policies they should be seamlessly put back.

With the current implementation we are therefore forced to either;

1. Use the public upstreams directly, defeating some of the purpose of the Azure Artifact feeds

2. Keep running builds to ensure that no needed packages are ever removed

3. Disable, or use less restrictive, retention policies for feeds with public upstreams - no OK when you are soon about to charge for feed storage...

How packages/versions from public upstreams should work;

1. If a package that has been removed from the feed by the retention policies, regardless if it has been moved to the Recycle Bin or purged completely, it should seamlessly be put back when requested - build should not fail

2. If a package that has been removed manually (possibly for good reasons) it should not be put back when requested - build should fail

3. There should be a way to get manually removed packages back in case of packages being wrongly removed

The customer wanted to use both .Net and PHP in the application. The PHP application was running on PHP 5.6 and wanted to change it to PHP 7.2.
We understand that the PHP version remains same after you switch to the .Net stack. For example, if you choose Stack as PHP and version 7.2 even after switching application stack to .Net the PHP Version remains as PHP 7.2.
However we feel this UI could be more better when you can configure multiple application stacks. If we have user friendly hinty note this helps in understanding that PHP application stack configuration persist after changing the .net stack that would be helpful. Please advise.

Azure has thousands of public IP addresses which do not have PTR records. Consider adding a PTR record for all IP addresses Microsoft owns, whether or not it is allocated to a customer or service. When naming the PTR domain, consider following a naming convention that makes it easy to determine the region/datacenter it has been allocated to (e.g. US West vs US East vs Singapore), to which services it's been allocated (Yammer, SharePoint, Key Vault, Monitoring, SQL Server, OMS, HDI). This would allow firewalls, intrusion detection and prevention systems, and others to determine that an IP address belongs to Azure by simply looking up the PTR record and performing domain matching. The absence of the PTR record makes it nearly impossible to implement network policies/rules based on PTR records.