There’s a known issue with the Azure AD DS Health Monitoring Agent, which is a part of the Azure AD Connect Health offering from Microsoft.
I’m a big fan of this service, which after installing a small agent on each DC, will alert you of any issues such as replication failing, or a DC unavailable.
However, there’s a problem with how the agent handles its temporary files. As covered on this TechCommunity post, the utility creates a lot of temp files in C:\Windows\Temp locally on each DC. They’re 1/2KB each, but I see around 288 daily being generated. These are never cleaned up.
One one domain controller, since I’ve been running the utility from the 16th September 2016, there are now ~133,000 temporary files. The actual size of these log files is a small 90mb, but the space on disk due to how allocating blocks works, takes up 519MB. I’m going to assume there’s many factors that can change the size and number of log files.
Many people will have small drives for their DCs, and also having lots of files in a folder can cause weird performance issues.
The files are in a format such as 20160915T024226Z-20160915T031125Z-SERVERNAME-6acbd4cb99a1448d848298a59b6fc6e2.json.gz – so it’s easy to set up a daily scheduled task to delete anything older than a day. There’s a couple of examples on how to do this here.
Microsoft has advised this won’t be fixed anytime soon (at least Q3 2018 is what I’ve heard), so it’s worth checking out that C:\Windows\Temp folder and even doing a one time delete if it’s full of log files!
Login prompts to websites are a pain. Enterprise employees these days expect to have a single sign-on experience (meaning the same username/password everywhere) and a minimal amount of logging in to systems each day.
It’s a very different from years ago where every system had it’s own unique login, and users got into the habit of synchronizing password changes when the regular password expiries hit (and I’m sure some companies still run this way), but it’s a problem IT as a whole has worked on for many years.
Microsoft has had a big focus in identity management for many years, with products such as FIM/MIM and ADFS along with the old faithful Active Directory, controlling and giving framework for authentication. The on-premises approach didn’t work for cloud based technologies though. Going to a site such as Office365.com will show an area to sign in:
Going back to the requirements of getting logged out of sites, or needing to log into each different Microsoft service is a pain and time sink for users. The original answer to this problem was ADFS. This works well, but requires the ADFS infrastructure to be set up, and needs to be highly available. If ADFS goes down, your users can no longer authenticate to Azure AD, which is what powers the identity management and authentication orchestration for Microsoft enterprise users (this includes Office 365).
More recently, another native solution was released – Pass Through Authentication for Azure AD Connect (Azure AD Connect being the service that syncs your on premises AD to Azure AD). This removes the requirement for entering a password to these Microsoft services which is great for users, but still requires the entry of the username (which in Azure AD, is the User Principal Name, and looks the same as an email address to confuse things more for users). It’s a good start, but still not the seamless authentication many users expect.
There is another way of providing zero-touch logins to Microsoft services without ADFS, which is Azure AD Domain Join. Windows 10 is a requirement here, but beyond that, the setup is quite easy if you’re already configured for Azure AD. Maurice Daly has written a great guide on this, which outlines all the requirements and steps to follow to be up and running. (Thanks Maurice for your help on this!)
Gotcha for myself: I found that I had an old version of the Microsoft Azure Active Directory Module for Windows PowerShell which didn’t have the get-msoldevice cmdlet at all, and had to download an updated version. I also updated the AzureRM module for good measure since it was also out of date, but shouldn’t have been a requirement.
This is a rather complex topic, so I’ve tried to give a fly-over view of the native options available. There’s also Smart Links which can speed up and improve the user experience.
If you’re on Azure AD and Windows 10, give Azure AD Domain Join a try. It may save you the hassle of building and maintaining an ADFS server, and give your users a better experience overall.
Along with my Azure AD B2B journey (still in preview at time of writing), the option of pushing out something like a SharePoint Online site as an app is one of the jigsaw pieces required to make the whole B2B process work – as a version of the apps page is displayed as the default link to anyone who accepts an Azure AD B2B invite and logs in for the first time.
MyApps – an externally invited user will only see the apps they have access to (by default, none)
I’m trying to gloss over details here, as there’s a lot of steps with different parts of the Microsoft world to get a process automated end to end for inviting external users to a SharePoint Online site – but the last step of assigning a user or group to an application has no documentation I could find, that showed how to achieve this via PowerShell.
All I want to do here, is create an Application in Azure AD, then assign a group to it. Members of the group will then see the application on MyApps.
You can check that this has applied by the Azure Active Directory portal too, by going to your Active Directory section, choosing ‘Applications’ and finding your app, then go into ‘users and groups’ and find the group. You should see a ‘yes’ in the assigned field.
If there’s any interest in documenting the entire SharePoint Online and Azure AD B2B invite process and script, let me know. It’s a great way of sharing data with clients via a portal.
Update 15th June 2017
Microsoft made a change with the IdentifierURI field, which is also called AppID if you view it in the Azure portal. Previously, it could be any unique URL, it just has to be unique amongst your apps (as to why it has to be a URL at all, I couldn’t get an answer on). Now, it can be anything as long as it’s not sharepoint.com or dynamics.com as they’ve reserved those for other reasons. My example above, and what I’d been using in production was variants of sharepoint.com – as the unique URI might as well be the actual URL of the site. If you use a URL that’s not allowed anymore, you’ll get the error:
New-AzureRMADApplication : Operation returned an invalid status code ‘BadRequest’
If you’re using Office 365 and/or Azure, you may have run into this scenario. If you want detailed information about Microsoft Accounts vs Work or school accounts, read this comprehensive article.
For people who set up a Microsoft Account on a work email address, and then configured it for Office 365/Azure, you’d be used to seeing this screen every time you log in:
It’s necessary, but annoying when you’re signing in a lot. I’m not sure how long this has been around, but you can change the email address associated with your Microsoft account, and move it away from your work email address.
And you may notice, there’s that ‘Tired of seeing this?’ message. My brain blocked that out, so you can follow that link too :)
Atwork have a writeup on how to change the email address (the first link gives a 404 message, but you’re still in the right place to make the changes). I tested this on my own account, and within a few minutes I was no longer seeing the choice between Work or Personal when signing into Office 365/Azure services.
A few days ago, an updated version of Azure AD Connect was released – 1.1.371.0 (download). This included the public preview of Passthrough Authentication and Seamless Single Sign-on which lets an internal domain connected computer authenticate against an internal domain controller and sign into Office 365 resources. This gives a great cheap option to do this rather than requiring ADFS on premise to do this or just entering user credentials to authenticate against Azure AD; but there are caveats I’ll cover below.
After you’ve updated the client (regardless of the authentication type chosen), there’s a quick ‘gotcha’: The Azure AD Connect application shows a different message when you launch it:
“Synchronization has been disabled to allow changes to your current configuration. Azure Active Directory will not receive further updates until reconfiguration is complete.”
This is very different from previous versions:
As I was testing passthrough authentication at the time, I misunderstood this message to mean that something was being configured, and I had to wait. What it actually means is that by launching the application, syncs are now paused until you go finish with this program; either by making a configuration change or just exiting.
This also means that if you leave this window open, synchronization will not occur again until it’s closed – even if you have multiple servers set up. If you get an email alert saying synchronisation hasn’t occurred for a while, this is the first thing to is to check that someone didn’t leave the application open.
Azure AD Connect Passthru Auth
I’ve been waiting all year for this option, but there is a lot of misinformation around what it actually can do. After having the privilege of speaking to the Senior Program Manager on SSO and Passthru Auth for Azure AD Connect Ross Adams for two hours (thanks Ross for your invaluable time!) I found out about these key points:
Passthrough Authentication right now does not give you a pure automatic authentication experience. It avoids the requirement of having to retype your password, you still need to choose your account
Azure AD App Proxy is required for Single Sign-on and Passthrough Authentication, but won’t function for actual application proxying when in this mode. You’ll need a different box running App Proxy if you use it this way.
Appending your domain onto supported urls with WHR (Custom login page e.g. https://login.microsoftonline.com/?whr=contoso.com) will reduce the amount of clicks a user needs to get in – generally a single click to pick their account
This doesn’t quite match the experience compared to having ADFS on premise, as I confirmed with friend Ken Goodwin. This is his explanation of the ADFS experience:
If you just go to office.com to logon, after you type in your email address it’ll redirect you to the adfs server which will automatically log you on (assuming internal). If you pre-specify the domain using https://login.microsoftonline.com/?whr=domin.com, then the logon will be automatic.
This might act differently if you’re able to enable auto-acceleration on your SharePoint sites at least which drops the WHM requirement – as long as you have Azure Active Directory Premium.
Keep in mind, Passthrough Authentication and Single Sign-On are still in public preview so this may change and improve. I’m still having a mixed experience on a few items, so don’t go too crazy with rolling this out to your live setup yet. I expect we’ll see some updates soon, and finish up with a really solid new feature to improve the experience for all.
Update: Another tip – if you disable and re-enable Pass Through Auth then your old Kerberos tickets will be invalid. Wait 10 hours or run the command “Klist purge” on an affected PCs – otherwise you’ll get weird authentication errors when trying to log into a site.