SMTP to Exchange Online

Posted on by Adam Fowler

SMTP is still needed by certain applications and devices, such as printers, which don’t support Modern Authentication and instead require legacy authentication to talk to a SMTP server.

You are able to use Exchange Online as an SMTP server, but this can be tricky to set up if you’ve hardened your environment by requiring Multi-factor authentication through Security Defaults or Conditional Access.

Microsoft have good documentation on “How to set up a multifunction device or application to send email using Microsoft 365 or Office 365” with the recommended approach to use SMTP, but you may need to poke some security holes through your environment.

Assuming you can get out through your firewalls on port 587 or 25 for SMTP, you’ll need to turn off Azure AD Security Defaults if you have them on. If you do this, understand what you’re turning off and rebuild those same settings in Conditional Access. If you have them off, then you should have Conditional Access policies already.

Personally, I have a ‘Block Legacy Authentication’ conditional access policy which as it says, blocks legacy authentication. For an account I want to send emails from via SMTP, I add it as an exception to this policy.

I then have a second policy ‘Allow Legacy Authentication Internal Only’ which I then target this user at, which still blocks legacy auth unless it’s coming from a trusted IP address. These two rules together then block all users from legacy auth, except the ones on the second policy, and then only if they’re coming from inside my network. The goal of this is to prevent anyone externally using spray attacks against accounts to gain a username and password – although they couldn’t log in anywhere beyond SMTP due to MFA policies, they could still start sending emails that would be from a legitimate email address.

If you have IPs restricted on Exchange Online connectors, that does not appear to affect SMTP auth and you shouldn’t need to add your internal IPs there.

The account you want to use for SMTP sending must have a mailbox license, I use ‘Exchange Online Plan 1’ for one of the cheaper options that is pure mailbox. The SMTP settings are listed here.

You also need to allow SMTP auth across your organisation (not ideal), or on a per account basis (much better security wise, plus it overrides the org default – so you can disable at org level and allow at account level). Microsoft Docs covers this in detail but the command (which requires connecting to Exchange Online via PowerShell first) to allow on a single mailbox is:

Set-CASMailbox -Identity [email protected] -SmtpClientAuthenticationDisabled $false

Once these policies and licenses is in place, you can test. The easiest way I found was a 1 liner PowerShell command. You must use the source mailbox’s account as the from address:

Send-MailMessage –From [email protected] –To [email protected] –Subject "Test Email" –Body "Test SMTP Service from Powershell on Port 587" -SmtpServer smtp.office365.com -UseSsl -Port 587 -credential $madeupvariable

When testing, I found that after changing the Conditional Access rules to let a specific account go through as legacy auth took several minutes. Azure AD logs also take several minutes to show auth attempts, so don’t rush and change too many things at once trying to do this.

Ideally, nobody would be using SMTP – but in the real world we still have to, so the above will at least keep login records in Azure AD, and limit it to trusted IPs, certain accounts, or any other Conditional Access rules you can come up with to reduce the risk of allowing this.

PowerShell Slow to Load and AutoFill

Posted on by Adam Fowler

I had this problem on a server for a while – when first launching PowerShell, it would take ~20 seconds or so to accept input. Also, when pressing tab to auto-complete a command, it would again take ~20 seconds to start, like it was freezing. These were one time problems when launching PowerShell, after that it would work fine until a new session was launched.

