Whilst Endpoint Protection can be suitably managed for traditional Active Directory-joined devices using Group Policies, you’ll need an alternative to protect your Azure AD joined devices. Luckily Intune can do this for us by way of a device configuration profile.
Azure AD Password Protection is part of Azure Active Directory and helps prevent users from picking poor/easily guessable/compromised passwords. Microsoft maintain a “global banned passwords” list which stores passwords which are “deemed too common”. Obviously this list is not published, but by using Azure AD Password Protection you can have password changes run against it for both cloud and on-premises users. You can also create a custom banned password list, of up to 1000 entries, containing easily guessable things about your organisation, e.g. product names.
When a password change is processed, the service will “normalise” the password (which in essence would be taking it to lower case, swapping out any common substitutions, e.g. Pa$$w0rd -> password), and then checking the resulting string against the banned password lists. If it matches the user will get an error telling them to pick something more difficult to guess.
The only thing I don’t like about this at the moment – and hopefully is something that will be worked on in a future update – is that it’s all or nothing. At work we give staff a much more strict password policy than pupils, so it would be nice to be able to do the same here.
I’ve looked at using Azure to back up on-premise workloads in a couple of posts now (Azure Backup for smaller loads, and Azure Backup Server for things like a Hyper-V cluster), so I think it’s time I looked at backing up workloads that are already running from Azure. I’m going to look at backing up Virtual Machines and storage accounts – there’s not much more I store in Azure that would need backing up.
I’m going to take a quick look at the options for storage accounts, virtual machines and databases.
There’s been a Group Policy setting to sync Team/SharePoint libraries for a while although last time I looked at it the functionality didn’t actually work yet – I think it was meant to be available from Windows 10 1909 but didn’t quite make it. Besides the fact that the setting didn’t do anything, all the documentation claimed it could take “up to 8 hours” for the library to appear in the user’s sync client/Explorer – clearly this is no use especially if you’re in an environment where people hot desk and share machines. I’ve had another look at it to see if it’s any better now.
It’s something that isn’t recommended but sometimes there’s not really much you can do otherwise – we have a set of iPad minis which are shared between multiple pupils and at the moment they are on Meraki MDM, connected to the 8021X Enterprise wireless network using a username/password which is set via the MDM profile. I really want to move these devices to Intune but you can’t create a WiFi profile with embedded credentials on Intune – presumably this was never an option for obvious reasons.
The only other option I can see is to set up SCEP and have the devices issued with certificates, and then use those to authenticate, presumably I’d also need to enable device writeback so that the NPS server can see the devices in AD. Due to the way our AD is configured (single forest with lots of domains, synced to multiple Azure AD tenancies) device writeback is unsupported, so let’s look at embedding the credentials into Intune instead. Continue reading “Intune: iOS Wireless Profile with embedded credentials”
Azure AD Application Proxy is a really neat tool for publishing internal applications without exposing your servers to the Internet. If your applications require authentication for users to access them you can get Azure to handle all this for you, and it supports single sign on. Alternatively if you’ve got an old or obscure application that can’t cope with Azure SSO you can configure it to use passthrough authentication, where the internal application remains responsible for this task.
You can use Conditional Access to restrict and secure access to your application, such as enforcing MFA, or only permitting access from specific devices or locations. The way the proxy works does not require you to open any inbound ports through your firewall – the proxy connector simply connects outbound to Azure and all traffic is routed through that connection.
You’ll need Azure AD Premium P1 or P2 for this to work. There’s been some talk of it working on the Office 365 Basic level of Azure AD however it’s not listed as supported, and I’d expect that this may be an educational SKU specific exception case.
Last year I replaced a 3 node VMWare+SAN cluster with a 2 node hyperconverged Hyper-V cluster. I’ve been quite impressed with it so far so thought I’d write how I did it – especially considering I did the bulk of the work through Windows Admin Centre.
Before you decide to sit down and do this, be warned it’s not a quick process. If you’re in any doubt you should probably consult a vendor who has the Microsoft certified hardware and expertise available before putting this into production – if you’re fine with setting up complicated things yourself, or it’s for testing, then you’re welcome to come along for the ride. You’ll no doubt waste countless hours trying to get Windows to play with the disk adapters and get the disks into the right mode for S2D, especially if you’re using older hardware, so I’d set aside at least a full day or two.
If you’ve connected Windows Admin Centre to Azure you’ll find a section called Azure Backup. This will allow you to back up your on-site workloads to Azure using the Microsoft Azure Recovery Services agent. It’s ideal for backing up physical servers or individual virtual machines, however if you’re after backing up all the guests on your Hyper-V host you’re better off looking into Azure Backup Server, which runs on the host rather than the guest.
In this post I’m going to look at configuring and backing up a server through Windows Admin Centre, and then at how to recover the data – both for a partial failure (such as some files being deleted but the server still boots) and a total failure.
Windows Admin Centre is a web based server (and desktop) administration package which, eventually, should replace the majority of the work currently done through MMC consoles and snap-ins. If you’ve ever opened Server Manager on a Windows 2019 machine you’ll have seen the popup telling you to “Go get Windows Admin Centre!”. Whilst it’s not there yet, it is constantly being updated and improved and I find it really useful.
It’s a lot more than just managing a couple of systems – when I set up our hyperconverged Hyper-V cluster I primarily did this from within WAC (post to follow on this if I get chance to write it up) – and it integrates nicely with a lot of Azure services (including any Azure VMs you might have)
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.