Self-service software is knowledge and process management software which contains a range of applications that simplify the way information, process rules and logic are collected, framed within an organised taxonomy,

, , , , , , , , , , , , , ,

Office 365 App Password with MFA | HowTo | 1 of 2

Part One | Part Two

If you’re using Multi-Factor Authentication for your organisation, and want to use applications which connect to your Office 365 account, you will need to create an Office 365 App Password. This is to enable the App to connect to Office 365. For example, if you’re using Outlook 2016 or earlier, Apple Mail App, Skype for Business or any other third party client with Office 365, you’ll need to create an App Password.

Thankfully, creating an Office 365 App Password is really easy to do, if a little hard to find.

Log in to the portal here:

  1. Once logged in, click on the Profile Picture on the top right:

    Office 365 App Password Portal Login Step One

    Office 365 Portal Login Step One

  2. Click on View account:

    Office 365 View Account App Password Step Two

    Office 365 View Account Step Two

  3. Click on Manage Security & Privacy:

    Manage Office 365 App Password Security Privacy Step Three

    Manage Security & Privacy Step Three

  4. Click on Additional security verification:

    Office 365 App Password Security Privacy Step Four

    Additional Security Verification Step Four

  5. Click on Update your phone numbers used for account security:

    Office 365 Update Numbers App Password Step Five

    Update Numbers Step Five

  6. Click on app passwords:

    Office 365 Select App Passwords Step Six

    Select App Passwords Step Six

  7. Click on create:

    Create Office 365 App Password Step Seven

    Create Office 365 App Password Step Seven

  8. Enter a Name in the box, something unique is recommended. I usually name the client application the App Password is associated with. In the example below I have used Apple Mail App. Click next:

    Name Office 365 App Password Step Eight

    Name Office 365 App Password Step Eight

  9. Now either copy by selecting the line, taking care not to pick up any spaces or other characters, or click on copy password to clipboard. You can now use this App Password in your client application, such as Apple Mail App, Thunderbird, iPhone, iPad. Take care as this is the only time you will see Your app password. They cannot be viewed or changed once you click close:

    Copy Office 365 App Password Step Nine

    Copy Office 365 App Password Step Nine

  10. When you Enrolled in Multi-Factor Authentication you were given an initial App Password. I recommend deleting the initial app password, in favour of creating individually named App Passwords. This allows you to ensure each device or client is separate, which is more secure and easier to manage when you want to remove authentication. Click Delete:

    Delete Office 365 App Password Step Ten

    Delete Office 365 App Password Step Ten

  11. Confirm you want to delete the App Password and click Yes:

    Confirm Delete Office 365 App Password Step Eleven

    Confirm Office 365 App Password Step Eleven

  12. The App Password has been successfully deleted. Click close:

    Change Office 365 App Password Step Twelve

    Change Office 365 App Password Step Twelve

  13. Thats it. You now have an App Password for your Apple Mail App. Repeat steps 7, 8 and 9 to create additional App Passwords.

    Review Office 365 App Password Step Thirteen

    Review App Password Step Thirteen

In Part Two, coming soon, I will demonstrate how you can add your App Password to a variety of clients and devices, including Apple Mail App, iPhone, iPad and Outlook 2016.

With over 20 years of experience, Serviceteam IT design and deliver sophisticated connectivitycommunicationcontinuity, and cloud services, for organisations that need to stay connected 24/7. We take the time to fully understand your current challenges, and provide a solution that gives you a clear understanding of what you are purchasing and the benefits it will bring you.

To find out how we can help you, call us on 0121 468 0101use the Contact Us form, or why not drop in and visit us at 49 Frederick Road, Edgbaston, Birmingham, B15 1HN.

We’d love to hear from you!

, , , , , , , , ,

Cyber Security: Office 365 as 802.1X RADIUS Password Authentication

Security is paramount for any business, especially given the rise in cyber attacks, data thefts and major network breaches. I won’t list the major names, as that’s been done, but you can read the Cyber Security Breaches Survey 2016. Much of that research was aimed at larger organisations, even though it’s far easier for enterprise-level companies to secure their resources. But what about the rest of us, Startups, Micro-Businesses and Small to Medium sized organisations?

, , , , , ,

User Password Expiry settings in Office 365 | HowTo

