Category Archives: SystemPlus

Webinar: Active Directory Basics

Ας ξεκινήσουμε από τα βασικά του Active Directory στον Windows Server 2019. Αποκτήστε τις βασικές γνώσεις για να μπορέσετε να διαχειριστείτε αποτελεσματικά το εταιρικό σας περιβάλλον.

Ύλη που περιλαμβάνεται:

  • Εγκατάσταση Windows Server 2019 και ρόλος Domain Controller
  • Δημιουργία χρηστών
  • Παρουσίαση και παραμετροποίηση Group Policy Objects

Διάρκεια 2 ώρες

Με την αγορά του σεμιναρίου σας στέλνουμε άμεσα τα στοιχεία πρόσβασης για να παρακολουθήσετε το σεμινάριο στον υπολογιστή σας.

Δείτε το webinar εδώ: https://systemplus.gr/product/active-directory-basics/

Azure AD Password Protection is now generally available

We’ve talked about this Azure AD feature a few months ago, when it was in Public Preview, you can take a look at the article here: https://systemplus.gr/azuread-password-protection-and-smart-lockout-are-now-in-public-preview/

Something that was not so clear and it needs to be, is the fact that it’s not only a cloud solution: it can be used even on on-premises environments, meaning that you can use it on your Domain Controllers. Simply create a banned password list and that’s all! Keep in mind that it’s not only the banned password list that you create the one that is being used: Microsoft has the proper algorithms and their own banned passwords lists that are also used in your password policy.

You should start configuring it by navigating to Azure Active Directory node in the Azure portal and then select Authentication Methods:

image

 

How to protect your on-premises environment

To use Azure AD Password Protection on our Windows Server Active Directory, download the agents from the download center and use the instructions in the Password Protection deployment guide.

Specifically, you need to deploy Azure AD Password Protection in audit mode, just to monitor the impact of your password policy to your users. Later you should change the mode to Enforce.

In a single-forest deployment, the following diagram shows how it works and the various components that you’ll need:

azure-ad-password-protection

 

Read-only domain controllers

Password changes/sets are not processed and persisted on read-only domain controllers (RODCs). They are forwarded to writable domain controllers. So, you don’t have to install the DC Agent software on RODCs.

 

Deployment requirements

  • All domain controllers that get the DC Agent service for Azure AD password protection installed must run Windows Server 2012 or later. This requirement does not imply that the Active Directory domain or forest must also be at Windows Server 2012 domain or forest functional level. There is no minimum DFL or FFL required for either the DC agent or proxy software to run.

  • All machines that get the DC agent service installed must have .NET 4.5 installed.

  • All machines that get the proxy service for Azure AD password protection installed must run Windows Server 2012 R2 or later.

  • All machines where the Azure AD Password Protection Proxy service will be installed must have .NET 4.7 installed. .NET 4.7 should already be installed on a fully updated Windows Server.

  • All machines, including domain controllers, that get Azure AD password protection components installed must have the Universal C Runtime installed. You can get the runtime by making sure you have all updates from Windows Update, see Update for Universal C Runtime in Windows.

  • Network connectivity must exist between at least one domain controller in each domain and at least one server that hosts the proxy service for password protection. This connectivity must allow the domain controller to access RPC endpoint mapper port 135 and the RPC server port on the proxy service. By default, the RPC server port is a dynamic RPC port, but it can be configured to use a static port.

  • All machines that host the proxy service must have network access to the following endpoints:

    Endpoints
    https://login.microsoftonline.com
    https://enterpriseregistration.windows.net

  • All machines that host the proxy service for password protection must be configured to allow outbound TLS 1.2 HTTP traffic.

  • A Global Administrator account to register the proxy service for password protection and forest with Azure AD.

  • An account that has Active Directory domain administrator privileges in the forest root domain to register the Windows Server Active Directory forest with Azure AD.

  • Any Active Directory domain that runs the DC Agent service software must use Distributed File System Replication (DFSR) for SysVol replication.

  • The Key Distribution Service must be enabled on all domain controllers in the domain that run Windows Server 2012. By default, this service is enabled via manual trigger start.

 

(The deployment requirements are just a copy of the official deployment document by Microsoft, just to give you a general idea of the components that you’ll need. There are a lot of additional steps that you need to perform, so I strongly recommend to check the documentation here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy)

 

Thanks for your time!

Azure AD B2C custom policies to build-your-own identity methods is in general availability

A few days ago the Azure AD product group has announced the general availability of the Identity Experience Framework and custom policy support in Azure Active Directory B2C. That really means that you can use your own identity frameworks to use the identity technology of your choice and interoperate with multiple identity providers.

