Microsoft has put out a new standard for security defaults in a tenant that harden default settings in the org. Security defaults make it easier to help protect your organization from these attacks with preconfigured security settings:
Requiring all users to register for Azure Multi-Factor Authentication.
Requiring administrators to perform multi-factor authentication.
Blocking legacy authentication protocols.
Requiring users to perform multi-factor authentication when necessary.
Protecting privileged activities like access to the Azure portal.
Now, there might be many reasons why you would not want these defaults enabled in your tenant, just remember that you will need to setup these things manually should you change the security defaults setting.
How to change security defaults in Azure/M365
Log into https://portal.azure.com with your Global Admin account.
Click on Azure Active Directory to navigate to that pane.
In the list to the left, click Properties.
Scroll to the bottom of the screen on the right and click Manage Security Defaults
Make the appropriate change: YES/NO
(IMPORTANT) Save the changes by clicking the Save button
This should set the defaults for your O365 tenant as you wish to have them. Please refer to the references below for more information and detail into each of the security defaults.
MORE POSTS TO COME ON SECURITY AND COMPLIANCE! HAVE A WONDERFUL DAY!
I have a VM that is joined to my Azure AD test tenant domain. I was having issues using RDP to access the box with my Azure AD credentials (email@example.com). I kept getting the following when trying to connect:
So I started researching and found that this was an common issue that many have started to face with their Azure AD Joined machines. Unfortunately, at this time it isn’t quite as easy as “open up a new RDP connection, type in the computer, type my email, and connect”. Here are the steps to connect a session to that Azure AD joined computer.
Steps to connect RDP to an Azure AD joined computer.
First, open remote desktop as if you were going to connect to any other computer. Type in the computer name or IP address and expand the the Show Options section. Next, click the Save As button to save the RDP file to your computer. At this point you can close the Remote Desktop Connection window as it isn’t needed any longer.
Next, open Notepad. Click File -> Open -> location your RDP file that was saved in the previous step.
Go to the very bottom of the list of parameters and add the following two lines:
enablecredsspsupport:i:0 authentication level:i:2
Save the changes to the .rdp file
NOTE: You can also add your username that will be used to connect to the session in the file as well:
As many of you know I have an existing Azure/M365 Tenant that I use with my company as many of you all do as well. When you get an MCT Certification, you get access to a monthly credit in Azure.
So I clicked on Activate and when activating the subscription, it created a new Azure tenant that was linked to my MCP ID and not my LDLNET ID. The problem here was that my Microsoft Identity was a different email address (@live.com) from my tenant Microsoft Identity (@ldlnet.net).
So now I have a new tenant that I really don’t need, so I started thinking, could I transfer the subscription to my LDLNET tenant and keep the monthly credit. The answer is Yes AND No.
Here is what I had to do to transfer the subscription to my LDLNET Directory
First, I created a guest account in my LDLNET tenant for the @live.com email address and then temporarily gave the account Global Admin privileges. This was so that I could access the subscription when transferred and assure that the proper accounts that needed subsequent access to the subscription get what the owner permissions by logging on with the @live.com account in the LDLNET tenant. I then activate the account in LDLNET.
NOTE: This is probably NOT the most secure option to start, but I will update as I find the article’s that define least privilege for setting this up.I’ve seen a couple of articles, but it wasn’t the exact same way. The thing here is that the billing cannot be transferred since it is being handled by Microsoft Directly with the credits. So, I have to keep the @live.com account active in the LDLNET tenant so that it bills correctly.
Next, I go to the setup tenant and look at the subscription Overview:
At the top of the screen, I choose Change Directory. Since my @Live.com account was an admin for the LDLNET Directory now, I could choose the directory on the following screen:
NOTE: I couldn’t change the billing on the setup tenant nor transfer it since it was through Microsoft, but why would I want to anyway since it’s my credit that was given to me monthly. Also, on my visual studio subscription, I made sure that my @ldlnet.net address was an alternate access account on the subscription. I want to make sure the credit stays after this month!!
So, I received the email asking to accept the transfer and clicked Accept The Transfer:
Once the subscription was accepted and transferred to LDLNET, I logged into LDLNET tenant with my @Live.com account. I then went to the subscription and made sure to add all necessary accounts to the subscription so that they would get access:
Once completed, I logged in with my Original Global Admin account and changed the @Live.com account permissions to a Global Reader in my LDLNET tenant, then gave them Owner Access permissions to the Subscription specifically.
And that has completed the transfer. Hopefully, the subscription will continue with the monthly credit as per my MCT Certification allows. I will update if something changes. If you have a better way to do this, please comment and I will be happy to verify it and post!
Microsoft365 allows the tenant administrators to grant external users access to content in their tenant by setting them up as a guest in their M365 Tenant. Microsoft365 provides a guest access feature that you can use to grant content access to contractors, partners or others who need access to certain content.
However, the process of setting up a guest user works differently from that of setting up a normal, licensed user from within your organization.
By default, Microsoft365 Admin Center contains a Guest Users screen. You will also notice, however, that this screen does not contain an option to create a guest user. In fact, the only things that you can do are search for a user or delete a user.
Being that the Guest Users screen doesn’t give you a way to create a guest user, you will need to either delve into PowerShell or perform the task within Azure Active Directory. I prefer using PowerShell, and will write a post about how to perform this via PowerShell, but unless you need to create a large number of guest users, it is usually going to be easier to use the GUI. Below is how to create a guest user via Azure AD.
To create a guest user, expand the Admin Centers container and then click on Azure Active Directory. When the Azure Active Directory Admin Center opens, click on the Users container. You can see that just to the right of the New User option, there is an option to create a New Guest User.
NOTE: Creating a guest user account isn’t like creating a normal user account. Rather than providing the account details and clicking a Create button, you will instead need to send an invitation to the user.
Make Sure You Verify Their E-Mail Address Beforehand!!!
Choose Invite User > Enter the Identity Information
Next Enter A Personal Message (optional) > Choose their Group Membership > Update any AAD or M365 Permissions under Roles > Update their Sign In Settings > Click Invite to send the invitation
When the guest user completes the registration process, they are logged into Microsoft365 however, there are no applications initially available to the user. This is because unlike a standard user, external users do not automatically get access to applications.
If you go back to the Guest Users screen, you will see the newly created guest user listed (you may have to refresh the screen). As previously noted, you can’t do much from this screen. You can, however, click on the user to see a few extra details now. Example is below.
The way that you grant an external user access to data is to add the user to a group that has access to the data. Let’s suppose, for example, that for whatever reason, you need to add an external user to a Teams Group named Microsoft Exchange Guys. To do so, you would go to the Groups folder within the Microsoft 365 Admin Center, click on the Microsoft Exchange Guys group, and then edit the Membership list, as shown below.
After clicking the Edit button, click on Add Members and then select the external user that you wish to add. Click Save to complete the process,
If you now go back to the Group’s membership, you are able to see the Microsoft Exchange Guys group membership showing the new guest user as a member.
Granting access in this way does not provide the external user with blanket access to the Teams Group. However, another group member is now able to e-mail the external user a link to the Teams Group. The external user can use this link to access the Group within the Teams app.
NOTE: Keep in mind that I am only using the Teams Group as an example. You can use somewhat similar techniques to provide access to a variety of Microsoft365 AND Azure AD content.
MORE M365 CONTENT TO COME! POSITIVE ATTITUDE = POSITIVE RESULTS
I’ve been working on installing Windows Server 2019 Core into my network to be able to look at new features for Windows Administration and learning how Server Core works. I was able to install a virtual machine with Server Core and get it activated. I then wanted to place my custom PowerShell script for loading PowerShell into the Server Core Environment.
So, I added the Server Core Server to the Windows Admin Center and copied my custom scripts for PowerShell into the proper directory:
I then logged on remotely to the server and started PowerShell. When I did that, I got this error with the script load:
At first, I tried using the -UseBasicParsing as a switch to see if that would repair the issue in the script. It did not because, IE is not installed by default on the default installation of Server Core. That is so there is less of a footprint that can be attacked by a hacker. I needed this installed though so that the Invoke-WebRequest cmdlet would load my script parameters properly.
I started looking for answers to how to install IE onto the Server Core box and found the following article. I had to run the Add-WindowsCapability cmdlet on the server to install the optional components. When I did, I received an error:
So I found out that there is a block that WSUS does keeping the cmdlet from going to the online source to download the software package and producing this error. After researching, I found this article. I setup a Group Policy to make sure this setting is propagated to my Server Core machine. I also setup in the same policy the ability to turn off the First-Run for IE so that you do not get that message and have to open IE to “set it up”
I then ran a gpupdate /force on the Server and was able to download the components for IE and App Compatibility.
I then rebooted the server and now my PowerShell loads successfully:
I learned a few different new things here and was able to get Server Core working more the way that I like it. I will keep posting updates when I run into issues with this type of installation. I would definitely give the Windows Admin Center a try as it has more robust features than Server Manager has, especially for Server 2019 and Server Core.
CONQUER THE UNCOMFORTABLE TO GROW! POSITIVE ATTITUDE ABIDES!
I was going through my LinkedIn feed as I do daily and found a post with the following document. Great post and document. I wanted to add this here to my blog for reference and to share with all of you!
The document includes the following topics:
Overview Azure Active Directory Identity Protection Azure Advanced Threat Protection Azure Information Protection Office 365 Advanced Threat Protection Office 365 Cloud App Security Microsoft Cloud App Security Office 365 Advanced Data Governance Office 365 Advanced eDiscovery Office 365 Customer Key Office 365 Customer Lockbox Privileged Access Management in Office 365 Data Loss Prevention for Exchange Online, SharePoint Online, and OneDrive for Business Data Loss Prevention for Teams chat and channel conversations Information barriers Advanced Message Encryption