In Office 365 and Exchange Online the simplest and easiest place to change the expiry term for passwords is in the Admin Centre. The expiry term is set at 90 days by default, with a default 14 day notice prior to the expiry. You can also disable password expiry, however as always, this is not recommended.

  1. Select Settings on the left:
    Office 365 Password Expiry Admin Centre
  2. Select Security and privacy. Click Edit password policy on this page:
    Office 365 Password Expiry Settings
  3. Make your changes to expiry time and notification time, or disable expiry entirely. Click Save:
    Office 365 Password Expiry Security & Privacy

And that’s it, all done. There are other ways to change these settings, including via the Azure control panel or using PowerShell with either Office 365 Exchange Online or Azure.

The PowerShell method to set Office 365 and Exchange Online password policy expiry settings is:

Set-MsolPasswordPolicy -DomainName -NotificationDays 14 -ValidityPeriod 90

The PowerShell method to display password expiry policy in Office 365 and Exchange Online:

Get-MsolPasswordPolicy –DomainName


-DomainName: is the domain you wish to manage

-NotificationDays: are the number of days notification prior to expiry

-ValidityPeriod: are the number of days passwords can be valid for

Additional PowerShell methods to set individual user password options can be found in this post.

If you have any questions or need a little more in-depth help please get in touch.

, , , , , , , , , , , , , , , ,

Office 365 SSO Security Guidance: Single sign-on and remote access

Office 365 SSO: The secure configuration of this cloud-hosted service aligns with government’s guidance on implementing the Cloud Security Principles. You can find out more regarding implementation of Federation in order to Restrict Access to Office 365.

1. What is Office 365 SSO (Single Sign-On)?

A Microsoft Online user usually signs in using the username and password associated with their Microsoft account. This process can be simplified with O365 by using Office 365 SSO, which allows a user to log in to O365 using their existing enterprise username and password. Office 365 SSO login may happen automatically, although this depends on how the enterprise and its devices are configured.

Office 365 SSO Single Sign-On

2. Microsoft Office 365 and SSO

O365 can be integrated with an existing on-premise Active Directory (AD) either by:

  • synchronising user credentials to the cloud or
  • implementing SSO using identity federation

Both options require account synchronisation between AD and the cloud, effectively copying user account and group data into Windows Azure Active Directory (Azure AD). Directory synchronisation is an ongoing relationship between the on-premise and cloud directories, implemented using the Directory Sync tool or with Azure AD Connect. Filters can be applied so only specified accounts in named organisational units or with certain user object attributes are synced.

O365 supports the implementation of SSO using identity federation which can be enforced once directory synchronisation is correctly established. In this configuration, the user authenticates to the enterprise instead of signing in to the O365 web app. This means there is no requirement to store enterprise passwords in the cloud, while also supporting multi-factor authentication such as a device identity or smartcard.

3. Synchronisation recommendations

CESG recommends implementing full identity federation rather than synchronising passwords into the cloud. Where possible, authentication should be made directly against the enterprise domain, connecting to it over a VPN when working remotely. This ensures there is no requirement to expose an authentication service directly to the Internet; a direct connection carries additional risk to the enterprise domain.

Enterprises implementing a cloud-first deployment may have already chosen to synchronise enterprise accounts and passwords into the cloud. In this case, an enterprise can take advantage of Azure AD services such as self-service password resets, Windows Azure Multi-Factor Authentication and integration options available with third party web apps adopting Microsoft Identity Manager.

Once user accounts have been synchronised to O365, an administrator will need to assign licenses to those users. While this is not automatically done using Directory Sync or Azure AD Connect, it can be scripted with PowerShell.

4. Office 365 SSO compatibility

Automatic SSO is supported in all O365 services accessed through the O365 portal, as well as Microsoft Office desktop apps installed on domain-joined devices. Office 365 SSO is also available on the Mobile Office platform for devices that support Workplace Join. Users of devices that are either unsupported or not enrolled in the enterprise will be able to log in to O365 using their enterprise username and password, unless O365 is configured to only allow connections from known and trusted devices.

5. SSO implementation requirements

An SSO implementation for O365 currently requires AD with a compatible Security Token Service (STS), also known as an Identity Provider (IdP). Microsoft currently supports Active Directory Federation Service (ADFS), Shibboleth IdP and other tested third party IdPs as an STS. It may be necessary to alter AD and ADFS configurations to meet the requirements defined by user identities and domain naming.

