Information about SharePoint, Microsoft 365, Azure, Mobility and Productivity from the Computer Information Agency
The slides from this month’s webinar are available at:
https://www.slideshare.net/directorcia/september-2023-ciaops-need-to-know-webinar
If you are not a CIAOPS patron you want to view or download a full copy of the video from the session you can do so here:
http://www.ciaopsacademy.com.au/p/need-to-know-webinars
Watch out for next month’s webinar.
This series of posts is an approach to implementing Intune inside a business. So far, I have covered off:
1. Create compliance policies and update devices to be compliant
2. Implement LAPS to control the local device admin account that cannot be deleted
3. Remove all other accounts from local administrator group on devices
One of the longer term best practice goals is to move all users to exclusive use of Microsoft Edge as a browser. Doing so will improve overall security, provide greater management of the browsing experience and provide a consistent environment.
In most existing environments today, users in a business are using a variety of browsers. It is my experience that, generally, users are not wedded to the type of browser they use but many are wedded to the search experience they have become familiar with. Changing this experience abruptly is going to reduce user productivity and create resistance to change. In order then to ease the transition from other browsers to using Microsoft Edge a recommended approach is to use Intune to change the default search experience in Microsoft Edge to the one users are familiar with. It is important to remember that Edge will be pretty much 100% compatible with the browser they use today, along with any extensions. Also, the idea with this step is not to force users to use a new browser but start preparing for that change.
The first step in the browser migration project will be to set the search experience in Edge to be what a user is familiar with. To do this you will need to create a new Intune configuration profile.
In the Intune console select Devices then Configuration profiles. Then select Create profile on the right. Select Windows 10 and later for the profile and Settings catalog for the profile type. Select Next to continue.
This policy is something that will be added to overtime so it is suggested you call the policy something like ”Edge configuration” as shown above. Select Next to continue.
Select the +Add settings link
Locate the Microsoft Edge\Default search provider in the top of the blade that appears on the right as shown above. Select this and a list will appear in the lower half. FRom the list in the lower portion, select the following four settings:
– Configure the new tab page search box experience
– Default search provider name
– Default search provider url
– Enable the default search provider
Close the settings picker by selecting the cross (x) in the top right hand corner.
Enable the four new settings, as shown above, and given that Google is the most common search engine, here are the appropriate settings for setting the default search engine in Microsoft Edge to be Google:
New tab page search box experience = Address bar
Default Search provider search URL = https://www.google.com/search?q={searchTerms}
Default search provider name = Google
You can of course use any search provider you wish. My preference would be for DuckDuckGo but remember, the idea here is to provide the lowest amount of friction to migrate users away from the third party browsers they are probably using. However, if you wish to force a new search experience, now is probably the best time to do that.
Complete the policy and assign it to your users. You then need to allow the policy to roll out.
Now when users type a search term into the URL box, while using Microsoft Edge, it will use the search engine you just configured via the Intune policy as shown above.
Remember, at this stage all that has been done is to set a new default search engine for Microsoft Edge. If the users are not yet using Edge then they will be unaffected by this change. The idea is to make the Edge environment as familiar as possible before forcing users to use Edge instead of the browsers they current use.
Of course, if some users are using Edge this change will affect them and you should prepare for that but communicating the reasons for the change and how everyone will be shifting to Edge and this is the first step in the process to provide a more secure and consistent environment for everyone. You could also just target this new policy to users not currently using Edge as their default policy. The choice is yours, but the endgame is to get everyone using a secured version of Edge with consistent settings.
We’ll come back and make more changes to this Edge configuration policy over time but for now we have all versions of Edge using the same search engine.
I recently outlined how to
Control local admin on a device with LAPS and Intune
Once you have LAPS in place I suggested that you want to eliminate any local device administrators as a best practice. You can achieve this via a policy in Intune.
The first step in the process is going to be to determine any local administrator accounts and what they are doing in your environment. A good starting point is this KQL query to look for local admin activity in your device fleet:
DeviceLogonEvents
| where TimeGenerated >= ago(7d)
| where IsLocalAdmin == true
| summarize count() by DeviceName, AccountName,LogonType
| sort by AccountName
That will, of course, only show you logon activity by an account that is a local administrator. For dormant local admin accounts you are going to need to do more work to flush them out. However, the query will at least show you active local admin accounts that maybe impacted by any changes made using something like LAPS.
To set a policy to control local groups on Windows devices, login to the Intune management portal and select Endpoint security and Account protection, as shown above. Create a new policy for Windows 10 and later and select Local user group membership as the Profile.
Give your policy a meaningful name and continue.
Select the local group (here Administrators), select the action (here Remove) and Manual for the User selection type.
When you select the Add users hyperlink in the Selected users/groups field you will see the above blade appear. In here, you’ll find a number of different methods of identifying users. If you have a list of local device admins then you can add them here.
Once you have entered all the users you wish to remove from the local device administrators group, complete the policy and assign it to the audience you wish.
The policy will then roll out to your environment and the changes will be made to the local group membership. In this case, it will remove local users from the local device administrator group so they can no longer administrate the device.
Remember, there are lots of options here. You could different policies for different users and/or devices. You could create policies to not only remove but also add. An example maybe where you wish an Entra ID user to be a local administrator of box. In that case, simply select the option to Add the user from Entra ID to the local administrators group. There is a lot of flexibility here with this policy.
Typically, once your policy has completed and there are no more local administrators you can remove the policy, as hopefully no more local accounts will be created with devices being joined directly to Entra ID. However, you may wish to retain it for if new devices are joined to your environment, especially if you don’t use Autopilot.
In summary then, the process so far, is:
1. Create compliance policies and update devices to be compliant
2. Implement LAPS to control the local device admin account that cannot be deleted
3. Remove all other accounts from local administrator group on devices
Typically, these steps will have no impact on users working with their devices and it commences the process of implementing a consistent environment and making it more secure.
You can read more about this particular policy here:
Manage local groups on Windows devices
I recently suggested that Compliance policies were the place to start with Intune device management.
From there, I would suggest that configuring the Local Administrator Password (LAPS) policy is a good follow on option. This will automatically rotate the password for the Windows local device administrator accounts.
In the Intune console select Endpoint Security and then Account protection. Create a new policy for Windows 10 and later and select Local admin password solution (Windows LAPS) as shown above.
Give the policy a meaning name and description.
Make the appropriate settings as shown above. You want to ensure that the Backup directory is set to Backup the password to Azure AD only.
Assign the policy and save it.
Once the policy has been assigned to the device a random password, to specifications set in the policy will be applied and a copy will be saved into the device details in the location shown above within Intune
In general it is best practice to have no other local admin accounts on devices except the default one provided by Windows that cannot be removed. Per the FAQs, LAPS supports only one account on a device. You can specify that account but it is best practice to not specify a name on the policy configuration and allow Intune to manage the default built-in administrator account.
Once the LAPS policy has been applied you will see the following for the Windows devices as shown above.
Selecting the Show local administrator password hyperlink will display a blade with the above information. Selecting the Show button here will display the current password and allow you to take a copy.
Best practice is to take control of the default local admin account using the LAPS policy deployed via Intune as shown. The next step would then to be to eliminate any other local admin account from the devices so the only ne left is the default which has its password rotated regularly thanks to LAPS.
Further information on LAPS with Intune can be found here:
Microsoft Intune support for Windows LAPS
If there is one piece of advice I can given when it comes to setting up policies in Microsoft 365, it is to have a good and consistent naming convention.
Microsoft 365 is full of policies, from Conditional Access, to Exchange Online to Intune and more. Having a naming convention worked about before you start creating policies is going to save you a lot of time down the track when you need to modify or troubleshoot your policies.
If you using something like Microsoft 365 Lighthouse to manage multiple tenants, then some additional thought will also need to be invested because if every tenant you manage has identically named policies then when these are rolled up into Microsoft 365 Lighthouse it is going to get confusing.
Although there is no agreed upon standard for naming conventions I’d give you these tips as general guidance:
– Short is better. i.e. ‘HR’ is far better than ‘Human Resources’
– Have the business name as a 3 letter acronym (i.e. ‘ABC’) at the beginning of the policy name if you are using Microsoft 365 Lighthouse
– Avoid special characters like @#$%, etc as well as spaces if you can. Use a ‘-‘ instead of a space and avoid using underscores (‘_’)
– Avoid upper case as well. My experience using the Microsoft Graph is that it can be very case sensitive at times. Having everything in lower case makes it much easier when you come to automating policies and the like with code such as PowerShell.
– Don’t state the obvious like starting every Microsoft Team with the full name of the business or words like ‘Project’. The shorter the name the easier it is to read and display.
– Be mindful of the names used on things like mobile devices
– Remove unnecessary policies to avoid confusion
– Avoid using names like ‘Test’, ‘Temp’, etc. if you do, remove these items when the test is complete to again avoid confusion.
– Try and make it easy for yourself and others in the future to understand and work with the names you have chosen.
The secret is to come up with a naming convention, document it and then use it everywhere. Consistency matters, because in the end it is going to be your time that gets chewed up by trying to work out what randomly named policies actually do. Take some time up front to have a convention and you’ll be rewarded with less pain later on.
I see many people struggle to get started with Intune and Device Management in Microsoft 365. My recommendation is always to start with configuring Compliance policies. Doing so will give you:
1. A device inventory
2. A list of devices that fail to meet the minimum standards set for connection to corporate data
However, the major benefit is that, by default, Intune Compliance Policies make no change to any of the device or impact users productivity. In effect, Compliance Policies simply READ the status of a device and make NO changes.
You’ll find Compliance Policies under Devices in the Intune portal as shown above.
Typically, you’ll create at least one Compliance Policy for each different operating systems you have in your environment (i.e. for Windows, iOS, Android, etc). You can, of course, have as many different Compliance Policies as you desire, potentially targeted at different users and or devices. However, the policies you have, the more maintenance and troubleshooting will be required. It is therefore recommended to stick with a single Compliance Policy for each operating system.
During the policy creation you’ll see a screen as shown above in which you can set actions for devices that fail compliance. You will not that, by default, the only taken is simply to mark the devices as non compliant. That is the only action take. You can add more actions if you want, but importantly, by default, the only action taken is simply to mark devices as non compliant.
Once you have created and assigned the Compliance Policy the machines covered that policy will be evaluated and results reported back to Intune.
If devices are found that are not compliant, then you can take action to make them compliant before allowing them to access corporate data.
Above all, using compliance policies is a great way to get an inventory of all the devices in your environment and report their configuration. Of course, these Compliance Policies will continue to be evaluated regularly in case anything changes on the device.
The recommendation then is to start with Compliance Policies to take an inventory of your device fleet before proceeding further with Device management. If you want to read more about Modern Device Management then read my series of blog posts starting here:
News and updates from the Microsoft Cloud in this episode to bring you up to date. I also take a look at break glass accounts and some best practice recommendations and considerations for you about settings these up[ and ensuring they stay as secure as possible.
You can listen directly to this episode at:
https://ciaops.podbean.com/e/episode-310-breakglass/
Subscribe via iTunes at:
https://itunes.apple.com/au/podcast/ciaops-need-to-know-podcasts/id406891445?mt=2
Don’t forget to give the show a rating as well as send me any feedback or suggestions you may have for the show.
This episode was recorded using Microsoft Teams and produced with Camtasia 2023.
Brought to you by www.ciaopspatron.com
Resources
Microsoft announces new Copilot Copyright Commitment for customers
Results of Major Technical Investigations for Storm-0558 Key Acquisition
Conditional Access Overview and Templates are now Generally Available!
Microsoft 365 Defender Monthly news
Microsoft announces changes to Microsoft 365 and Office 365 to address European competition concerns
Learn the steps needed to protect your data and manage identity
New Microsoft 365 app enhancements to use across your devices
Microsoft Purview Data Loss Prevention: Announcing general availability of several capabilities
Configure Just-in-Time Access to M365 Defender
CIAOPS Techwerks returns to Brisbane CBD on Thursday the 21st of September.
The course is limited to 20 people and you can sign up and reserve your place now! You reserve a place by completing this form:
or by sending me an email (director@ciaops.com) expressing your interest.
The content of these all day face to face workshops is driven by the attendees. That means we cover exactly what people want to see and focus on doing hands on, real world scenarios. Attendees can vote on topics they’d like to see covered prior to the day and we continue to target exactly what the small group of attendees wants to see. Thus, this is an excellent way to get really deep into the technology and have all the questions you’ve been dying to know answered. Typically, the event produces a number of best practice take aways for each attendee. So far, the greatest votes are for deeper dives into the Microsoft Cloud including Microsoft 365, Azure, Intune, Defender for Endpoint, security such as Azure Sentinel and PowerShell configuration and scripts, with a focus on enabling the technology in SMB businesses.
Recent testimonial – “I just wanted to say a big thank you to Robert for the Brisbane Techworks day. It is such a good format with each attendee asking what matters them and the whole interactive nature of the day. So much better than death by PowerPoint.” – Mike H.
The cost to attend is:
Gold Enterprise Patron = Free
Gold Patron = $33 inc GST
Silver Patron = $99 inc GST
Bronze Patron = $176 inc GST
Non Patron = $399 inc GST
I hope to see you there.
CIAOPS 