A lot of searching didn’t help me work it out, so I logged a Microsoft case. After a few task manager executable dumps, they worked out the delay was on a path I had in an environment variable. Somehow in my account’s user variable, I had a github desktop path that was mapping to a network share, using a PC name that was decommissioned (e.g. ;\\pcname\c$\Users\AdamFowler\AppData\Local\GitHubDesktop\bin.

I expect that this name was timing out, and PowerShell was waiting a while before giving up. In case you have the same symptoms as me, check the environment variables – user variables paths if it’s only your account affected, or the system variables if it’s all users. Click on the path value, then click edit, and remove anything that shoudn’t be there (take a backup of the text if you aren’t sure, it’s easy to put back in if you keep a copy).

To get to Environment Variables, depending on the OS version, get to System Properties, the Advanced tab, and then the Environment Variables button:

Hope that helps someone else with the same problem!

Device Limit Reached – Intune Company Portal App

Posted on by Adam Fowler
Device limit reached – You have added the maximum number of devices allowed by your company support. Plesae remove a device from the Azure portal or get help from your company support.

There’s a limit to the amount of devices you can register for the Intune Company Portal app.

To fix this, yes you’ll need to remove a device attached to your account. This is not done via Outlook for Web, where you can remove devices – that’s purely for Outlook. It’s also not done via https://myaccount.microsoft.com/device-list as it’s not removing it from Azure.

As per Microsoft Documentation , there’s Intune device limits, and Azure device limits. Intune / EndPoint Manager has a maximum of 15 devices, where Azure has a default of 20, but can be changed to a few different values, including ‘unlimited’.

Intune / Endpoint Manager Device Limits
Azure Device Limits

To remove devices from a user, and admin should use Azure Active Directory and go to Users > Find the user > then under Manage, choose ‘Devices’. Any old device (check by the activity date) can be selected and deleted.

After removing enough devices here, you should be able to register the new device via the Intune Company Portal app again – and in my testing, this was next to instant.

Best Practices to Maintain Application Security across Platforms

Posted on by Adam Fowler

Application security is the process of finding and fixing security vulnerabilities in applications for enhancing their security.

With application security, the goal is to prevent code or data within applications from getting hacked or stolen. Though this process was hardly popular a decade ago, application security has become a crucial part of today’s software development lifecycle.

Nowadays, it has become one of the top priorities for businesses, thanks to the ever-changing and ever-growing digital ecosystem.

Also, it has become one of the major challenges for software developers and security professionals since today’s software have become more complex than ever and cybercriminals are continuously improving their efforts and skills to find vulnerabilities and compromise applications.

Why is application security the top priority cybersecurity work for businesses? According to Verizon’s 2020 Data Breach Investigations Report, web applications top the list of hacking vectors used in the popular breaches in 2020.

That is, the report confirms that cybercriminals mostly target applications’ vulnerabilities to compromise an organization’s networks and systems and wreak havoc on their target organization. Moreover, the report predicts that this trend of attackers targeting web application vulnerabilities is not going away anytime soon. S

What made application security so lucrative to attackers?

According to The Increasing Risk to Enterprise Applications by Ponemon Institute, “Investment in application security is not commensurate with the risk. An average of 16 percent of the overall IT budget is dedicated to data protection and security. There is a significant gap between the level of application risk (33 percent of total risk) and what companies are spending to protect their applications (20 percent of annual spending in IT security). However, the level of risk to networks is much lower (18 percent) than the investment in network security (35 percent),” states the report about the investment vs. risk ratio of application security.

That means organizations are not doing enough to mitigate application security risks. The report states that 74 percent of respondents reported that it is difficult to prevent online attacks targeting application vulnerabilities because their organizations are unable to monitor and prevent attacks at the application level, unfortunately. And one of its major reasons is the shift to cloud computing, which resulted in the loss of control and visibility over business-critical apps, as reported by 81 percent of respondents. Moreover, the information technology industry quickly adopted remote working in 2020 due to COVID-19, which left decision-makers with no to little time for performing the security planning.

Nowadays, organizations are not restricted to one cloud provider, but they mostly opt for a multi-cloud architecture for their mission-critical applications.

The reason being this architecture provides better reliability and speed for their applications, however, it hampers its security because of its complexity. Also, the popularity of mobile applications has skyrocketed in recent years, making organizations of all sizes to launch mobile versions of their applications, and thus providing more attack surface to the hackers and increasing the probability of attacks.

How to maintain application security across many platforms?

First of all, organizations must follow application security best practices starting with the industry-leading practices around multi-cloud security. They must synchronize their policies and settings across their cloud setups, use multiple security policies (one per application or service).

Automate as much as possible, choose the right security tools, configure a monitoring strategy to keep track of all cloud setups, opt for efficient compliance tools, simplify security by bringing all controls under a single dashboard, and minimize point security solutions that do not integrate with each other or the all-in-one centralized dashboard.

Secondly, organizations should understand the threats of APIs. They must perform regular security testing of their APIs, monitor third-party applications using their APIs, follow the industry best practices for APIs, add solid support for authentication and authorization, double-secure the data at the backend like databases and data lakes, and opt for security tools and gateways for APIs.

With regular security testing of the codebase as well as third-party applications and libraries, organizations can decrease the chances of attacks on their apps.

Thirdly, organizations must secure their mobile applications from the ground up by writing secure code and encrypting all data on mobile devices.

As with any software, developers must cautiously utilize third-party libraries as open-source libraries can be extremely insecure and vulnerable, providing access to the apps in the hands of attackers, deploy proper authorization and authentication along with session handling, utilize the principle of least privilege, and opt for the best cryptography and security tools and techniques along with regular testing.

Lastly, organizations should understand the risk of bots.

In recent years, hackers have gained unprecedented resources for compromising millions if not billions of devices to perform their bidding. Though web application firewalls may offer crucial security capabilities to detect and prevent complex attacks, they are not enough against bot traffic. That is why businesses must opt for bot management tools to build a robust defense posture against bots and attacks like DDoS.

Microsoft Forms now has a shorten URL option

Posted on by Adam Fowler

Such a basic thing, but great to see. As per this Forms Uservoice suggestion, Microsoft Forms now has a ‘shorten URL’ option. It’s still rolling out right now (March 2021) but it turned up in my tenants. You’ll find it under the Share menu, and then under ‘Send and collect responses’ :

The tick box is called ‘Shorten URL’:

Before ticking this box, the Forms URL for sharing looks like this:

https://forms.office.com/Pages/ResponsePage.aspx?id=gp6jfCyryEOFjHcqjfOQaicaufj5P4hCmrpZg_pruFhUNUFYSUlQMFEwRjVRNkZPUDBLOFYwUUtRVy4u

After ticking the box, it takes about a second or so to update, then looks like this:

The resulting link is of course, shorter. It also looks a lot nicer:

https://forms.office.com/r/Qca3qTjcMu

It’s nice to see a much more usable URL come out of Microsoft Forms, and still on the forms.office.com domain without having to resort to a third party URL shortener service.