From a user perspective, SSO works by pointing them at an IdP which they authenticate against using a username and password. The browser then passes a security token toO365, allowing the user to log on to the service.

  • For users on a domain-joined or workplace-joined device, this login will be seamless once the device is unlocked.
  • For users on other device types, including those not connected to the enterprise network, they will authenticate against an enterprise authentication proxy using their username and password.

6. Web access

Public cloud services such as O365 are designed to be accessed from any device with an Internet connection. Some enterprises prefer to only allow their information to be accessed from authorised devices, whether these are enterprise managed or personal devices that meet a required security specification.

If you wish to restrict access to enterprise data to a subset of devices, one solution is to implement procedural controls for End User Devices (EUDs) which allow users to only log into O365 from certain devices. This can be achieved either through Mobile Device Management, Intune or through Group Policy with ADFS. Additional policy and security control can be achieved through private VLANs, removing the complexity of managing outbound requests via the Internet from trusted locations, such as fixed office sites or data centre locations.

7. Restricting access to known devices

There is no specific feature in O365 designed to restrict access to the service by network location or device, through mechanisms such as IP range restrictions or forcing user certificate-based authentication. If ADFS is used as an IdP, it may be configured to require that devices come from known IP addresses. However, it is possible to configure SSO so that only devices that are connected to the enterprise network can authenticate, using any IdP:

Office 365 SSO ADFS

With SSO configured as shown above, EUDs can only log in to O365 when they can see the IdP. This ensures that only devices that are connected directly to the enterprise network and those approved to connect using a VPN will be able to log in to O365. Once a user has logged in, the VPN can be dropped since the EUD will maintain the session with a web browser cookie, held until the user logs out. There should be an exception created in the VPN aggregator for managing latency-sensitive applications, such as Lync and Skype, in order to sustain a high level of usability.

SSO can also be configured to work with online IdPs. All approved EUDs should be provisioned with a non-exportable client certificate that identifies the user as a member of the enterprise. This certificate should be hardware-backed on supported devices. TheIdP is required to only accept authentication from devices that have this certificate. The logon could also identify the unique user using the certificate, streamlining the logon.

Permissions can be applied to some data held in O365 so that it is only accessible by certain managed devices, or groups of specified devices. This is enabled primarily for devices enrolled in AD or Azure AD, through the Workplace Join or Domain Join mechanisms.

8. Shared devices

O365 sets non-persistent session cookies once a user has successfully logged in, whether or not SSO is being used. If the SSO implementation provides persistent session management, CESG recommend that users should be advised to manually log out of both O365 and their IdP. This will ensure that the cookie is deleted and in doing so separate user sessions on shared devices. It cannot be assumed that O365 will delete the SSO cookie set by the IdP.

9. References

In addition to the web pages referenced in the list of URLs below, Microsoft provides documentation to support SSO deployments including a troubleshooting guide:

See also CESG’s deployment security considerations for Microsoft Office 365: Administrator Good Practice in addition to documentation on End User Devices Security and Configuration Guidance.

If you have any questions or need a little more in-depth help please get in touch.


, , , , ,

Passwords, encryption and good practice

Passwords should be complex and changed regularly. Encryption should be implemented for any business critical information and especially for any information which is mobile or transported in any fashion. Why then do we still get asked the question “why do we need to change our passwords so often” and “do we have to have such difficult passwords”?

Admittedly a good policy is not to just enforce password changes and complexity, as that only satisfies the need for security without taking in to account the needs of the users, therefore, account lockout policies should not be applied haphazardly. While you increase the probability of preventing unauthorised access to your organisations information, you can also unintentionally lock out authorised users. This can be quite costly for your organization, in loss of productivity and inability to carry out functions which could be brand or perception affecting.

In the age of simplicity and self-service we’re big fans of the ability to synchronise user information, securely of course, using the Azure AD Service. Coupled with an on-site Appliance, which enables self-service password management, information is secure, organisations can easily adopt cloud services, providing employees and partners with an easy single-sign on experience. Most importantly users and administrators are frustration free as users are able to manage their own passwords without intervention. As long as they can remember their security questions!

All of which makes us happy. Our customers are secure from network attack and self-managing. Azure AD Basic is free and we use Nervepoint Technologies, a UK company, for our Self-Service Appliance, which in the non-Enterprise version, is free for unlimited users.