With the release of custom policies in Azure Active Directory B2C you can now customize your identity experience for clients and partners. Do not forget to take a look at this article here: Get started with custom policies in Azure Active Directory B2C

There is also an upcoming webinar that you cannot miss it, Sign up for the webinar on April 18th: Connect more effectively with customers using Azure Active Directory B2C.

There have been many customers and partners that already use today Azure AD B2C and one of them is Subway, a leading restaurant in the US and elsewhere. They managed to migrate their customers seamlessly without changing passwords from an old, identity solution into Azure Active Directory B2C. By upgrading customer identity, Subway customers can connect through their mobile native application and take better advantage of their loyalty program:

subway_mobile_app

 

This new technology is a Microsoft-patented technology called the Identity Experience Framework. Some of the features that are included are:

  • Author and upload your own user identity journey using custom policies.
  • Federate with OpenIDConnect (e.g. Azure Active Directory multitenant, social account providers, two-factor authentication providers).
  • Federate with SAML 2.0 providers (e.g. ADFS, Salesforce, Shibboleth).

identity-experience-framework

The best way to get familiarized is to take a look here Solutions and Training for Azure Active Directory B2C page and start using it today.

 

Thanks for your time!

Azure AD Naming Policy for Office 365 Groups is now available

Another cool Azure AD feature was announced these days: we now have the ability to enforce a Naming Policy for Office 365 Groups. That new Naming Policy feature enables admins to define prefix or suffix conventions that can be automatically appended to group names and create a list of words that are blocked from use in group names. Please keep in mind that you’ll need Azure AD Premium 1 licenses for the users that will belong to these groups, the group creator and the Naming Policy administrator.

One of the obvious things that you can do with a Naming Policy could be to block specific words from being used in group names and aliases, or even create groups having names that declare the function of a group, membership, or even the geographic region that a group belongs.

How it works

You can enforce naming policy for Office 365 groups in two different ways:

  • Prefix-suffix naming policy You can define prefixes or suffixes that are then added automatically to enforce a naming convention on your groups (for example, in the group name “GRP_Athens_Accounting”, GRP_Athens_ is the prefix, and _Accounting is the suffix).

  • Custom blocked words You can upload a set of blocked words specific to your organization to be blocked in groups created by users (for example, “CEO, Payroll, HR”).

 

Install PowerShell cmdlets to configure a naming policy

Make sure to uninstall any older version of the Azure Active Directory PowerShell for Graph Module for Windows PowerShell and install Azure Active Directory PowerShell for Graph – Public Preview Release 2.0.0.137

Then:

  • Open the Windows PowerShell app as an administrator.
  • Uninstall any previous version of AzureADPreview by running: Uninstall-Module AzureADPreview
  • Install the latest version of AzureADPreview by running: Install-Module AzureADPreview
  • Reply Y to the next question and wait for a few minutes to get installed.

 

How to configure the group naming policy for a tenant using Azure AD PowerShell

 

This is an example of how you can import blocked words from a text file that you don’t want them to be used in group names:

$BadWords = Get-Content «C:\work\currentblockedwordslist.txt»

$BadWords = [string]::join(«,», $BadWords)

$Settings = Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq «Group.Unified»}

if ($Settings.Count -eq 0)

{$Template = Get-AzureADDirectorySettingTemplate | Where-Object {$_.DisplayName -eq «Group.Unified»}

$Settings = $Template.CreateDirectorySetting() New-AzureADDirectorySetting -DirectorySetting $Settings

$Settings = Get-AzureADDirectorySetting | Where-Object {$_.DisplayName -eq «Group.Unified»}}

$Settings[«CustomBlockedWordsList»] = $BadWords

$Settings[«EnableMSStandardBlockedWords»] = $True Set-AzureADDirectorySetting -Id $Settings.Id -DirectorySetting $Settings

 

For a full documentation please take a look here: https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/groups-naming-policy

 

Thanks for your time!

You can now collaborate using Azure AD and login with any account

Azure AD B2B Collaboration gives you the ability to collaborate with other organizations and people, even if they do not use Azure AD. The Azure AD Team recently improved the way that an external company can authenticate to your Azure AD using Google IDs. So, even if your external partners use Gmail accounts, you can successfully share to them apps and resources, without asking them to use Microsoft accounts. Actually it is Google the first identity provider that Azure AD supports.

If you want to read more about how GMail accounts are supported, you can take a look at this article.

So today we have another announcement, the ability to use OTPs (one-time passwords) for your external partners, making B2B collaboration really easy with anyone that has an email account.

By using email OTP, anyone who doesn’t have a Microsoft or Google account can access shared resources, without the need to create a new account just for this. They can still use their existing account to login to Azure AD and receive an OTP code via email. This code will be used during the authentication process. And if you really need it, you can integrate and use Conditional Access and MFA.

Let’s take a look at how it works:

OTP 1.png

Since we want the whole process to be really secure, remember that each authenticated session lasts for 24 hours, then you have to re-authenticate using a new OTP code. This means that external users need to verify again that they have access to the email address that they used the first time.

This is what your external users will get when they authenticate:

OTP 2.png

As soon as they receive the OTP code via email, they have to use it:

OTP 3.png

Do you need to know more? Take a look at the official documentation here.

 

Thanks for your time!

New enhancements for Azure AD MFA and Self-Service Password Reset (SSPR)

Good news today! If you really like the increased level of security that Multi-Factor Authentication offers when you use the Azure services, it is now easier than ever to enable MFA and SSPR. Self-service password reset is another great tool that allows the end-user to reset the password easily, without any need to contact an admin. So practically, through a single step-by-step process, the end-user can enable both features through the registration process.

The Azure AD Team received a lot of feedback from customers with the release of the combined registration public preview experience, so it seems that many customers asked that the whole process should be even easier for the end users. Let’s see how it works today.

 

As soon as users are required to register while signing in, they’ll see the following dialog box:

registration experience

When a user completes registration, he will get a result of all the options that they selected:

Picture1

 

But wait, there is more: When you enable the enhanced security info registration experience for your users, they’ll also get the new My Profile experience, now in public preview, which looks like this:

new profile experience

This new experience is great, because from the Security info page, users can easily change their phone number or choose a different default method for MFA:

Picture2

 

But how can you enable these new settings?

  • Sign into the Azure portal as a global administrator or user administrator.
  • Browse to Azure Active Directory > User settings > Manage settings for access panel preview features
  • Under Users you can use the preview features for registering and managing security info – refresh, you can choose to enable for a Selected group of users or for All users:

enhanced security info registration experience.

 

And do not forget to check the official documentation of these features here:

https://docs.microsoft.com/en-us/azure/active-directory/user-help/myprofile-portal-overview

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-registration-mfa-sspr-combined

https://docs.microsoft.com/en-us/azure/active-directory/user-help/user-help-security-info-overview

 

Thanks for your time!

Azure AD B2C now has JavaScript customization and some cool new features!

Today was officially announced by the Azure AD Team that customizing user flows with Azure AD B2C is now easier than ever with more features, including the general availability of a new portal experience and custom password complexity option. And there are some new features in public preview that you should try them today, such as:

  • User templates—Create beautiful authentication experiences using default templates as a starting point for your branded UI.
  • JavaScript and page layout versions—Add more functionality to all your Azure AD B2C pages with your own custom JavaScript.
  • Identity provider access token passthrough—Send the access token from social identity providers back to the application.

 

So let’s take a look at them.

 

New portal experience

Now it’s really easy to create a user flow in Azure B2C. If you want to try the new UI, you should go to the Azure Portal, and then go to the Azure AD B2C extension. Ensure you’re in your B2C directory and select User flows from the left-hand menu:

Azure AD B2C new features 1

 

Custom Password Complexity (really a nice one!)

You can use this feature to lower password requirements or increase the password complexity required to meet your compliance guidelines. Whatever requirement you enforce, you can help your users by having error messages that dynamically change as requirements are met. By default, password complexity is set to Strong for all newly created user flows.

Azure AD B2C new features 2

 

New user templates

You can easily customize what the users will see when they sign in, by creating beautiful sign in and sign up experiences.

Azure AD B2C new features 3

 

JavaScript and Page Layout Versions in Public Preview

Do you want to customize your sign in and sign up experiences using your own JavaScript? It’s now possible!

Azure AD B2C new features 4 v2

 

Identity Provider Access Token Passthrough in Public Preview

When a user signs in using an identity provider, like Facebook, your application can get the identity provider’s access token passed through as part of the Azure AD B2C token. You will be able to use this access token to call the identity provider’s API, such as the Facebook Graph API.

Azure AD B2C new features 5

 

There is a lot of documentation that can be found here:

https://docs.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-password-complexity

https://docs.microsoft.com/en-us/azure/active-directory-b2c/user-flow-javascript-overview

https://docs.microsoft.com/en-us/azure/active-directory-b2c/idp-pass-through-user-flow

 

Thanks for your time!